| >> No, because PBKDFs are not a good mechanism for creating encryption keys > I'm curious about what you mean by this. Isn't it in part what PBKDFs are designed for? Password-based key derivation functions start with the assumption that some entropy is provided by the user. Which means that the entropy is typically of awful quality. A PBKDF does the best it can with that low entropy, which is to make it into a time- and maybe space-expensive brute-forcing problem. But a PBKDF is starting with one hand tied behind its back if the user-supplied entropy is "password" or "hunter2." If we aren't burdened by that assumption, then we can generate high-quality entropy -- like 128 or 256 bits of CSRNG-generated noise -- and merely associate it with the user, rather than basing it on the user's human-scale memory. PBKDFs also generally assume that users are transmitting their plaintext passphrases to the server, e.g., when you HTTP POST your credentials to server.com. Of course, browsers and apps use transport security so that MITMs can't grab the passphrase over the wire, but the server actually does receive the phrase "hunter2" at some point if that's your passphrase. So again, it's a rotten assumption -- basically the foundation of most password-database compromises on the internet -- and PBKDF does the best it can. If you remove that assumption and design a true asymmetric-encryption-based authentication system, then you don't need the obfuscation rounds of a PBKDF because the asymmetric-encryption algorithm is already resistant to brute-forcing. The script kiddie who steals /etc/passwd from a server would effectively obtain a list of public keys rather than salted hashes, and if they can generate private keys from public keys, then they are already very wealthy because they broke TLS and most Bitcoin wallets. Think of passkeys as a very user-friendly client-side certificate infrastructure. You wouldn't let your sysadmin base your enterprise website's TLS certificates on a private key derived from their dog's birthday. You wouldn't let users do that for their certs, either. |