lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Apr 2014 13:32:34 +0200
From: Dmitry Khovratovich <>
To: "" <>
Subject: Re: [PHC] Deriving multiple keys (was RE: Mechanical tests)

Hi Christian,

>Let H be a KDF and let K1||K2 = H(PWD || salt).  Are K1 and K2 be
considered to be independent?

The independency is a not a well-defined notion here. Consider, for
instance, distinct bytes of K1. Are they independent?

If we think about it for a while, it becomes clear that a single key can be
splitted into as many keys as its length without any security loss.

>y= H(PWD || salt)
K1' =   F(y, 1)
K2' =   F(y, 2)

This method is clearly equivalent to the first one. Indeed, consider H'(x)
= F(H(x)||1)||F(H(x)||2). Then the second method turns into the first one
with H = H'.

For well-established security notions I would refer to Krawczyk's paper

Best regards,

On Wed, Apr 9, 2014 at 11:48 AM, Christian Forler <> wrote:

> On 09.04.2014 00:10, Greg Zaverucha wrote:
> > Christian, can you clarify/justify your recommendation?
> Let H be a KDF and let K1||K2 = H(PWD || salt).  Are K1 and K2 be
> considered to be independent?
> Personally, I would feel better when using the following key derivation
> algorithm.
> y= H(PWD || salt)
> K1' =   F(y, 1)
> K2' =   F(y, 2)
> where F is a cryptographic hash function. Here you have only two
> additional hash function calls and since (y, 1) != (y,2) one can argue
> that K1' and K2' are pairwise independent. But is hard to argue that K1
> and K2 are pairwise independent.
> > Its common  practice to call a KDF with an input parameter for the
> required
> > number of output bytes then divide the output into two or more keys.
> > For instance, you might derive separate encryption authentication
> > keys from a DH secret with one call to the KDF.
> > One example standard that does this is in Section 7.3 of:
> >
> Using KDF (modeled as PRF) in Counter or Feedback mode is fine.
> Note that these modes do not work for password based key derivation. The
> PRF model assumes a secret key K which is chosen uniformly at random
> from a key space. A password is not chosen uniformly at random.
> > Another example is the scrypt encryption utility
> > ( Quoting the FORMAT file:
> > "AES256-CTR is computed with a 256-bit AES key key_enc, and
> > HMAC-SHA256 is computed with a 256-bit key key_hmac, where
> > scrypt(password, salt, N, r, p, 64) == [key_enc][key_hmac]"
> >
> > The reference code for all PHC submissions to accept an output
> > length.  It should be a requirement that any subset of the output
> > bytes be suitable for use as keying material.  Is this not the case?
> Assume that the output of our KDF is larger than the internal
> state of the underlying cryptographic primitive. Where should the
> additional security come from?
> An output transformation does not protect you against an adversary which
> can reconstruct the internal state.
> Best regards,
> Christian

Best regards,
Dmitry Khovratovich

Content of type "text/html" skipped

Powered by blists - more mailing lists