Cryptography basics

Before you read. You type a password. Something on the machine compares it against whatever is on file for your account and either lets you in or does not.

But the machine is not supposed to have your password on file. That is the one rule everybody has heard. And yet the comparison plainly happens, thousands of times a second, on machines whose administrators genuinely cannot tell you what your password is.

So what is in that file, and how does comparing against it work?

What is stored is not the password. It is the result of pushing the password through a function that runs easily in one direction and cannot be run in the other, stored alongside the recipe for repeating the calculation.

Checking a password is therefore not a lookup. It is a re-computation: take the password that was offered, read the algorithm and the salt out of the stored field, run the same calculation on the offered password, and compare the two results. Equal results mean equal inputs. Nothing anywhere held the password, and nothing can recover it, which is why every system you have ever used offers to reset a forgotten password and never to tell you it.

That one-way operation is hashing, and half the confusion in this subject comes from filing it under “encryption”. They are different operations with different purposes, and the difference is not strength.

Some words you will need

plaintext

The readable thing, before anything is done to it. The opposite is ciphertext.

digest

The output of a hash function. Fixed length, whatever the input was. Also called a hash, a checksum, or a fingerprint.

salt

Random bytes mixed into a password before hashing, stored in the clear beside the result. Not a secret.

work factor

A deliberate cost setting that makes a password hash slow. Higher costs the attacker more than it costs you.

HMAC

A hash with a key mixed in, so only a holder of the key can produce or check it.

key pair

Two mathematically linked keys. One is published, one never leaves the machine that made it.

signature

A value produced with a private key that anybody holding the matching public key can check. Proves integrity and origin together.

collision

Two different inputs with the same digest. A hash function is broken when somebody can produce one on purpose.

AEAD

An encryption mode that authenticates as well as encrypts, so tampering is detected rather than decrypted into garbage. AES-GCM and ChaCha20-Poly1305 are the two you will meet.

key agreement

Two parties each combine their own private key with the other's public key and arrive at the same shared secret without transmitting it. Diffie-Hellman is the name.

forward secrecy

The property that a private key stolen later cannot decrypt traffic recorded earlier, because the session key was ephemeral and was destroyed.

pepper

A secret value mixed into every password hash and stored outside the database. Not a salt: it is one value for everybody, and it is secret.

What breaks without this

You store something you cannot afford to store. A password database that can be turned back into passwords is a breach waiting for somebody else’s timetable, and the difference between that and a safe one is a design decision made once, early.

You reach for the wrong operation. “Encrypt the passwords so we can recover them” and “hash the file so nobody can read it” are both wrong, in opposite directions, and both get proposed in real meetings.

You trust a checksum that proves nothing. A SHA-256 line published beside a download, on the same server, over the same connection, is checked by exactly the same people who could change it. Knowing why a signature is different is the whole point of the second half of this topic.

You keep a dead algorithm alive. MD5 and SHA-1 still work, still ship, and still appear in scripts. Knowing precisely which property broke, and which one did not, is what separates a defensible answer from a repeated slogan.

Two operations that look alike and are not

Written out as a table, because the exam and most interviews want it that way:

“Decrypt this hash” is not a hard problem, it is not a problem at all. There is no operation with that signature. Sites offering to reverse an MD5 are running a lookup table of things somebody already hashed; give them a digest of something nobody has hashed before and they have nothing.

What a hash actually promises

Four properties, and each of them is doing a specific job.

Deterministic. The same input gives the same digest, on any machine, in any year, in any implementation. Without this a password could never be checked twice.

Fixed length. A digest is a fixed number of bits no matter how large the input was.

Avalanche. A one-bit change to the input changes about half the output bits, and the change is not localised, ordered, or predictable.

Preimage resistance. Given a digest, there is no practical way to find an input that produces it, other than guessing inputs and hashing them.

The first and third are visible in one command, and they are worth predicting before reading.

# Debian 13 (trixie), x86_64
$ echo -n hello | sha256sum; echo -n hello | sha256sum; echo -n hellp | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  -
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  -
fdd7585e08c4e2afd71dcabdb4636c89d557a3f42db9e2040c8bbd1708aa4ce7  -

The first two lines are identical, which is determinism. The third shares nothing with them (not a prefix, not a pattern, not a length difference) which is avalanche. hello and hellp are neighbours; 2cf24dba... and fdd7585e... are not.

This is why a digest is useless as an approximate comparison. “The hashes are nearly the same, so the files are nearly the same” is not a sentence anybody can say. Digests are equal or they are unrelated, and there is no third case.

Fixed length is equally easy to see, and more surprising:

# Debian 13 (trixie), x86_64
$ ls -l /tmp/big; sha256sum /tmp/big; echo -n hi | sha256sum
-rw-r--r--. 1 root root 10000000 Aug  8 16:50 /tmp/big
b4de47e75c706647957e18540b96f94fa8c03847e801a882b5f1420cd35ecd04  /tmp/big
8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4  -

