lists.openwall.net   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: Sat, 05 Apr 2014 13:24:46 -0400
From: Daniel Franke <dfoxfranke@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Re: Mechanical tests

Peter Maxwell <peter@...icient.co.uk> writes:

> On 5 April 2014 16:41, Daniel Franke <dfoxfranke@...il.com> wrote:
>
>     "Poul-Henning Kamp" <phk@....freebsd.dk> writes:
>     
>     > Dieharder looks for bits which do not carry one full bit of
>     entropy,
>     > whivh is important if you are in the market for random-looking
>     bits.
>     >
>     > We are not, we are in the business of making sure that entropy
>     is
>     > not lost, and we do not care if an algorithm spits out 100 bits
>     > with full entropy or 1000 bits each with only 1/10th bit of
>     entropy.
>     
>     Some of the PHC candidates claim to be key derivation functions.
>     In
>     those cases we most assuredly do care about this. It would mean
>     that the
>     effective length of your derived key is only a 1/10 what you
>     thought it
>     was.
>     
>
> ​No, PHK's definition was, probably provably, correct (for password
> hash or key derivation)​, assuming the *full* output is being used.

The definition of weakly-secure KDF, given in
http://palms.ee.princeton.edu/PALMSopen/yao05design.pdf requires the
adversary to distinguish the output of the KDF from uniformly-random
output of equal length. In the case where the KDF's output is 1000 bits
long with each bit carrying 1/10th bit of entropy, the adversary can,
with high probability, win this game in a single query just by counting
Hamming weight.

In terms of practical rather than mathematical security, "assuming the
*full* output is being used" is unreasonable. If a function is sold to
me as a KDF, I expect to safely be able to destructure its output in
order to derive multiple keys from a single invocation.

Powered by blists - more mailing lists