Conversation
…bution + parameter_file_sha algo Three substantive Codex post-merge findings on PR #268: P0 (line 275) — issuance_epoch bound into h_r: The earlier issuance-epoch deprecation gate referred to a 'claimed issuance epoch' that wasn't actually defined as a receipt field. Without binding it into h_r, an attacker could forge a receipt under a deprecated hash_version and put the claimed epoch BEFORE the deprecation cutoff to slip past the gate. Fix: add issuance_epoch as a 10th hash-input field (u64-be milliseconds since Unix epoch), bound into h_r. Field count v0: 10 (was 9). Hash input set diagram updated. P1 (line 126) — Amara attribution accuracy: Earlier line said Amara's 7th-ferry proposal had approval_set_commitment, but the original was approval_set (raw) — Aminata's side-channel finding is what motivated the v0 swap to approval_set_commitment. Updated attribution to say 'approval_set [raw, replaced by approval_set_commitment in v0 per Aminata's side-channel finding — same slot, different binding]'. P1 (line 166) — parameter_file_sha name vs BLAKE3 algorithm: Field name implies SHA-family but the canonical encoding specifies BLAKE3-256. Added clarification: the '_sha' suffix is legacy Otto-91 naming (where '_sha' meant 'hash digest' in that context); the actual algorithm bound by hash_version = 0x01 is BLAKE3-256. Future schemes may pick different digest algorithms via the hash_version registry; the field name stays for Otto-91-prose compatibility.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 553fdf00e8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Pull request overview
Updates the BLAKE3 receipt-hashing v0 design writeup to incorporate post-merge review findings from #268, tightening the specified hash inputs and clarifying naming/attribution to better support downstream lucent-ksk ADR work.
Changes:
- Adds
issuance_epochas an explicit hash input and defines its canonical encoding. - Clarifies that
parameter_file_shais legacy naming and thathash_version = 0x01binds BLAKE3-256 (not SHA-256). - Adjusts the Amara/Aminata attribution around
approval_set→approval_set_commitmentand updates field-count references to 10.
Codex P2: the changes-from-Amara list at line 199 enumerated '1. hash_version, 2. parameter_file_sha, 3. approval_set → commitment' but didn't include the issuance_epoch addition. Added as #3, renumbered approval_set replacement to #4. Now the changes-list matches the v0 hash-input definition (10 fields = 7 base with approval_set→commitment swap + 3 v0 additions: hash_version + parameter_file_sha + issuance_epoch).
…kdating limitation note Two substantive Codex post-merge findings on PR #431: P1 (line 183) — forward-pointer for parameter_file_sha: The field name implies SHA-256 binding via the early Otto-91 quote; the legacy-naming clarification appears later in the canonical-encoding section. Readers may miss it. Added an inline parenthetical at the field's first introduction (line 126-130 area) noting the legacy-naming + actual-algorithm distinction, with a 'details below' pointer. P1 (line 130) — backdating limitation: Binding issuance_epoch into h_r prevents POST-signature mutation only — it does NOT prevent a compromised signer or coerced agent from setting issuance_epoch BEFORE the deprecation cutoff at receipt-creation time. Added an explicit 'Backdating limitation' section listing three mitigations (RFC 3161 TSA / Aurora-anchored chained timestamps / forward-only highest-epoch registry), with v0 explicitly documenting the gap as known and deferring the specific countermeasure to the lucent-ksk ADR.
There was a problem hiding this comment.
Pull request overview
Follow-up update to the BLAKE3 receipt-hashing v0 design-input document to incorporate post-#268 review findings, clarifying hash inputs and field semantics for the future lucent-ksk ADR.
Changes:
- Adds
issuance_epochas an explicit hash-input field and documents the backdating limitation plus mitigations. - Clarifies that Amara’s original proposal used raw
approval_set, with v0 switching toapproval_set_commitmentper side-channel concerns. - Clarifies that
parameter_file_shais legacy naming and the v0 algorithm is BLAKE3-256 (not SHA-256).
| (`u64-be`), milliseconds since Unix epoch. Bound into | ||
| `h_r` so the verifier-side issuance-epoch deprecation | ||
| gate (req #2) cannot be circumvented by post-facto | ||
| rewriting the claimed epoch on a forged receipt. |
| ### Hash input set (10 fields) | ||
|
|
||
| ```text | ||
| h_r = BLAKE3( |
3 tasks
AceHack
added a commit
that referenced
this pull request
Apr 25, 2026
…w-up) (#462) Otto-268 follow-on: drain-log for the 3-finding cascade PR #431 (post-merge follow-up to #268 BLAKE3 receipt-hashing v0 design). Captures three substantive cryptographic-protocol design improvements: 1. `issuance_epoch` field added (8 → 9 → 10 field-count evolution across review waves; cross-epoch replay resistance during protocol upgrades). Backdating-limitation section also got 3 mitigations (RFC 3161 TSA / Aurora-anchored chained timestamps / forward-only registry). 2. Per-design-element attribution preservation (Amara's original vs Otto's refinement vs joint synthesis with Aaron's directive). 3rd observation of the verbatim-vs-annotation pattern (#235 + #430 + #431). 3. `parameter_file_sha` algorithm specification: BLAKE3 default; `hash_version` field determines algorithm for forward- compatibility. Same algorithm-agility-via-version-field pattern. Per Otto-250 training-signal discipline. Pattern observations: - Cryptographic-protocol design iterates through fields (8 → 9 → 10) across review waves. Each addition fixes a specific adversary class. - Algorithm-agility-via-version-field is the standard pattern (`hash_version`, `*_key_version`, `parameter_file_sha`-tied-to- `hash_version`). - Per-design-element attribution preservation is a recurring class (now 3 observations: #235 / #430 / #431). - Codex functioning as cryptographic-design reviewer is a high- value capability surface.
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.
Codex post-merge review on #268 surfaced 4 substantive findings on the BLAKE3 receipt-hashing v0 design. Addressed in this follow-up.