Send one secret, without leaving it in a chat history.
You create a receiving link, the other person encrypts their message into it, and only your browser can read the reply. Nothing is stored on our servers.
- 01
Prepare secure receipt
Your browser creates a key pair and gives you a public link to share.
- 02
The sender encrypts
They open your link, type the secret and get an encrypted reply to send back.
- 03
You read it locally
Paste the reply into your open tab. The private key never leaves your browser.
- 01 Receiving link
- 02 Encrypt
- 03 Read
What do you want to do?
Start on the left if you need someone to send you a secret. Start on the right if you already received an encrypted reply.
Prepare secure receipt
Open an encrypted message
What is Nexum Secure Share?
Secure Share is a small tool for one job: moving a short secret from one person to another without leaving a readable copy in a chat, a mailbox or a ticket.
There is no account and no sign-up. Encryption and decryption happen in your browser, and no plaintext, private key or encrypted payload is sent to a Nexum Trust server. The tool is in Public Beta.
How the exchange works
- 01
Create a receiving link
The person who needs to receive the secret opens Secure Share and prepares a secure receipt. The browser generates a key pair and produces a public link containing only the public key.
- 02
Encrypt the message
The sender opens that link, sees the recipient fingerprint, and types the secret. Their browser encrypts it and returns an encrypted link or text block.
- 03
Decrypt the reply
The recipient pastes the encrypted reply into their still-open tab, or loads their protected key file, and reads the message locally.
What people use it for
It is built for short, sensitive strings — not for file transfer.
- API keys handed over during an integration
- Temporary access credentials for a support session
- Tokens for a pipeline or a one-off deployment
- Recovery codes for an account handover
- Initial passwords that will be changed immediately
- Short sensitive notes that should not persist in a chat
Why not just use Slack, Teams or email?
Those tools are good at communication. They are not built to make a secret disappear afterwards.
- Messages are retained on servers, often far longer than the conversation stays relevant.
- Workspace and mailbox exports can include the message long after everyone forgot about it.
- Screenshots and copy-paste move the secret into places nobody tracks.
- Search indexes make an old secret easy to find again.
- Forwarded threads carry the secret to people who were never meant to see it.
- A single compromised account exposes the whole history at once.
Secure Share does not replace those tools. It gives you one narrow channel for the part of a conversation that should not be archived.
What does hybrid cryptography mean here?
Secure Share combines two key exchange methods. One is classical elliptic-curve cryptography, which is well understood and widely deployed today. The other is a lattice-based method designed to resist attacks by a future quantum computer.
Both results are combined into a single key, so the encryption stays sound as long as at least one of the two methods holds. That combination is what X-Wing describes.
This is a design choice, not a guarantee. Secure Share is a Public Beta, the JavaScript cryptography stack is treated as unaudited and not hardened against side-channel attacks, and no certified security level is claimed.
What leaves your browser?
The short answer: the secret does not.
- NEVERNo plaintext message is sent anywhere.
- NEVERNo private key is sent anywhere, and none is written to browser storage.
- NEVERNo key file password is sent anywhere.
- NEVERNo encrypted payload is sent to Nexum Trust — you forward it yourself.
To be honest about the rest: loading this page is a normal web request, so our web server sees the usual connection metadata such as your IP address, the requested path and your user agent. The part after the # in a link is never sent to a server by the browser. This route loads no analytics, no consent manager, no session replay and no third-party scripts.
Why check the fingerprint?
A receiving link proves that somebody generated a key pair. It does not prove who that somebody is. If an attacker can substitute their own link on the way to you, they receive the secret instead.
For anything sensitive, read the fingerprint out on a phone call, in person or through another channel the attacker does not control. If both sides see the same fingerprint, you are encrypting to the right key.
Limits you should know about
- A compromised browser or device breaks the model
- Malware, a malicious extension or an attacker on the device can read the message while it is on screen. Client-side encryption cannot fix an untrusted endpoint.
- A lost private key means a lost message
- If you close the tab without saving a key file, or forget the key file password, the message cannot be recovered by anyone, including us.
- Browser history and clipboard keep traces
- Links you open may end up in history or sync, and the clipboard is readable by other applications. Clear the message when you are done.
- It is not a secrets manager
- Secure Share moves a secret once. It does not store, rotate, audit or scope access. For ongoing credential management, use a proper secrets manager.
- Public Beta status
- Formats, wording and behaviour can still change. Treat the tool as useful but not yet a certified product.
Frequently asked questions
Do you store the message?
No. There is no database entry and no upload. The encrypted message only exists in the link or text block that you forward yourself.
Can Nexum Trust read the message?
No. The private key needed to decrypt is generated in the recipient’s browser and never sent to us. We never receive the encrypted payload either.
What happens if I lose the private key?
The message stays encrypted and cannot be recovered. Ask the sender to encrypt it again to a new receiving link.
Why do I have to check the fingerprint?
Because a link does not authenticate anyone. Comparing fingerprints on a second channel is what turns "some key" into "the right person’s key".
Is this post-quantum secure?
It uses a hybrid construction with a post-quantum component, which is designed to stay secure if either component holds. We do not claim a certified post-quantum security level for the browser implementation.
Can I share files?
No. Secure Share is limited to short text so the whole message fits in a link. For files, use a channel designed for that.
Can I close the tab?
Only if you downloaded the protected key file first. Otherwise the private key is gone and the reply cannot be opened.
How is this different from a password manager or secrets manager?
Those tools store and manage credentials over time. Secure Share does not store anything — it is a one-time transport for handing a secret over.