Pawel Jakub Dawidek wrote: > On Mon, Aug 06, 2007 at 11:55:58AM +0100, Darren J Moffat wrote: >> Pawel Jakub Dawidek wrote: >>> That's really not user-friendly... What if user simply misspell the >>> passphrase? He won't be asked again, but will find garbage instead? >> Agreed but to verify it was the correct one you need to store something >> known to do so and that leads to known plaintext problems. > > Can't you simply store HMAC result, where password is the passphrase > given by the user, read from a file, etc.
You mean the HMAC secret ? > and data is the wrapping key? So an HMAC of the wrapping key itself ? In the case of the wrapping key being in a PKCS#11 token you might not be able to get the value of it (the token won't give it too you because it is sensitive) only use it. In that case I don't see how you can run an HMAC over it. What if we used the pool GUID as the data and stored an HMAC of that ? However that still leaves us with a possible minor issue in that we need to ensure that the actual wrapping key is usable as both an HMAC and encryption key. That is usually okay but for the case where it is in a PKCS#11 token there could be so edge cases in theory (I don't think we have a problem with that in OpenSolaris libpkcs11/kcf though). > You can always strengthen passphrase using PKCS#5. That was in the plan anyway for when the passphrase is used as the wrapping key. > I don't really see why you don't want to do that. Do you want to protect > against brute-force attacks? I hadn't considered storing an HMAC - not sure why because that is basically how we solved the implementation of C_Login in pkcs11_softtoken and that was in the back of my mind. -- Darren J Moffat
