phc-discussions - Re: [PHC] Re: Mechanical tests

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 linux-cve-announce 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]

Message-ID: <877g73ofj5.fsf@wolfjaw.dfranke.us>
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.