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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