In the world of cybersecurity, there is a mantra: "Trust, but verify".
When you use an online tool to send a password or an API key, you are placing trust in that company. But have you ever wondered who holds the key to decrypt that message?
The answer defines the difference between a "secure" tool and a private tool. This is where the battle between Server-Side Encryption and Client-Side Encryption comes in.
Today we are going to explain client side encryption and why, if you take security seriously, it is the only acceptable architecture.
The Traditional Model: Server-Side Encryption
Most web applications work like this:
- You write your secret in a form.
- You click "Send".
- The data travels via HTTPS (secure in transit) to the company's server.
- The server receives the data, encrypts it, and saves it in its database.
The Problem: The server has the key.
In this model, the company managing the service could technically read your data if they wanted to, if a rogue employee accessed the database, or if a court order forced them to hand over the keys.
Is OneTimeSecret safe?
This is a common question. Classic tools like OneTimeSecret have worked under the model where the link is generated on the server. While they are respectable tools and generally secure against external attackers, they are not "Zero Knowledge". Technically, they process your secret on their servers before saving it. This introduces a single point of failure: trust in the provider.
The Evolution: Client-Side Encryption
This is where Nurbak changes the game through Zero Knowledge Sharing.
In this model, encryption happens in your browser, before any data leaves your computer.
How the Nurbak flow works:
- You write your secret in the browser.
- Nurbak uses your browser's Web Crypto API to generate a unique encryption key.
- Your secret is encrypted locally. It turns into unintelligible text.
- Nurbak sends only the encrypted text to the server. The decryption key is never sent to the server.
- The key is added to the link as a "fragment" (the part after the # in the URL).
Technical Fact: Web browsers never send the "hash" (#) part of a URL to the server. This mathematically guarantees that Nurbak never sees the key needed to read your secret.
Why "Zero Knowledge" is Superior
By using a Client-Side architecture like Nurbak's, you get three insurmountable advantages:
1. Subpoena-Proof Privacy
If an authority demanded Nurbak to reveal the content of your notes, we couldn't do it. We only have encrypted garbage data. We don't have the key; you have the key (in the link).
2. Protection Against Data Breaches
If hackers managed to enter Nurbak's servers and steal the entire database, they would get nothing useful. Without the keys (which never touched the server), the data is mathematically impossible to read.
3. Technical Trust, Not Blind Trust
You don't need to take our word for it. Being client-side encryption, you can inspect the Javascript code in your browser and verify that the data leaves encrypted.
Technical Comparison
| Feature | Server-Side (Traditional) | Client-Side (Nurbak) |
|---|---|---|
| Who encrypts the data? | The Company's Server | Your Browser |
| Who has the key? | The company (and you) | Only you (in the link) |
| Can the provider read it? | Technically, yes | Mathematically, no |
| Privacy Level | Trust in the company | Zero Knowledge |
Conclusion: Demand Client-Side Encryption
In 2025, using a tool that encrypts data on the server to share secrets is an unnecessary risk. Current web technology allows for robust encryption directly in the browser.
When you use a tool to share passwords, ask yourself this question: "If the owners of this website wanted to read my secret, could they?"
- If the answer is "yes" (or "maybe"), look for an alternative.
- If the answer is "no, because they don't have the key", then you are in the right place. You are on Nurbak.
Want to try true Zero Knowledge?
Generate an encrypted link in your browser right now. We can't read it, and neither can hackers.