Ten million bytes and two bytes produce the same amount of output. SHA-256 gives 256 bits, written as 64 hexadecimal characters, always. That is what makes a digest a usable identifier: you can put one in a database column, print it on a release page, or compare a million of them without knowing anything about what was hashed.

It also tells you something that people find uncomfortable at first. There are more possible ten-megabyte files than there are 256-bit digests, so collisions must exist mathematically. The claim a hash function makes is not that they do not exist; it is that nobody can find one.

The digest belongs to the input, not to the tool. Two different programs, same answer:

# Debian 13 (trixie), x86_64
$ cat /tmp/file; sha256sum /tmp/file; openssl dgst -sha256 /tmp/file
the quick brown fox jumps over the lazy dog
1153a4080f1fcb04425aa0b841c2b14606fe6df25d9076d2a1face2d5af57129  /tmp/file
SHA2-256(/tmp/file)= 1153a4080f1fcb04425aa0b841c2b14606fe6df25d9076d2a1face2d5af57129

Note that OpenSSL 3 calls it SHA2-256 rather than SHA-256, which is the formally correct family name and occasionally makes people think they have computed something different. They have not. And a third tool, formatting it differently again:

# Debian 13 (trixie), x86_64
$ echo -n hello | gpg --print-md SHA256
2CF24DBA 5FB0A30E 26E83B2A C5B9E29E 1B161E5C 1FA7425E 73043362 938B9824

Uppercase, split into eight groups, same 64 characters. gpg --print-md is formatting for humans reading a fingerprint aloud. Presentation differences like this cause more “the checksums do not match” reports than actual mismatches do.

The family, and the number in the name

The number is the digest length in bits, and that is nearly all it means:

# Debian 13 (trixie), x86_64
$ echo -n hello | md5sum; echo -n hello | sha256sum; echo -n hello | sha512sum
5d41402abc4b2a76b9719d911017c592  -
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  -
9b71d224bd62f3785d96d46ad3ea3d73319bfbc2890caadae2dff72519673ca72323c3d99ba5c11d7c7acc6e14b8c5da0c4663475c2e5c3adef46f73bcdec043  -

SHA-2 is the family, and SHA-256 and SHA-512 are members of it. SHA-3 is not a bigger SHA-2; it is a completely different construction, standardised in 2015 as insurance in case a structural weakness were ever found in SHA-2. None has been. Both are current.

The counter-intuitive row is SHA-512. In pure software it is faster than SHA-256 despite the longer output, because it works on 64-bit words and gets through more input per round. That was the standing advice for years, and hardware has since complicated it: the x86 SHA-NI instructions accelerate SHA-1 and SHA-256 and originally did not cover SHA-512 at all, so on most server CPUs shipped since about 2017 the shorter digest is the quicker one. Do not repeat either version of the claim about a specific machine without measuring it; openssl speed sha256 sha512 settles it in under a minute on the machine that matters. If you need one digest for general use and have no other constraint, either is defensible, and SHA-256 wins on how many other systems expect exactly 64 characters.

Nothing removed the old ones from the toolbox:

# Debian 13 (trixie), x86_64
$ openssl dgst -list | head -4
Supported digests:
-blake2b512                -blake2s256                -md4                      
-md5                       -md5-sha1                  -ripemd                   
-ripemd160                 -rmd160                    -sha1                     

md4, md5, and sha1 are all still there and still work. Availability is not endorsement. The library implements what the world’s existing files and protocols contain; deciding what this machine will accept is a policy question handled somewhere above the library, which is the last section of this topic.

Back to the password

Everything above now cashes out. Create a user, set a password, and look at what landed on disk:

# Debian 13 (trixie), x86_64
$ useradd -m demo; echo 'demo:hunter2' | chpasswd; grep '^demo:' /etc/shadow
demo:$y$j9T$2z.ahBivOfVZwYyB/1NIL0$QPvE5jjyobfJpdMopFl4C9cBhwH66szvFai9D2jNan6:20673:0:99999:7:::

The second colon-separated field is the whole answer, and it has four parts of its own, separated by more dollar signs:

$y$j9T$2z.ahBivOfVZwYyB/1NIL0$QPvE5jjyobfJpdMopFl4C9cBhwH66szvFai9D2jNan6
 |   |            |                             |
 |   |            |                             the hash itself
 |   |            the salt, stored in the clear
 |   the algorithm's cost parameters
 the algorithm: y is yescrypt

Read that as a recipe, not as a secret. Three of the four fields are instructions for repeating the calculation, and they are deliberately readable. Only the last field is the output. When demo types a password, the login stack reads y, reads j9T, reads the salt, runs yescrypt over the offered password with exactly those settings, and compares the result to the last field. Equal means the same password was typed. Nothing was decrypted, because there was nothing to decrypt.

The leading identifier is worth memorising, because it is the fastest audit you can run on an inherited machine:

That last row is the one that catches people, and it links straight back to lesson 28: a ! prefix is how usermod -L locks an account, and * is what a system account with no password ever set looks like.

Now the salt, which is the part most explanations get wrong. Same password, two salts chosen by hand so you can see what varies:

