fix(aztec-nr): account for AES PKCS#7 padding in message plaintext length by nchamo · Pull Request #20840 · AztecProtocol/aztec-packages

nchamo · 2026-02-25T01:19:58Z

Summary

Fixes index-out-of-bounds when using notes with arrays by accounting for AES PKCS#7 padding expansion (16 bytes) when computing MESSAGE_PLAINTEXT_LEN
Updates MAX_NOTE_PACKED_LEN (9 -> 8) and MAX_EVENT_SERIALIZED_LEN (11 -> 10) in both Noir and TypeScript to match the corrected capacity
Adds boundary tests for max-size and oversized messages, notes, and encryption plaintexts

Fixes F-336
Fixes #20737

…ngth

nchamo · 2026-02-25T01:23:02Z

yarn-project/pxe/src/contract_function_simulator/noir-structs/note_validation_request.test.ts

      '0x0000000000000000000000000000000000000000000000000000000000000000',
      '0x0000000000000000000000000000000000000000000000000000000000000000',
-      '0x0000000000000000000000000000000000000000000000000000000000000000',
-      '0x0000000000000000000000000000000000000000000000000000000000000000', // content end (MAX_NOTE_PACKED_LEN = 10)


The comment was wrong, the value used to be 9

nchamo · 2026-02-25T01:30:21Z

yarn-project/txe/src/rpc_translator.ts

 } from './util/encoding.js';

-const MAX_EVENT_LEN = 12; // This is MAX_MESSAGE_CONTENT_LEN - PRIVATE_EVENT_RESERVED_FIELDS
+const MAX_EVENT_LEN = 10; // This is MAX_MESSAGE_CONTENT_LEN - PRIVATE_EVENT_MSG_PLAINTEXT_RESERVED_FIELDS_LEN


Why MAX_EVENT_LEN in rpc_translator.ts went from 12 to 10

Two corrections are stacked here:

Pre-existing off-by-one: The old value of 12 was MAX_MESSAGE_CONTENT_LEN itself, not MAX_MESSAGE_CONTENT_LEN - PRIVATE_EVENT_MSG_PLAINTEXT_RESERVED_FIELDS_LEN as the comment claimed. The reserved fields subtraction (- 1) was never applied, so the old value should have been 11.

PKCS#7 padding fix (the actual bug fix in this PR): MESSAGE_PLAINTEXT_LEN was computed without accounting for the 16-byte AES PKCS#7 padding block that is always appended when encrypting field-aligned data. Subtracting this reduces MESSAGE_PLAINTEXT_LEN by 1, which propagates down to MAX_MESSAGE_CONTENT_LEN (12 -> 11) and consequently MAX_EVENT_LEN (11 -> 10).

…-zero test data

nventuro

tyvm! the writeup is quite nice

nventuro · 2026-02-26T18:41:25Z

noir-projects/aztec-nr/aztec/src/messages/encryption/aes128.nr

+    /// AES128-CBC encryption for Aztec protocol messages.
+    ///
+    /// ## Overview
+    ///


y u no 120 char

Fixed, reflowed to 120 chars.

nventuro · 2026-02-26T18:50:08Z

noir-projects/aztec-nr/aztec/src/messages/encryption/aes128.nr

        // the output `header_ciphertext_bytes` is 16 bytes larger than the input in this case.
        let header_ciphertext_bytes = aes128_encrypt(header_plaintext, header_iv, header_sym_key);
-        // I recall that converting a slice to an array incurs constraints, so I'll check the length this way instead:
+        // Static check avoids the constraint cost of slice-to-array conversion.


I don't think there are slices anywhere here?

nventuro · 2026-02-26T18:55:39Z

noir-projects/aztec-nr/aztec/src/messages/encoding.nr

+        assert_eq(decoded_content, BoundedVec::from_array(msg_content));
+    }
+
+    #[test(should_fail_with = "Invalid message content: it must have a length of at most MAX_MESSAGE_CONTENT_LEN")]


I am very surprised this is caught by a test. Static asserts trigger compilation errors, not runtime errors, and I thought #[test] would not catch these - I expected nargo test to fail instead. Can you check with the Noir team that this is correct?

