phc-discussions - Re: NIST standardization

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] [day] [month] [year] [list]

Date: Fri, 8 May 2015 10:39:24 -0400
From: Meltem Sonmez Turan <meltemsturan@...il.com>
To: Solar Designer <solar@...nwall.com>
Cc: discussions@...sword-hashing.net
Subject: Re: NIST standardization

Hi everyone,

Thanks Alexander for forwarding the questions to the discussion list.

On 4 May 2015 at 17:15, Solar Designer <solar@...nwall.com> wrote:

>
> Is NIST any more likely to standardize an eventual PHC winner that is
> based on a NIST-standardized primitive such as SHA-2 than on e.g. BLAKE2?
>

I believe this is correct. The candidates that are based on well-analyzed
primitives or the candidates that provide flexibility of selecting the
underlying primitive have a clear advantage for standardization. NIST would
probably want to approve a mode-like construction rather than a whole new
primitive. Approving a winner based on SHA-2 or SHA-3 will be 'faster' too.

Similarly, is NIST any more likely to standardize an eventual PHC winner
> that is based on an established primitive such as BLAKE2 than on custom
> crypto such as what we see in POMELO?
>

This is correct too. Although I like Pomelo, it needs more third-party
analysis. I don’t think it is ready for standardization.

>
> Finally, is it a valid argument for NIST that with proper entropy
> bypasses from {password, salt} to PHS() output via an established crypto
> primitive, the bulk of the processing may be considered non-crypto and
> thus any custom non-crypto like this (e.g., yescrypt's pwxform) isn't a
> barrier to standardization?

This can be a valid argument, I don't have a strong opinion on this. I
think simplicity of the non-crypto part is important here.

Cheers,
Meltem Sonmez Turan

Content of type "text/html" skipped