User Manual
User Manual

PQCServer
Complete Guide

Everything you need to send quantum-safe encrypted messages, store files in an encrypted vault, notarize documents, and manage post-quantum cryptographic keys — for both technical and non-technical users.

NIST FIPS-203 ML-KEM NIST FIPS-204 ML-DSA Zero-Knowledge Server Open Source AGPL v3

Quick Navigation

Create Account Key Generation Encrypted Messages File Vault Document Notary Key Server Embed Widget Algorithms FAQ Glossary
Introduction

What is PQCServer?

PQCServer is a zero-knowledge post-quantum cryptography platform that lets you send encrypted messages, store files securely, and notarize documents — all using the latest NIST-standardized post-quantum algorithms.

It is part of the OnionSearchEngine LLC privacy ecosystem, alongside OnionMail and OnionDrive.

🔒
Encrypted Messaging
Send end-to-end encrypted messages via secure shortlinks. No app required for the recipient.
📁
File Vault
Store files permanently in your personal encrypted vault. Only you can decrypt them.
🔏
Document Notary
Prove a document existed at a specific time with a quantum-safe digital signature.
🔑
Key Server
Publish your ML-KEM and ML-DSA public keys so anyone can encrypt messages for you.
🔌
Embeddable Widget
Add a quantum-safe "Send Encrypted Message" button to any website with one line of code.
🧅
Tor / .onion Ready
Accessible via Tor Browser for maximum anonymity. No account required to send messages.
Background

Why Post-Quantum Cryptography?

Today's most common encryption (RSA, ECC) relies on mathematical problems — like factoring large numbers — that classical computers cannot solve in reasonable time. However, quantum computers can break these algorithms using Shor's Algorithm.

Quantum computers powerful enough to do this don't yet exist at scale, but security agencies and intelligence services are already collecting encrypted traffic today to decrypt it later — the so-called "Harvest Now, Decrypt Later" attack. If your data needs to remain secret for years, you need post-quantum encryption now.

Timeline
YearEvent
1994Shor's Algorithm published — theoretically breaks RSA/ECC
2016NIST launches post-quantum algorithm competition
2024NIST finalizes FIPS-203 (ML-KEM) and FIPS-204 (ML-DSA)
2030NSA CNSA 2.0 deadline — all US government systems must use PQC
2035Estimated Q-Day horizon — quantum computers may break classical encryption

PQCServer uses ML-KEM (FIPS-203) for key encapsulation and encryption, and ML-DSA (FIPS-204) for digital signatures — the official 2024 NIST standards, not experimental or proprietary algorithms.

Architecture

Zero-Knowledge Design

PQCServer is designed so that the server never sees your plaintext data. All cryptographic operations happen in your browser before any data is sent to the server.

🛡️
What this means for you Even if PQCServer's servers were seized, hacked, or forced to hand over data, the attacker would only get encrypted ciphertext that cannot be decrypted without your private key — which never leaves your device.
What the server stores vs what it never sees
Server storesServer never sees
✓ Encrypted ciphertext (unreadable)✗ Plaintext messages
✓ Your public keys (by design — shareable)✗ Your private keys
✓ Encrypted file chunks in GridFS✗ Original file content
✓ Document hash + timestamp✗ The document itself
✓ Username + hashed password✗ Your password in plaintext
Getting Started

Create an Account

You can receive and send encrypted messages without an account — just paste the recipient's public key directly. An account is required to publish your public keys on the key server, use the file vault, and access the document notary.

ℹ️
No personal data required Registration only requires a username, password, and optionally an email address. You can use any username. Your email is optional and only used for account recovery.

Step by Step

