On Sun, Apr 10, 2011 at 4:17 PM, Serge Hallyn <[email protected]> wrote: .... > Cool. Now the other thing I don't like is having the username:pwd > pushed to the yubikey, only bc it's usb and i dunno, I can just see > someone coming up with a sneaky way to grab that.
I don't like it either - I mean there is even USB over IP (even though that approaches the old "if it hurts, don't do it"). I think that brings us to exploring either version 1 or 2 of the "rolling challenges" I described in my previous e-mail. My initial questions are then - is it a good or bad idea to re-wrap your mount passphrase on each mount? - where should the required metadata be stored? In scheme 1 this would be the next expected response, in scheme 2 the AES key of the Yubikey encrypted with the next response, and the next challenge in clear text - how to make this either completely separate from eCryptfs, or vendor neutral enough for you to think it is a good idea to include it in eCryptfs > Does it help at > all to have send sha1sum(username:pwd) to the yubikey instead? It also > helps with your concerns about sufficent salt, right? I think the current BCP is to use Password-Based Key Derivation Function 2 (PBKDF2) with a sufficiently large number of iterations. Wikipedia says the iPhone4 uses 10,000. You come very close with your suggestion =). /Fredrik _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
