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. The decryption keys are held separately from the encrypted content. Revoke or expire or cryptographically shred access to still-encrypted copies at any time after delivery. Built-in versioning is ransomware-resilient.
ML-KEM · FIPS 203 · AES-256-GCM · SHA3-256 content addressing
Quantum-safe by default and national by choice
The problem
Once a file leaves your hands you lose control. Today's encryption won't outlive the quantum threat
Mainstream sharing tools hand off both the file and its key. They offer no post-quantum protection. They treat secure sharing as an expert-only chore. Files leak. Keys can't be recalled. 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. The sender loses all control once it's delivered: no revocation. No expiry. No post-delivery key destruction.
Harvest now and decrypt later
SharePoint and 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. Ransomware can encrypt in place and destroy the recoverable copies you'd rely on to restore.
Usability pushes people to plain email
Secure sharing often demands that users manage keys and 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. Existing platforms lean on network segmentation instead of enforcing clearance cryptographically at download time.
Admins can reach your keys
Administrators can reach file content or the keys that unlock it on most platforms. That insider-threat surface 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. Every decryption key and 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 is computed concurrently and 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) public key or their KAZ-KEM public key as a national option. 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 and ACLs and 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 or 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. It renders still-encrypted copies permanently unrecoverable wherever they've been delivered.
# PQC secure-file upload: key and 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
# control stays with the owner after delivery:
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
What shredding can and can't do. Cryptographic shredding destroys the key material. No still-encrypted copy can be decrypted after the fact. It cannot reach a copy a recipient has already downloaded and decrypted to plaintext. That data sits outside any system's control. What you get is the power to stop all future decryption of ciphertext wherever it exists.
Capabilities
Post-delivery control · ransomware resilience · zero admin access to keys
Securing a file is as simple as dragging it into a folder. The platform handles the post-quantum cryptography and the access rules and the whole lifecycle for you.
Post-delivery revocation & expiry
Add or remove recipients at any time and set time-based expiry. Key metadata is cryptographically shredded automatically when the clock runs out.
Cryptographic shredding
Emergency or scheduled crypto-erasure overwrites the key material so still-encrypted copies become permanently unrecoverable. Useful during incident response.
Ransomware-resilient versioning
There is no overwrite operation: every upload creates a new immutable version. Deletions enter a configurable grace period (30 days by default) so clean copies stay recoverable.
Single-copy and multi-group sharing
Identical content is stored exactly once (SHA3-256 addressing). Folders act as logical access groups. One encrypted object can serve many groups with no duplication as a result.
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 and never key bundles. That makes a real zero-trust posture possible.
Signed plugin pipeline
DLP and virus scanning and watermarking run as sandboxed plugins that must be digitally signed by the platform PKI. Unsigned or tampered plugins are rejected.
Distributed and geo-separated storage
Files and their key metadata can live in different locations across BEAM nodes. A single-node compromise never exposes both the ciphertext and the keys as a result (tier-gated).
Tamper-evident audit trail
Every upload and download and access change and expiry and shred event is recorded as a signed and tamper-evident audit entry for full accountability.
Everywhere your files travel
Encrypt before the file ever leaves the device
The platform works where your files already move beyond the web portal. Content is encrypted 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. Trigger immediate shredding. All of it uses 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. Use BLE proximity authentication. Runs on Windows · macOS · Linux · iOS and Android.
Integration API & SDKs
Encrypt email and WhatsApp/Telegram attachments before they leave the device. Intercept browser-form uploads. 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 stop being decryptable either way.
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.
National insider-resistant sharing
A Malaysian and PQC-native stack where administrators never touch keys. A locally built option that reduces foreign-platform dependence.
Standards & cryptography
A NIST-standardized core with a national 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 sits alongside it as an optional and policy-selectable national choice. It is never a NIST-standardized primitive. Crypto-agility means you can change the choice 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 (national option) | KAZ-KEM | Optional and 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 · ransomware-resilient versioning.