Re: bcrypt or other key derivation algorithm

[Tyler Hicks <tyhicks@canonical.com>]

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

On 2016-01-19 09:35:34, Wiebe Cazemier wrote:
> ----- Original Message -----
> > From: "Sylvain Pelissier" <sylvain.pelissier@gmail.com>
> > To: "Wiebe Cazemier" <wiebe@halfgaar.net>
> > Cc: ecryptfs@vger.kernel.org
> > Sent: Monday, 18 January, 2016 12:00:36 PM
> > Subject: Re: bcrypt or other key derivation algorithm
> > 
> > Hi,
> > 
> > I think it is a good idea to support stronger algorithms. As a new
> > hashing algorithm, you can also consider Argon2 algorithm, the winner
> > of the Password hashing compettion (https://password-hashing.net/).
> > The implementation is already available:
> > https://github.com/p-h-c/phc-winner-argon2.
> > Reagrds
> > 
> > Sylvain
> 
> That's interesting. I wonder why nobody is talking about it. Bcrypt and scrypt are all the rage, and even those are not fully trusted by all, because they haven't withstood the test of time.
> 
> Question remains though, I can't implement it without knowing what to do with the v2 wrapped passphrase file. I can think of something myself, but I'd rather do something that I know won't be rejected :)
> 
> From the source code:
> 
>  * Reads a version 2 wrapped passphrase file containing the following format:
>  *
>  *   Octet  0:      A ':' character
>  *   Octet  1:      uint8_t value indicating file version (MUST be 0x02)
>  *   Octets 2-9:    Wrapping salt
>  *   Octets 10-25:  Signature of wrapping key (16 octets)
>  *   Octets 26-N1:  Variable length field containing the encrypted
>  *                  passphrase. (Up to 64 octets. Must be non-empty.)
> 
> Would a v3 be in order?:
> 
>  *   Octet  0:      A ':' character
>  *   Octet  1:      uint8_t value indicating file version (MUST be 0x03)
>  *   Octet  2:      uint8_t id of hashing algorithm.

Don't you mean KDF instead of hashing algorithm here? (scrypt, PBKDF2,
etc.)

>  *   Octets 3-10:   Wrapping salt
>  *   Octets 11-26:  Signature of wrapping key (16 octets)
>  *   Octets 27-N1:  Variable length field containing the encrypted
>  *                  passphrase. (Up to 64 octets. Must be non-empty.)

If octet 2 is KDF instead of hashing algorithm, octets 3-N1 are going
to vary based on the KDF used. For instance, scrypt will need to store
the values of N, r, and p while PBKDF2 will need to store the number of
iterations.

Tyler

> 
> 
> Regards,
> 
> Wiebe
> --
> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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