# Debian 13 (trixie), x86_64
$ openssl passwd -6 -salt abcdefgh 'hunter2'; openssl passwd -6 -salt zyxwvuts 'hunter2'
$6$abcdefgh$M/eYsB4rVXAm3ZNc88J.UD9rCKAT6FB1rahiwJCHtEndQNORCub5qhjxn50qbqVVthkM.9HpEwtf0t.iV9uH0/
$6$zyxwvuts$zC.zWoufBLT293YNjAHSR04HNWS8v9KTM9kVGc6Nnw7v7GsNahLSG0Ye5Y909iT3BTAWFZuW2FAf4KpvjVjap.

The same password, twice, and the two results have nothing in common. The salt you can see, abcdefgh and zyxwvuts, is right there in the output, readable by anybody who can read the file.

And because the salt is part of the recipe rather than part of the secret, the recipe travels. Here is the first of those two commands run on a completely different distribution:

# AlmaLinux 10.2, x86_64
$ openssl passwd -6 -salt abcdefgh 'hunter2'
$6$abcdefgh$M/eYsB4rVXAm3ZNc88J.UD9rCKAT6FB1rahiwJCHtEndQNORCub5qhjxn50qbqVVthkM.9HpEwtf0t.iV9uH0/

Character for character identical, on a different distribution, a different libcrypt build, and a different OpenSSL. That is determinism doing its job: $6$ plus that salt plus hunter2 has exactly one answer everywhere, which is what makes it possible to move an /etc/shadow between machines and have everybody still able to log in.

That is not a mistake. A salt is not a secret and was never intended to be one. Its job is narrow and specific:

• It defeats precomputation. An attacker cannot compute a table of hashes for the ten million most common passwords once and then use it against every account in the world, because every account salts differently. The table would have to be rebuilt per salt, which is the same work as attacking that one account directly.
• It breaks cross-account comparison. Without a salt, two users with the same password have the same stored hash, so a leaked database instantly reveals which accounts share a password, and cracking one cracks all of them.

And equally important, what a salt does not do:

• It does not slow down an attack on one specific password. The attacker has the salt. Guessing against a single account costs exactly the same salted or not. Only the work factor changes that, which is the next panel.
• It does not need to be secret, long, or memorable. It needs to be unique per password and unpredictable. Sixteen random characters is plenty.

Real tools do not let you choose the salt, and that is a feature:

# Debian 13 (trixie), x86_64
$ mkpasswd -m yescrypt 'hunter2'; mkpasswd -m yescrypt 'hunter2'
$y$j9T$Wc3qWDOFQwNl7amE7qiai1$WLDSZvBu3SkAZzCbBOzReQf/aENO1rAJXbKl8KAGeZ6
$y$j9T$rxoJ3uhaCDZXnmPqGz0hH.$NwT6CJPzPQUkO8CC8Derznsd6KouWRQqiLiyvGtD.a9

Same password, two runs, two completely different results, because a fresh random salt was generated each time. A useful consequence: you cannot compare two password hashes to see whether two people chose the same password. Even your own hash from five minutes ago will not match the one you generate now.

What algorithms a machine actually offers is a property of its C library, not of your imagination:

# Debian 13 (trixie), x86_64
$ mkpasswd -m help | head -12
Available methods:
yescrypt        Yescrypt
gost-yescrypt   GOST Yescrypt
scrypt          scrypt
bcrypt          bcrypt
bcrypt-a        bcrypt (obsolete $2a$ version)
sha512crypt     SHA-512
sha256crypt     SHA-256
sunmd5          SunMD5
md5crypt        MD5
bsdicrypt       BSDI extended DES-based crypt(3)
descrypt        standard 56 bit DES-based crypt(3)

mkpasswd -m help is asking libcrypt what it supports. The obsolete entries are listed because old /etc/shadow files still contain them and have to keep verifying; that is a completely different question from what a new password should be created with, which /etc/login.defs decides.

A hash with a key

A plain digest has one weakness that has nothing to do with the algorithm: anybody can compute it. If an attacker changes a file, they can recompute the digest and change that too. A digest proves the file has not changed by accident. It proves nothing about deliberate change unless the digest itself is protected.

Mixing a secret key into the hash fixes that:

# Debian 13 (trixie), x86_64
$ openssl dgst -sha256 -hmac 'secretkey' /tmp/file; openssl dgst -sha256 -hmac 'secretkez' /tmp/file
HMAC-SHA2-256(/tmp/file)= da49116d0645e941f1bd30cbd6ba6004bc84accab5b615a1de3aab06525713c4
HMAC-SHA2-256(/tmp/file)= a11b23e3ee12b6a6b6e5e07c32430ec3ace4ab30e46730bbdeea7e46271960fc

The same file, the same algorithm, two keys differing by one character, and two unrelated results. Anybody holding secretkey can produce or check that value. Anybody who does not, cannot, not by trying, not by being clever about the file.

That is HMAC, and it is everywhere once you know the name: AWS request signing, a JWT with alg: HS256, the RADIUS Message-Authenticator attribute, IPsec integrity, the record MAC in TLS 1.2’s CBC suites, and HKDF, the key derivation step inside TLS 1.3, which is built entirely out of HMAC. Whenever two parties already share a secret and need to know a message was not altered in transit, HMAC is the answer, and it is far cheaper than a signature.

