“I turned it into gibberish, so it’s encrypted now” — if that sounds familiar, it’s probably Base64. Anyone can reverse it, no key required. Encoding, hashing, encryption and signing are four different tools that get mixed up constantly. Use the wrong one and you leak.
The four tools
- Encoding (Base64) — change the representation so binary data can travel through text-only channels. Provides zero secrecy.
- Hashing (SHA-256, SM3) — a one-way fingerprint. Verifies integrity and stores passwords. You can’t reverse it.
- Encryption (AES-256-GCM, SM4-GCM) — a lock. You need the key to read it back.
- Signing (Ed25519, RSA) — a seal. Proves who sent it and that it wasn’t changed. Publicly verifiable, but not secret.
Two questions tell them apart
Does it need a key? Can you reverse it?
| Tool | Needs a key? | Reversible? |
|---|---|---|
| Encoding | No | Yes (trivially) |
| Hashing | No | No |
| Encryption | Yes | Yes (with the key) |
| Signing | Yes | Verifiable, not secret |
Use the wrong one and you leak
- Encoding as secrecy → Base64 reverses in one step.
- Hashing as signing → you can’t tell who sent it.
- Encryption to store passwords → a key leak becomes plaintext.
- Signing as encryption → signatures don’t hide anything.
A real case: Heartbleed (CVE-2014-0160)
In 2014, OpenSSL’s heartbeat lacked bounds checking, leaking up to 64 KB of process memory per request — potentially including private keys. Everything that relied on that key for secrecy or signing was compromised; encoding and hashing, which need no key, were unaffected. Encryption and signing both hang on the key.
Engineering practice
- Base64 only for transport/display — never for secrecy.
- SHA-256 / HMAC-SHA256 / SM3 for integrity and password storage (with bcrypt/argon2 + salt).
- Only AEAD ciphers for encryption (AES-256-GCM / SM4-GCM).
- Ed25519 for signing.
These practices come from building Autional, an open-core identity layer — https://www.autional.com
Reference: RFC 4648 (Base64), FIPS 180-4 (SHA-2), FIPS 197 (AES) / NIST SP 800-38D (GCM), RFC 8032 (Ed25519); Heartbleed (CVE-2014-0160).
Top comments (0)