Repository navigation
OreEncrypt for u128/i128 panics on OreAes128 (never worked, no tests) #105
Description
Bug
OreEncrypt is implemented for u128 and i128 against OreAes128, and the README and crate docs list them as supported, but every encryption panics:
let ore: OreAes128ChaCha20 = OreCipher::init(&k1, &k2).unwrap();
5u128.encrypt(&ore); // panicsthread 'probe' panicked at packages/ore-rs/src/scheme/bit2.rs:200:13:
index out of bounds: the len is 16 but the index is 16
Cause
The legacy scheme writes the block index at byte N of the 16-byte left-tag (PRF₁) input (left.f[n][N] = n as u8). With one block per byte, this limits it to 15 bytes. u128/i128 encode to 16 bytes. encrypt_left fails the same way.
History
- The impls were added in ad90f0b (2026-05-05, "impl OreEncrypt for all primitives via ToOrderableBytes"), so they have never worked on
main. - No test or benchmark encrypts a
u128ori128, which is why nobody noticed. - The ORE v2 stack doesn't support them either. Bit6 (ORE v2 (5/n): 6-bit block scheme + v2 wire format #82) caps at 14 blocks (64-bit types), and the chained scheme (ORE v2 (6/n): chained-prefix variable-length scheme + string encryption #83) takes byte slices and has no
OreEncryptimpl for them.
Options
- Remove the
u128/i128impls (breaking), or make them fail at compile time. - Add typed
u128/i128support on the chained scheme. - At minimum, return an
OreErrorinstead of panicking, and add tests.
#82 already corrects the docs so they no longer recommend OreAes128 for these types.
Activity
coderdan commentedon Oct 12, 2026
Why this was missed, and how to stop it recurring
A coverage or CRAP gate would not have caught this.
complexity² × (1 − coverage)³ + complexity. Theu128/i128impls are one-line, macro-generated functions with complexity 1. Even at 0% coverage they score 2, well below the usual threshold of about 30.OreAes128::encrypt<N>(bit2.rs), which theu64tests already cover line for line. It fails only for one value of a const generic (N = 16), and line and branch coverage don't record which values ofNwere tried.cargo-llvm-cov.The real gap: each type's support is declared in one place (the impl macro invocations) and tested somewhere else, and nothing checks that the two lists match.
Proposed guards (alongside the fix itself):
Nin the legacy scheme. Bit6 already has one:impl_ore_encrypt_bit6!asserts$blocks_const <= MAX_BLOCKS, so an out-of-range type doesn't compile. Adding the equivalentN <= 15check to theOreAes128impls would have stopped theu128impl building on the day it was added (ad90f0b).feat(chained): encrypt u128/i128 on the chained scheme; drop the pani…