HMAC does not need a strong hash underneath it. HMAC-MD5 has no practical break even now, because HMAC’s security rests on the key rather than on collision resistance, and RADIUS still uses it. That is a genuinely surprising result and the exam will not ask you to defend it; do not use it as an argument for keeping MD5 anywhere else.

HMAC is not the key glued onto the front of the message. It hashes twice, with the key mixed in differently each time. The reason is a real property of the SHA-2 family called length extension: given sha256(secret + message) and the length of secret, an attacker can compute sha256(secret + message + extra) for content of their choosing, without ever knowing the secret. The naive construction is therefore forgeable, the nested one is not, and this is a mistake that has shipped in production APIs more than once. Use -hmac, or your language’s HMAC function, rather than concatenating anything yourself.

Encryption, which does go backwards

Now the other operation. Encrypt a file with a password:

# Debian 13 (trixie), x86_64
$ openssl enc -aes-256-cbc -pbkdf2 -in /tmp/plain -out /tmp/cipher -pass pass:demo; ls -l /tmp/plain /tmp/cipher; xxd /tmp/cipher | head -3
-rw-r--r--. 1 root root 64 Aug  8 17:05 /tmp/cipher
-rw-r--r--. 1 root root 47 Aug  8 17:05 /tmp/plain
00000000: 5361 6c74 6564 5f5f 21c0 7425 d63e 483c  Salted__!.t%.>H<
00000010: 7ea0 a0c3 faf9 e3f6 e31e 3985 fffc f1f5  ~.........9.....
00000020: 62ae 7061 2c50 e34f e7ec 964a 0d61 4cad  b.pa,P.O...J.aL.

Three things to read there. The output is binary, not text: xxd is showing bytes that are not characters. It begins with the literal string Salted__ followed by the random salt OpenSSL generated, which is that same idea again: the salt is stored in the clear with the ciphertext because decryption needs it. And 47 bytes of plaintext became 64 bytes of ciphertext: 8 bytes of magic plus the 8-byte salt for the header, then the plaintext padded up from 47 to the next multiple of the 16-byte AES block, which is 48.

-pbkdf2 is not optional decoration. A password is not a key, and something has to turn one into the other. With -pbkdf2 OpenSSL runs PBKDF2-HMAC-SHA256 over the password and salt, 10000 iterations by default and settable with -iter. Leave the flag off and it silently falls back to EVP_BytesToKey, a single-pass MD5 construction from the 1990s with no cost parameter at all, and you get a warning-free file that a GPU chews through. This is the same work factor argument as /etc/shadow, appearing in a completely different command, and the flag is the whole difference.

The whole point is that it comes back:

# Debian 13 (trixie), x86_64
$ openssl enc -d -aes-256-cbc -pbkdf2 -in /tmp/cipher -out /tmp/back -pass pass:demo; diff /tmp/plain /tmp/back && echo 'round trip identical'
round trip identical

diff says the files are identical. That is the difference from hashing stated as plainly as it can be: the original is recoverable, exactly, given the key. With the wrong key it is not:

# Debian 13 (trixie), x86_64
$ openssl enc -d -aes-256-cbc -pbkdf2 -in /tmp/cipher -out /tmp/back -pass pass:wrongpw; echo "exit $?"
bad decrypt
40E7089AFFFF0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../providers/implementations/ciphers/ciphercommon_block.c:107:
exit 1

bad decrypt and exit status 1. Worth being precise about why that error appeared, because it is a trap: OpenSSL decrypted the data with the wrong key, got garbage, and then noticed the padding at the end of the garbage was not valid padding. It is a coincidence detector, not an integrity check. Roughly one wrong key in 256 produces plausible padding and no error at all, handing you garbage silently.

That is a property of AES-CBC, which encrypts and nothing more. An AEAD mode such as AES-GCM builds authentication in, so a wrong key or a tampered ciphertext fails loudly and always. When you get to choose, choose one of those; when you inherit CBC, do not treat a successful decrypt as proof of anything.

Symmetric encryption means one key does both directions. It is fast, AES has had dedicated CPU instructions since 2010, which is why it does all the bulk work: LUKS volumes in lesson 49, TLS session traffic in lesson 48, encrypted backups, everything large.

The names worth recognising, because a question will list four of them and ask which one you would not deploy:

Two words attached to those that the exam does test. A block cipher such as AES transforms fixed-size blocks and therefore needs a mode to handle anything longer (CBC, CTR, GCM, XTS) and the mode is where most of the real security decisions live, which is why aes-256-cbc and aes-256-gcm behave so differently a few paragraphs above. A stream cipher such as ChaCha20 produces a keystream and needs no padding at all.

Symmetric encryption’s problem is not mathematical. It is that both parties must already have the same key, and getting it to them is the hard part.

Two keys instead of one

Asymmetric cryptography solves exactly that problem. Generate two mathematically linked keys and publish one of them:

# Debian 13 (trixie), x86_64
$ openssl genpkey -algorithm ed25519 -out /tmp/priv.pem; openssl pkey -in /tmp/priv.pem -pubout -out /tmp/pub.pem; cat /tmp/pub.pem
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEADUIppu4jzHsHQt4ek66Js7tdYaLzUbZgiuF5FzGLEfQ=
-----END PUBLIC KEY-----

The whole public key is that one line of base64 between two delimiters (a 32-byte Ed25519 key plus its algorithm identifier, wrapped in PEM) and it can go anywhere: a web page, a DNS record, a certificate. The private key stays in /tmp/priv.pem and never leaves the machine. Everything asymmetric rests on that single asymmetry of distribution, not of mathematics.

One practical wrinkle, because it wastes an afternoon the first time. That PEM is not what ~/.ssh/authorized_keys wants. SSH carries the same 32 bytes in its own single-line ssh-ed25519 AAAAC3Nza... encoding, and nothing converts between the two implicitly. Two encodings, one key, two toolchains: generate SSH keys with ssh-keygen -t ed25519 and keep openssl genpkey for signing and certificate work.

The keys do two different jobs, and the direction reverses between them. This is the table people misremember, so read it twice:

Both rows use both keys, in opposite orders, and that inversion is the single most common confusion in the subject. The way to keep it straight is to ask what the property is protecting. Confidentiality means anybody may lock it and only one person may open it, so the lock is the published key. Authenticity means only one person may produce it and anybody may check it, so the production step is the private one.

Asymmetric operations are slow and size-limited (an RSA-2048 key cannot encrypt more than about 245 bytes in one operation, and Ed25519 cannot encrypt at all) so nothing large is ever encrypted with them directly.

The third operation, which is the one actually in use

There is a row missing from that table, and it is the row that runs every time you open a web page. Key agreement takes two key pairs and produces a shared secret that neither side transmitted:

Nobody encrypted the key and sent it. Both sides computed it, and an observer who recorded every byte of the exchange cannot compute it. That secret then becomes the AES key, and the connection switches to symmetric work for everything else.

The E on the end of ECDHE is ephemeral: a fresh key pair per connection, discarded afterwards. That buys forward secrecy, the property that stealing the server’s long-term private key next year does not decrypt the traffic you recorded this year, because the key that traffic actually used was thrown away when the connection closed. It is the reason TLS 1.3 removed the non-ephemeral key exchanges entirely rather than leaving them configurable.

So a real protocol uses all three: key agreement to establish a session key, signatures to prove who you are agreeing with, and symmetric encryption for the data. That hybrid is what TLS is doing in lesson 48 and what gpg --encrypt does to a file. The roster:

That “No” against Ed25519 under Encrypt is the row people trip on. It is not a limitation of the tooling. The algorithm has no encryption operation, which is why “the public key encrypts” is a description of RSA rather than a rule about asymmetric cryptography.

What a signature proves that a checksum does not

Take a message that matters and sign it with the private key:

# Debian 13 (trixie), x86_64
$ cat /tmp/msg; openssl pkeyutl -sign -inkey /tmp/priv.pem -rawin -in /tmp/msg -out /tmp/sig; ls -l /tmp/sig
transfer 500 to account 12345
-rw-r--r--. 1 root root 64 Aug  8 17:08 /tmp/sig

Two things worth noticing. The message is not encrypted: cat printed it in the clear, and it stays readable. A signature is a separate value that sits beside the data, not a transformation of it. And the signature is 64 bytes, which is what an Ed25519 signature always is, regardless of whether the message is one line or a gigabyte.

Anybody with the public key can now check it:

# Debian 13 (trixie), x86_64
$ openssl pkeyutl -verify -pubin -inkey /tmp/pub.pem -rawin -in /tmp/msg -sigfile /tmp/sig
Signature Verified Successfully

That single line is doing more work than it looks. It says the message has not changed since it was signed, and that it was signed by the holder of the private key matching this public key. A checksum gives you the first half. Only a signature gives you both.

# Debian 13 (trixie), x86_64
$ sed -i 's/500/900/' /tmp/msg; cat /tmp/msg; openssl pkeyutl -verify -pubin -inkey /tmp/pub.pem -rawin -in /tmp/msg -sigfile /tmp/sig
transfer 900 to account 12345
407709B7FFFF0000:error:030000EA:digital envelope routines:EVP_DigestVerify:provider signature failure:../crypto/evp/m_sigver.c:779:ED25519 digest_verify:
Signature Verification Failure

Signature Verification Failure, plus a library error naming the operation. Changing 500 to 900 changed the message, which changed its digest, which no longer matches what the signature covers. There is no partial credit and no tolerance: a signature verifies or it does not.

This is the mechanism behind package signing from lesson 31 and certificates in lesson 48, and it is worth stating the practical consequence out loud. Publishing a SHA-256 checksum next to a download protects against a corrupted transfer and nothing else. Anybody who can replace the tarball on that server can replace the checksum on that page. What distributions actually do is sign the checksum file, so the chain is: the signature proves who wrote the checksum list, and the checksum proves which bytes they meant.

