Repository navigation
ORE v2 (1/n): compatibility vectors + bench baselines - #78
Merged
Merged
Conversation
coderdan
force-pushed
the
feat/ore-v2-test-vectors
branch
from
June 16, 2026 10:02
5b235fb to
6f54805
Compare
6 of 9 tasks
coderdan
force-pushed
the
feat/ore-v2-test-vectors
branch
from
October 8, 2026 08:09
6f54805 to
5b17ce8
Compare
coderdan
marked this pull request as ready for review
October 8, 2026 08:49
There was a problem hiding this comment.
🟡 Changes recommended
The benchmark methodology permits dead-code elimination, and the SIMD plan specifies signed comparisons for unsigned data.
3 open findings
What changed in this PR
Adds compatibility safeguards and performance baselines for the planned ORE v2 refactor.
Changes:
- Pins deterministic bit2 ciphertext and comparison vectors.
- Records current benchmark results.
- Documents the ORE v2 architecture and roadmap.
| File | Description |
|---|---|
packages/ore-rs/tests/compat_vectors/vectors.rs |
Stores pinned ciphertext bytes. |
packages/ore-rs/tests/compat_vectors.rs |
Validates serialization and ordering compatibility. |
docs/plans/2026-06-12-ore-v2-architecture.md |
Defines the v2 design and rollout plan. |
docs/benchmarks/2026-06-13-baseline-main.md |
Records baseline performance measurements. |
🧠 Review effort: Balanced
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
coderdan
force-pushed
the
feat/ore-v2-test-vectors
branch
from
October 8, 2026 09:52
5b17ce8 to
0083985
Compare
coderdan
force-pushed
the
feat/ore-v2-test-vectors
branch
from
October 9, 2026 09:31
0083985 to
bf3b158
Compare
freshtonic
reviewed
Oct 11, 2026
freshtonic
left a comment
freshtonic
left a comment
Contributor
There was a problem hiding this comment.
Security review of this layer. One finding: the compat fixtures do not pin which operand supplies the nonce to the comparator. See the inline comment.
🤖 Generated with Claude Code
Pins serialised ciphertext bytes (left + full via deterministic test RNG) and comparison fixtures for the bit2 scheme, as the byte-identity contract for the v2 refactor. Adds the v2 architecture plan and the criterion baseline numbers on Apple M1 Max. Part of the ORE v2 program (docs/plans/2026-06-12-ore-v2-architecture.md, PR 1).
The ignore reason said tests/vectors/mod.rs; the generator emits tests/compat_vectors/vectors.rs, and the harness shows the reason when listing ignored tests.
The table named vpcmpgtb and cmgt, both signed compares, but permutation entries and x are unsigned bytes: 0xff > 0x01 is false under a signed compare, which would change the indicator mask and break ciphertext compatibility. The shipped kernels are already correct (AVX2 biases both operands by 0x80 before vpcmpgtb; NEON uses vcgtq_u8, i.e. cmhi); the plan now says so.
The helpers returned (), so no result reached Criterion's black_box, and the inputs were literal constants, which lets the optimiser elide work whose result is unused. They now return their results, and the inputs are black-boxed. The baseline machine (M1 Max) is not available, so the baseline doc gets an addendum with a same-machine A/B on an M4: encrypt, compare and serialize move 0-4%, the cost of producing and dropping the result, and are not materially affected; deserialize-8 was under-measured by about 1.8x.
Every unequal pair in FULL_U64 shares one nonce, because each cipher_a() call reseeds the test RNG. The pinned fixtures therefore never checked which operand supplies the hash nonce: reading it from `a` instead of `b` still passed every compat test. FULL_U64_ONE_CIPHER encrypts four values under one cipher, so each has its own nonce. Pairs first differ at block 0, block 3 and block 7, and every ordered pair is checked through compare_raw_slices and the typed Ord. Reading the nonce from `a` now fails the test.
coderdan
force-pushed
the
feat/ore-v2-test-vectors
branch
from
October 12, 2026 01:05
3783446 to
cad46bb
Compare
freshtonic
approved these changes
Oct 12, 2026
freshtonic
left a comment
freshtonic
left a comment
Contributor
There was a problem hiding this comment.
Approved after the round-2 security re-review. The round-1 findings for this PR are fixed or have no remaining blocking items.
🤖 Generated with Claude Code
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
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.
First PR of the ORE v2 program — see
docs/plans/2026-06-12-ore-v2-architecture.md(included in this PR).What
bit2scheme (tests/compat_vectors.rs): exact serialised bytes for left and full ciphertexts under fixed keys, plus comparison fixtures over the pinned bytes. Full ciphertexts are made deterministic via a test RNG whosefrom_entropyis overridden to a fixed seed (the library is already generic over the RNG, so no library changes needed).docs/benchmarks/2026-06-13-baseline-main.md.Why
These vectors are the byte-identity contract for the upcoming core refactor (PR 2): the legacy scheme must keep producing identical bytes because stored ciphertexts in the wild depend on it. The baseline numbers are the reference for the performance PRs (3–5).
Notable baseline observation: per-block encrypt cost is ~47 µs against a sub-µs raw AES floor — the headroom the plan targets is real and large.