nventuro · 2026-02-26T19:22:37Z

noir-projects/aztec-nr/aztec/src/messages/encryption/aes128.nr

    fn encrypt<let PlaintextLen: u32>(
        plaintext: [Field; PlaintextLen],
        recipient: AztecAddress,
    ) -> [Field; MESSAGE_CIPHERTEXT_LEN] {


Should we not statically assert PlaintextLen < MAX_LEN?

Added std::static_assert(PlaintextLen <= MESSAGE_PLAINTEXT_LEN, ...) at the top of encrypt. Also updated the encrypt_oversized_plaintext test to use should_fail_with to match the new message.

nventuro · 2026-02-26T19:25:10Z

noir-projects/aztec-nr/aztec/src/messages/encryption/aes128.nr

        encoding::{
            EPH_PK_SIGN_BYTE_SIZE_IN_BYTES, EPH_PK_X_SIZE_IN_FIELDS, HEADER_CIPHERTEXT_SIZE_IN_BYTES,
-            MESSAGE_CIPHERTEXT_LEN, MESSAGE_PLAINTEXT_LEN,
+            MESSAGE_CIPHERTEXT_LEN, MESSAGE_PLAINTEXT_LEN, MESSAGE_PLAINTEXT_SIZE_IN_BYTES,


It's a bit weird that we take the constant from messages, since the constant itself is derived from AES. But this will make sense later on. It does look a bit odd now though.

Agree, we should refactor it when we start making more changes to this

…sertions

…ngth (#20840) ## Summary - Fixes index-out-of-bounds when using notes with arrays by accounting for AES PKCS#7 padding expansion (16 bytes) when computing `MESSAGE_PLAINTEXT_LEN` - Updates `MAX_NOTE_PACKED_LEN` (9 -> 8) and `MAX_EVENT_SERIALIZED_LEN` (11 -> 10) in both Noir and TypeScript to match the corrected capacity - Adds boundary tests for max-size and oversized messages, notes, and encryption plaintexts Fixes F-336 Fixes #20737

AztecBot · 2026-02-26T20:34:44Z

✅ Successfully backported to backport-to-v4-staging #20923.

BEGIN_COMMIT_OVERRIDE fix(aztec-up): install noir-profiler alongside nargo (#20896) fix(aztec-nr): account for AES PKCS#7 padding in message plaintext length (#20840) END_COMMIT_OVERRIDE

The backport of #20840 (AES PKCS#7 padding fix) changed MAX_NOTE_PACKED_LEN and MAX_EVENT_SERIALIZED_LEN, which alters compiled protocol contracts bytecode and thus the Protocol Contracts tree root hash.

…ngth (#20840) ## Summary - Fixes index-out-of-bounds when using notes with arrays by accounting for AES PKCS#7 padding expansion (16 bytes) when computing `MESSAGE_PLAINTEXT_LEN` - Updates `MAX_NOTE_PACKED_LEN` (9 -> 8) and `MAX_EVENT_SERIALIZED_LEN` (11 -> 10) in both Noir and TypeScript to match the corrected capacity - Adds boundary tests for max-size and oversized messages, notes, and encryption plaintexts Fixes F-336 Fixes #20737

AztecBot · 2026-02-27T23:08:58Z

✅ Successfully backported to backport-to-v4-staging #20980.

PR #20840 changed MAX_EVENT_LEN from 12 to 10 in yarn-project/txe/src/rpc_translator.ts to account for AES PKCS#7 padding, but forgot to update the corresponding Noir constant MAX_EVENT_SERIALIZATION_LENGTH in txe_oracles.nr. This caused the TXE to return 50 fields (10 * 5) while Noir expected 60 fields (12 * 5), crashing emit_and_discover_event test.

## Summary Two fixes: ### 1. Fix `MAX_EVENT_SERIALIZATION_LENGTH` mismatch (fixes backport CI failure) #20840 changed `MAX_EVENT_LEN` from 12 to 10 in `yarn-project/txe/src/rpc_translator.ts` but forgot to update the corresponding Noir constant `MAX_EVENT_SERIALIZATION_LENGTH` in `txe_oracles.nr`. This caused the TXE oracle to return `10 * 5 = 50` fields while the Noir oracle declaration expected `12 * 5 = 60` fields, crashing the `emit_and_discover_event` test. ### 2. Re-enable TXE-dependent noir tests in CI Since Feb 24, all TXE-dependent noir tests (`noir-projects-txe-tests`) have been silently disabled in CI. The `build_and_test` function in `bootstrap.sh` has a guard `if [ -z "${1:-}" ]` that only runs TXE tests when no argument is passed, but CI always calls `build_and_test fast` or `build_and_test full`. This means the TXE tests only ran in local dev (no args) but never in CI. This fix removes the conditional so TXE tests run in all CI modes (ci-fast, ci-full, ci-full-no-test-cache). [ClaudeBox log](http://ci.aztec-labs.com/7a1d8c5993720a62-5)

… CI (#21020) ## Summary Two fixes: ### 1. Fix `MAX_EVENT_SERIALIZATION_LENGTH` mismatch (fixes backport CI failure) #20840 changed `MAX_EVENT_LEN` from 12 to 10 in `yarn-project/txe/src/rpc_translator.ts` but forgot to update the corresponding Noir constant `MAX_EVENT_SERIALIZATION_LENGTH` in `txe_oracles.nr`. This caused the TXE oracle to return `10 * 5 = 50` fields while the Noir oracle declaration expected `12 * 5 = 60` fields, crashing the `emit_and_discover_event` test. ### 2. Re-enable TXE-dependent noir tests in CI Since Feb 24, all TXE-dependent noir tests (`noir-projects-txe-tests`) have been silently disabled in CI. The `build_and_test` function in `bootstrap.sh` has a guard `if [ -z "${1:-}" ]` that only runs TXE tests when no argument is passed, but CI always calls `build_and_test fast` or `build_and_test full`. This means the TXE tests only ran in local dev (no args) but never in CI. This fix removes the conditional so TXE tests run in all CI modes (ci-fast, ci-full, ci-full-no-test-cache). [ClaudeBox log](http://ci.aztec-labs.com/7a1d8c5993720a62-5)

… CI (backport #21020) (#21027) Backport of #21020 to v4. Cherry-pick applied cleanly — no conflicts. ## Summary Two fixes: ### 1. Fix `MAX_EVENT_SERIALIZATION_LENGTH` mismatch PR #20840 changed `MAX_EVENT_LEN` from 12 to 10 in `yarn-project/txe/src/rpc_translator.ts` but forgot to update the corresponding Noir constant `MAX_EVENT_SERIALIZATION_LENGTH` in `txe_oracles.nr`. This caused the TXE oracle to return `10 * 5 = 50` fields while the Noir oracle declaration expected `12 * 5 = 60` fields, crashing the `emit_and_discover_event` test. ### 2. Re-enable TXE-dependent noir tests in CI The `build_and_test` function in `bootstrap.sh` had a guard that only ran TXE tests when no argument was passed, but CI always calls `build_and_test fast` or `build_and_test full`. This fix removes the conditional so TXE tests run in all CI modes. ClaudeBox log: http://ci.aztec-labs.com/ed670f8e16fb711b-1

BEGIN_COMMIT_OVERRIDE fix(aztec-nr): account for AES PKCS#7 padding in message plaintext length (#20840) feat: remove epk sign from message payload (#20926) chore: increase mainnet local ejection threshold to 190k (#20884) feat: add pinned-build support for protocol contracts in noir-contracts (v4) (#20982) fix!: undo bad fix (#20987) chore: backport #20967 to v4 (metric on how many epochs validator has been on committee) (#20989) chore(sequencer): e2e tests for invalid signature recovery in checkpoint attestations (#20971) feat: allow custom addresses to be prefunded with fee juice in local network (backport #21000) (#21004) chore: increase max fee bots use in tests (#20867) END_COMMIT_OVERRIDE

…ngth (#20840)

## Summary Two fixes: ### 1. Fix `MAX_EVENT_SERIALIZATION_LENGTH` mismatch (fixes backport CI failure) #20840 changed `MAX_EVENT_LEN` from 12 to 10 in `yarn-project/txe/src/rpc_translator.ts` but forgot to update the corresponding Noir constant `MAX_EVENT_SERIALIZATION_LENGTH` in `txe_oracles.nr`. This caused the TXE oracle to return `10 * 5 = 50` fields while the Noir oracle declaration expected `12 * 5 = 60` fields, crashing the `emit_and_discover_event` test. ### 2. Re-enable TXE-dependent noir tests in CI Since Feb 24, all TXE-dependent noir tests (`noir-projects-txe-tests`) have been silently disabled in CI. The `build_and_test` function in `bootstrap.sh` has a guard `if [ -z "${1:-}" ]` that only runs TXE tests when no argument is passed, but CI always calls `build_and_test fast` or `build_and_test full`. This means the TXE tests only ran in local dev (no args) but never in CI. This fix removes the conditional so TXE tests run in all CI modes (ci-fast, ci-full, ci-full-no-test-cache). [ClaudeBox log](http://ci.aztec-labs.com/7a1d8c5993720a62-5)

fix(aztec-nr): account for AES PKCS#7 padding in message plaintext le…

31738d4

…ngth

nchamo self-assigned this Feb 25, 2026

nchamo added ci-no-fail-fast Sets NO_FAIL_FAST in the CI so the run is not aborted on the first failure ci-draft Run CI on draft PRs. labels Feb 25, 2026

nchamo commented Feb 25, 2026

View reviewed changes

nchamo added 2 commits February 26, 2026 12:23

fix(aztec-nr): use MESSAGE_PLAINTEXT_SIZE_IN_BYTES in decrypt and non…

f58f9ac

…-zero test data

fix(aztec-nr): add round-trip decode to max-size encode tests

910d466

nchamo marked this pull request as ready for review February 26, 2026 15:50

nchamo requested a review from nventuro as a code owner February 26, 2026 15:50

nventuro approved these changes Feb 26, 2026

View reviewed changes

nventuro linked an issue Feb 26, 2026 that may be closed by this pull request

[BUG] incorrect detection of too-large note #20737

Closed

fix(aztec-nr): address review feedback on encrypt doc comments and as…

9b7cf94

…sertions

nchamo added the backport-to-v4 label Feb 26, 2026

nchamo merged commit 10197f4 into merge-train/fairies Feb 26, 2026
20 checks passed

nchamo deleted the fix/f-336-review-fixes branch February 26, 2026 20:33

AztecBot mentioned this pull request Feb 26, 2026

feat: merge-train/fairies #20907

Merged

AztecBot mentioned this pull request Feb 26, 2026

chore: Accumulated backports to v4 #20923

Merged

AztecBot mentioned this pull request Feb 27, 2026

fix: update Protocol Contracts tree root for v4 backport #20931

Closed

nchamo mentioned this pull request Feb 27, 2026

fix(pxe): backward & forward compatible deserialization of validation requests #20957

Closed

AztecBot mentioned this pull request Feb 27, 2026

chore: Accumulated backports to v4 #20980

Merged

AztecBot mentioned this pull request Mar 2, 2026

fix: update MAX_EVENT_SERIALIZATION_LENGTH and re-enable TXE tests in CI #21020

Merged

AztecBot mentioned this pull request Mar 3, 2026

fix: update MAX_EVENT_SERIALIZATION_LENGTH and re-enable TXE tests in CI (backport #21020) #21027

Merged

AztecBot mentioned this pull request Mar 3, 2026

chore(v4): release 4.1.1 #20979

Open

johnathan79717 pushed a commit that referenced this pull request Mar 4, 2026

fix(aztec-nr): account for AES PKCS#7 padding in message plaintext le…

80d0dc2

…ngth (#20840)

nchamo mentioned this pull request Mar 5, 2026

feat(pxe)!: pass BoundedVec sizes as oracle params #21176

Merged

Conversation

nchamo commented Feb 25, 2026 • edited by nventuro Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nventuro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

AztecBot commented Feb 26, 2026

Uh oh!

AztecBot commented Feb 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

nchamo commented Feb 25, 2026 •

edited by nventuro

Loading