Where salts and keys come from

Everything above assumes unpredictable bytes, and getting those is one command:

# Debian 13 (trixie), x86_64
$ openssl rand -hex 16; openssl rand -base64 24
faa42aceb5ee897a250278bfabec515d
gzPw4eGoILCIz52VNOCgV53x+gR+7/LN

openssl rand draws from the kernel’s random pool through the library’s generator. -hex gives you something you can paste into a config file; -base64 packs more entropy per character.

Do not build these yourself. $RANDOM in the shell, the current timestamp, the process ID, and anything seeded from the clock are all predictable enough to enumerate, and a salt or key that can be enumerated is not one. Use openssl rand, /dev/urandom, or your language’s cryptographic random source, never its ordinary one.

/dev/urandom is the right device on any current kernel. The old advice to prefer /dev/random for “real” randomness described behaviour that Linux stopped exhibiting years ago: both draw from the same pool, and /dev/urandom does not block once the pool has been seeded at boot. The one case that still matters is a freshly booted machine with no entropy sources (a headless VM starting from a fresh image, generating host keys) which is why virtual machines are given a paravirtualised entropy device.

Retiring an algorithm on a whole machine

Old algorithms do not vanish. They are still compiled in, because files and protocols out in the world still contain them:

# Debian 13 (trixie), x86_64
$ openssl version; openssl list -digest-algorithms | head -12
OpenSSL 3.5.6 7 Apr 2026 (Library: OpenSSL 3.5.6 7 Apr 2026)
Legacy:
  RSA-MD4 => MD4
  RSA-MD5 => MD5
  RSA-RIPEMD160 => RIPEMD160
  RSA-SHA1 => SHA1
  RSA-SHA1-2 => RSA-SHA1
  RSA-SHA224 => SHA224
  RSA-SHA256 => SHA256
  RSA-SHA3-224 => SHA3-224
  RSA-SHA3-256 => SHA3-256
  RSA-SHA3-384 => SHA3-384
  RSA-SHA3-512 => SHA3-512

Reading that output honestly matters. Legacy: here is OpenSSL’s word for its older algorithm-name table, not a security judgement, and it is easy to misquote as “OpenSSL has marked MD5 legacy”. What the list actually tells you is that MD5 and SHA-1 are present and functional in OpenSSL 3.5, as they will be for years, because a program that cannot verify an old signature cannot tell you the old signature is bad.

Deciding what a machine will accept is therefore a layer above the library. It is a policy question, and the practical shapes it takes are:

• Refuse the algorithm in each application’s configuration, one at a time: sshd_config, openssl.cnf, the web server’s cipher list, the VPN’s.
• Or set one system-wide policy that rewrites all of those at once, which is what the RHEL family provides and the next panel covers.

That second bullet has a name the exam uses: algorithm agility. A system has it when the algorithm is a setting rather than an assumption, when it is written down in one place, negotiated at run time, and carried inside the stored data so old material stays verifiable while new material uses the new choice. The $y$ prefix in a shadow field is algorithm agility in miniature: the format announces which function produced the hash, so a machine can change its default without invalidating a single existing password. A protocol or file format with no such field is stuck with whatever it was born with, which is how MD5 outlived its usefulness by a decade.

The named retirements worth knowing, because they are the ones you will actually trip over:

# AlmaLinux 10.2, x86_64
$ openssl version; update-crypto-policies --show
OpenSSL 3.5.5 27 Jan 2026 (Library: OpenSSL 3.5.5 27 Jan 2026)
DEFAULT

# AlmaLinux 10.2, x86_64
$ ls /usr/share/crypto-policies; ls /usr/share/crypto-policies/policies
DEFAULT
FIPS
FUTURE
LEGACY
back-ends
default-config
default-fips-config
policies
python
reload-cmds.sh
DEFAULT.pol
EMPTY.pol
FIPS.pol
FUTURE.pol
LEGACY.pol
modules

sudo update-crypto-policies --set FUTURE

sudo update-crypto-policies --set DEFAULT:SHA1

Across distributions

Two rows deserve care. mkpasswd existing on both families and doing different things is a real trap: a script written on Debian that pipes mkpasswd output into chpasswd -e produces a random password rather than a hash when it runs on RHEL, and nothing errors.

The first row is the one to be careful repeating, because it changed recently and most of the study material predates the change. “RHEL uses $6$” was true for years and is not true on RHEL 10:

# AlmaLinux 10.2, x86_64
$ grep ^ENCRYPT_METHOD /etc/login.defs; useradd -m demo; echo demo:hunter2 | chpasswd; getent shadow demo | cut -d: -f2
ENCRYPT_METHOD YESCRYPT
$y$j9T$FkITuihiYppUguAhqPvDF1$TFKnyosfIPdvz4dRYi5MEhCOcqO6DnpsAsSnNQkjq21

