Security whitepaper

1. Summary

GrataQ is a platform for securely receiving sensitive documents from external senders. Anyone who installs the GrataQ application becomes a recipient of encrypted files — with no registration required of the sender, no shared passwords, and no dependency on a third party. Content is encrypted with post-quantum cryptography on the sender's side (in the browser or in the native application), so our server only ever sees unreadable data and never learns the content of the files. Each file has its own one-time key, so the exposure of one file does not endanger the others.

2. Problem addressed

Institutions receive sensitive documents from external parties every day: identity documents, contracts, medical reports, photo evidence of insurance claims. Common channels have structural weaknesses:

• Email — typically unencrypted in transit, with copies left on mail servers, in backups and on shared drives. Neither sender nor recipient has control over where the data ends up.
• Cloud storage — requires the sender to register and to trust the operator. Content is usually encrypted with the operator's key, not the recipient's key, so the operator technically has access to the data.
• Messengers — require both parties to use the same platform, and most rely on classical cryptography that is vulnerable to quantum computers.

On top of this sits the "harvest now, decrypt later" risk: traffic intercepted today can be decrypted by a quantum computer years from now. For documents with a long lifespan (contracts, identity documents, medical records) this is a real threat at the very moment of transfer. GrataQ therefore encrypts content in a way designed to remain resistant even to quantum computers.

3. Cryptographic protocol

GrataQ uses no proprietary cryptography. The protocol relies exclusively on NIST-standardized algorithms at the NIST Level 3 security level (equivalent to AES-192). These algorithms are in production today. Live

