Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
|
|
|
# Security policy
|
|
|
|
|
|
|
|
|
|
## Reporting a vulnerability
|
|
|
|
|
|
|
|
|
|
Please report vulnerabilities privately, not in public issues:
|
|
|
|
|
|
|
|
|
|
- Send an e-mail to the maintainers at info@activething.com with "DateKeys
|
|
|
|
|
security" in the subject. Ask for an encrypted channel before sending
|
|
|
|
|
sensitive material.
|
|
|
|
|
- Do not open an issue on the repository for a vulnerability.
|
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
|
|
|
|
|
|
|
|
Include a reproducible case: ideally a `.dkc` or `.dkk` file, or a test in the
|
|
|
|
|
style of `capsule/mutation_test.go`. We aim to acknowledge reports within
|
|
|
|
|
three working days.
|
|
|
|
|
|
|
|
|
|
## Supported versions
|
|
|
|
|
|
|
|
|
|
The module is pre-1.0 (`v0.x`). Only the latest `v0.x` release receives fixes.
|
|
|
|
|
|
|
|
|
|
## Scope and assumptions
|
|
|
|
|
|
Format 3, step 7: the documentation of spec v0.10
- README and README.es: specification 0.10, format 3 written and formats
1 to 3 read; BODY in the picture of a capsule; the CLI with folders,
-comment, -author, -no-mtime and decrypt into a new folder, with the
presentation of 29.7; EncryptFiles, Source and Sink in the library; the
metadata that format 3 hides, safe extraction, and the declared author
and comment that prove nothing; the fixtures, vectors and mutations of
format 3; 18 normative errors.
- CHANGELOG: the section of specification v0.10.
- docs/traceability.md: rows 29.2 to 29.7 and 29.5.1, and the rows that
format 3 changes (22, 23, 28, 29, 29.1, 31, 33, 39, 56, 57, 61 to 64,
67 to 70, 75 and 76); ERR_HEAD_INVALID in the error mapping; two
implementation decisions, the Sink and the width of the terminal.
- testdata/README.md: the nine fixtures of format 3 and their records,
the four new vector files, the mutation corpus of 209 cases with its
list of format 3 and the verdicts of the cases that open, and the two
bases of format 3 of the differential corpus.
- SECURITY.md: specification v0.10, and the head as untrusted input.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
|
|
|
In scope: every rule of the DateKeys Protocol Specification v0.10 this module
|
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
|
|
|
implements (see `docs/traceability.md`), the CLI, and the handling of
|
Format 3, step 7: the documentation of spec v0.10
- README and README.es: specification 0.10, format 3 written and formats
1 to 3 read; BODY in the picture of a capsule; the CLI with folders,
-comment, -author, -no-mtime and decrypt into a new folder, with the
presentation of 29.7; EncryptFiles, Source and Sink in the library; the
metadata that format 3 hides, safe extraction, and the declared author
and comment that prove nothing; the fixtures, vectors and mutations of
format 3; 18 normative errors.
- CHANGELOG: the section of specification v0.10.
- docs/traceability.md: rows 29.2 to 29.7 and 29.5.1, and the rows that
format 3 changes (22, 23, 28, 29, 29.1, 31, 33, 39, 56, 57, 61 to 64,
67 to 70, 75 and 76); ERR_HEAD_INVALID in the error mapping; two
implementation decisions, the Sink and the width of the terminal.
- testdata/README.md: the nine fixtures of format 3 and their records,
the four new vector files, the mutation corpus of 209 cases with its
list of format 3 and the verdicts of the cases that open, and the two
bases of format 3 of the differential corpus.
- SECURITY.md: specification v0.10, and the head as untrusted input.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
|
|
|
untrusted input (`.dkc`, `.dkk`, relay responses), among it the paths and
|
|
|
|
|
texts of a format 3 head, which the CLI writes to disk and to a terminal.
|
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
|
|
|
|
|
|
|
|
The protocol's own limits, which are not vulnerabilities of this module:
|
|
|
|
|
|
|
|
|
|
- The Quicknet timelock is not post-quantum; long-lived ciphertexts are exposed
|
|
|
|
|
to harvest-now, decrypt-later (spec §7.7, §53).
|
|
|
|
|
- Time confidentiality depends on drand's threshold assumption (spec §7.6).
|
|
|
|
|
- `time_only` and `time_and_key` do not authenticate the creator (spec §36.1).
|
Format 3, step 7: the documentation of spec v0.10
- README and README.es: specification 0.10, format 3 written and formats
1 to 3 read; BODY in the picture of a capsule; the CLI with folders,
-comment, -author, -no-mtime and decrypt into a new folder, with the
presentation of 29.7; EncryptFiles, Source and Sink in the library; the
metadata that format 3 hides, safe extraction, and the declared author
and comment that prove nothing; the fixtures, vectors and mutations of
format 3; 18 normative errors.
- CHANGELOG: the section of specification v0.10.
- docs/traceability.md: rows 29.2 to 29.7 and 29.5.1, and the rows that
format 3 changes (22, 23, 28, 29, 29.1, 31, 33, 39, 56, 57, 61 to 64,
67 to 70, 75 and 76); ERR_HEAD_INVALID in the error mapping; two
implementation decisions, the Sink and the width of the terminal.
- testdata/README.md: the nine fixtures of format 3 and their records,
the four new vector files, the mutation corpus of 209 cases with its
list of format 3 and the verdicts of the cases that open, and the two
bases of format 3 of the differential corpus.
- SECURITY.md: specification v0.10, and the head as untrusted input.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 week ago
|
|
|
In format 3 the declared author, the comment and the modification times are
|
|
|
|
|
text of the creator that proves nothing, and this version checks no author
|
|
|
|
|
signature and no time seal: its verdicts say so (spec §29.3, §29.7, §55.1).
|
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
|
|
|
- Opening a mature capsule years later needs the historical release (spec §50).
|
|
|
|
|
- A compromised device can copy plaintext or secrets (spec §7.8).
|
|
|
|
|
- Go cannot guarantee that secrets are erased from memory. The module wipes
|
|
|
|
|
its own buffers (`I_PAYLOAD`, `CONTROL_CBOR`, `.dkk` material) on a best
|
|
|
|
|
effort basis and promises no more.
|
|
|
|
|
|
|
|
|
|
## Cryptographic dependencies
|
|
|
|
|
|
|
|
|
|
No cryptography is implemented in this module. It depends on:
|
|
|
|
|
|
|
|
|
|
| Dependency | Role |
|
|
|
|
|
|---|---|
|
|
|
|
|
| `filippo.io/age` v1.3.2 | age files, X25519, STREAM, header MAC |
|
|
|
|
|
| `github.com/drand/tlock` v1.2.0 | `TimeLock`, `TimeUnlock`, ciphertext encoding |
|
|
|
|
|
| `github.com/drand/drand/v2` v2.1.7 | BLS verification (`crypto.Scheme`), chain-info hash |
|
|
|
|
|
| `github.com/drand/kyber`, `github.com/drand/kyber-bls12381` | BLS12-381 pairing |
|
|
|
|
|
|
|
|
|
|
Deterministic CBOR (spec §58) is implemented by the module itself, in package
|
|
|
|
|
`codec`, without dependencies.
|
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
|
|
|
|
|
|
|
|
All versions are pinned in `go.mod` and verified through `go.sum`. Changes to
|
|
|
|
|
`age`, `tlock`, `drand` or `kyber` are reviewed manually.
|
|
|
|
|
|
|
|
|
|
### Known risks under watch
|
|
|
|
|
|
|
|
|
|
- **`github.com/kilic/bls12-381` is archived.** `kyber-bls12381` builds on it,
|
|
|
|
|
and both `drand` and `tlock` depend on that stack. Mitigation: pinned
|
|
|
|
|
versions, `govulncheck` on every change and nightly, and this plan if a
|
|
|
|
|
vulnerability appears or the dependency becomes untenable: (1) move to a
|
|
|
|
|
maintained fork adopted by drand, or (2) extract BLS verification onto a
|
|
|
|
|
maintained BLS12-381 implementation, keeping the golden vectors and fixtures
|
|
|
|
|
as the acceptance test.
|
|
|
|
|
- **`tlock` has had no tagged release since August 2024.** Only its exported
|
|
|
|
|
core (`TimeLock`, `TimeUnlock`, `CiphertextToBytes`, `BytesToCiphertext`) is
|
|
|
|
|
used, pinned by version.
|
|
|
|
|
- **`drand/v2` brings gRPC and protobuf into the binary** through
|
|
|
|
|
`common/chain`, used for the chain-hash self-check of profiles. With the
|
|
|
|
|
`google.golang.org/grpc` v1.81.1 that `drand/v2` v2.1.7 selects,
|
|
|
|
|
`govulncheck` reported GO-2026-6348 and GO-2026-6061 as reachable, so
|
|
|
|
|
`go.mod` requires grpc v1.84.0, and `golang.org/x/crypto` v0.57.0 for
|
|
|
|
|
GO-2026-6354 and GO-2026-6355. With those, `govulncheck` v1.8.0 on
|
|
|
|
|
Go 1.26.8 finds no reachable vulnerability (25 September 2026); two
|
|
|
|
|
unreachable advisories without a released fix remain, GO-2026-6443 (grpc)
|
|
|
|
|
and GO-2026-5932 (x/crypto). Build with a patched Go toolchain: Go 1.26.0
|
|
|
|
|
itself has reachable standard-library advisories fixed in 1.26.1 and later.
|
|
|
|
|
Plan §11 item 5 (extracting BLS verification onto `kyber-bls12381` alone)
|
|
|
|
|
would remove gRPC from the graph entirely.
|
|
|
|
|
- **Fixtures over past rounds** rely on the embedded signatures being genuine;
|
|
|
|
|
every test run verifies them against the pinned public key.
|
|
|
|
|
|
|
|
|
|
## Supply chain
|
|
|
|
|
|
|
|
|
|
- Reproducible builds: `-trimpath`, `CGO_ENABLED=0`, pinned toolchain in CI.
|
|
|
|
|
- Releases publish SHA-256 checksums and a CycloneDX SBOM, and are signed with
|
|
|
|
|
cosign using the project's signing key.
|
Initial implementation of the DateKeys Protocol v0.8.1
Reference implementation in Go, built from the implementation plan
(milestones M0 to M5): datekey, profile, provider, codec, agewrap,
extension, capsule, accesskey, the datekeys CLI, official vectors and
fixtures, the mutation corpus, fuzz targets, interop and live tests,
CI workflows, traceability and policy documents.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2 weeks ago
|
|
|
- The Quicknet root of trust is compiled into the binary and checked against
|
|
|
|
|
its pinned `profile_hash` (`4147645109798ecbc9f630c2f709835bb5846fe7911a6bd5c5755e25ade2ada4`).
|