Crypto You'll Actually Call¶
Stub — being built out
This is a stub page. The spine — trust, chains, the one keypair primitive — lives on Who Said You Could Trust That?. This page is the opt-in depth that page promised: the handful of cryptographic operations you'll actually call (never implement), and which one you want when. Outline below; prose coming.
Reminder, because it's the whole point: you are not implementing any of this. You are calling a vetted library, correctly. This page exists so you reach for the right function and don't confuse three things that look similar and do completely different jobs.
The three things people constantly confuse¶
| You want to... | You reach for... | Reversible? | Needs a key? |
|---|---|---|---|
| Prove data hasn't changed / store a password | Hashing | No — one way | No |
| Keep data secret | Encryption | Yes — with the key | Yes |
| Prove who sent it and that it's unaltered | Signing | N/A — you verify, not reverse | Yes (private to sign, public to verify) |
The single most common mistake is reaching for one when you wanted another — encrypting a password (you wanted to hash it), or hashing something you needed to get back (you wanted to encrypt it).
What this page will cover¶
- Hashing — what a cryptographic hash guarantees and what it doesn't. Why SHA-256 is fine for integrity but wrong for passwords, and what you actually use for passwords (bcrypt / scrypt / Argon2) and why slow-on-purpose is the feature. Salts, in one paragraph.
- Symmetric encryption — one shared key, fast, for bulk data. Why you want authenticated encryption (AES-GCM, ChaCha20-Poly1305) and not raw AES, and what "don't reuse a nonce" means in practice.
- Asymmetric encryption — the keypair from the main page, expanded. Why nobody encrypts bulk data with it (it's slow) and what it's actually for: exchanging a symmetric key, and signing.
- Signing vs. encryption — the part everyone muddles. Signing with the private key proves origin; encrypting with the public key provides secrecy. Same keypair, opposite directions, completely different guarantees.
- The "just use this" recommendations —
libsodium/ NaCl, the platform crypto library, the named high-level functions to call so you never touch a mode or a padding scheme by hand.
The footnote that's load-bearing anyway¶
Why "don't roll your own" isn't gatekeeping: the failures are silent. A textbook-correct RSA implementation can leak the key through timing. A "working" encryption routine can be trivially decryptable because of a padding choice you didn't know mattered. You cannot test your way to confidence here — the test passes, the data round-trips, and the side channel is still wide open. That's the whole reason this page tells you which library to call instead of how the algorithm works.
Back to the main page for the trust structure this all serves.