Re: bcrypt or other key derivation algorithm

[Tyler Hicks <tyhicks@canonical.com>]

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

On 2016-01-20 20:33:29, Wiebe Cazemier wrote:
> ----- Original Message -----
> > From: "Tyler Hicks" <tyhicks@canonical.com>
> > To: "Wiebe Cazemier" <wiebe@halfgaar.net>
> > Cc: ecryptfs@vger.kernel.org
> > Sent: Wednesday, 20 January, 2016 3:48:44 AM
> > Subject: Re: bcrypt or other key derivation algorithm
> > 
> > > 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.
> 
> Has there already been plans for the layout of v3? Is it as simple as my suggestion?
> 
> The read_v2_wrapped_passphrase_file method could be renamed to read_v2plus_wrapped_passphrase_file and use different offsets for v3. 
> 
> > 
> > > 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?
> 
> The man page for crypt says: 
> 
>   2a | Blowfish (not in mainline glibc; added in some Linux distributions)". 
> 
> A Debian 5 system I still have says:
> 
>   2a | Blowfish (on some Linux distributions)
> 
> It's not as portable, apparently.
> 
> Also, it's a little inconvenient that it returns an encoded string, not bytes. But I guess that's convertable.

That is a bit unfortunate and could cause issues down the line if there
were any changes in encoding.

> 
> I'll look a bit more for bcrypt code/libs.
> 
> Is ecryptfs Linux only, BTW?

Yes, eCryptfs is Linux only.

Tyler

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]