[coderdan]

Closes #105.

Problem

OreEncrypt for u128/i128 on OreAes128 has panicked on every call since it was added (ad90f0b): the legacy left-tag input puts the block index at byte N of one AES block, so the scheme takes at most 15 bytes. At 22 six-bit blocks the types do not fit OreAes128Bit6's 14-block packed prefix either. The chained scheme's CMAC accumulator has no length cap, so they go there, as the v2 plan intended (cmac spec §5, architecture doc "not yet in").

Changes

Chained scheme (scheme/chained.rs)

• OreEncrypt<OreAes128Bit6Chained<R>> for u128 and i128. Outputs are ChainedCipherText<22> / ChainedLeft<22> (U128_BLOCKS, I128_BLOCKS): the same bytes as a Var* of that length, with the block count in the type. Their OreOutput::from_slice, TryFrom<Var*> and typed compare_raw_slices / compare_left_to_full accept only that count, so the typed path never orders an integer ciphertext against a string (spec §7 length rejection). The untyped comparators still order them lexicographically.
• encrypt_fixed / encrypt_left_fixed for any FixedOrderableBytes type (the route Decimal can take later), and VarLeft::from_slice.
• Wire vectors for both types pinned in tests/compat_chained_vectors.rs. The existing vectors are byte-identical.

OreEncrypt<T> drops its T: OreCipher bound so the chained scheme (single key, no const N) can implement it. Existing impls and callers are unaffected.

Legacy scheme (scheme/bit2.rs, encrypt.rs)

• The u128/i128 impls are removed. The impl macro asserts ENCODED_LEN <= bit2::MAX_BLOCKS (15) at compile time, so a type too wide for the scheme cannot be given an impl again. Verified: re-adding u128 fails with assertion failed: U128_LEN <= MAX_BLOCKS.
• encrypt / encrypt_left return OreError::TooManyBlocks for N > 15 instead of indexing out of bounds.

Tests per impl. Every OreEncrypt impl macro (legacy, Bit6, chained) now takes $lo, $hi and emits a round-trip, ordering and equality-across-nonces test for the type it implements, so a type cannot be listed as supported without being exercised (the gap the issue identified).

Cost (chained, per docs/benchmarks/2026-06-15-chained-results.md)

	u128 / i128
blocks	22
encrypt	~15 µs (0.69 µs/block)
full ciphertext	570 bytes
left only	378 bytes

Notes for review

• 0u128 and i128::MIN encrypt to identical bytes under one key: the orderable-bytes encodings coincide. The legacy and Bit6 schemes have the same property for 64-bit types. The block count in the type guards against mixing with strings, not against mixing the two 128-bit types; the comparator doc says so. Type-level domain separation is a separate discussion.
• feat(chained): pad strings to a length bucket (powers of two, 16-byte floor) #110 (padding) also edits chained.rs. encrypt_fixed calls the internal encrypt_blocks directly, so it must stay on the unpadded path through that rebase.

Verification

cargo test -p ore-rs --all-features    165 lib + 48 integration + 6 doctests pass
cargo clippy --all-features --all-targets    clean
cargo doc    same 6 pre-existing warnings as main, none in new code

[coderdan]

