.gkp v4 format — public reference.
This page reflects active implementation 4.0.0. It describes the container; it does not turn a mathematically valid signature into automatic proof of identity, authority or legal effect.
Binary order
- 64-byte fixed header;
- canonical CBOR metadata;
- payload, protected according to creation policy;
- 32-byte BLAKE3 payload fingerprint;
- 64-byte primary signature;
- optional append-only
GKPRrecords.
Fixed header
| Bytes | Size | Field |
|---|---|---|
| 0–3 | 4 | GKP2 magic |
| 4–5 | 2 | Binary version 4 |
| 6–7 | 2 | Flags |
| 8–11 | 4 | Metadata length |
| 12–15 | 4 | Payload length |
| 16–47 | 32 | Keyed BLAKE3 header checksum |
| 48 | 1 | Content kind |
| 49–63 | 15 | Reserved, zero-filled |
Metadata and cryptography
The CBOR manifest describes the file, author, payload integrity and cryptographic parameters, plus optional TSA, PKI, sharing, evidence and policy elements.
- primary signatures: Ed25519 or ECDSA-P256;
- integrity: BLAKE3;
- authenticated encryption: AES-256-GCM or ChaCha20-Poly1305;
- derivation: Argon2id then HKDF-SHA-256.
The primary signature covers every preceding block, including the payload fingerprint. P-384 is not part of the current primary production registry.
Local checks and trust decisions
Structure, header checksum, fingerprint and signature may be checked locally when the required keys and capabilities are available. A complete decision may also depend on current anchors, revocation, timestamps, policy or external authority.