YESCRYPT, and a $y$ hash to prove it took effect, on the RHEL-family container. Both major families now default to the same memory-hard algorithm; the split you may have memorised is a RHEL 9 fact, not a RHEL fact. Note also that openssl passwd -6 still produces $6$ on this same machine, because that flag asks for SHA-512-crypt explicitly and has nothing to do with login.defs, the default only governs what useradd, passwd, and chpasswd create.

And do not trust any of that over the evidence in front of you. Read the prefix in the actual file. A machine upgraded across several releases has hashes in whatever format was default when each password was last changed, so a single /etc/shadow can easily hold $6$ and $y$ side by side, and possibly a $1$ belonging to an account nobody has touched since 2014. That last one is the finding.

Prove it

# What algorithm is a given account's password actually stored under
sudo getent shadow alice | cut -d: -f2 | cut -d'$' -f2

# Every account still on a retired algorithm, which is the audit that matters
sudo cut -d: -f1,2 /etc/shadow | grep -E ':\$1\$|:[^$*!]{13}$'

# What this machine will create new hashes with
grep -E '^ENCRYPT_METHOD|^SHA_CRYPT' /etc/login.defs

# Determinism, in two commands you can run anywhere
printf 'hello' | sha256sum
printf 'hello' | sha256sum

# What the crypto library still implements, which is not what policy allows
openssl list -digest-algorithms

# And on the RHEL family, what policy allows
update-crypto-policies --show

# Verify a download properly: establish who wrote the list BEFORE trusting it
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum -c SHA256SUMS

The order of the last pair is the habit worth building, and it is the order most people get backwards. Running sha256sum -c first tells you the file matches a list that anybody could have written; if the list was replaced along with the tarball, the check passes and tells you nothing. Verify the signature over the list first, so that by the time you compare digests you already know who stood behind them. If gpg --verify fails, there is nothing to check the checksum against and the second command should never run.

What trips people up

1. Decrypting a hash

There is no such operation, at any key length, with any tool, at any budget. Hashing has no inverse; that is its definition, not a limitation of current software.

Services advertising MD5 or SHA-1 “decryption” are searching a table of digests somebody has already computed. They succeed on password123 and fail on anything nobody has hashed before, which is exactly the behaviour of a lookup and not of a reversal.

2. Treating the salt as a secret

The salt is stored in the clear beside the hash, in the same field, by design. Its purpose is to make precomputed tables useless and to stop identical passwords producing identical hashes.

It does not slow down an attack on one password, because the attacker has it. Only the work factor does that. A “secret salt” shared across all accounts is a different thing entirely, called a pepper, and it belongs outside the password database, typically in an HSM or an application config, where a database dump alone does not reveal it.

3. “MD5 is broken, so those passwords can be recovered”

Wrong property. What broke for MD5 and SHA-1 is collision resistance: an attacker can construct two inputs sharing a digest. Preimage resistance, the one that would let somebody work backwards from a stored hash to a password, is intact for both.

$1$ hashes are still bad, for the different reason that MD5 is fast and guessing is therefore cheap. Getting this precise matters because the fix differs: the collision break means stop using it for signatures immediately, and the speed problem means change the password hashing scheme and force a reset.

4. Signing with the public key

You sign with the private key and verify with the public one, which is the reverse of encryption, where you encrypt with the public key and decrypt with the private one.

Anchor it to the property. Only one person should be able to produce a signature, so production uses the key only they have. Anybody should be able to send them a secret, so encryption uses the key everybody has.

5. Reading bad decrypt as an integrity check

It is a padding check on garbage, not authentication. With CBC, a wrong key usually produces invalid padding and an error, but not always, and there is no guarantee at all that a tampered ciphertext will be noticed.

Use an authenticated mode such as AES-GCM when you choose, and never treat a clean CBC decrypt as evidence the data is genuine.

6. Hashing passwords with the fast hash you already know

sha256sum is the right tool for a file and the wrong one for a password. The property you want in a file hash is speed; the property you want in a password hash is slowness, and they are the same word pointing in opposite directions.

Use yescrypt, bcrypt, or Argon2id. If the platform offers only SHA-512-crypt, raise rounds well above the 5000 default.

Work it through

An application team tells you their user database stores passwords “hashed with SHA-256, so we are fine”. A copy of that database has turned up on a paste site. Two hundred thousand rows.

Reason it out before reading on.

What is not the problem. Nobody is going to reverse those hashes. SHA-256 has no known preimage weakness, and the phrase “decrypt the hashes” that will appear in the incident channel within the hour describes an operation that does not exist. Say so early, because the panic and the mitigation both go wrong if that is the working theory.

The question that decides the severity: is there a salt? Look at the column. If every row is exactly 64 hexadecimal characters with nothing else in it, there is no salt and no algorithm identifier, which means the passwords were hashed raw.

That is the bad case, and it is bad in a specific way. Identical passwords now have identical hashes, so the attacker sorts the column, finds that four thousand rows share one value, hashes Password1, and has cracked four thousand accounts with one operation. Then they run a precomputed table against the rest, because with no salt one table works against every row at once.

The cost of the attack even where the table misses. Raw SHA-256 on commodity GPU hardware runs at the order of tens of billions of guesses per second. Against a dictionary with mutations, most human-chosen passwords in that file fall inside a day. The absence of a work factor, not the absence of a salt, is what makes that number so large.

