Key lifecycle

1. Two kinds of keys

GrataQ works with two distinct kinds of cryptographic material that serve different purposes and have different lifetimes:

• Identity — a long-term ML-DSA-65 key pair (digital signatures). It represents the recipient in the system and lasts for the entire lifetime of the account.
• Pre-keys — single-use ML-KEM-768 key pairs (key encapsulation) used to encrypt individual files. Each one is used exactly once.

Symmetric encryption of the content itself is performed with AES-256-GCM. All algorithms meet NIST Level 3 (quantum-resistant cryptography).

2. Recipient identity

The ML-DSA-65 key pair is generated on the user's device at the moment the account is created. The private key never leaves the device in readable form — only the public part is sent to the server.

The account identifier (ID) is the SHA-256 fingerprint of the public ML-DSA key. It is therefore derived from the key, not chosen by the user — the user cannot pick or invent it; it is produced deterministically from the cryptographic identity.

Authentication to the server uses neither a password nor OAuth. It runs over a challenge-response protocol: the server sends a random nonce, the client signs it with its private ML-DSA key, and the server verifies the signature against the stored public key. The private key never leaves the device in the process.

• Public key → stored on the server; it lets others send a file securely.
• Private key → stays with the user on the device.
• Account ID → SHA-256(public ML-DSA key), derived and immutable for a given identity.

3. Pre-keys and per-file forward secrecy

At registration, the app generates 100 single-use ML-KEM pre-keys. The public part of each pre-key is signed by the recipient's identity (ML-DSA) and uploaded to the server; the private parts stay on the device.

The process of sending a single file:

1. The sender requests one of the recipient's pre-keys.
2. It performs an Encapsulate operation over the public part of the pre-key → producing a unique shared secret.
3. From that secret a unique AES-256 key for this one file is derived, and the content is encrypted with it.
4. After use, that pre-key is deleted and is never used again.

The app replenishes its supply of pre-keys automatically: as soon as fewer than 20 remain, it generates another batch.

4. Where keys live

The split between device and server is essential for assessing risk:

• On the recipient's device: the private identity key (ML-DSA) and the private parts of all pre-keys (ML-KEM).
• On the server: only the public identity key, the public parts of the pre-keys, and their ML-DSA signatures.

5. Backup and recovery Live

A user can back up their identity and later recover it on a different (e.g., new) device. The backup takes the form of an encrypted package protected by the user's secret, held by the user themselves — not by the server.

Because the server never holds the private identity key, there is a direct consequence:

6. Device loss or compromise

The design accounts for several scenarios:

• Loss without a backup — access to future files sent to the original identity ends, because the private key is irretrievably gone. The solution is to create a new identity (a new account / new ID) and send out a new receiving link to the other parties.
• Recovery from a backup — if the user has a backup, they restore the same identity (same ID) from the encrypted backup on a new device and continue without interruption.
• Suspected compromise — the recommended course of action is to create a new identity and have it re-verified by the other parties (see identity verification below), so that those parties stop trusting the original, potentially compromised ID.

Multiple devices with a shared identity (the same identity active on several devices at once) is a planned extension. Roadmap

7. Identity verification by the other party

So that a sender can be certain who they are sending a file to, GrataQ offers independent models for verifying the recipient's identity:

• Model A — Fingerprint Live — the other party compares the SHA-256 fingerprint of the public key over a different channel (out-of-band), e.g., by scanning a QR code at an in-person meeting or reading the fingerprint over the phone. Security does not rest on keeping the fingerprint secret, but on the fact that it arrives by a route other than the key from the server.
• Model B — Verified domain Live — an institution binds its identity to its own domain (verified via DNS). The sender then sees a “Verified domain” label on the upload page. This model has been tested in real-world operation.
• Further independent layers Roadmap — a combination of DNSSEC + DNS TXT and a public transparency log (Sigstore Rekor), which add further independent anchors of trust.

8. Key rotation

Rotation works differently for each kind of key:

• Pre-keys “rotate” naturally by their very nature — they are single-use, deleted after each use, and the supply is replenished automatically. No two files share a key.
• Identity is long-term. It “changes” in that the user creates a new identity (a new ID) — typically after losing a device or on suspicion of compromise. The other parties then verify the new identity again.

Automatic periodic rotation of the identity is not part of the product — the identity remains stable until the user changes it themselves by creating a new one.

9. Account deletion Live

When an account is deleted, the following happens:

• On the server, the public identity key, all pre-keys, and the account data are removed.
• The private key on the device is deleted by the user — the server never had access to it, so it cannot remove it on the user's behalf either.

After deletion, files can no longer be received at that ID, and the identity cannot be recovered unless the user backed it up beforehand.

---

Related documents:

• Whitepaper — a complete technical and cryptographic description of the system.
• Threat model — what GrataQ protects, against what, and under what assumptions.
• What the server stores and logs — the exact scope of data on the server side.