[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH=RJiR4TvtOXSfvFQQ82bsH8G6McYrCkGn1u3hub0CVg1pXgQ@mail.gmail.com>
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
Powered by blists - more mailing lists