Cryptography on Linux

Why this matters

Encryption protects data in two situations, and they need different tools: at rest, on a disk that could be stolen or decommissioned carelessly, and in transit, on a network somebody else can see.

You are not being asked to design cryptography — you are being asked to use it correctly, which mostly means picking current algorithms, managing keys and certificates properly, and knowing why a self-signed certificate is not a solution.

The lesson

Data at rest: full-disk encryption with LUKS

LUKS — the Linux Unified Key Setup — is the standard for encrypting block devices. LUKS2 is the current version.

cryptsetup luksFormat /dev/sdb1                  # LUKS2 by default now
cryptsetup luksOpen /dev/sdb1 securedata         # unlock → /dev/mapper/securedata
mkfs.xfs /dev/mapper/securedata
mount /dev/mapper/securedata /srv/secure
cryptsetup luksClose securedata

cryptsetup luksDump /dev/sdb1                    # header, key slots, KDF
cryptsetup luksAddKey /dev/sdb1                  # add another passphrase
cryptsetup luksRemoveKey /dev/sdb1
cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/luks.img

LUKS has key slots — up to eight passphrases can unlock the same volume, which is how you give a second administrator access, or rotate a passphrase without re-encrypting the disk. The actual encryption key is stored once, encrypted separately by each slot's passphrase.

LUKS2 uses Argon2 as its key derivation function, replacing PBKDF2. The difference matters: Argon2 is deliberately memory-hard, so it needs a large amount of RAM per guess. That specifically defeats GPU and ASIC cracking rigs, which get their advantage from running thousands of cheap parallel guesses — memory is the resource they cannot cheaply multiply.

Back up the LUKS header. It holds the encrypted master key; corrupt it and every byte on the disk is permanently unrecoverable, correct passphrase or not. luksHeaderBackup takes seconds. Store it somewhere that is not the encrypted disk.

For unlocking at boot without typing a passphrase, /etc/crypttab plus a key file works, and TPM-backed unlocking (systemd-cryptenroll) binds the key to the machine's own hardware.

Data at rest: file encryption with GPG

Where LUKS protects a whole device, GPG encrypts individual files — which is what you want for something that will be sent or stored elsewhere.

gpg --gen-key                              # create a keypair
gpg --list-keys
gpg --list-secret-keys

gpg -c secrets.txt                         # SYMMETRIC: passphrase only
gpg -e -r alice@example.com report.pdf     # ASYMMETRIC: to a public key
gpg -d report.pdf.gpg > report.pdf         # decrypt

gpg --sign document.txt                    # sign
gpg --verify document.txt.sig
gpg --armor --export alice@example.com     # export a public key as text

The two modes answer different problems. Symmetric (-c) uses one passphrase for both directions — fine for a file you will decrypt yourself, but it requires sharing the passphrase to share the file. Asymmetric (-e -r) encrypts to someone's public key, so only their private key opens it, and no secret ever has to be transmitted.

LUKS protects the disk; GPG protects the file. A stolen laptop is a LUKS problem. An emailed export is a GPG problem. They are not alternatives.

Data in transit

TLS — Transport Layer Security — is what encrypts nearly everything on a network. The version history matters because old ones are broken:

# nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

TLS 1.3 is a genuine improvement rather than an increment: it removed the weak options entirely, so a misconfiguration cannot select a broken cipher. Support 1.2 for compatibility, prefer 1.3.

OpenSSL is the library and command-line tool most things use. LibreSSL is OpenBSD's fork, created after Heartbleed with a smaller, audited codebase — a drop-in replacement you will meet on OpenBSD and in some appliances.

openssl s_client -connect example.com:443           # inspect a live TLS service
openssl s_client -connect example.com:443 -tls1_2
openssl x509 -in cert.pem -text -noout              # read a certificate
openssl x509 -in cert.pem -noout -dates             # validity window
openssl req -new -newkey rsa:4096 -nodes -keyout site.key -out site.csr
openssl rand -base64 32                             # a strong random secret

openssl s_client is the diagnostic tool: it shows the negotiated version and cipher, the certificate chain, and whether verification succeeded. When a browser complains and you need to know why, this tells you.

WireGuard is the modern VPN. Compared with IPsec and OpenVPN it is a few thousand lines rather than hundreds of thousands, lives in the kernel, uses one fixed modern cipher suite with no negotiation, and configures in about ten lines:

