Threat model

1. Purpose and scope

GrataQ addresses one specific task: secure receipt of files from third parties. The recipient (an institution or a professional) publishes an intake link; the sender uses it to upload a file — either in a web browser or from a desktop application. This threat model covers exactly this path: from the moment the sender selects a file to its decryption in the recipient's application.

The document's perspective is the attacker's: what an attacker in a given position can obtain, and how the architecture prevents it. We do not describe marketing features or the operator's internal processes here — only the security properties of the product itself and their limits.

Out of scope for this model are organizational controls on the institution's side (internal policies, training, physical security) and the behavior of endpoint devices outside the GrataQ application. Where the boundary touches the endpoint, we name it explicitly in section 6.

2. Protected assets

Assets ordered by protection priority:

• Confidentiality of file content — the actual data the sender uploads (contracts, identity documents, medical records). The most valuable asset.
• Content integrity — assurance that the received file is exactly the one the sender sent, unaltered in transit.
• Sender privacy — the sender does not register and provides neither email nor phone number. The server deliberately records no identifying information about them.
• Recipient privacy — who receives files, and which ones, should not be discoverable beyond what is technically necessary for delivery.
• Recipient identity and keys — the recipient's private ML-DSA identity and ML-KEM keys; their compromise would allow reading delivered files and impersonating the recipient.
• Availability — the ability to receive files; the target of a denial-of-service (DoS) attack.

3. Actors and attackers

We consider the following attackers and their capabilities:

• Passive network eavesdropping — the attacker captures traffic between the sender/recipient and the server. This includes the "harvest now, decrypt later" scenario: data stored today may be decrypted by a quantum computer in 5–15 years, which is a real threat for long-lived documents (contracts, identity documents, medical records).
• Attacker with server access / compromised server — has full access to data stored on the server, including the database and blob storage. Can read everything the server actually holds.
• On-path attacker (MITM) — actively interferes with communication, attempting to inject altered data or forged keys.
• Attacker impersonating an institution — phishing and impersonation: sets up a fake intake page so the sender uploads a file to the attacker instead of the real institution.
• Malicious sender — uploads malware or abuses the service (abuse, flooding).
• Loss or theft of the recipient's device — the attacker gains physical access to the device running the recipient's application and holding its private keys.

4. Trust boundaries

During receipt, data passes through four zones. What matters is where data crosses from a trusted zone into an untrusted one:

1. Sender's browser (or application) — the trusted zone for this transfer. Here, and only here, is the content encrypted, before it ever leaves the device.
2. Network — untrusted. Protected by TLS 1.3; the content is additionally encrypted independently of TLS.
3. Server — an untrusted intermediary. It sees only the encrypted blob and technically necessary metadata. It holds no private key and cannot read the content.
4. Recipient's device — the trusted zone. The only place with a private key, and the only place where the content is decrypted.

5. What the product protects

Guarantees the architecture provides against the attackers in section 3:

• Content is unreadable to the server and to eavesdroppers — encryption happens on the sender's side using the standards ML-KEM-768 + AES-256-GCM (NIST Level 3). The resistance holds even against a future quantum computer, and thus against the "harvest now, decrypt later" scenario.
• Content integrity — every bundle is protected by an AES-256-GCM authentication tag; any modification of the encrypted data in transit is detected and rejected at decryption.
• Forward secrecy for each file individually — every file uses a one-time ML-KEM pre-key (the recipient has 100 uploaded, and the application automatically replenishes them if the count drops below 20). After use, the pre-key is deleted. Compromise of one file's key does not endanger any other.
• Recipient identity verification — the sender confirms that it is encrypting for the correct recipient: the identity is bound to the fingerprint of the public ML-DSA key (SHA-256, which also serves as the account identifier) and optionally to the institution's verified domain (DNS check).
• Passwordless authentication — access to the recipient's account rests on a challenge-response ML-DSA-65 signature, not on a shared secret stored on the server.
• Encrypted transport — all communication with the server runs over TLS 1.3; content protection is an additional layer independent of TLS.

6. What the product explicitly does NOT protect (non-goals)

A threat model is only meaningful if it is honest about its limits. GrataQ does not guarantee the following:

• Metadata visible to the server — for delivery, the server needs and technically sees: who (which account) is the recipient, roughly when the transfer occurred, the sender's IP address in operational logs, and the size of the encrypted bundle. Not the content, but this metadata yes.
• Security of the sender's endpoint device — if the sender's device is infected (a keylogger, malware reading content before encryption), GrataQ does not address it. We encrypt what we are given; what happens before that on a compromised endpoint is beyond our reach.
• Security of the recipient's endpoint device — after decryption the file is in readable form on the recipient's device. Malware on that device can read it. Endpoint protection is the institution's responsibility.
• What the recipient does with the data after decryption — further storage, forwarding, printing, or sharing of decrypted content is outside the product's control.
• Content the sender discloses outside the system — if the sender also sends the same data over an insecure channel (ordinary email, chat), GrataQ has no influence over it.
• Antivirus scanning of content — because the server does not see the content, it cannot scan it for malware either. Any content scanning happens only on the recipient's device after decryption, outside the service. This is a direct consequence of end-to-end encryption, not an oversight.

7. Threats and mitigations

A summary of the main threats, their severity, the mitigation, and its current status. The status distinguishes what is live today from what is on the roadmap.

8. Assumptions and dependencies

The model's security guarantees hold under the following assumptions:

• Correctness of the NIST-standardized algorithms — we trust the security of ML-KEM-768, ML-DSA-65, and AES-256-GCM as standardized.
• Correctness of the client code on the device — we assume the application (or upload script) on the sender's/recipient's device actually does what it declares and runs on an uncompromised endpoint.
• TLS integrity — the transport layer (TLS 1.3) protects metadata and prevents ordinary MITM; content protection is an additional layer independent of it.
• Trust in DNS for domain verification — Model B (verified domain) relies on DNS; without DNSSEC, DNS is the weaker link (which is why DNSSEC is on the roadmap).
• The user protects their key and backup — the guarantees fall away if the user discloses the private key or exposes the identity backup.

9. Residual risks

Even after applying the mitigations above, the following risks remain; they are knowingly accepted and stem from the nature of the service:

• Metadata — the server necessarily sees who the recipient is, the approximate time of transfer, the sender's IP, and the bundle size. The content is protected, but the communication pattern cannot be hidden entirely.
• Endpoint devices — compromise of the sender's device before encryption or the recipient's device after decryption lies beyond the product's reach.
• Human factor — phishing can succeed if the user ignores domain verification; disclosure of the key, backup, or decrypted content outside the system is something the product cannot influence.

---

Related documents for security teams: Technical whitepaper · Key lifecycle · What the server stores and logs.