1
Go to pqcserver.com/register.html
Open the registration page in your browser.
2
Choose a username
Type your desired username in the field. The system checks availability in real time. 3–32 characters, letters, numbers, hyphens and underscores only.
Example: alice_smith, bob-privacy, mario2026
⚠️ Your username will be public — it appears on your profile page and key server listing.
3
Set a password
Choose a strong password. It is hashed with bcrypt before being stored — the server never sees your actual password.
4
Optional: add an email
Used only for account recovery. Can be an OnionMail address or any other email.
5
Click Register
Your account is created. You will be redirected to the key generation page automatically. Generate your keys immediately — without keys, you cannot receive encrypted messages.
Getting Started

Generate Your Keys

PQCServer uses two types of key pairs. Both are generated entirely in your browser — the private keys never leave your device.

🔑
ML-KEM Key Pair
Used for encryption. Others use your public key to encrypt messages for you. You use your private key to decrypt.
✍️
ML-DSA Key Pair
Used for digital signatures. You use your private key to sign documents. Others use your public key to verify your signature.

Step by Step

1
Go to pqcserver.com/keygen.html
You must be logged in. The page loads the post-quantum crypto library from pqcserver.com itself — never from a third-party CDN, because that library is what generates your private keys.
2
Choose your security level
Leave the defaults selected. The ML-KEM variants are:
ML-KEM-1024 — ~256-bit security, the level this account needs
ML-KEM-768 — ~192-bit security, for interoperability with outside systems only
ML-KEM-512 — ~128-bit security, smallest keys, fastest, least margin
💡 Leave the defaults: ML-KEM-1024 and ML-DSA-87. These are the levels PQCMail, PQCChat, PQCDrive and PQCVault expect, so keys generated lower down will not work with your account on those services. The smaller sets stay available for outside systems that require them.
3
Click "Generate Keys"
The browser generates both ML-KEM and ML-DSA key pairs using the Web Crypto API and the pqc JavaScript library. This happens entirely in your browser — nothing is sent to the server yet.
4
Download your private keys
Click Download keyfile (.json). The file contains both private keys and carries each one in base64 and hex, so it imports directly into PQCMail, PQCChat, PQCDrive and PQCVault without conversion. A plain .txt export is also available for reference. This is the only copy — store it safely.

Recommended storage locations:
• Encrypted USB drive or hardware wallet
• Password manager (Bitwarden, KeePass, etc.)
• Encrypted disk image (VeraCrypt)
⚠️ If you lose your private keys, you cannot decrypt your messages or files. There is no recovery mechanism by design.
5
Public keys are published
Your public keys are automatically sent to the PQCServer key server and associated with your username. Anyone can now look up your public key at pqcserver.com/u/YOUR_USERNAME to send you encrypted messages.
⚠️
Keep your private key file safe Your private key file is the only thing that can decrypt your messages and files. Back it up in multiple secure locations. Never share it, never upload it anywhere, never email it. If someone gets your private key, they can read all your encrypted data.

Key File Format

The keyfile is JSON. Every key is carried in both encodings, so an importer never has to guess or convert:

{ "format": "pqc-keyfile-v1", "username": "alice", "created_at": "2026-09-10T10:00:00Z", "keys": { "kem": { "public": { "algorithm": "ML-KEM-1024", "base64": "…", "hex": "…" }, "secret": { "algorithm": "ML-KEM-1024", "base64": "…", "hex": "…" } }, "dsa": { "public": { "algorithm": "ML-DSA-87", "base64": "…", "hex": "…" }, "secret": { "algorithm": "ML-DSA-87", "base64": "…", "hex": "…" } } } }

The Import an existing keyfile button on the key generation page reads this format, the older .txt export, and the password-protected backups produced by PQCMail, PQCChat, PQCDrive and PQCVault. Keys are recognised by their contents rather than by field name, so a file from any of those services imports without editing.

Service

🔒 Encrypted Messaging

This section is the how-to. For the design rationale, see how encrypted messaging works.

Send end-to-end encrypted messages to anyone. The recipient receives a shortlink (pqcserver.com/m/xxxxxxxx) they can open in any browser to decrypt the message using their private key. No app required.

