Re: bcrypt or other key derivation algorithm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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?


Attachment: signature.asc
Description: Digital signature

[Index of Archives]     [Linux Crypto]     [Device Mapper Crypto]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux