DateKeys

Commit Graph

Author	SHA1	Message	Date
dev	f24a280c28	Implement capsule format 2 of spec v0.9 The reference moves to the DateKeys Protocol Specification v0.9, approved by its author on 29 September 2026. Encrypt writes capsule format 2 only; Open and Inspect read formats 1 and 2, and a format 1 capsule keeps the verdict v0.8.2 gave it. Format 2 (spec §22, §29.1, §31, §39): - VERSION in the PRELUDE is the capsule format, capsule.Format; any other value is ERR_UNSUPPORTED_VERSION at step 2. - CONTROL_CBOR has the schema version of its format. Version 2 adds key 6, payload_length (8 bytes, big-endian, at most L_MAX = 2^53 - 2^46), and key 7, padding (1 bloque256, 2 reforzado); it is 103 bytes without extensions, whatever L. - The payload is the content padded with zeros to P = rule(L). Step 17 checks the length and the zeros, and Open writes only the first L bytes. - INNER_ACCESS_AGE holds exactly 16 X25519 stanzas: 1 to 16 credentials, and a dummy in each slot left, in a uniformly random order. Writer rules (spec §62.1): EncryptOptions.Length is required and the source must deliver exactly that many bytes; recipients that are not canonical or of low order are rejected (agewrap.CheckX25519Recipient); self-checks of the header, the control, INNER_ACCESS_AGE and PAYLOAD_AGE. The CLI measures its input, takes -padding and reports the format. Test data: seven format 2 fixtures, padding vectors checked against math/big, format 2 CBOR vectors, and the mutation corpus in both formats with the 22 cases of the third list of spec §64, built without randomness by sealing the fixtures again with their known keys and nonces. The format 1 fixtures are kept byte for byte and never regenerated; the differential corpus keeps its 1825 cases and adds a block per format 2 fixture. The spec copy loses its "to be implemented" markers, and the READMEs, CHANGELOG, traceability and testdata/README.md follow v0.9. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 week ago
dev	4a025d10fb	Spec v0.9 draft: apply the 22 corrections of the final review The final review of the draft found 22 problems, and none had been applied yet. All of them are applied now, together with four places that repeated them (§62.1 rules 1 and 4, §76 changes 4 and 10). - §29.1, §76 change 4: 32-bit arithmetic first gives a wrong P at L = 2 113 929 217 with signed operators and at L = 4 227 858 433 with >>> 0, not at 2^32 + 1. The vector table gains a row for each, checked against a BigInt Padme. Above 2^32, Padme exceeds bloque256 except at L_MAX. The Node log2 error changes E and lastBits, not P or S. - §56, §76 change 4: a reader MUST NOT present the content as valid before step 17 ends; a streaming reader MUST NOT write the padding and MUST signal the step 17 error so that what it wrote is discarded. The author chose this over the stricter rule, which forbade delivering any byte before step 17 and so the streaming Open(dst) of the reference. - §64: the 15 and 17 stanza mutations recalculate the PRELUDE and header_binding; every time_and_key mutation offers the identity, because any change breaks the capsule_digest of a .dkk; the duplicate recipient mutation names its identity. Three new mutations cover the shape of payload_length (7 or 9 bytes, a CBOR integer); the format 2 cbor.json vectors of §76 list them too. - §39, §62.1 rule 4: the official test vectors may show which slots are dummies. §70, §62.1 rule 1: the format 2 rule binds implementations that write capsules, and a test vector generator MAY write format 1. - §62 step 8 gets the 64 MiB limit of §61 step 6. - Accuracy: §22 (an older reader detects a new padding code only after the network request; the .dkk schema is §41), §37 and §76 change 10 (the §63 rules do not detect those recipients), §55.2 (the writer knows the number of parties; relays are §48), §76 changes 1 and 8. - Wording: §62.1 rules 7 and 11, §63 step 4, §76 change 11, the field names in the CDDL comments, and a v0.9 entry in spec/README.md. go test ./... passes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 week ago
dev	1189f2f37b	Spec v0.9 draft, work in progress (not approved) Draft decided by the author on 29-09-2026: format 2 with exactly 16 X25519 stanzas in INNER_ACCESS_AGE (dummies, shuffled), payload padding (code 1 bloque256, code 2 reforzado = max(bloque256, Padme)) with L and the code in CONTROL_CBOR v2, VERSION 2 so v0.8.2 readers reject early, a privacy section (§55.2) and writer rules (§62.1). The CDDL holds the draft schemas. The fixes from the final review were being applied when work stopped: they may be partial. See App/docs/HANDOFF.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	1 week ago

Author

SHA1

Message

Date

dev

f24a280c28

Implement capsule format 2 of spec v0.9

The reference moves to the DateKeys Protocol Specification v0.9, approved
by its author on 29 September 2026. Encrypt writes capsule format 2 only;
Open and Inspect read formats 1 and 2, and a format 1 capsule keeps the
verdict v0.8.2 gave it.

Format 2 (spec §22, §29.1, §31, §39):
- VERSION in the PRELUDE is the capsule format, capsule.Format; any other
  value is ERR_UNSUPPORTED_VERSION at step 2.
- CONTROL_CBOR has the schema version of its format. Version 2 adds key 6,
  payload_length (8 bytes, big-endian, at most L_MAX = 2^53 - 2^46), and
  key 7, padding (1 bloque256, 2 reforzado); it is 103 bytes without
  extensions, whatever L.
- The payload is the content padded with zeros to P = rule(L). Step 17
  checks the length and the zeros, and Open writes only the first L bytes.
- INNER_ACCESS_AGE holds exactly 16 X25519 stanzas: 1 to 16 credentials,
  and a dummy in each slot left, in a uniformly random order.

Writer rules (spec §62.1): EncryptOptions.Length is required and the
source must deliver exactly that many bytes; recipients that are not
canonical or of low order are rejected (agewrap.CheckX25519Recipient);
self-checks of the header, the control, INNER_ACCESS_AGE and PAYLOAD_AGE.
The CLI measures its input, takes -padding and reports the format.

Test data: seven format 2 fixtures, padding vectors checked against
math/big, format 2 CBOR vectors, and the mutation corpus in both formats
with the 22 cases of the third list of spec §64, built without randomness
by sealing the fixtures again with their known keys and nonces. The
format 1 fixtures are kept byte for byte and never regenerated; the
differential corpus keeps its 1825 cases and adds a block per format 2
fixture. The spec copy loses its "to be implemented" markers, and the
READMEs, CHANGELOG, traceability and testdata/README.md follow v0.9.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dev

4a025d10fb

Spec v0.9 draft: apply the 22 corrections of the final review

The final review of the draft found 22 problems, and none had been applied
yet. All of them are applied now, together with four places that repeated
them (§62.1 rules 1 and 4, §76 changes 4 and 10).

- §29.1, §76 change 4: 32-bit arithmetic first gives a wrong P at
  L = 2 113 929 217 with signed operators and at L = 4 227 858 433 with
  >>> 0, not at 2^32 + 1. The vector table gains a row for each, checked
  against a BigInt Padme. Above 2^32, Padme exceeds bloque256 except at
  L_MAX. The Node log2 error changes E and lastBits, not P or S.
- §56, §76 change 4: a reader MUST NOT present the content as valid before
  step 17 ends; a streaming reader MUST NOT write the padding and MUST
  signal the step 17 error so that what it wrote is discarded. The author
  chose this over the stricter rule, which forbade delivering any byte
  before step 17 and so the streaming Open(dst) of the reference.
- §64: the 15 and 17 stanza mutations recalculate the PRELUDE and
  header_binding; every time_and_key mutation offers the identity, because
  any change breaks the capsule_digest of a .dkk; the duplicate recipient
  mutation names its identity. Three new mutations cover the shape of
  payload_length (7 or 9 bytes, a CBOR integer); the format 2 cbor.json
  vectors of §76 list them too.
- §39, §62.1 rule 4: the official test vectors may show which slots are
  dummies. §70, §62.1 rule 1: the format 2 rule binds implementations that
  write capsules, and a test vector generator MAY write format 1.
- §62 step 8 gets the 64 MiB limit of §61 step 6.
- Accuracy: §22 (an older reader detects a new padding code only after the
  network request; the .dkk schema is §41), §37 and §76 change 10 (the §63
  rules do not detect those recipients), §55.2 (the writer knows the number
  of parties; relays are §48), §76 changes 1 and 8.
- Wording: §62.1 rules 7 and 11, §63 step 4, §76 change 11, the field names
  in the CDDL comments, and a v0.9 entry in spec/README.md.

go test ./... passes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dev

1189f2f37b

Spec v0.9 draft, work in progress (not approved)

Draft decided by the author on 29-09-2026: format 2 with exactly 16
X25519 stanzas in INNER_ACCESS_AGE (dummies, shuffled), payload padding
(code 1 bloque256, code 2 reforzado = max(bloque256, Padme)) with L and
the code in CONTROL_CBOR v2, VERSION 2 so v0.8.2 readers reject early,
a privacy section (§55.2) and writer rules (§62.1). The CDDL holds the
draft schemas. The fixes from the final review were being applied when
work stopped: they may be partial. See App/docs/HANDOFF.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

3 Commits (18eb3c3f484d6028ac21236cf193cb0c52ba7829)