There are ways to securely use passwords for cryptography (see PAKE), but the correct thing to do almost always is to generate a secure cryptographic key using a CSPRNG, almost always using the CSPRNG provided by the OS kernel. So although the API might accept any 32 bytes as a cryptographic key, using a human generated password directly will break security and should be flagged in any audit/review. No dictionary attack or using the birthday of the user's kids or the password the user used on their luggage would work at breaking it. So if it is 256 bits long, then is has 256 bits of entropy. A cryptographic key generated this way genuinely has the amount of entropy that is assumed by its size.
Reading from /dev/urandom on linux is perfectly fine. Also, people reuse passwords.Ī cryptographic key is generated by a computer, not by a human, and it must be generated using a CSPRNG. A dictionary attack that tries the common things people do (add numbers, l33t speak, etc.) will break most passwords. That means there are about 1 million possible passwords they could have chosen. The important distinction between cryptographic keys and passwords is that when humans choose passwords, they generally only get about 20 bits of entropy.
The encoding of the value (32 bytes of binary, 256 bytes of ASCII ones and zeros, 64 bytes of hex, 44 bytes of base64, etc.) does not affect the security of the key in any way.
0 kommentar(er)