[Interface]
PrivateKey = <server private key>
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <client public key>
AllowedIPs = 10.0.0.2/32

wg-quick up wg0
wg show

Having no cipher negotiation is a security property, not a limitation: downgrade attacks are impossible when there is nothing to downgrade to.

Hashing

Hashing is one-way — it verifies rather than conceals.

sha256sum file.iso
sha256sum -c checksums.txt
sha512sum file.iso
md5sum file.iso            # legacy only. BROKEN for security

SHA-256 is the current default and appropriate for integrity. MD5 and SHA-1 are cryptographically broken — collisions can be produced deliberately, so an attacker can craft a different file with the same digest. They survive only as non-security checksums, and treating an MD5 match as proof of integrity is a real mistake.

An HMAC is a hash keyed with a secret:

openssl dgst -sha256 -hmac "secretkey" file.txt

The distinction is the point. A plain hash proves the file has not changed; anyone can recompute it, so anyone who alters the file can also alter the published hash. An HMAC proves the file came from someone holding the key, because you cannot compute it without that key. Integrity versus authenticity — a checksum on a compromised mirror is worthless, an HMAC is not.

For password storage the requirement inverts: you want something deliberately slow. bcrypt, scrypt, Argon2 and — in /etc/shadow — SHA-512 with many rounds. A fast hash like SHA-256 is exactly wrong for passwords, because fast is what the attacker wants.

Removing weak algorithms

update-crypto-policies --show               # RHEL: current policy
update-crypto-policies --set DEFAULT:NO-SHA1
update-crypto-policies --set FUTURE          # aggressive

RHEL's system-wide crypto policies set the floor for OpenSSL, GnuTLS, OpenSSH and Kerberos in one place, rather than per-application. LEGACY, DEFAULT, FUTURE and FIPS are the levels.

Elsewhere it is per-service: Ciphers and MACs in sshd_config, ssl_protocols in nginx. The principle is the same — remove the weak option rather than preferring the strong one, because anything still offered can be negotiated.

Certificates

A certificate binds a public key to an identity, signed by a certificate authority the client already trusts. That chain of trust is the entire mechanism.

Trusted root certificates ship with the system:

ls /etc/pki/ca-trust/source/anchors/       # RHEL
ls /usr/local/share/ca-certificates/       # Debian
update-ca-trust                            # RHEL: rebuild the bundle
update-ca-certificates                     # Debian

Adding your organisation's internal CA here is what makes internally-issued certificates verify without warnings — the correct fix for internal services, rather than telling everyone to click through.

No-cost certificates come from Let's Encrypt, issued by automated domain validation and valid for 90 days, with renewal automated:

certbot --nginx -d example.com
certbot renew --dry-run

The short lifetime is deliberate: it forces automation, and automation means renewal does not depend on somebody remembering. Commercial certificates cost money and add organisation validation, extended validation, warranties and support — worth it where the identity of the organisation rather than control of the domain is what needs proving.

Avoiding self-signed certificates. A self-signed certificate encrypts the connection but proves nothing: it is signed by itself, so anyone can produce one claiming any name. Every client shows a warning, and the real damage is what that trains people to do:

• Users learn to click through certificate warnings, which is exactly the behaviour a real attacker needs.
• Automated clients get --insecure or verify=False added to make them work, and that flag disables verification permanently and everywhere in that code path.

A self-signed certificate gives you encryption without authentication, and authentication is what stops a machine-in-the-middle. Since Let's Encrypt is free and an internal CA is a morning's work, there is now no cost argument for one outside a lab.

On the exam

• LUKS encrypts block devices; GPG encrypts files. Not alternatives.
• LUKS2 uses Argon2, which is memory-hard and therefore resistant to GPU cracking. Back up the header or the data is unrecoverable.
• LUKS key slots allow several passphrases for one volume.
• TLS 1.2 and 1.3 only; SSL and TLS 1.0/1.1 are disabled.
• openssl s_client -connect host:443 inspects a live TLS service.
• WireGuard has no cipher negotiation, so downgrade attacks are impossible.
• MD5 and SHA-1 are broken for security. SHA-256 for integrity.
• A hash proves integrity; an HMAC proves authenticity because it needs a key.
• Password hashing wants a slow function — Argon2, bcrypt, SHA-512 with rounds — not a fast one.
• Self-signed certificates give encryption without authentication, and train people to ignore warnings.