ORE v2 (2/n): core refactor — width abstraction, seed/tag separation, template RO keys#79
Draft
coderdan wants to merge 1 commit into
Draft
ORE v2 (2/n): core refactor — width abstraction, seed/tag separation, template RO keys#79coderdan wants to merge 1 commit into
coderdan wants to merge 1 commit into
Conversation
coderdan
force-pushed
the
feat/ore-v2-core-refactor
branch
from
ab17b5a to
7170514
Compare
Introduces the ORE v2 core abstractions (plan §1) with byte-identical output, verified by the PR 1 compatibility vectors: - BlockWidth trait (Bit8 today; Bit6 arrives with its scheme) carrying the domain-sized types stable Rust can't express const-generically. - 6-bit MSB-first block decomposition with order-preservation property tests, ahead of the scheme that consumes it. - PRP seeds (PRF2 outputs, key-equivalent material) now live in a dedicated zeroize-on-drop SeedBuf, never in the serialisable Left; tag inputs are built directly into Left.f. - RO keys maintained as an incrementally-updated template plus a work buffer for the in-place PRF/hash passes (3 byte-writes per entry per block instead of a full rebuild), both zeroized after use. - Indicator encoding extracted behind encode_right_block (naive form retained; bulk form lands in the next PR). Drops the now-unused lazy_static dependency. Part of the ORE v2 program (docs/plans/2026-06-12-ore-v2-architecture.md, PR 2).
coderdan
force-pushed
the
feat/ore-v2-test-vectors
branch
from
5b235fb to
6f54805
Compare
coderdan
force-pushed
the
feat/ore-v2-core-refactor
branch
from
7170514 to
220c498
Compare
coderdan
commented
Jun 16, 2026
| let mut seeds = [AesBlock::default(); N]; | ||
| for (n, block) in seeds.iter_mut().enumerate() { | ||
| block[0..n].clone_from_slice(&x[0..n]); | ||
| // TODO (tracked in v2 plan, fixed for new schemes by the §5(b) |
Contributor
Author
There was a problem hiding this comment.
We should link to the relevant PR
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
1 participant
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.
Stacked on #78. Plan §1 (
docs/plans/2026-06-12-ore-v2-architecture.md).What
BlockWidthtrait (scheme/width.rs): sealed trait carryingBITS/DOMAINand the domain-sized associated types (RightBlock,Prp,RoKeyBuf) that stable Rust can't express const-generically.Bit8is the only width today;Bit6arrives with its scheme (PR 5).scheme/decompose.rs): MSB-first bit-packing with quickcheck properties for order preservation, domain bounds, and injectivity — landed ahead of the scheme that consumes it so the packing is independently pinned.SeedBufand never touch the serialisableLeft. Previously the only thing separating seeds from published tags was statement ordering insideencrypt.lazy_staticblock each iteration; a work buffer takes the in-place PRF/hash passes. Both zeroized after use.lazy_staticdependency dropped.encode_right_block: the naive per-bit indicator loop extracted behind a width-generic function — deliberately not optimized here (risk staging); the permutation-direct bulk form is PR 3.Byte identity
All 12 compatibility vector tests from #78 pass unchanged — the AES input bytes are identical to before; only buffer management moved.
Note for review
OreCipher's public shape is unchanged in this PR; the associated-type change flagged in the plan lands with the Bit6 scheme instead, keeping this diff purely internal.