DateKeys/SECURITY.md

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.

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

In scope: every rule of the DateKeys Protocol Specification v0.11, tagged spec-v0.11, and of the draft v0.12 of the branch v0.12, that this module implements (see docs/traceability.md), the CLI, and the handling of untrusted input (.dkc, .dkk, relay responses, author key files). Among it: the paths and texts of a format 3 head, which the CLI writes to disk and to a terminal; the signatures, certificates and seals of the security area, whose names reach the lines of the verdicts; the public note; and the locator of a .dkk, with its addresses.

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). In format 3 the declared author, the comment, the public note and the modification times are text of the creator that proves nothing (spec §24.1, §29.7, §55.1).
• An author signature of alg 1 proves that someone with the secret key signed, not who holds it (spec §29.9, §29.12). For a signature with certificates (alg 2) and for a seal, the module checks the cryptography and the dates, never who issued a certificate or a seal, or whether it was revoked: an official validator does (spec §29.10, §29.11). Whoever can open a capsule can remake its security area, so only a valid seal says that it was signed before the date (spec §7.9). The verdicts never decide the opening (spec §29.3).
• A key of words is as strong as its words: after the date, whoever holds the .dkc can try words offline (spec §38.1).
• 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; scrypt for the files of author keys
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
The Go standard library	crypto/ed25519 (with the strict checks of internal/ed25519strict), crypto/rsa, crypto/ecdsa and SHA-2: author signatures and seals; crypto/pbkdf2: the key of words

Deterministic CBOR (spec §58) is implemented by the module itself, in package codec, without dependencies. So are DER and the reading of CMS signatures, X.509 certificates and RFC 3161 tokens (spec §29.10, §29.11), in internal/der and internal/cms: they read the structures with the profile of the specification, and the standard library verifies the signatures.

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.
• The Quicknet root of trust is compiled into the binary and checked against its pinned profile_hash (4147645109798ecbc9f630c2f709835bb5846fe7911a6bd5c5755e25ade2ada4).