Skip to main content
Clarified penultimate paragraph to distinguish between using salt for decryption and key-reuse attacks for static/no salt
Source Link

It is almost universally a bad idea to use the actual password you typed as an encryption key. While the ciphers mentioned use 128-256 bit keys, and ideally with 8 bits of entropy (complexity/randomness, loosely) per byte, the symbols a user can type on a keyboard are no more than 5 bits - even assuming a very diverse character set beyond the typical letters, numbers and top row of symbols. As pointed out, they can even be less than the full size the cipher requires, so presumably padded with nulls or something else predictable, further reducing entropy.

Add to that we humans like patterns, enjoy dictionary words and can only remember a few simple substitutions (S-$), and the eventual key is likely not very strong and so more guessable.

Key-Derivation Functions (KDF) "stretch" these relatively simple passphrases into the required number of bits, and even turn longer passwords into the required shorter length - considering how weak the original could be, this shorter derived bit sequence (key) can be stronger than even a very long text passphrase.

Additionally, since good derivation functions add in some randomness (salt), typing the same password should result in very different keys each time they are are used to generate a key, while ensuring an existingnew key can be(to encrypt a new thing) since a new salt is used. Using the same salt (or no salt) will result in the same derived repeatedly for eventual decryptionkey which is obviously essential to actually decrypt the content. However, stoppingusing the same derived key to encrypt two different objects introduces vulnerabilities related to key reuse issues, so effective salting very much improves security while allowing re-use of the same passphrase, which humans like.

Finally, many implementations allow you to tweak how hard the KDF works to create the derived key, so that you can set how hard an attacker should work to break it, and trade that off against the time a successful derivation would take with the correct passphrase. A ten second derivation on an embedded device may be a millisecond task for a well-equipped attacker with GPU or other hardware-based assistance.

It is almost universally a bad idea to use the actual password you typed as an encryption key. While the ciphers mentioned use 128-256 bit keys, and ideally with 8 bits of entropy (complexity/randomness, loosely) per byte, the symbols a user can type on a keyboard are no more than 5 bits - even assuming a very diverse character set beyond the typical letters, numbers and top row of symbols. As pointed out, they can even be less than the full size the cipher requires, so presumably padded with nulls or something else predictable, further reducing entropy.

Add to that we humans like patterns, enjoy dictionary words and can only remember a few simple substitutions (S-$), and the eventual key is likely not very strong and so more guessable.

Key-Derivation Functions (KDF) "stretch" these relatively simple passphrases into the required number of bits, and even turn longer passwords into the required shorter length - considering how weak the original could be, this shorter derived bit sequence (key) can be stronger than even a very long text passphrase.

Additionally, since good derivation functions add in some randomness (salt), typing the same password should result in very different keys each time they are are used to generate a key, while ensuring an existing key can be derived repeatedly for eventual decryption, stopping key reuse issues.

Finally, many implementations allow you to tweak how hard the KDF works to create the derived key, so that you can set how hard an attacker should work to break it, and trade that off against the time a successful derivation would take with the correct passphrase. A ten second derivation on an embedded device may be a millisecond task for a well-equipped attacker with GPU or other hardware-based assistance.

It is almost universally a bad idea to use the actual password you typed as an encryption key. While the ciphers mentioned use 128-256 bit keys, and ideally with 8 bits of entropy (complexity/randomness, loosely) per byte, the symbols a user can type on a keyboard are no more than 5 bits - even assuming a very diverse character set beyond the typical letters, numbers and top row of symbols. As pointed out, they can even be less than the full size the cipher requires, so presumably padded with nulls or something else predictable, further reducing entropy.

Add to that we humans like patterns, enjoy dictionary words and can only remember a few simple substitutions (S-$), and the eventual key is likely not very strong and so more guessable.

Key-Derivation Functions (KDF) "stretch" these relatively simple passphrases into the required number of bits, and even turn longer passwords into the required shorter length - considering how weak the original could be, this shorter derived bit sequence (key) can be stronger than even a very long text passphrase.

Additionally, since good derivation functions add in some randomness (salt), typing the same password should result in very different keys each time they are are used to generate a new key (to encrypt a new thing) since a new salt is used. Using the same salt (or no salt) will result in the same derived key which is obviously essential to actually decrypt the content. However, using the same derived key to encrypt two different objects introduces vulnerabilities related to key reuse, so effective salting very much improves security while allowing re-use of the same passphrase, which humans like.

Finally, many implementations allow you to tweak how hard the KDF works to create the derived key, so that you can set how hard an attacker should work to break it, and trade that off against the time a successful derivation would take with the correct passphrase. A ten second derivation on an embedded device may be a millisecond task for a well-equipped attacker with GPU or other hardware-based assistance.

Source Link

It is almost universally a bad idea to use the actual password you typed as an encryption key. While the ciphers mentioned use 128-256 bit keys, and ideally with 8 bits of entropy (complexity/randomness, loosely) per byte, the symbols a user can type on a keyboard are no more than 5 bits - even assuming a very diverse character set beyond the typical letters, numbers and top row of symbols. As pointed out, they can even be less than the full size the cipher requires, so presumably padded with nulls or something else predictable, further reducing entropy.

Add to that we humans like patterns, enjoy dictionary words and can only remember a few simple substitutions (S-$), and the eventual key is likely not very strong and so more guessable.

Key-Derivation Functions (KDF) "stretch" these relatively simple passphrases into the required number of bits, and even turn longer passwords into the required shorter length - considering how weak the original could be, this shorter derived bit sequence (key) can be stronger than even a very long text passphrase.

Additionally, since good derivation functions add in some randomness (salt), typing the same password should result in very different keys each time they are are used to generate a key, while ensuring an existing key can be derived repeatedly for eventual decryption, stopping key reuse issues.

Finally, many implementations allow you to tweak how hard the KDF works to create the derived key, so that you can set how hard an attacker should work to break it, and trade that off against the time a successful derivation would take with the correct passphrase. A ten second derivation on an embedded device may be a millisecond task for a well-equipped attacker with GPU or other hardware-based assistance.