The choice of Level 3 matches the industry consensus (Signal, hybrid TLS in browsers, NIST's primary recommendation). The protocol is designed to allow a future move to Level 5 without changing the overall architecture.

3.1 ML-KEM — key encapsulation

ML-KEM-768 is a key encapsulation mechanism based on the learning-with-errors problem over lattices (Module-LWE). It operates in three steps: key pair generation (public key 1,184 B, private key 2,400 B), encapsulation against the recipient's public key (ciphertext 1,088 B + a 256-bit shared secret), and decapsulation with the private key (the same shared secret). The shared secret serves as the key for AES-256-GCM. Only the holder of the private key can derive the secret from the ciphertext — that is, the recipient on their own device.

3.2 ML-DSA — identity and authentication

ML-DSA-65 is a lattice-based digital signature scheme. The ML-DSA key pair is the account identity in GrataQ — no password, no OAuth, no dependency on a third party. Authentication to the server uses a challenge-response protocol: the server sends a random nonce, the client signs it with its ML-DSA key, and the server verifies the signature against the stored public key. The server therefore never holds any shared secret that the client would use to prove itself.

3.3 Per-file forward secrecy

Each file uses a unique one-time ML-KEM key pair (pre-key). The recipient generates 100 pre-keys, signs their public parts with their ML-DSA identity key, and uploads them to the server. The sender requests a single pre-key, performs encapsulation and encrypts the file; once used, the pre-key is deleted. When fewer than 20 unused pre-keys remain, the application automatically generates another batch. The chain for a single file is: 1 pre-key → 1 encapsulation → 1 unique shared secret → 1 unique AES-256 key. Compromising the key of one file therefore does not endanger any other file. Live

3.4 Encrypted payload format

The payload is always a ZIP archive — whether one file is sent or twenty. The ZIP is created on the sender's side and only then encrypted:

šifrovaný blob = AES-256-GCM( [1 B verze] + [ZIP data] )

Original file names are part of the ZIP, that is, inside the encrypted envelope — the server never sees them. The uniform format also lets the web app and the native application produce the same type of payload. Live

4. Architecture

The server is designed as a "dumb relay". It only receives and forwards signed pre-keys and encrypted blobs. It holds no private key, stores no plaintext, and stores no identifying information about the sender (no email, no phone number). Live

4.1 Data model

The server data model consists of four entities:

• Account — the account identifier (ID), the ML-DSA public key, and branding (name, logo, verified domain). The account identifier is derived from the public key; it is not a user-chosen name.
• PreKey — an ML-KEM public key together with an ML-DSA signature, one-time use.
• Blob — an encrypted file awaiting pickup, stored temporarily.
• Session — a short-lived authentication token.

4.2 Transport security

Communication between client and server is protected by standard TLS 1.3. Live File content, however, is protected by post-quantum cryptography independently of TLS: even if an attacker with a quantum computer broke intercepted TLS traffic, they would obtain metadata (who, to whom, when), not the content of the files. A move to PQ-hybrid TLS (a combination of classical and post-quantum key exchange) is planned once the standard stabilizes. Roadmap

5. Trust models

GrataQ supports two trust models depending on whether individuals or institutions are communicating.

5.1 Model A — Fingerprint

For communication between individuals. The fingerprint is a SHA-256 digest of the ML-DSA public key and also serves as the account identifier. Verification happens out-of-band: by phone, in person (QR code), or through another independent channel. Security does not rest on keeping the fingerprint secret, but on the recipient comparing a digest obtained by another route with the digest of the key supplied by the server. Live

5.2 Model B — Verified domain

For institutions. An institution binds its identity to its own domain through a DNS check. Once verification succeeds, a "Verified domain" indicator appears on the upload page, so the sender can see that the page belongs to that institution. This process has been tested in production for real. Live

5.3 Trust anchors by level

Each additional independent source of verification raises the difficulty of an attack, because an attacker would have to compromise several independent infrastructures at the same time.

• Level 1 — Verified domain: binding the public key to the institution's domain via a DNS check. The base layer. Live
• Level 2 — DNSSEC + DNS TXT: the public-key digest recorded in a DNS TXT record under DNSSEC. DNS is a different infrastructure from the web, so an attacker would have to compromise the web, DNS and GrataQ all at once. Roadmap
• Level 3 — Transparency log: every registration and key change would be recorded in a public append-only Merkle log (Sigstore Rekor), which can be independently audited and whose records cannot be altered after the fact. Roadmap

6. What the server cannot do

The architecture is designed so that a compromise of the server has minimal impact. Specifically, the server:

• cannot decrypt content — it holds no private key; that key exists only on the recipient's device;
• cannot inject a forged key — pre-keys are signed by the recipient's identity key, and for an institution they are bound to a verified domain;
• cannot identify the sender — it stores no registration or contact details about the sender;
• cannot alter data undetected — the AES-256-GCM authentication tag reveals any change to the encrypted blob during decryption.

7. Content authenticity verification (C2PA) Roadmap

C2PA (Coalition for Content Provenance and Authenticity) is an open standard for verifiable provenance of digital content. A C2PA manifest is a cryptographically signed structure embedded directly in the file, recording who created the content, when, with what device, and what edits were made. Some modern devices generate this manifest at the moment a picture is captured.

Integration plan: GrataQ would preserve the C2PA manifest unchanged along the entire path (ZIP → encryption → transfer → decryption), and the recipient's application would automatically verify the manifest after decryption and display the provenance information. This would create a demonstrable chain from content capture through to its secure delivery. This feature is part of the roadmap and is not yet deployed. Roadmap

8. Technology stack

• Server — C# / .NET 10 with native support for ML-KEM and ML-DSA. Live
• Client application — a desktop application for Windows. Live A cross-platform version (macOS, iOS, Android) built on .NET MAUI is planned. Roadmap
• Web upload page — a static page; encryption takes place entirely in the sender's browser using @noble/post-quantum, JSZip and the Web Crypto API, with no registration and no installation. Live

9. Roadmap

The following features are planned and not yet deployed.

Phase 3 — Native sender and chain of trust Roadmap

• A native sending application with direct camera integration.
• Preservation and verification of C2PA provenance.
• App Attest (iOS) and Play Integrity (Android) as proof of the sending application's integrity.
• A Sigstore Rekor transparency log as an additional trust anchor.

Phase 4 — Enterprise Roadmap

• API and webhooks for integration with internal systems.
• An on-premise version.
• HSM support.
• Audit logs and compliance reports.
• Integration with government PKI.

10. Transparency

The protocol and the algorithms used are described openly — in line with Kerckhoffs's principle, security does not rest on keeping them secret. Public are the protocol, the algorithms and the architecture (this document); private remain the users' private keys, the deployment details of the server infrastructure, and the business logic.

Part of building trust is a planned independent security audit and a bug bounty program. Roadmap

---

Related documents for the security team:

Threat model — an overview of threats and their mitigations.

Key lifecycle — generation, signing, replenishment and deletion of keys.

What the server stores and logs — a precise inventory of the data held on the server.