Send notes using Addresses instead of keys #8969
Assignees
Labels
C-aztec.nr
Component: Aztec smart contract framework
C-pxe
Component: PXE (Private eXecution Envrionment)
team-fairies
Nico's team
Comments
nventuro
added
C-aztec.nr
sklppy88
added a commit
that referenced
this issue
Oct 25, 2024
… address secret (#9272) Resolves #9326, #8966, #8969 This PR finally implements the new address scheme in encryption and decryption. We encrypt with the address's point, and decrypt with preaddress + ivsk (addressSecret). Some nomenclature before we start: The old address (h in Mike's presentation; hash(partialAddress, publicKeysHash)) -> preAddress The secret corresponding to the address point -> addressSecret The flow generally works by taking a secret, and deriving a valid point from it. We then store the x-coordinate of this point as the address. We do this even though we know that this x-coordinate has two valid y-coordinates (a positive and negative one), but we do not store any information about the sign in the address. Even still, we can support secrets that get computed into a positive and a negative y coordinate. To do this, whenever we recompute the y-coordinate to recover the point from the x-coordinate, we make sure to encrypt to the positive point only. i.e. if we solve for y with x, and we get a negative coordinate, we subtract it from the Field modulus to get a positive one. But if you think "hey, we can't do that, our secret corresponds to a negative y-coordinate", you would be right. In order to address this, we as the owner of the secret, can recompute our full point as we know all of the information that can derive this point. Thus we know what sign our "true" y-coordinate is. In this case, if our y-coordinate is negative, all we need to do is negate our secret (Field modulus minus secret) to derive the secret for point containing the negated negative (and now positive) y-coordinate. You can see that this above process is being done, with the the encryption taking place in `payload.nr`, and that the decryption taking place in `note_processor.ts`. Outstanding work: The interface of `getEvents` in pxe_service should be investigated. With these changes it works... but it's unnecessarily disgusting I think. The interface of the encryption api in `payload.nr` is extremely jank, but this pr is getting pretty big, so it will be handled imminently in #9390. Look through the rest of the tests, think about replacing arbitrary addresses with "valid" ones. Remove any excess code relating to needing the ivpk in both ts and nr Docs and migration notes. As this change is pretty big I think it would be good to go through this also later / with someone on the devrel team to make sure the docs are comprehensively updated. More of this stack doesn't show up on the graphite comment here: <img width="1415" alt="image" src="https://github.com/user-attachments/assets/4570a071-29ad-4148-9e7b-60c2fc978324">
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We will now generate secret keys by combining the ephimeral secret key with the address, not the Ivpk. This means an address is sufficient to send notes to somone:
Sis then used for encryption andEpkis broadcast along with the encrpyed cyphertext. The recipient does:where
handivskhave been defined in #8966.Address validity
In
AztecAddress::to_point()above, we'll go from aField(the x coordinate) to aPoint. However, not all x coordinates are in the curve in the first place. We can prove this by calculatinga = x^3 - 17and then provingsqrt(a)does not exist - @iAmMichaelConnor has a snippet that does this.If the
xcoord is not on the curve, we can simply fail for now. #8970 will handle this.The text was updated successfully, but these errors were encountered: