> Arno Wagner wrote: > Also I want to remove hardcoded SHA-1 (used in PBKDF2) implementation > and replace it with libgcrypt calls. > > It would be probably better to make hash algoritm as parameter > (through -h option), so everything provided by libgcrypt for hash will > be usable here. > (This way is hash already used in non-LUKS mapping, so it is just major > cleanup > of code, no new dependences on any crypto library) > > Milan I'd be interested in seeing this happen. I've been playing around with a command line pbkdf2 app, to feed generate a key to cryptsetup, what I came up with uses either libgcrypt or libtomcrypt (which supplies it's own pbkdf2 function). Anyway, what I wanted to bring up was the gcrypt function I'm using, which is based on this, which may be of use to you; http://lists.gnupg.org/pipermail/gcrypt-devel/2002-December/000202.html I have a "cleaned up" version if you're interested, although I'm an amateur programmer at best. The reason I used tomcrypt as well is because it seems to be about 50% faster for all hashes they have in common (other than whirlpool, where gcrypt is ~50% faster), also this is with libgcrypt compiled with -O3, which is easily more than TWICE as fast as when it's compiled with -O2... If you do implement this, do you intend to do it only for luks, or could it be used as a replacement for non-luks key generation too (ie a user supplies the salt, pass and iterations just as they would normally supply a passphrase for grcypt to hash)? That's what I'd be really interested to see. --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
