On 2016-01-18 11:51:36, Wiebe Cazemier wrote: > Hi, > > What are the thoughts on implementing bcrypt as key derivation > algorithm? I already found a TODO in the code that ecryptfs should > support more algorithms than just SHA512 * 65536. I tried brute > forcing this, and got no further than about 20/s, but on FPGAs/GPUs > this would be a lot faster. bcrypt would be a fine kdf. > It should be easy enough to borrow code from OpenSSH, which uses > bcrypt in their secure new private key file format (ssh-keygen -o; > their old format is pretty weak (MD5 once, encrypt with AES 128)). > > Questions: > > 1) The v2 wrapped does not have a field to indicate which algorithm is > used (like /etc/shadow (crypt API) has). Does this necessitate a > v3, which does have said field? Yes. The v2 wrapped passphrase format was intended to be the most simple fix possible for CVE-2014-9687 in order to make backporting to stable releases and transparent upgrades easy. The thought was always that a v3 would be needed to support greater algorithm agility. > 2) Are there objections to including BSD licensed code from OpenSSH? That bit of code looks like it is under the 4-clause BSD license. I think that'll be a problem since the ecryptfs-utils project is GPLv2. Can you reuse the crypt(3) interface, passing the "2a" ID for bcrypt? Tyler
Attachment:
signature.asc
Description: Digital signature
