The Problem with Passwords
Cryptography has three jobs:
- Hide the content so nobody else can read it
- Prove it wasn't tampered with during storage or transmission
- Stay secure even if an attacker sees everything except your secret
That secret is usually a password. And here's the uncomfortable truth: human-made passwords are terrible cryptographic secrets.
They're short. They're predictable. They get reused. They can be guessed or brute-forced. People pick "Summer2024!" instead of "X7$mK9#pQw2@nF5&".
The entire architecture of Ephemeral Notes is built around compensating for this fundamental weakness.
Why Passwords Aren't Keys
Let's get this straight:
Password: A string chosen by a human. Weak, memorable, often reused. "ilovecats123"
Cryptographic Key: Fixed-size, random, unpredictable data. "7a3f9c2e8b1d4f6a9c3e7b2d8f1a5c9e4b7d2a6f8c3e1b9d7f4a2c8e5b1d6f9a"
Cryptographic algorithms can't work with passwords directly. They need keys. So we need a secure way to transform one into the other.
Enter Password Hashing
Why Regular Hashes Don't Work
You've probably heard of SHA-256 or MD5. They're fast—really fast. Bitcoin miners calculate billions of hashes per second. That's great for blockchain verification.
But it's terrible for password security.
If an attacker steals your encrypted file, they can test billions of passwords per second against it. "password123"? Checked in 0.0001 seconds. "ilovecats123"? Done before you blink.
What We Need: crypto_pwhash
Instead of speed, we need slowness. We need memory hunger. We need something that's a pain to parallelize.
This is where crypto_pwhash comes in. It's specifically designed to make brute-forcing passwords economically unprofitable. An attacker would need to spend more money on computing power than your data is worth.
Argon2: The Gold Standard
Argon2 is the algorithm behind crypto_pwhash. It won the Password Hashing Competition in 2015—basically the Olympics of password security.
Why it's good:
- Resistant to GPUs and specialized hardware (ASICs)
- Modern and actively maintained
- Three variants for different security models
The variants:
- Argon2i: Protects against timing attacks (side-channel attacks)
- Argon2d: Maximum resistance to GPU cracking
- Argon2id: Hybrid approach — this is what we use Argon2id gives us the best of both worlds: resistance to both timing attacks and GPU brute-forcing.
Making It Even Slower (On Purpose)
We configure Argon2id with two parameters:
OPSLIMIT
How many operations to perform. More operations = slower derivation.MEMLIMIT
How much RAM to use. More memory = harder to parallelize on GPUs.
The philosophy: You'll enter your password maybe once a day. That's fine if it takes half a second. But an attacker needs to try millions of passwords, and half a second times a million is... expensive.
We set the limits to "MODERATE"—not paranoid, not lazy. Just enough to make your laptop wait a moment, and an attacker's server farm cry.
The Nonce Problem
Okay, we have a key now. Problem solved?
Not quite.
If you encrypt two different messages with the same key and the same "starting state," patterns emerge. Cryptographers can analyze those patterns and break your encryption.
This is where the nonce comes in.
What's a Nonce?
Nonce = Number used ONCE
It's a random (or at least unique) value that you use exactly one time with each key. Think of it as ensuring every encryption operation is unique, even if you're using the same password.
Important: The nonce is NOT a secret. You can store it right next to your encrypted data. It's not there to hide anything—it's there to prevent patterns.
Analogy: It's like adding a random starting position to a lock. The key still works, but the mechanism starts from a different place each time.
XChaCha20: Fast and Paranoid
Now we get to the actual encryption algorithm: XChaCha20-Poly1305.
Let's break that down.
ChaCha20
ChaCha20 is a stream cipher designed by Daniel J. Bernstein (a legend in crypto). Why it's good:
- Fast: Even on weak processors
- Simple: No complex lookup tables (S-boxes) that can leak timing information
- Secure: Resistant to timing attacks and side-channel attacks
The X in XChaCha
XChaCha is an extended version of ChaCha20. The main improvement?
> Huge nonces: 192 bits (24 bytes)
Why does this matter? With a 192-bit nonce, you can generate them completely randomly and the chance of ever getting a duplicate is... basically zero. You'd need to encrypt 2^96 messages before you'd have even a tiny chance of collision.
That's more messages than atoms in a small country.
Philosophy: "Better to have way too much space than rely on perfect randomness."
Poly1305: The Authentication Tag
Here's the thing about encryption: it only hides data. It doesn't prove the data wasn't tampered with.
An attacker could flip bits in your encrypted file. When you decrypt it, you'd get garbage—but how would you know it was garbage vs. a wrong password?
Enter Poly1305: a message authentication code (MAC).
How It Works
When you encrypt, Poly1305 generates an authentication tag — a cryptographic fingerprint of your encrypted data. This tag is stored alongside the ciphertext.
When you decrypt:
- You compute what the tag should be
- You compare it to the stored tag
- If they don't match exactly, something was tampered with—reject immediately
This is called AEAD: Authenticated Encryption with Associated Data.
Result: If someone modifies even a single bit of your encrypted note, decryption fails instantly. No garbage output, no confusion—just a clear "this has been tampered with" error.
Putting It All Together
Here's what happens when you create an ephemeral note:
Why This Design?
Every choice compensates for human weakness:
Weak passwords?
→ Argon2id makes them expensive to brute-force
Same password reused?
→ Unique salt per note prevents rainbow table attacks
Patterns in encryption?
→ Random nonces ensure every encryption is unique
Tampered data?
→ Poly1305 catches any modifications instantly
Side-channel attacks?
→ ChaCha20 is timing-attack resistant
What We DON'T Protect Against
Let's be honest about what this system can and can't do:
We Protect Against:
✅ Brute-forcing the password
✅ Forensic recovery after deletion
✅ Accidental backups to the cloud
✅ Someone finding your encrypted file
We DON'T Protect Against:
❌ Malware running on your computer
❌ Screen recording while the note is open
❌ Memory dumps during decryption
❌ Someone with physical access + root privileges
This is intentional. We're not selling snake oil. If your computer is compromised while the note is open, no software can save you. That's physics, not a bug.
What we guarantee is this: Once a note self-destructs, it's cryptographically gone. Not "deleted," not "overwritten," but mathematically unrecoverable.
The Self-Destruction Mechanism
When a note hits its limit (max opens or TTL expiry):
- The encryption key is zeroed out in memory (Not just deleted—every byte overwritten with zeros)
- The file is overwritten with random data Multiple passes, different random bytes each time
- The file header is corrupted Even if someone recovers the bits, the structure is broken
- The file is deleted
On modern SSDs, physical overwriting isn't guaranteed due to wear-leveling. But here's the thing: without the key, the encrypted data is just random noise anyway.
The multi-pass overwrite is defense-in-depth. Even if somehow the bits persist, you'd need to:
- Recover the exact file structure
- Crack 256-bit XChaCha20 (computationally infeasible)
- Do it without the salt or nonce working properly It's paranoia layered on top of math.
Why This Matters
Most "secure note" apps lie to you. They promise:
- "Military-grade encryption!" (meaningless marketing)
- "Unhackable!" (nothing is unhackable)
- "Your data is 100% safe!" (under undefined conditions) We don't do that.
Ephemeral Notes is built on a simple principle: Respect the limits of what's possible, and be honest about what's not.
Your password is weak—we assume that and design around it. Your computer might be compromised—we can't fix that, so we don't claim to. You might want to read a note twice—we let you set that limit yourself.
What we can promise:
- Your note is encrypted with algorithms that actual cryptographers trust
- Your password is strengthened with techniques that make brute-forcing impractical
- Once the note self-destructs, it's gone in a way that no "undelete" tool can reverse
For the Curious
If you want to verify any of this, the entire project is open source. Every line of crypto code can be audited. We use:
- libsodium: Industry-standard crypto library (used by Signal, GitHub, and more)
- Argon2id: Winner of Password Hashing Competition 2015
- XChaCha20-Poly1305: Modern AEAD cipher recommended by cryptographers No custom crypto. No "we made it better." Just proven, peer-reviewed algorithms used correctly.
The Bottom Line
Ephemeral Notes is not about perfect security. Perfect security doesn't exist.
It's about honest security:
- We know passwords are weak, so we strengthen them mathematically
- We know files can be recovered, so we encrypt and then destroy properly
- We know attackers will try to brute-force, so we make it unprofitable If you need to share a secret once and have it vanish forever — this is how you do it right.
Not with magic. Not with marketing. Just math, engineering, and honesty about what's actually possible.
The code is open source. The algorithms are public. The design choices are documented. If you don't trust it, audit it. That's the point.
Top comments (0)