How to Send an Encrypted Message

1
Go to pqcserver.com/encrypt.html
This page works without an account. You only need the recipient's public key.
2
Enter the recipient
Either:
• Type a PQCServer username — the system fetches their public key automatically
• Paste a public key directly — use the base64 ML-KEM public key
• Use your own username — to save files only you can decrypt
3
Write your message
Type your text in the message box. Optionally attach a file (any format, any size).
4
Optional: configure TTL and burn after read
TTL (Time to Live) — how long before the message auto-deletes (1 day to 30 days, or never).
Burn after read — the message is permanently deleted after the first time it's opened. Ideal for one-time sensitive information.
5
Click "Encrypt & Generate Link"
The browser:
1. Loads the recipient's ML-KEM public key
2. Performs ML-KEM key encapsulation — generates a shared secret + KEM ciphertext
3. Encrypts your message with AES-256-GCM using the shared secret
4. Sends only the ciphertext (never the plaintext) to the server
5. Returns a shortlink
6
Share the shortlink
Copy the link and send it via email, chat, SMS, or any channel. The link looks like: https://pqcserver.com/m/abc12345

The link itself reveals nothing about the content — it is safe to share over any channel, including unencrypted email.

How to Decrypt a Message

1
Open the shortlink
Click or paste the link in any browser. No account or app needed.
2
Paste your ML-KEM private key
Open your key file and copy the ML-KEM secret value. Paste it in the private key field on the page.
🔒 Your private key is used locally in the browser — it is never sent to the server.
3
Click "Decrypt"
The browser:
1. Downloads the ciphertext from the server
2. Uses your ML-KEM private key to decapsulate the shared secret
3. Decrypts the message locally with AES-256-GCM
4. Displays the plaintext — which never leaves your browser
4
Download attached file (if any)
If the message has a file attachment, a "Download & Decrypt" button appears. Click it to download and decrypt the file locally.
💡
Example use case Alice wants to send her password for the company server to Bob securely. She opens encrypt.html, types "bob" as recipient, writes the password, enables "burn after read", and gets a link. She sends the link via Slack. Bob opens the link, pastes his private key, reads the password. The message is permanently deleted from the server immediately.
Service

📁 Zero-Knowledge File Vault

This section is the how-to. For the design rationale, see how the encrypted vault works.

Store files permanently in your personal encrypted vault. Files are encrypted in your browser before upload — the server only stores ciphertext. Only you can decrypt them using your private key. There are no file size limits — files are split into 3MB chunks and stored in MongoDB GridFS.

Upload a File to Your Vault

1
Go to pqcserver.com/vault_upload.html
You must be logged in. Your ML-KEM public key is loaded automatically.
2
Select a file
Drag and drop a file onto the upload area, or click to open a file browser. Any file type is supported: documents, images, videos, archives, code, etc.
3
Optionally add tags and a note
Tags help you organize and search your vault later. Example: work, 2026, contracts. The note is a short description visible only to you.
4
Click "Encrypt & Upload"
The browser encrypts the file using your ML-KEM public key (AES-256-GCM) and uploads it in chunks. A progress bar shows reading → encrypting → uploading → complete.
5
File is saved with a shortlink
After upload, a shortlink is generated automatically (pqcserver.com/m/xxxxxxxx). You can share this link with anyone — but only someone with your ML-KEM private key can decrypt the file.

Manage Your Vault

1
Go to pqcserver.com/vault.html
Lists all your uploaded files with name, size, date, and tags.
2
Search and filter
Use the search box to find files by name, or filter by tag.
3
Share a file
Each file has a "Copy Link" button to copy the shortlink. You can also generate new shortlinks or share with a specific username.
4
Delete a file
Click the delete icon, confirm, and the file is permanently removed from the server — including all encrypted chunks in GridFS and all associated shortlinks.

Download and Decrypt a Vault File

