About Secretus

🌐 The Problem with Secret Sharing Today

Most "secure" secret sharing tools store your plaintext — or at best a weakly encrypted version of it — on their servers. When you paste a password into those tools, the company can read it. When their database leaks, your secrets leak with it.

The more forward-thinking tools use end-to-end encryption, but almost all of them rely on classical cryptography — specifically elliptic-curve Diffie-Hellman (ECDH). That's perfectly safe today. The problem is tomorrow.

Nation-state actors and well-resourced attackers already run "harvest now, decrypt later" campaigns: they record encrypted traffic today and archive it until quantum computers powerful enough to break ECDH become available. Estimates range from 5 to 15 years. Anything sensitive you share today with classical encryption could be decrypted in the future.

⚖️ Two Modes, One Platform

Different secrets require different threat models. Secretus gives you two distinct modes, and you choose which one fits the moment.

⚛️ ML-KEM-768 — Post-Quantum Encryption Explained

How classical ECDH works (and why it breaks)

Classical key exchange like ECDH relies on the hardness of the discrete logarithm problem on elliptic curves. A classical computer would need billions of years to break it. Shor's algorithm, running on a sufficiently large quantum computer, reduces that to hours. The encryption doesn't break today — it breaks the moment quantum hardware matures.

How ML-KEM-768 works

ML-KEM is based on the Module Learning With Errors (MLWE) problem — a lattice-based mathematical problem that is believed to be hard for both classical and quantum computers. There is no known quantum algorithm that offers a meaningful speedup against MLWE.

In Secretus Maximum Security mode, here's what happens at the cryptographic level:

1. 1
   Receiver generates an ML-KEM-768 keypair (1184-byte public key, 2400-byte secret key) entirely in the browser. The public key is included in the prekey bundle sent to the sender.
2. 2
   Sender encapsulates against the receiver's public key — producing a 1088-byte ciphertext and a 32-byte ML-KEM shared secret. The ciphertext is sent via the signaling channel; the shared secret stays local.
3. 3
   Receiver decapsulates the ciphertext with their secret key, recovering the same 32-byte shared secret independently.
4. 4
   Hybrid combination via HKDF-SHA256: The ECDH 4-DH output (from X3DH) and the ML-KEM shared secret are concatenated and fed into HKDF with info string "Secretus-Hybrid-X3DH-v1". The output becomes the session root key for the browser-side ratchet state.

Maximum Security Protocol Scope

X3DH Key Agreement

X3DH (Extended Triple Diffie-Hellman) allows two parties who have never spoken before to establish a shared secret securely, without any pre-shared passwords. In Maximum Security mode, Secretus extends X3DH with an ML-KEM-768 layer:

• Identity Keys (IK): Long-term ECDH P-256 keypairs that identify each party.
• Signed Prekey (SPK): A medium-term key signed by the identity key, preventing man-in-the-middle attacks.
• One-Time Prekey (OPK): A single-use key that ensures forward secrecy even if all other keys are compromised.
• 4-DH + ML-KEM hybrid: The four ECDH outputs are combined with the ML-KEM shared secret via HKDF into a single session root key that is resistant to both classical and quantum attacks.

Current Ratchet Behavior

Once the hybrid session root key is established, every message uses a unique key derived from the current chain key and message number:

• Chain Keys: Sender and receiver maintain separate chain keys that ratchet forward with each message.
• Message Keys: Each message gets a unique AES-256-GCM key derived from the current chain key plus the message number. After use, it is immediately discarded.
• Forward secrecy for past messages: Compromising a message key does not reveal earlier message keys or plaintexts.
• DH ratchet trigger: Each side proactively rotates its own DH ratchet key on a fixed message schedule (not only in reaction to a message from the peer), as long as it already has a ratchet public key from the peer to pair with.

⚡ Standard Mode — Async AES-256-GCM

The Maximum Security mode requires both parties to be online at the same time — a real constraint in business contexts where people are in different time zones or simply check messages at different hours. Standard Mode solves this with a different, equally sound cryptographic approach.

The #fragment trick — why the server never sees your key

The URL for a Standard Mode secret looks like: secretus.app/s/{id}#async_{key}

The part after # is the URL fragment. By HTTP specification, browsers never include the fragment in requests to the server. When a recipient opens the link, their browser fetches the ciphertext from our server — but our server only sees secretus.app/s/{id}, never the key. The decryption happens entirely client-side. This is not a trust-based privacy guarantee — it is architecturally enforced.

Storage: DynamoDB + S3, claim-and-consume one-time read

The encrypted payload is stored in Amazon S3 (eu-central-1). Metadata (expiry, s3 key) is in DynamoDB. When the recipient reads the secret, the server first acquires a conditional DynamoDB claim with a short, renewable lease — this is what makes concurrent reads mutually exclusive, not a single atomic delete. While holding the claim it reads the ciphertext from S3, then deletes the DynamoDB metadata with the claim's ownership checked, and only returns the payload to the recipient once that deletion succeeds. The link is invalid from that point on. Deleting the underlying S3 object is a separate, best-effort step that happens asynchronously after the response — a 37-day S3 lifecycle rule is the physical cleanup backstop if that best-effort delete is ever missed, not the primary mechanism.

🔑 Team Split — Shamir's Secret Sharing

Some secrets shouldn't rest in the hands of a single person. API keys for critical infrastructure, recovery codes for shared accounts, encryption passphrases for company data — these deserve threshold access control: split the secret so that no one individual can access it alone, but a quorum of trusted holders can reconstruct it when needed.

How Team Split Works in Secretus

🌍 Infrastructure & Privacy