Skip to content
Lucas Mauro

Type to search…

↑↓ to navigate
Esc

Notes on Symmetric Encryption

What it does, why it's useful and where it fails.

security 2 min read

Every message we send across the internet travels like a postcard: readable by any router, proxy or curious bystander along the way. Base64 cannot help us hide the content (it merely changes the envelope), and Hashing cannot either (a fingerprint can never be turned back into the message). What we need is something in between: data that becomes unreadable on departure and readable again only on arrival, for whomever holds the right key. That is symmetric encryption, and because it runs fast (modern CPUs even ship dedicated instructions for it), it is the standard answer whenever confidentiality matters: HTTPS traffic, full-disk encryption, password managers and encrypted messaging all rely on it.

Suppose we want to send Bob the message "meet me at noon". Beforehand, we agree with him on a secret key; then we scramble the message with it before sending, and Bob unscrambles it with the very same key upon arrival. Anyone reading in between sees only noise:

encryption:  plaintext + key → ciphertext
decryption:  ciphertext + key → plaintext

Note that the algorithm itself is public knowledge; the key is the only secret worth protecting (an old idea known as Kerckhoffs’s principle).

  • AES: arguably the industry standard; hardware-accelerated, with key sizes from 128 up to 256 bits;
  • ChaCha20: its software-friendly rival, popular on mobile devices and in WireGuard;
  • Anything older, such as DES, 3DES or RC4: broken or deprecated.

One extra choice hides behind the algorithm: the “mode”, which chains blocks of ciphertext together so patterns do not leak through. Modern modes such as GCM also detect tampering, so they are the ones worth picking.

Let’s send our message to Bob through OpenSSL’s eyes:

Terminal window
echo "meet me at noon" > message.txt


openssl enc -aes-256-cbc -salt -pbkdf2 \
  -in message.txt -out message.enc -pass pass:hunter2
# No output; message.enc is now binary noise


openssl enc -d -aes-256-cbc -pbkdf2 \
  -in message.enc -out decrypted.txt -pass pass:hunter2


cat decrypted.txt
# meet me at noon

Anyone intercepting message.enc sees only gibberish, and a wrong password makes decryption fail outright rather than leaking fragments of our lunch plans. Two flags do quiet work here: -pbkdf2 derives a proper AES key from our password through many rounds of Hashing (AES needs raw bytes, not words humans choose), and -salt adds randomness (as seen in Salt) so the same message never encrypts to the same bytes twice.

Our little story has one loose end: how did Bob get the key? Handing it over the network would expose it to exactly the eavesdroppers we are hiding from. This is the key distribution problem, solved in practice by Asymmetric Encryption: protocols such as TLS use it during the handshake purely to agree on a temporary symmetric key, then switch back to symmetric encryption for all the actual data.

Comments