1
Open the file shortlink
Open pqcserver.com/m/xxxxxxxx in a browser.
2
Paste your ML-KEM private key and click Decrypt
The browser recovers the shared secret using ML-KEM decapsulation.
3
Click "Download & Decrypt File"
The encrypted file is downloaded from GridFS, decrypted locally in the browser with AES-256-GCM, and saved to your device with the original filename and format.
💡
Example use case Mario needs to store sensitive client contracts. He uploads each PDF to his vault with tag "contracts". The files are stored encrypted — Mario's employer, the server admin, or any attacker who breaches the server cannot read the files without Mario's private key. When Mario needs a contract, he opens the vault, clicks the shortlink, pastes his private key, and downloads the decrypted PDF.
Service

🔏 Document Notary

This section is the how-to. For the design rationale, see how document timestamping works.

The Document Notary lets you prove that a specific document existed at a specific time and that it has not been modified since. It works by hashing your document locally and signing the hash with an ML-DSA digital signature. The document itself never leaves your browser.

How the date is proven

A signature proves who signed what, but carries no date. On most timestamping services the date comes from a field in the operator's database — which the operator can change, with nothing in the certificate to show it.

PQCServer links every certificate to the one issued before it, forming an append-only chain. Each certificate carries its position (seq), the hash of its predecessor (prev_hash) and its own chain hash. Altering a certificate changes its hash and breaks the link in every certificate issued afterwards, so anyone holding a later one can demonstrate the tampering.

The end of the chain is published hourly at pqcserver.com/anchors/ and submitted to OpenTimestamps, whose calendars commit it into the Bitcoin blockchain. Once an anchor is in a block, back-dating a certificate covered by it would require rewriting Bitcoin.

The limit: anchors are hourly, so a certificate is proven to have existed by the time of the next anchor, not to the second. For establishing precedence that bound is what matters; if you need certified time to the second, an accredited Time-Stamping Authority under eIDAS is the right instrument.

Certificates issued before the chain was introduced remain outside it and are reported as such by the verification page. They cannot be added retroactively — writing a history that did not happen is exactly what the chain prevents.

✅
Privacy guaranteed The notary process only sends the document's hash (a fixed-length fingerprint) to the server — not the document itself. The server cannot reconstruct your document from its hash.

Sign and Notarize a Document

1
Go to pqcserver.com/sign.html
You must be logged in with your ML-DSA private key available.
2
Upload the document
Drag and drop any file. The browser immediately computes SHA-256 and SHA-512 hashes of the file. The file itself is not sent to the server.
3
Paste your ML-DSA private key
Open your key file and copy the ML-DSA secret value. Paste it in the field. The browser signs the document hash with your ML-DSA key.
4
Click "Sign & Notarize"
The server receives only:
• The document hash (never the document)
• Your ML-DSA signature
• The file name and size, if you chose to record them

It issues a timestamp certificate — a JSON document with an immutable ID (ts_xxxxxxxxxx), the UTC time, and the certificate's position in the append-only chain described above.
5
Download the certificate
Save the JSON certificate. It contains everything needed to verify it, including the chain position. The public verification URL is pqcserver.com/verify.html?id=ts_xxxxxxxxxx — share it with anyone who needs to check.

Verify a Notarized Document

1
Go to pqcserver.com/verify.html
No account required — verification is public.
2
Provide the original, and the certificate
Paste the certificate ID (or the full certificate JSON). The page then asks for the original — a file if a file was signed, a text box if a text message was signed, chosen automatically from the certificate. The browser re-hashes it locally and compares.

