End-to-end encrypted file sharing —
you keep control after the file leaves your hands.
Post-quantum file sharing with ML-KEM (FIPS 203) key encapsulation, where the decryption keys are held separately from the encrypted content. Revoke, expire, or cryptographically shred access to still-encrypted copies at any time after delivery — with built-in, ransomware-resilient versioning.
ML-KEM · FIPS 203 · AES-256-GCM · SHA3-256 content addressing
Quantum-safe by default, sovereign by choice
The problem
Once a file leaves your hands, you lose control — and today's encryption won't outlive the quantum threat
Mainstream sharing tools hand off both the file and its key, offer no post-quantum protection, and treat secure sharing as an expert-only chore. Files leak, keys can't be recalled, and ciphertext captured today can be decrypted later.
The key travels with the file
S/MIME and similar approaches embed the recipient's wrapped key inside the encrypted message. Once it's delivered, the sender loses all control — no revocation, no expiry, no post-delivery key destruction.
Harvest now, decrypt later
SharePoint, Google Drive and Dropbox don't support post-quantum algorithms. Confidential files encrypted with classical crypto today can be captured and decrypted once a cryptographically relevant quantum computer exists.
Ransomware overwrites in place
Conventional platforms allow files to be overwritten, so ransomware can encrypt in place and destroy the recoverable copies you'd rely on to restore.
Usability pushes people to plain email
When secure sharing demands that users manage keys, pick algorithms and handle certificates, they fall back to plain email attachments and USB drives instead.
No cryptographic classification
Government and defence need classification-based access control, but existing platforms lean on network segmentation rather than enforcing clearance cryptographically at download time.
Admins can reach your keys
On most platforms, administrators can reach file content or the keys that unlock it — an insider-threat surface that blocks any real zero-trust posture.
How it works
Separate the key from the content — and you keep control forever
The core design move: encrypted files are stored as opaque objects, while every decryption key, access rule and lifecycle policy lives in a separate metadata layer. Control the metadata and you control access — long after the file has been delivered.
1 · Encrypt the content
A random AES-256-GCM data encryption key (DEK) encrypts the file. A SHA3-256 content hash — computed concurrently — provides integrity and content-addressable de-duplication.
2 · Encapsulate the key per recipient
The DEK is individually encapsulated for each authorised recipient using their ML-KEM (FIPS 203) — or, as a sovereign option, KAZ-KEM — public key. Each recipient gets their own key bundle; one compromised private key never exposes another's.
3 · Store keys separately from content
Encrypted files are opaque binary objects; all key bundles, ACLs, classification labels and expiry policies live in a separate metadata layer that storage administrators never touch. Metadata can even be geographically separated from the files.
4 · Revoke, expire, or shred access
Remove a recipient and their key bundle is deleted. Set an expiry and the metadata is cryptographically shredded on schedule. Shredding the key material revokes the ability to decrypt any copy that hasn't already been decrypted, and renders still-encrypted copies permanently unrecoverable — anywhere they've been delivered.
# PQC secure-file upload — key/content separation
1. dek = random AES-256-GCM key
2. ciphertext = AES-256-GCM(dek, file) # content encrypted
3. hash = SHA3-256(file) # dedup + integrity
4. store(ciphertext) -> single opaque object # content-addressable
# keys live in a SEPARATE metadata layer, per recipient:
for recipient in authorised:
bundle = ML-KEM.encapsulate(recipient.pubkey, dek)
metadata.put(file_id, recipient, bundle) # admins never see this
# after delivery — control stays with the owner:
metadata.revoke(file_id, recipient) # remove access
metadata.expire(file_id, at: deadline) # time-boxed
metadata.shred(file_id) # crypto-erase keys
# -> still-encrypted copies can no longer be decrypted, anywhere
A precise promise. Cryptographic shredding destroys the key material, so no still-encrypted copy can be decrypted after the fact. It does not — and cannot — reach into a copy a recipient has already downloaded and decrypted to plaintext; that data is outside any system's control. What you get back is the power to prevent all future decryption of ciphertext, everywhere it exists.
Capabilities
Post-delivery control, ransomware resilience, and zero admin access to keys
Securing a file is as simple as dragging it into a folder — the platform handles the post-quantum cryptography, the access model, and the full lifecycle behind the scenes.
Post-delivery revocation & expiry
Add or remove recipients at any time and set time-based expiry. When the clock runs out, key metadata is cryptographically shredded automatically.
Cryptographic shredding
Emergency or scheduled crypto-erasure overwrites the key material so still-encrypted copies become permanently unrecoverable — ideal for incident response.
Ransomware-resilient versioning
There is no overwrite operation: every upload creates a new immutable version, and deletions enter a configurable grace period (30 days by default) so clean copies stay recoverable.
Single-copy, multi-group sharing
Identical content is stored exactly once (SHA3-256 addressing). Folders act as logical access groups, so one encrypted object can serve many groups with no duplication.
Cryptographic access control
Classification labels (Top Secret / Secret / Confidential / Restricted) gate the download itself — both the machine and the requesting user must clear the file's level before a key bundle is released.
Zero admin access to keys
The metadata engine is the sole custodian of decryption information. Administrators see routing metadata only, never key bundles — enabling a genuine zero-trust posture.
Signed plugin pipeline
DLP, virus scanning and watermarking run as sandboxed plugins that must be digitally signed by the platform PKI — unsigned or tampered plugins are rejected.
Distributed, geo-separated storage
Files and their key metadata can live in different locations across BEAM nodes, so a single-node compromise never exposes both the ciphertext and the keys (tier-gated).
Tamper-evident audit trail
Every upload, download, access change, expiry and shred event is recorded as a signed, tamper-evident audit entry for full accountability.
Everywhere your files travel
Encrypt before the file ever leaves the device
Beyond the web portal, the platform meets users where they work — so content is protected at the source and only a secure link travels through the channel.
Drag-and-drop web portal
Folders are access groups. Drop a file to encrypt and share it, view every version, control recipients, set expiry, and trigger immediate shredding — with colour-coded classification banners.
Desktop & mobile apps
Watch local folders and USB drives for auto-encryption, decrypt locally to a wiped-after-use secure store, and use BLE proximity authentication. Windows, macOS, Linux, iOS and Android.
Integration API & SDKs
Encrypt email and WhatsApp/Telegram attachments before they leave the device, intercept browser-form uploads, and drive it all over REST (OpenAPI 3.0) with Java, Python, JavaScript and Elixir SDKs.
Use cases
Built for the highest-stakes sharing
Classified government distribution
Distribute Top Secret / Secret / Confidential / Restricted files gated on both machine and user clearance certificates at download time.
Time-boxed & revocable sharing
Send a file that auto-expires, or revoke a recipient's access after delivery — the still-encrypted copies simply stop being decryptable.
Ransomware recovery
Restore clean immutable prior versions, or recover deleted files within the delayed-deletion grace window, when an endpoint is hit.
Multi-group distribution
Reference one encrypted object from several folders so multiple recipient groups share it — no duplicate copies, no version drift.
Incident-response shredding
Trigger emergency cryptographic shredding to make files instantly unrecoverable everywhere the ciphertext still exists.
Sovereign, insider-resistant sharing
A Malaysian, PQC-native stack where administrators never touch keys — a locally developed option that reduces foreign-platform dependence.
Standards & cryptography
A NIST-standardized core, with a sovereign option you can swap at any time
ML-KEM (FIPS 203) is the primary key-encapsulation mechanism and AES-256-GCM encrypts content. KAZ-KEM is offered alongside as an optional, policy-selectable sovereign choice — never as a NIST-standardized primitive — and crypto-agility means the choice can be changed whenever policy dictates.
| Function | Algorithm | Role in the platform |
|---|---|---|
| Key encapsulation (primary) | ML-KEM — NIST FIPS 203 | Encapsulates each file's DEK for every authorised recipient |
| Key encapsulation (sovereign option) | KAZ-KEM | Optional, policy-selectable Malaysian PQC KEM offered alongside ML-KEM — not a NIST standard |
| Content encryption | AES-256-GCM | Symmetric encryption of file content under the per-file DEK |
| Content addressing & integrity | SHA3-256 | Single-copy de-duplication and tamper detection |
Share files that stay under your control
See PQC Secure File Sharing in action — post-quantum encryption, post-delivery revocation, and ransomware-resilient versioning.