Re: bcrypt or other key derivation algorithm

[Tyler Hicks <tyhicks@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]