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: <CAAS2fgRd3UqXy--c7UbrX_XTySbB63CTfMhdKtiAJd2sPZu8mg@mail.gmail.com>
Date: Fri, 6 Mar 2015 14:00:02 +0000
From: Gregory Maxwell <gmaxwell@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] PHC output specifics

Iterate. Put something out, ask for comments. Decide on the comments.

It would be foolish to not capture detailed public requirements; the
panel may be brilliant but will not think of everything, you just want
to make sure you have a process which can converge. Maybe not everyone
will be happen in the end, but if something is omitted it shouldn't be
because no one knew about the requirement.

On Fri, Mar 6, 2015 at 1:53 PM, Jean-Philippe Aumasson
<jeanphilippe.aumasson@...il.com> wrote:
> 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
> bikeshedding...
>
>
>
> On Fri, Mar 6, 2015 at 5:03 AM, Peter Gutmann <pgut001@...auckland.ac.nz> wrote:
>> 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.
>>