fix(aztec-nr): reject infinity ephemeral key in message encryption - #24665
Merged
nventuro merged 1 commit intoJul 14, 2026
Conversation
nchamo
added
ci-draft
nchamo
marked this pull request as ready for review
July 13, 2026 20:25
nventuro
approved these changes
Jul 14, 2026
Comment on lines
+42
to
43
| assert(!eph_pk.is_infinite(), "Ephemeral public key is the point at infinity"); | ||
| assert(get_sign_of_point(eph_pk), "Got an ephemeral public key with a negative y coordinate"); |
Contributor
There was a problem hiding this comment.
If infinite points will be more generally disallowed, perhaps we should eventually make fns like get_sign_of_point reject them.
Contributor
There was a problem hiding this comment.
We could also validate as part of a type, thus making no infinite points an invariant of working with that type.
nventuro
deleted the
nchamo/f-799-aztec-packages-zeroinfinity-ephemeral-key-accepted-in
branch
July 14, 2026 02:53
PhilWindle
pushed a commit
that referenced
this pull request
Jul 21, 2026
…24665) ## Problem When encrypting a message, the ephemeral secret key comes from an unconstrained routine, so a malicious sender can substitute any value while proving. Substituting `eph_sk = 0` yields the point at infinity as the ephemeral public key, which passed the y-sign check: its y-coordinate is 0, which counts as positive. Its x-coordinate (0) is then broadcast, but 0 is not a valid x-coordinate on the curve, so the recipient can never reconstruct the key and the message is permanently undecryptable. This breaks the constrained-delivery guarantee that a note delivered by an untrusted sender remains decryptable by the recipient. ## Fix `generate_positive_ephemeral_key_pair` now asserts the ephemeral public key is not the point at infinity, alongside the existing sign check. A test emulates the substitution by mocking the randomness oracle to return 0. Fixes F-799 (cherry picked from commit 47c30a1)
PhilWindle
pushed a commit
that referenced
this pull request
Jul 21, 2026
…24665) ## Problem When encrypting a message, the ephemeral secret key comes from an unconstrained routine, so a malicious sender can substitute any value while proving. Substituting `eph_sk = 0` yields the point at infinity as the ephemeral public key, which passed the y-sign check: its y-coordinate is 0, which counts as positive. Its x-coordinate (0) is then broadcast, but 0 is not a valid x-coordinate on the curve, so the recipient can never reconstruct the key and the message is permanently undecryptable. This breaks the constrained-delivery guarantee that a note delivered by an untrusted sender remains decryptable by the recipient. ## Fix `generate_positive_ephemeral_key_pair` now asserts the ephemeral public key is not the point at infinity, alongside the existing sign check. A test emulates the substitution by mocking the randomness oracle to return 0. Fixes F-799 (cherry picked from commit 47c30a1)
6 tasks
rangozd
pushed a commit
to rangozd/aztec-packages
that referenced
this pull request
Aug 5, 2026
…ztecProtocol#24665) ## Problem When encrypting a message, the ephemeral secret key comes from an unconstrained routine, so a malicious sender can substitute any value while proving. Substituting `eph_sk = 0` yields the point at infinity as the ephemeral public key, which passed the y-sign check: its y-coordinate is 0, which counts as positive. Its x-coordinate (0) is then broadcast, but 0 is not a valid x-coordinate on the curve, so the recipient can never reconstruct the key and the message is permanently undecryptable. This breaks the constrained-delivery guarantee that a note delivered by an untrusted sender remains decryptable by the recipient. ## Fix `generate_positive_ephemeral_key_pair` now asserts the ephemeral public key is not the point at infinity, alongside the existing sign check. A test emulates the substitution by mocking the randomness oracle to return 0. Fixes F-799 (cherry picked from commit 47c30a1)
rangozd
pushed a commit
to rangozd/aztec-packages
that referenced
this pull request
Aug 5, 2026
…ztecProtocol#24931) Forward-ports the **noir / aztec-nr / contracts** slice of the v5-next → next backlog (work merged to `v5-next` after the ~2026-07-08 cut that reshaped `next`). ## Applied (clean cherry-picks, chronological) - fix: prevent reception of messages too far into the future (AztecProtocol#24645) - fix(aztec-nr): reject infinity ephemeral key in message encryption (AztecProtocol#24665) - fix(aztec-nr): tolerate malformed partial-note completion logs (AztecProtocol#24668) - docs(aztec-nr): document partial note completion trust model (AztecProtocol#24816) - refactor(aztec-nr): shared no-op sync handler for stateless contracts (AztecProtocol#24844) - fix: dont panic on note msgs on contracts with no notes (AztecProtocol#24852) - docs(noir-contracts): document standard-contract re-pin consequences (AztecProtocol#24890) ##⚠️ Needs owner conflict-resolution (conflict against reshaped `next`; not included here) Cherry-pick onto this branch and resolve: - [ ] `git cherry-pick -x 9f1167e` — feat!: make inbox secrets be multiple fields (AztecProtocol#24599) - [ ] `git cherry-pick -x 4490597` — fix(aztec-nr): prevent recipient forging a colliding handshake (AztecProtocol#24403) - [ ] `git cherry-pick -x 8b1903c` — feat!: forbid external note validation checks (AztecProtocol#24644) - [ ] `git cherry-pick -x 10e339a` — fix(aztec-nr)!: compute note property selectors from the packed layout (AztecProtocol#24689) - [ ] `git cherry-pick -x 15c7a1e` — chore: clarify scope of packable impl detection (AztecProtocol#24820) - [ ] `git cherry-pick -x f66808c` — fix: change init and single claim nullif to incl owner address, add testing utilities (AztecProtocol#24892) Part of the manual v5-next → next backlog sweep. Draft until conflicts are resolved and CI is green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When encrypting a message, the ephemeral secret key comes from an unconstrained routine, so a malicious sender can substitute any value while proving. Substituting
eph_sk = 0yields the point at infinity as the ephemeral public key, which passed the y-sign check: its y-coordinate is 0, which counts as positive. Its x-coordinate (0) is then broadcast, but 0 is not a valid x-coordinate on the curve, so the recipient can never reconstruct the key and the message is permanently undecryptable. This breaks the constrained-delivery guarantee that a note delivered by an untrusted sender remains decryptable by the recipient.Fix
generate_positive_ephemeral_key_pairnow asserts the ephemeral public key is not the point at infinity, alongside the existing sign check. A test emulates the substitution by mocking the randomness oracle to return 0.Fixes F-799