Privacy-first.
Quantum-ready.
Zero-knowledge.

PQCServer is a free, open-architecture service for post-quantum encrypted messaging, file storage, and document notarization. It was built to make NIST 2024 post-quantum cryptography accessible to everyone — not just developers and researchers.

The service is part of a privacy ecosystem that includes onionmail.org (anonymous email), oniondrive.org (anonymous file storage), pqctoolkit.com (standalone PQC toolkit), and postquantum.tools (educational hub).

Who runs PQCServer

Encryption tools ask for a great deal of trust, and anonymous ones deserve less of it. PQCServer is operated by Onion Search Engine LLC, a registered company in New York, which also runs onionsearchengine.com and onionmail.org.

Company

Onion Search Engine LLC

Registered address

244 Madison Avenue #1031, New York, NY 10016, United States

General inquiries

[email protected]

Source code

github.com/Onion-Search-Engine/pqcserver

Licence

AGPL-3.0

Open source and auditable

This matters more than it might seem. A zero-knowledge claim is unverifiable by inspection: from the outside, a service that encrypts in the browser and one that quietly sends plaintext look identical. The only thing that turns the claim into something you can check is published code plus client-side execution you can observe in your own browser's developer tools. Both are available here.

Zero-Knowledge Architecture

The term "zero-knowledge" is often used loosely in the security industry. On PQCServer it has a precise technical meaning: the server is cryptographically incapable of reading your data.

This is not a policy choice or a promise — it is a mathematical property of the system. All cryptographic operations happen exclusively in your browser using the Web Crypto API and the pqc JavaScript library. Your private keys never leave your device. The server receives only ciphertext.

Cryptographic Algorithms

PQCServer uses exclusively algorithms standardized by NIST in August 2024 after a 7-year global competition involving hundreds of submissions from academic and industry researchers worldwide.

The construction is a standard KEM/DEM scheme: ML-KEM establishes a shared secret (the key encapsulation mechanism), and that secret keys AES-256-GCM, which encrypts the actual payload (the data encapsulation mechanism). AES-256 is already quantum-safe on its own — Grover's algorithm only halves its effective key length, which 256-bit keys comfortably absorb.

On hybrid key exchange — and why we do not use it

A note on terminology, because it is frequently blurred. In post-quantum cryptography, "hybrid" has a specific meaning: combining a classical key exchange with a post-quantum one and deriving the session key from both, so that breaking either algorithm alone is not enough. That is what browsers and CDNs deploy in TLS today under the name X25519MLKEM768 — X25519 elliptic-curve Diffie-Hellman alongside ML-KEM-768. Pairing ML-KEM with AES, as above, is not hybrid in that sense; it is simply how any KEM is used.

PQCServer uses ML-KEM alone, with no classical companion algorithm. This is a deliberate choice and it carries a real trade-off, so it is worth stating plainly rather than glossing over.

The argument for hybrid is insurance: lattice cryptography is younger than elliptic curves, and if an unexpected cryptanalytic advance weakened ML-KEM, the classical component would still stand. The argument against it, in our setting, is that it protects a different threat than the one we are built for. Hybrid TLS defends a live connection where the classical half is assumed sound today. PQCServer protects payloads that are expected to outlive classical cryptography entirely — a vault file or a notarised document may need to stay confidential for decades, which is precisely the horizon over which X25519 stops helping. We therefore use ML-KEM-1024, the highest parameter set in FIPS-203, rather than spending the complexity budget on a classical algorithm with a known expiry date.

Reasonable cryptographers disagree with this, and the reasoning is documented here so you can weigh it yourself rather than take it on trust. If you want to see exactly what the code does, it is open source.

Design Principles

• Server-side zero-knowledge by construction. Not a policy. The server architecture makes it mathematically impossible to access plaintext.
• No installation required. Everything runs in the browser. No plugins, extensions or apps. Any modern browser on any device works.
• NIST 2024 standards only. No custom or unreviewed algorithms. Every cryptographic primitive used has been through years of public scrutiny.
• No tracking, no analytics, no cookies. We collect the minimum data required to provide the service. We do not sell or share any data.
• Free forever. Encryption is a right, not a premium feature. The full service is free with no artificial limits.
• Embeddable by design. The widget architecture allows any website to add post-quantum encryption with one line of code.
• Open architecture. The cryptographic approach is fully documented and auditable. The server-side code handles only ciphertext.

The Privacy Ecosystem

PQCServer is part of a broader set of privacy tools built by the same company and designed to work together. They share the ML-KEM public-key registry, so an account on one is usable across the others:

Standards & References

NIST FIPS-203 — ML-KEM standard (August 2024)
NIST FIPS-204 — ML-DSA standard (August 2024)
NIST FIPS-205 — SLH-DSA standard (August 2024)
Open Quantum Safe Project — open source PQC implementations
Cloudflare — State of post-quantum internet 2025
AWS Post-Quantum Cryptography