No RSA, No ECC, No Problem: Why 1time.io Is Already Quantum-Safe

The Quantum Threat in 30 Seconds

Today's public-key cryptography — RSA, ECDSA, ECDH, Diffie-Hellman — relies on mathematical problems that classical computers cannot solve in reasonable time. Quantum computers change this. Two algorithms matter:

• Shor's algorithm breaks RSA, ECC, and Diffie-Hellman completely. A sufficiently powerful quantum computer could factor RSA keys and compute elliptic-curve discrete logarithms in polynomial time. All asymmetric cryptography based on these problems becomes worthless.
• Grover's algorithm attacks symmetric encryption by effectively halving the key length. AES-128 becomes 64-bit security (breakable). AES-256 becomes 128-bit security — which is still far beyond any known attack, classical or quantum.

Why Most Secret Sharing Tools Are Vulnerable

The weak point is not the encryption itself — it is the key exchange. When two parties need to agree on an encryption key over an untrusted channel, they typically use asymmetric cryptography: RSA, ECDH, or Diffie-Hellman. These are exactly the algorithms that Shor's algorithm destroys.

How 1time.io Avoids This Entirely

1time.io does not use any asymmetric cryptography. None. The encryption protocol is pure symmetric:

1. Your browser generates a random 20-character key using the Web Crypto API.
2. HKDF-SHA-256 derives two sub-keys: one for encryption, one for authentication.
3. AES-256-GCM encrypts your secret with a random 96-bit IV.
4. Only the ciphertext and a hashed authentication token are sent to the server.
5. The encryption key is placed in the URL fragment (after the #), which browsers never send to the server.

The key insight: there is no key exchange problem because the key travels inside the link itself. The URL fragment is the key distribution mechanism. It never touches the server, and it does not require any public-key cryptography. This is what makes 1time.io a genuinely quantum-safe password sharing tool — not a marketing claim bolted onto a vulnerable architecture.

How Competitors Compare

We looked at the cryptographic architecture of four popular secret sharing tools. The results may surprise you.

Yopass — OpenPGP Is the Weak Link

Yopass uses OpenPGP for client-side encryption. OpenPGP is a well-established standard, but it relies on RSA or ECC for key management. These are exactly the algorithms that Shor's algorithm targets. The symmetric layer (AES) inside OpenPGP is fine — but the asymmetric key wrapping around it is not.

A quantum adversary who captures a Yopass ciphertext and the associated OpenPGP public key material could recover the session key and decrypt the message.

OneTimeSecret — Server-Side Means Server-Vulnerable

OneTimeSecret encrypts on the server, not in the browser. This means the plaintext travels over TLS to the server before encryption happens. TLS today relies on ECDH or RSA for key exchange. A “harvest now, decrypt later” attack captures the TLS session, and a future quantum computer recovers the plaintext.

Even worse, the server sees your plaintext — so a compromise of the server (classical or quantum) exposes everything.

Bitwarden Send — RSA Key Wrapping

Bitwarden Send uses AES-256 for encryption (quantum-safe), but wraps the encryption key with RSA-OAEP as part of its account-based key hierarchy. This RSA layer is what a quantum computer would target. Breaking the RSA key wrapping recovers the AES key, which decrypts the message.

The Honest Caveats

We want to be transparent about what “quantum-safe” means and does not mean for 1time.io:

What this does NOT protect against:

• Link interception. If someone intercepts the URL (from Slack, email, or a compromised device), they have the key. This is a channel security problem, not a cryptographic one. Quantum computing does not change this threat.
• TLS interception. While the encryption key never leaves your browser (it stays in the URL fragment), the ciphertext does travel over TLS. If TLS itself is broken by a quantum computer, an attacker could capture the ciphertext in transit. However, without the key (which is in the URL fragment, not in the TLS stream), they still cannot decrypt it.
• Endpoint compromise. If the sender's or recipient's device is compromised, no encryption helps — classical or quantum.

Why This Architecture Was Chosen

We did not set out to build a “quantum-safe” tool. We set out to build the simplest possible zero-knowledge architecture for one-time secret sharing. The URL-fragment-as-key pattern emerged from a practical constraint: we wanted the server to never see the key, and we did not want to require accounts or key exchange protocols.

The result is an architecture with no asymmetric cryptography — not because we were worried about quantum computers, but because we did not need it. The quantum safety is a side effect of simplicity.

This is worth noting because it illustrates a broader principle in security engineering: simpler systems have fewer attack surfaces. By eliminating key exchange entirely, we eliminated an entire category of vulnerabilities — including the quantum ones.

What NIST Says

NIST's post-quantum cryptography standardization effort (FIPS 203, 204, 205) focuses on replacing asymmetric algorithms — RSA, ECDSA, ECDH — with lattice-based and hash-based alternatives. The symmetric algorithms 1time.io uses are explicitly recommended for continued use:

• AES-256 — listed in NIST SP 800-131A as approved for use beyond 2030.
• SHA-256 — listed in NIST SP 800-131A as approved. HKDF built on SHA-256 inherits this approval.
• GCM mode — listed in NIST SP 800-38D as an approved authenticated encryption mode.

No migration is needed. 1time.io's encryption is already compliant with NIST's post-quantum guidance because it never used the algorithms being replaced.

Should You Care Today?

Cryptographically relevant quantum computers do not exist yet. Current estimates range from 5 to 15 years. But the “harvest now, decrypt later” threat is real today — state-level adversaries are collecting encrypted traffic for future decryption.

For most one-time secrets (passwords, API keys, tokens), this threat is limited because the secrets themselves expire or rotate. But for organizations subject to compliance requirements — SOC 2, ISO 27001, NIST frameworks — being able to say “our secret sharing tool uses no quantum-vulnerable cryptography” is a meaningful differentiator today.