So the response is: every password in that file is compromised, force a reset on all of them, and change the scheme to a memory-hard hash before reopening sign-in.

Now change one detail and watch the answer move. Suppose the column had held $2b$12$ values instead. Still leaked, still needs a reset, but now the attacker is testing a few thousand candidates per second per GPU rather than tens of billions, every row needs its own attack because every row has its own salt, and the strong passwords in that file are realistically safe. Same breach, completely different week.

Change a different one. Suppose the hashes were salted but still raw SHA-256. The precomputed tables are dead and identical passwords no longer show up as identical, which is a real improvement, and the guessing rate has not changed at all. Weak passwords still fall in minutes. That is the cleanest demonstration that salt and work factor solve different problems and neither substitutes for the other.

And one more. Suppose the team had “encrypted” the passwords with AES so support staff could read them back. Now the incident is worse, not better, because the question becomes where the key is, and if it is on the same application server, which it always is, the attacker who took the database took the key.

The point worth extracting: hashing, salting, and work factor are three independent decisions, and the answer to “are we fine” needs all three. Hashing stops recovery. Salting stops the attack from scaling across accounts. The work factor sets the price per guess. A system with the first two and not the third is the most common shape of a real breach, because it looks correct in code review.

Try it

Optional, on any machine with openssl installed.

1. printf 'hello' | sha256sum twice, then printf 'hellp' | sha256sum. Compare character by character until you are satisfied nothing carries over.
2. sha256sum a one-byte file and a large one. Note the output lengths are equal.
3. printf 'hello' | md5sum, sha1sum, sha256sum, sha512sum. Count the hex characters and divide by two for bytes, then multiply by eight for the bits in the name.
4. openssl passwd -6 -salt aaaaaaaa 'test' and openssl passwd -6 -salt bbbbbbbb 'test'. Then run the first one again and confirm it reproduces exactly.
5. sudo getent shadow "$USER" | cut -d: -f2 and identify the algorithm, the parameters, the salt, and the hash by their dollar signs.
6. openssl dgst -sha256 -hmac 'k1' file and the same with k2. Then with k1 again, and confirm it reproduces.
7. Generate an Ed25519 key pair, sign a file, verify it, change one byte of the file, and verify again. Read both messages.
8. Try to encrypt to that Ed25519 public key with openssl pkeyutl -encrypt -pubin -inkey /tmp/pub.pem -in /tmp/msg -out /tmp/x. Read the error. The operation does not exist for this key type, which is the whole point of the roster table.
9. openssl speed sha256 sha512 on the machine in front of you and see which one actually wins there, rather than trusting either version of the folklore.
10. openssl enc -aes-256-cbc -in f -out f.enc -pass pass:x with and without -pbkdf2, then xxd the first 16 bytes of each. The header looks identical; the key derivation behind it is not.
11. On a RHEL-family machine, update-crypto-policies --show, then ls -l /etc/crypto-policies/back-ends/ and note that the entries are symlinks into /usr/share/crypto-policies/. That is the whole mechanism.

Verification step. You have it when you can look at a /etc/shadow field and say aloud which part is the algorithm, which is the salt, which is the hash, and what happens to each of them the next time that user logs in.

Check yourself

References

• crypt(5) - Debian manpages, libxcrypt. Accessed 2026-08-08.
• shadow(5) - Linux man-pages project. Accessed 2026-08-08.
• sha256sum(1) - Linux man-pages project. Accessed 2026-08-08.
• openssl-dgst(1ssl) - Debian manpages, OpenSSL. Accessed 2026-08-08.
• openssl-pkeyutl(1ssl) - Debian manpages, OpenSSL. Accessed 2026-08-08.
• openssl-enc(1ssl) - Debian manpages, OpenSSL. Accessed 2026-08-08.
• login.defs(5) - Linux man-pages project. Accessed 2026-08-08.
• cryptsetup(8) - Debian manpages, cryptsetup. Accessed 2026-08-08.
• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard - NIST. Accessed 2026-08-08.
• mkpasswd(1) - Debian manpages, whois. Accessed 2026-08-08.
• RFC 2104: HMAC, Keyed-Hashing for Message Authentication - IETF. Accessed 2026-08-08.
• Security hardening - Red Hat. Accessed 2026-08-08.
• SHAttered: the first collision for full SHA-1 - CWI Amsterdam and Google Research. Accessed 2026-08-08.

Captured output came from two containers on x86_64: Debian 13 (trixie) running OpenSSL 3.5.6 and its shipped libxcrypt, and AlmaLinux 10.2 running OpenSSL 3.5.5, which is where the update-crypto-policies output came from because that tooling does not exist on Debian. The shadow field, the signature verification, and the signature failure after tampering are all real runs against real keys generated on that machine; the key pair was discarded afterwards. Blocks without a distribution and architecture header are illustrative, the update-crypto-policies --set and fips-mode-setup invocations in particular are shown without output rather than with invented output, because applying them changes a machine rather than reporting on one.