Re: password based key-wrap (Re: The Crypto Gardening Guide and Planting Tips)
- Original Message - From: Adam Back [EMAIL PROTECTED] To: Peter Gutmann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Adam Back [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:07 PM Subject: password based key-wrap (Re: The Crypto Gardening Guide and Planting Tips) [...] Or is the problem that the above ensemble is ad-hoc (though using standardised constructs). Or just that the ensemble is ad-hoc and so everyone will be forced to re-invent minor variations of it, with varying degrees of security. One of the problems is exactly that. There is no known proof of security for PBKDF2 (it might be possible to come up with one, but to the best of my knowledge nobody did so far). Ironically, there are some proofs of security for the older version of the same standard, PBKDF1 (which was replaced by PBKDF2 only because the output of PBKDF1 was of fixed length, so you couldn't derive much key material). You can prove some things about PBKDF1 relating to the fact that an adversary cannot compute the result of PBKDF1 without having to compute a certain required amount of hashes (this is the stretching part). The details of that are in the paper Secure Applications of Low-Entropy Keys by Kelsey, Schneier, Hall and Wagner: http://www.counterpane.com/low-entropy.pdf But I do think that PBKDF2 sounds reasonable, and I wouldn't be surprised if we can prove something about it's security in some reasonable model. I would use PBKDF2 if I needed to wrap a session key with only a password. In general, the problems with existing proposed key derivation functions is that they are all based on ad-hoc constructions. There is a skunks work group trying to come up with a proposal for a key derivation function which is based on some provable secure results. --Anton
Re: password based key-wrap (Re: The Crypto Gardening Guide and Planting Tips)
- Original Message - From: Adam Back [EMAIL PROTECTED] To: Peter Gutmann [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Adam Back [EMAIL PROTECTED] Sent: Thursday, February 06, 2003 8:07 PM Subject: password based key-wrap (Re: The Crypto Gardening Guide and Planting Tips) [...] Or is the problem that the above ensemble is ad-hoc (though using standardised constructs). Or just that the ensemble is ad-hoc and so everyone will be forced to re-invent minor variations of it, with varying degrees of security. One of the problems is exactly that. There is no known proof of security for PBKDF2 (it might be possible to come up with one, but to the best of my knowledge nobody did so far). Ironically, there are some proofs of security for the older version of the same standard, PBKDF1 (which was replaced by PBKDF2 only because the output of PBKDF1 was of fixed length, so you couldn't derive much key material). You can prove some things about PBKDF1 relating to the fact that an adversary cannot compute the result of PBKDF1 without having to compute a certain required amount of hashes (this is the stretching part). The details of that are in the paper Secure Applications of Low-Entropy Keys by Kelsey, Schneier, Hall and Wagner: http://www.counterpane.com/low-entropy.pdf But I do think that PBKDF2 sounds reasonable, and I wouldn't be surprised if we can prove something about it's security in some reasonable model. I would use PBKDF2 if I needed to wrap a session key with only a password. In general, the problems with existing proposed key derivation functions is that they are all based on ad-hoc constructions. There is a skunks work group trying to come up with a proposal for a key derivation function which is based on some provable secure results. --Anton
password based key-wrap (Re: The Crypto Gardening Guide and Planting Tips)
Peter lists applied crypto problem in his Crypto Gardening Guide at: http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt One of the problems from the Problems that Need Solving section is: * A key wrap function where the wrapping key is derived from a password. The requirements for this are subtly different from a straight symmetric key wrap in that the threat model is rather different. For example a symmetric key wrap may use HMAC to ensure non-malleability, but for password-based key wrap this makes a dictionary attack rather easier (throw passwords at the HMAC, sidestepping the encrypted key altogether). There exists a (ad-hoc) design that has rather limited non-malleability in order to avoid potential dictionary attacks. I may not be fully understanding the problem spec: you want to encrypt (wrap) a randomly generated key (a per message session key for example) with a key derived from a password. What would be wrong with using PBKDF2 (from PKCS #5 / RFC2898) as the key derivation function to give you defense against dictionary attack. (Allows choice of number of iterations to stretch the password, allows a salt to frustrate precomputation.) Why do you care about non-malleability of the key-wrap function? If you do want non-malleability of th ekey-wrap function, isn't encrypt and MAC a standard way to do this? Then you would need two keys, and I presume it would make sense to derive them (using KDF2 from IEEE P1363a) a start key: sk = KDF2( password, salt, iterations ) ek = KDF( sk, specialization1 ) mk = KDF( sk, specialization2 ) and then AES in CBC mode with random IV encrypting with ek, with appended HMAC with key mk. That leaves the comment: but for password-based key wrap this makes a dictionary attack rather easier (throw passwords at the HMAC, sidestepping the encrypted key altogether). but in this case the attacker could take his pick with no significant advantage of either method: - brute force passwords to get sk, derive ek from sk, decrypt the wrapped key and use some knowledge about the plaintext encrypted with the wrapped key to tell if the write password was chosen; or - brute force passwords to get sk, derive mk from sk, and see if the MAC is valid MAC of the ciphertext (presuming encrypt and then MAC) Or is the problem that the above ensemble is ad-hoc (though using standardised constructs). Or just that the ensemble is ad-hoc and so everyone will be forced to re-invent minor variations of it, with varying degrees of security. Adam