Rebased onto main (#107 added a rustdoc gate to CI). The module docs on scheme::chained used bare intra-doc links, which rustdoc resolves in the parent module's scope when outer and inner docs are combined; now absolute paths. RUSTDOCFLAGS=-D warnings cargo doc --no-deps --all-features passes locally along with the rest of the CI sequence.

[Copilot]

🟡 Changes recommended

Fixed-value encryptors construct potentially oversized stack encodings before checking the wire-length limit.

2 open findings

• Check encoded length before stack allocation · New
• Document block-count restriction instead of plaintext-type isolation · New

What changed in this PR

Adds working u128/i128 encryption through the chained scheme, addressing #105’s legacy encryption panics.

Changes:

• Adds block-count-typed chained outputs and fixed-value encryptors.
• Removes unsupported legacy implementations and rejects oversized plaintexts.
• Adds per-type tests, pinned wire vectors, and updated documentation.

File	Description
packages/​ore-rs/​tests/​compat_chained_vectors/​vectors.rs	Pins 128-bit integer ciphertext bytes.
packages/​ore-rs/​tests/​compat_chained_vectors.rs	Tests integer vectors, parsing, and comparisons.
packages/​ore-rs/​src/​scheme/​chained.rs	Adds fixed-value encryption and typed outputs.
packages/​ore-rs/​src/​scheme/​bit2.rs	Rejects plaintexts exceeding 15 bytes.
packages/​ore-rs/​src/​scheme/​bit2_w6.rs	Adds per-type tests and updates support documentation.
packages/​ore-rs/​src/​lib.rs	Documents chained support for 128-bit integers.
packages/​ore-rs/​src/​encrypt.rs	Relaxes the trait bound and removes panicking implementations.
packages/​ore-rs/​README.md	Updates supported types and scheme guidance.
packages/​ore-rs/​CHANGELOG.md	Records API additions and legacy fixes.
docs/​plans/​2026-06-12-ore-v2-architecture.md	Updates chained implementation status.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[coderdan]

Rebased onto main after #110 merged (now 730220e). Two decisions in the merge, both in the first commit's message:

• The fixed-length path (encrypt_fixed, the u128/i128 impls) stays unpadded and ignores the cipher's Options: every value of a type has the same length, so there is nothing to hide, and the string ceiling is a cost guard for caller-supplied strings. Its ciphertexts carry the Padding::None tag in feat(chained): pad strings to a length bucket (powers of two, 16-byte floor) #110's 7-byte header.
• ChainedCipherText<N> / ChainedLeft<N> accept only that tag along with the pinned count, so a padded string of 22 blocks is refused by the typed path too (the untyped comparators already refuse it on the policy tag). An unpadded 16-byte string still passes: the count is a length guard, as the docs say.

The u128/i128 vectors are re-pinned for the padded header; the string vectors from #110 are unchanged.

[Copilot]

🟡 Changes recommended

Accepted large arrays can leave plaintext copies outside the stack scrub’s coverage in both fixed-length encryptors.

1 open issue

• Large fixed-array encryption leaves plaintext outside stack scrubbing · New

2 resolved since last review

• Check encoded length before stack allocation
• Document block-count restriction instead of plaintext-type isolation

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The new cryptographic entry points and plaintext-handling paths warrant final human security review.

No open issues 🎉

1 resolved since last review

• Large fixed-array encryption leaves plaintext outside stack scrubbing

_{Review effort: Balanced}

[freshtonic]

I examined the full diff and all earlier feedback. I built the PR head (8712cf3) and ran cargo test -p ore-rs --all-features. All tests pass.

I examined these items:

• The compile-time assert in the legacy impl macro, and the TooManyBlocks return for N > 15 in OreAes128.
• The ChainedCipherText<N> / ChainedLeft<N> parsers, the TryFrom conversions and the typed comparators. They refuse other block counts and padded tags.
• The ordering at the boundaries: 0, 1, -1, u128::MAX, i128::MIN, i128::MAX, through the property tests and the pinned vectors.
• The relaxed OreEncrypt<T> bound. It only removes a requirement, so existing callers still compile.
• to_orderable_bytes against to_fixed_orderable_bytes. The traits are sealed, and the two encodings are the same bytes for every type.

I found no blocking issue. The earlier points (length check before the copy, length guard against type guard, large arrays and the stack scrub) are fixed.

One related point is not in this diff. Please do it in a follow-up PR:

• OreAes128Bit6 still panics on a too-wide PlainText<N> through the public OreCipher::encrypt / encrypt_left. encrypt_blocks and encrypt_left_blocks in bit2_w6.rs (lines 155 and 180) use assert!(N <= MAX_BLOCKS). I tested OreCipher::encrypt(&[0u8; 15]) on OreAes128Bit6ChaCha20 at this head. It panics at bit2_w6.rs:180. This PR changes the same panic in OreAes128 to OreError::TooManyBlocks. Make the 6-bit scheme do the same, so that both schemes behave the same way.

The inline comments are nits (non-blocking). Please do them in a follow-up PR, not in this one.

[coderdan]

Addressed in this PR rather than follow-ups (30ad268 is the new head):

• Bit6 panic (7402a93): OreAes128Bit6::encrypt_blocks / encrypt_left_blocks return OreError::TooManyBlocks for N > MAX_BLOCKS, as OreAes128 does. Test too_many_blocks_is_an_error_not_a_panic covers OreCipher::encrypt(&[0u8; 15]) and the left path.
• Nits (88b46e0): all four inline points.
• No runtime panics in library code (30ad268). Every assert!, debug_assert!, unwrap and expect outside tests and kani proofs is gone:
  • SIMD kernels, the Z2 hashes and the PRP builders take fixed-size arrays rather than asserting slice lengths. Hash::hash_all_into and the scalar packs are generic over block/byte counts, checked equal at compile time.
  • Prp::Mask and RightBitVec::Bits tie the PRP mask to the right block by type.
  • The draw stream is a 512-byte array, so LemireFyPrp::from_stream cannot fail.
  • The wire header count is a u16, with a const check on N.
  • Breaking: RightBlock32::set_bit takes a u8.
• Lint: both crates deny clippy::{panic, unwrap_used, expect_used, unreachable, todo, unimplemented, panic_in_result_fn} outside cfg(test). Clippy cannot lint assert!, so a new CI step (scripts/no-runtime-asserts.py) rejects runtime assertions outside tests and kani; const _: () = assert!(..) stays allowed.
• Checks: wire format unchanged, and every pinned vector passes. Bit6 encrypt and compare and legacy encrypt benchmark the same as before (within noise). Tests pass on aarch64 and x86_64 (debug and release).

#114, #109 and #115 are restacked on top.