phc-discussions - RE: [PHC] PHC output specifics

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: <E1YTjUE-0005pi-Pj@login01.fos.auckland.ac.nz>
Date: Fri, 06 Mar 2015 17:03:42 +1300
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: discussions@...sword-hashing.net
Subject: RE: [PHC] PHC output specifics

Greg Zaverucha <gregz@...rosoft.com> writes:

>I support having a standardization phase. Better that we do it than some 
>standards organization. I think following the selection of a winner, a spec 
>is written

I think we could/should start on this before a winner is adopted, to make sure 
that we get there first.  If you look at the SHA-3 process, Keccak was 
declared the winner 1 1/2 years ago, but there's still nothing available 
telling you how to use it in TLS, S/MIME, etc.  I don't know which is the tail 
and which is the dog, but the lack of interest in SHA-3 and use of 
alternatives like Blake2 may have something to do with this.

In terms of standardisation, there's not much there that's design-specific, 
the API, data formats for at least PGP, S/MIME, SSH, and TLS, are all 
independent of the final choice, or at least semi-independent in that you can 
specify most of what's needed, an algorithm ID, the salt, iteration count, and 
other bits and pieces, and then fill in the gaps when the winner is chosen.  
So at least having a template available as early as possible would do two 
things, provide guidance on what to do, and dissuade others from inventing 
their own (incompatible) way of doing things.

>For comparison, the AES algorithm Rijndael supported different block sizes, 
>but the final spec fixed this parameter to 16 bytes.

There was some debate over this at the time, it's a good thing some of the 
proposals that were put forward (parameterise all the things!) didn't make it 
out...

Peter.