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: Fri, 6 Mar 2015 14:53:34 +0100
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] PHC output specifics

Should the "standardization phase" be public (thus after selection and
announcing winners) or not (thus by panel members only, after
selecting but before announcing winners)?

Should it be public, a risk is that it degenerates into CFRG-like

On Fri, Mar 6, 2015 at 5:03 AM, Peter Gutmann <> wrote:
> Greg Zaverucha <> 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.

Powered by blists - more mailing lists