GKP 2.x Format Technical Specifications

Open standard for certified, sealed, and timestamped electronic originals

Summary

1. Introduction to GKP 2.x format 2. Format objectives 3. General structure of a GKP 2.x file 4. Metadata model 5. GKP lifecycle 6. Cryptographic algorithms 7. Interoperability and extensions 8. Official references (ANSSI & electronic archiving)

1. Introduction to GKP 2.x format

GKP 2.x is an open electronic original format. It allows transforming any type of digital file (documents, images, videos, audio, archives, etc.) into a certified container, sealed and timestamped, whose authenticity can be verified, even offline.

The goal of GKP is to answer a simple question in a context where generative AI, deepfakes, and fake documents are multiplying:

« How can I continue to trust a digital file that I receive, sign, or share? »

GKP 2.x defines:

•a container structure (header, metadata, payload, signatures, timestamp)
•a metadata model
•a cryptographic model (hashing, encryption, signature, timestamping)
•an identification mechanism (GKP number, manifest)
•a legacy mode to support older files

2. Format objectives

The GKP 2.x format aims to:

Guarantee integrity

Detect any modification, even minimal, of the content

Attest authenticity

Prove who sealed the electronic original, with what identity

Attest date

Associate a reliable timestamp from a Time Stamping Authority (TSA)

Remain usable offline

Allow basic verification without Internet connection

Ensure interoperability

Allow different implementations to read and verify the same files

Be extensible

Allow adding complementary information without breaking compatibility

3. General structure of a GKP 2.x file

A GKP 2.x file is a structured container that groups several components:

1. Header

• Format version (e.g. 2.1)
• Magic bytes / format identifier
• Flags (encrypted / unencrypted, legacy / non-legacy, timestamp presence, etc.)
• Minimal information for the reader to know how to interpret the rest

2. Metadata – Canonical CBOR

Serialized in Canonical CBOR (RFC 8949 §4.2)

• Keys sorted lexicographically
• Strict UTF-8 encoding

Contain notably:

• File name, MIME type, size
• Algorithms used (hashing, encryption, signature)
• Context information (optional): organization, user, description, tags
• Cryptographic parameters (salts, KDF, etc.)
• PKI / TSA references if present

3. Payload (original file content)

• Content of the file to protect (PDF, image, video, audio, DOCX, ZIP, etc.)
• Stored in clear or encrypted depending on configuration
• In encrypted case, payload is encrypted in AEAD mode (AES-256-GCM or ChaCha20-Poly1305), with metadata used as AAD

4. Digital signature(s)

• Based on Ed25519
• Sign the whole: header || metadata || encrypted_payload || payload_hash
• Prove the authenticity of the electronic original and the identity of the signer

5. Timestamping (TSA, optional)

• Timestamp token (RFC 3161) encoded in DER
• Covers the BLAKE3 fingerprint of the payload (or an enclosing structure)
• Allows proving that at a given time, a file possessed this fingerprint

6. GKP Manifest (GkpManifest)

Logical structure grouping identification information:

• Readable GKP number
• Legacy / non-legacy indicator
• Context references (organization, user, etc.)

The GKP number has for example the form:

GKP-YYYYMM-ORGCODE-USERCODE-XXXX

This manifest can be embedded in metadata and/or reconstructed from fields.

4. Metadata model (simplified view)

GKP metadata can include, among others:

Original file information

• file_name
• mime_type
• file_size
• created_at, imported_at

Algorithms used

• hash_algo (e.g. blake3)
• cipher_algo (e.g. aes-256-gcm)
• signature_algo (e.g. ed25519)
• KDF parameters (Argon2id, HKDF)

Issuance context

• Issuing organization (internal code, name)
• User identifier
• Role or service

Sharing information

• Sharing policy (public / private / restricted)
• Password protection parameters

PKI / TSA references

• Signer certificate fingerprint
• Possible OCSP/CRL references
• TSA token (or reference to it)

The detailed structure and exact keys can be exposed in finer documentation, but metadata are:

✓Serialized in Canonical CBOR
✓Strictly structured
✓Designed to be verifiable and interoperable

5. GKP lifecycle

5.1 Creation

1.User selects a file
2.Gankpo calculates BLAKE3 fingerprint of content
3.Metadata are prepared (Canonical CBOR, key sorting)
4.
If file must be encrypted:
- • a master key is derived (Argon2id)
- • a content key is derived (HKDF)
- • payload is encrypted in AES-256-GCM or ChaCha20-Poly1305
5.Header, metadata, and payload (encrypted or not) are assembled
6.The whole is signed with Ed25519
7.Optionally, an RFC 3161 TSA token is obtained and integrated
8.A readable GKP number (e.g. GKP-202511-PG-USR01-0042) is generated and recorded in the manifest

5.2 Verification

1.The reader (Gankpo Reader, Gankpo Suite, other implementation) opens the GKP file
2.It verifies header and metadata consistency
3.It recalculates BLAKE3 fingerprint of payload
4.It verifies Ed25519 signature (integrity + authenticity)
5.If there is a TSA timestamp, it verifies RFC 3161 token and certificate chain
6.It presents a clear diagnostic: file intact / modified, signature valid / invalid, timestamp valid / expired, etc.

5.3 Legacy support

• First GKP files (previous versions) can be interpreted in legacy mode
• In this case, a partial manifest can be reconstructed on the fly, with a flag legacy = true
The goal is to ensure that:
✓ old files remain readable
✓ migration to GKP 2.x is progressive

6. Cryptographic algorithms

Gankpo uses modern cryptographic algorithms, audited and aligned with ANSSI recommendations: BLAKE3, Ed25519, AES-256-GCM, Argon2id, HKDF, Canonical CBOR, X.509 and RFC 3161.

7. Interoperability and extensions

GKP 2.x is designed to be implemented in:

• Gankpo Suite
• Gankpo Reader
• Other libraries or services to come

The format and algorithms are documented to allow:

• Integration into third-party systems (justice, administration, banking, media...)
• Validation by external auditors
• Publication of open source verification tools

Open and interoperable format

The GKP 2.x format is an open standard. Any organization can develop its own tools for creating, reading, and validating GKP files by following this specification, thus fostering adoption and trust in the global digital ecosystem.

8. Official references (ANSSI & electronic archiving)

The GKP format and Gankpo suite were designed inspired by ANSSI recommendations and public repositories on cryptographic mechanisms, electronic signatures, timestamping, and electronic archiving. Gankpo is not an ANSSI certified product, but its technical choices (AEAD encryption, public key signatures, structured metadata, PKI, timestamping) align with these best practices.