8.1 Encryption Concepts for Personal and Shared Data
Two Families of Keys
Encryption turns plaintext into ciphertext, and every scheme answers one question: who holds the key? Symmetric ciphers use a single shared secret to encrypt and decrypt -- fast, and fit for bulk data, but every pair of communicants needs a secret that first has to be exchanged securely. Asymmetric systems split the key: a public half anyone may publish and a private half only the owner keeps, so a peer encrypts toward the public key and only the private key can recover the data. Asymmetric math is orders of magnitude slower and can only process small payloads, which is why no real protocol encrypts a file or a video stream directly with RSA or ECC.
Symmetric Workhorse: AES-256-GCM
AES-256-GCM is an AEAD mode: it encrypts with AES in counter mode and appends an authentication tag computed over the ciphertext plus any associated data. A flipped bit fails the tag check and the stack discards the record, so tampering is detected, not silently accepted. GCM demands a unique nonce per message under a given key; nonce reuse under the same key is catastrophic -- it leaks XOR relationships and exposes the authentication subkey. Treat the 256-bit key as brute-force proof; the practical risks are key handling and nonce discipline, never the cipher math itself.
Asymmetric Role: Transport and Agreement
Asymmetric crypto rarely carries data; it carries keys. RSA-KEM with OAEP padding wraps a session key: the sender encrypts 32 random bytes under the recipient's RSA public key, and only the matching private key unwraps them. Key agreement is more dynamic: in ECDHE each side combines a freshly generated ephemeral keypair with the peer's public value and both derive the same shared secret without ever transmitting it. Because ephemeral keys are destroyed after the session, recorded traffic cannot be decrypted later even if a long-term key is compromised -- forward secrecy.
The Hybrid Handshake (TLS Key Schedule)
Real protocols chain both families, and TLS 1.3 shows the pattern cleanly. The handshake performs ECDHE to agree on a shared secret, then the HKDF key derivation function expands it into independent keys -- separate client-to-server and server-to-client record keys, plus distinct resumption and exporter keys -- with AES-256-GCM protecting application records. Public-key signatures (ECDSA or RSA) only authenticate the handshake; bulk payload encryption is always symmetric. Personal tools use the identical hybrid shape: PGP and age encrypt the file payload under a symmetric session key, then wrap that key once per recipient public key.
Architecture Diagram
Key Takeaways
- Symmetric ciphers do the bulk work; asymmetric ciphers solve the key-distribution problem around them.
- AES-256-GCM is AEAD: it detects tampering, and reusing a nonce under one key is catastrophic.
- RSA-KEM wraps (transports) a session key; ECDHE agrees on one without ever transmitting it.
- TLS 1.3 derives independent per-direction record keys via HKDF; public-key signatures only authenticate.
- Ephemeral key exchange gives forward secrecy: today's captured traffic stays safe after tomorrow's key leak.