{"uuid": "b17aeb61-83c9-488d-bd0e-f0aa81e13c06", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2014-0160", "type": "seen", "source": "https://gist.github.com/boyce-huang/36de7299b278cadaa6c947306a49017d", "content": "# Base64 Is Not Encryption\n\nEncoding, hashing, encryption, and signing are four different tools that get mixed up constantly. Use the wrong one and you leak.\n\n- **Encoding (Base64)** \u2014 change the representation; zero secrecy. Anyone can reverse it.\n- **Hashing (SHA-256, SM3)** \u2014 a one-way fingerprint; verifies integrity, stores passwords; not reversible.\n- **Encryption (AES-256-GCM, SM4-GCM)** \u2014 a lock; you need the key to read it back.\n- **Signing (Ed25519, RSA)** \u2014 a seal; proves *who* and *not changed*; publicly verifiable, not secret.\n\n## Two questions tell them apart\nDoes it need a key? Can you reverse it?\n- Encoding: no key, reversible\n- Hashing: no key, not reversible\n- Encryption: key required, reversible with it\n- Signing: key required, verifiable, not secret\n\n## Real case: Heartbleed (CVE-2014-0160, 2014)\nOpenSSL leaked up to 64KB of process memory per request \u2014 potentially private keys. Everything relying on that key for secrecy/signing was compromised; encoding and hashing (no key) were unaffected.\n\nPractices from building **Autional**, an open-core identity layer \u2014 https://www.autional.com\n\n> Reference: RFC 4648, FIPS 180-4, FIPS 197 / NIST SP 800-38D, RFC 8032.", "creation_timestamp": "2026-10-09T05:11:22.000000Z"}