For signed text the match is exact: a trailing space or newline produces a different hash, so copy the text from where you signed it rather than retyping it.
3
Verification result
✓ Valid — the content matches the recorded hash and the ML-DSA signature is cryptographically valid. The page separately reports the chain position and whether it has been committed to a published anchor.
✗ Invalid — the content has been modified since signing, or the certificate does not match its own chain position.
What a timestamp certificate looks like
{ "version": "1", "id": "ts_abc123xyz0", "service": "PQCServer Cryptographic Timestamp", "document_hash": "e3b0c44298fc1c149afb...", "hash_algorithm": "SHA-256", "signature": "base64 ML-DSA signature...", "public_key_dsa": "base64 ML-DSA public key...", "algorithm": "ML-DSA (NIST FIPS-204)", "signer_name": "alice", "timestamp_utc": "2026-09-10T10:01:54Z", "chain": { "seq": 48213, "prev_hash": "sha256 of the previous certificate...", "hash": "this certificate's chain hash...", "anchors": "https://pqcserver.com/anchors/" }, "verify_url": "https://pqcserver.com/verify.html?id=ts_abc123xyz0" }
💡
Example use cases A freelancer notarizes a contract draft before sending it to a client — proof of the original version. A researcher notarizes experimental data — proof it wasn't altered after the results were known. A journalist notarizes source documents — tamper-evident timestamp for legal proceedings.
Service

🔑 Key Server

PQCServer doubles as a public key server for post-quantum ML-KEM and ML-DSA keys. When you generate keys and register your profile, your public keys are published and anyone can look them up to send you encrypted messages.

Your Public Profile

Your public profile is at: https://pqcserver.com/u/YOUR_USERNAME
It shows your ML-KEM and ML-DSA public keys and a button to send you an encrypted message.

API — Look Up a Public Key

Any application can fetch a user's public key via the REST API:

# Fetch public key for username "alice" GET https://pqcserver.com/api/pubkey.php?u=alice # Response { "ok": true, "username": "alice", "public_key_kem": "base64-ml-kem-public-key...", "public_key_dsa": "base64-ml-dsa-public-key...", "profile_url": "https://pqcserver.com/u/alice" }

Comparison with PGP Key Servers

PQCServer Key Server vs keys.openpgp.org
FeaturePQCServerkeys.openpgp.org
AlgorithmsML-KEM + ML-DSA (NIST 2024)RSA / ECC (pre-quantum)
APIREST JSONHKP Protocol
Public profile page✓✗
Integrated encryption✓ — encrypt from the profile page✗
Embeddable widget✓✗
Integration

🔌 Embeddable Widget

Add a "Send Encrypted Message" button to any website with a single line of HTML. The widget opens an inline modal with a 3-step flow: recipient lookup → write message → get shortlink. No redirect, no new tab, no installation for the recipient.

Usage

Known recipient (by username)
<script src="https://pqcserver.com/assets/widget.js" data-recipient="alice_smith"></script>

Automatically fetches Alice's public key. The user just writes the message and gets a link.

Direct public key
<script src="https://pqcserver.com/assets/widget.js" data-pubkey="BASE64_ML_KEM_PUBLIC_KEY"></script>

Use when the recipient has a public key but no PQCServer account.

Unknown recipient — user chooses
<script src="https://pqcserver.com/assets/widget.js"></script>

The widget shows a recipient lookup step first. The user types a PQCServer username or pastes a public key.

Optional Parameters

All available attributes
AttributeDefaultDescription
data-recipient—PQCServer username of recipient
data-pubkey—Base64 ML-KEM public key of recipient
data-label🔒 Send Encrypted MessageButton label text
data-themedarkdark or light

Integration with OnionMail

The widget is designed to integrate seamlessly with OnionMail. Add it to your OnionMail profile or signature page so anyone visiting your mail profile can send you a quantum-safe encrypted message directly, without knowing your email address.

💡
Self-hosting note If you self-host PQCServer on your own domain, change the const BASE variable at the top of widget.js to point to your own domain.
Advanced

Self-Hosting

PQCServer is open source under AGPL v3. You can run your own instance on any Ubuntu server. The source code is available at github.com/Onion-Search-Engine/pqcserver.

Requirements

# Server requirements Ubuntu 22.04 / 24.04 LTS PHP 8.1 or 8.3 MongoDB 7.0 (local or remote) Nginx Composer

Quick Install

git clone https://github.com/Onion-Search-Engine/pqcserver.git cd pqcserver chmod +x install.sh sudo bash install.sh

Configuration

# Copy and edit the environment file cp .env.example .env nano .env # Set these variables: MONGO_URI=mongodb://user:pass@host:27017 BASE_URL=https://your-domain.com # Generate server signing keys (for Notary) php scripts/generate_server_keys.php

Adding a Tor .onion Address

# Install Tor apt install tor # Add to /etc/tor/torrc HiddenServiceDir /var/lib/tor/pqcserver/ HiddenServicePort 80 127.0.0.1:80 # Restart and get address systemctl restart tor cat /var/lib/tor/pqcserver/hostname
Technical Reference

Cryptographic Algorithms

All algorithms used by PQCServer are official NIST post-quantum standards or NIST-approved symmetric primitives.

NIST FIPS-203
ML-KEM
Module-Lattice-Based Key Encapsulation Mechanism. Used for encryption and key exchange. Replaces RSA and ECDH. Available in 512, 768, and 1024-bit variants.
NIST FIPS-204
ML-DSA
Module-Lattice-Based Digital Signature Algorithm. Used for digital signatures and document notarization. Replaces ECDSA and RSA signatures. Available in 44, 65, and 87-bit variants.
NIST SP 800-38D
AES-256-GCM
Advanced Encryption Standard in Galois/Counter Mode. Used for symmetric encryption of message content and files. Provides both confidentiality and integrity.
FIPS 180-4
SHA-256 / SHA-512
Secure Hash Algorithm. Used for document hashing in the Notary service. SHA-256 provides a 32-byte fingerprint; SHA-512 provides a 64-byte fingerprint.

Key Sizes Reference

ML-KEM key sizes
VariantSecurityPublic keyPrivate keyCiphertext
ML-KEM-512~128-bit800 bytes1,632 bytes768 bytes
ML-KEM-768~192-bit1,184 bytes2,400 bytes1,088 bytes
ML-KEM-1024~256-bit1,568 bytes3,168 bytes1,568 bytes

Highlighted row = required default (ML-KEM-1024)

Help

Frequently Asked Questions

Do I need an account to send messages?

No. You can send an encrypted message to anyone by going to encrypt.html and entering their public key directly, or their PQCServer username. No account needed.

Do I need an account to decrypt messages?

No. You only need your private key file. Open the shortlink, paste your ML-KEM private key, and decrypt. The private key is used locally and never sent to the server.

What happens if I lose my private key?

There is no recovery. Your private key is the only way to decrypt your data. This is by design — the server cannot help you recover it because the server never had access to it. This is why you must back up your key file in multiple secure locations immediately after generating it.

Can the PQCServer admins read my messages?

No. The server only stores encrypted ciphertext. Without your private key — which never leaves your device — the ciphertext is mathematically indecipherable.

Can PQCServer back-date a notary certificate?

Not without it being detectable. Certificates form an append-only chain whose head is published hourly and committed to the Bitcoin blockchain. Altering one breaks every certificate after it, and rewriting the whole chain no longer matches what was published. See the anchors page for how to check this yourself.

What happens if PQCServer is seized by authorities?

Authorities would obtain only encrypted ciphertext and hashed passwords. Without private keys — which are stored only on users' devices — the data is useless. This is the practical benefit of zero-knowledge design.

Is PQCServer compatible with Tuta or ProtonMail?

PQCServer is not an email provider — it is a cryptographic layer that works alongside any email service. You can send a PQCServer shortlink via Tuta, ProtonMail, or Gmail. The encryption happens in the browser, not in the email itself.

How is this different from PGP?

PGP uses RSA or ECC — classical algorithms that quantum computers can break. PQCServer uses ML-KEM and ML-DSA — quantum-resistant algorithms standardized by NIST in 2024. PQCServer is also much easier to use: no key import/export tools, no keyring management, no email client plugins — just a URL.

Can I use PQCServer over Tor?

Yes. The site is accessible via Tor Browser. For maximum anonymity, access PQCServer via the .onion address (published on the homepage). All features work over Tor.

Is the code audited?

The code is fully open source under AGPL v3 on GitHub. Community audit is welcome and encouraged. The cryptographic implementation uses the pqc JavaScript library (pure JS implementation of NIST PQC standards) and the browser's native Web Crypto API for AES-256-GCM.

Is it free?

Yes. PQCServer is free to use. The hosted service at pqcserver.com is provided at no cost. You can also self-host your own instance for free.

Reference

Glossary

ML-KEM (Module-Lattice Key Encapsulation Mechanism)
NIST FIPS-203 standard. A post-quantum algorithm for key encapsulation — securely establishing a shared secret between two parties. Replaces RSA and ECDH. Used in PQCServer for encrypting messages and vault files.
ML-DSA (Module-Lattice Digital Signature Algorithm)
NIST FIPS-204 standard. A post-quantum algorithm for digital signatures. Replaces RSA-PSS and ECDSA. Used in PQCServer for the Document Notary and key authentication.
AES-256-GCM
Advanced Encryption Standard with 256-bit key in Galois/Counter Mode. A symmetric encryption algorithm that provides both confidentiality and data integrity. Not broken by quantum computers (Grover's algorithm only halves effective key length to 128-bit, still secure). Used in PQCServer to encrypt all message and file content.
Key Encapsulation (KEM)
A cryptographic mechanism for securely exchanging a shared secret. The sender uses the recipient's public key to "encapsulate" a random secret, producing a ciphertext. The recipient uses their private key to "decapsulate" and recover the secret. Neither party needs to transmit the secret directly.
Zero-Knowledge Server
A server architecture where the operator has no access to user plaintext data. All encryption and decryption happens on the client (browser). The server stores only ciphertext it cannot read.
Burn After Read
A message option that causes the message to be permanently deleted from the server immediately after the first time it is read. Useful for one-time credentials, one-time codes, or sensitive information that should not persist.
Harvest Now, Decrypt Later (HNDL)
An attack strategy where adversaries collect encrypted traffic today with the intent to decrypt it in the future, when quantum computers become powerful enough to break classical encryption. Post-quantum cryptography protects against this attack.
GridFS
A MongoDB specification for storing and retrieving files that exceed the 16MB BSON document size limit. PQCServer uses GridFS to store encrypted file chunks of 3MB each. Supports files of any size.
Timestamp Certificate
A JSON document issued by PQCServer after signing a document hash. Contains the hash, the UTC timestamp, the signer's ML-DSA signature and public key, and the certificate's position in the append-only chain. Proves that content with that exact hash was signed by the holder of that key, and — through the chain and its published anchors — that it existed no later than the anchor covering its position.
Public Key / Private Key
A pair of mathematically linked keys. The public key can be shared with anyone — it is used to encrypt data for you. The private key must be kept secret — it is used to decrypt data encrypted with your public key. In post-quantum cryptography, these are based on lattice problems rather than integer factorization.
AGPL v3
GNU Affero General Public License version 3. An open source license that requires anyone who modifies and distributes the software (including as a network service) to release their modifications under the same license. PQCServer is released under AGPL v3.
Q-Day
The hypothetical future date when quantum computers will be powerful enough to break currently deployed public-key cryptography at scale. Estimated by various agencies between 2030 and 2035, though the exact date is uncertain.

Read next   Encrypted messaging · Encrypted vault · Document notary · Key generator · How it works · Pricing · Home

PQCServer — Copyright © 2026 OnionSearchEngine LLC — Released under AGPL v3 — GitHub — PostQuantum.Tools