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 14:34:06 +0000
From: "Poul-Henning Kamp" <>
To:, Daniel Franke <>
Subject: Mechanical tests (was: POMELO fails the dieharder tests)

In message <>, Daniel Franke writes:

>#            dieharder version 3.31.1 Copyright 2003 Robert G. Brown          #
>   rng_name    |rands/second|   Seed   |
>stdin_input_raw|  1.33e+06  |3893399644|
>        test_name   |ntup| tsamples |psamples|  p-value |Assessment
>   diehard_birthdays|   0|       100|     100|0.00000000|  FAILED  
>      diehard_operm5|   0|   1000000|     100|0.00000000|  FAILED  
>  diehard_rank_32x32|   0|     40000|     100|0.00000000|  FAILED  

I spent some time thinking about "mechanical tests" for the PHC,
as a way to be able to contribute a bit "orthogonally" to all the
card-carrying cryptographers in the panel.

I do not dispute that dieharder is onto something here, but it is
not a valid test for our purposes.

If I take the ultimate password scrambler and hexdump its output,
it is going to fail dieharder even more spectaculary than the above,

Yet, it is still the ultimate password scrambler.

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.

So one of my ideas for "mechanical tests" was to use compressors
as measurement entropy, and run sanity-checking test along the
general scheme of:

	Generate_test_data > file1
	candidate_algorithm < file1 > file2
	gzip -9v file1 file2

Any algorithm where file2.gz can be smaller than file1.gz is toast.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@...eBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Powered by blists - more mailing lists