--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ef414f8dadd6437687871e4921feda0d%40nsa.gov.
On 31 Oct 2023, at 04:30, Markku-Juhani O. Saarinen <mjos....@gmail.com> wrote:
Hi,
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/4647cee6-81a8-472f-81f6-8935feabebd2n%40list.nist.gov.
Hi,
First, let me say that I think it is very good that NSA posts their suggestions on the list for public discussion. Otherwise, +1 to the comments from Mike and Markku. The suggestion seems problematic from a performance, domain separation, side-channel, and interface perspective. I think the suggestion would significantly delay adoption. To summarize, I don't think the NIST should change to SHA-2.
- As already pointed out by Mike and Markku I think the claim that "If the module is implemented in software, SHA2 is substantially faster than SHA3 or SHAKE." is incorrect. If more speed is wished for, I think TurboSHAKE is the way to go. But at this point in the standardization, I think changes would delay deployment and I don't want any delay, I want ML-KEM and ML-DSA standards and implementations as soon as possible.
- We definitely need side-channel security and more appropriate interfaces. I think the decision to use SHA-2, HMAC, and HKDF in TLS 1.3 was wrong and will haunt us in the future. Hash functions should be designed to provide indifferentiability from a random oracle. Looking at Section 10 of Draft FIPS 205 our initial thought internally was "do we really need to continue to support SHA-2" and "really hope we can get rid of SHA-2 soon". Doing anything secure with SHA-2 is complex. SHA-2 is not robust.
- NIST is in the process of updating FIPS 202. I think NIST should update FIPS 202 to discuss that the API does not have to be SHAKE(M,d) and can be “running” in both M and d. FIPS 202 states that "In other words, different procedures that produce the correct output for every input are permitted". I think the same thing should be said about APIs.
Cheers,
John Preuß Mattsson
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/AF2DEFB9-4632-4C8E-AADD-7D25D6781D41%40hoerder.net.
First, let me say that I think it is very good that NSA posts their suggestions on the list for public discussion. Otherwise, +1 to the comments from Mike and Markku. The suggestion seems problematic from a performance, domain separation, side-channel, and interface perspective. I think the suggestion would significantly delay adoption. To summarize, I don't think the NIST should change to SHA-2.
I’m not sure Domain Separation has to be a problem with SHA-2 based XOF. And I don’t think Hash_DRBG would/should be the way to employ SHA-2.
- As already pointed out by Mike and Markku I think the claim that "If the module is implemented in software, SHA2 is substantially faster than SHA3 or SHAKE." is incorrect.
We benchmarked SHA-2, SHA-3, and SHAKE. SHA-2 is absolutely faster than SHA-3, and a little faster than SHAKE. That’s a fact – if you disagree, run your own benchmarks.
If more speed is wished for, I think TurboSHAKE is the way to go.
AFAIK, TurboSHAKE is not a standard at this point, and It’s unclear if/when it would be. Nor is it SHAKE (nor SHA-3).
We aren’t comparing performance with TurboSHAKE, are we?
Leaving alone other points that I don’t want to debate, at least now.
TNX
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/GVXPR07MB96785932B0F3AA446187EAA989A0A%40GVXPR07MB9678.eurprd07.prod.outlook.com.
On Oct 31, 2023, at 14:52, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:
- As already pointed out by Mike and Markku I think the claim that "If the module is implemented in software, SHA2 is substantially faster than SHA3 or SHAKE." is incorrect.
We benchmarked SHA-2, SHA-3, and SHAKE. SHA-2 is absolutely faster than SHA-3, and a little faster than SHAKE. That’s a fact – if you disagree, run your own benchmarks.
Hi Uri,
I am sure that the domain separation problems could be fixed, but discussing and fixing such a basic security issue when the final standards are months away does not feel optimal.
Regarding performance, there are quite a lot of public benchmarks for x86 and ARM. I regret quoting NSA as their statement is both too general and not very relevant. I think the important comparison here is SHAKE128 and SHA-512 (correct me if I am wrong). SHAKE128 is slightly slower than SHA-512 on x86, but often slightly faster on ARM. I have not seen any performance figures for RISC-V. When looking at future standards I think ARM is likely more important than x86. ARM seems to be the future of both cloud and laptops. RISC-V is already important for embedded devices and will soon likely be important in cell phones. I don’t think it is correct to state that SHA-512 is substantially faster than SHAKE128 is software. Also, the important thing is not the hash functions themselves but the performance of Kyber and Dilithium. I think NSA has a lot of implementation and performance testing to do before they can claim that the suggested change makes Kyber and Dilithium faster in software. Right now, I tend to trust Markku’s analysis that the change would make Kyber and Dilithium slower in software. In hardware SHAKE is much more efficient than SHA-2.
Cheers,
John Preuß Mattsson
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/39724B5C-C4B0-4061-B98D-6ADE00732E15%40ll.mit.edu.
SHAKE is cool and all, but one downside is that it isn't parallelizable, whereas something like a cipher or hash in counter mode is.
The public comment period for the draft FIPS is still open until November 22nd. After that date, NIST will begin evaluating all the public feedback received, and decide what (if any) changes should be made in response to the comments.
We did want to offer a short response to part of Morgan's 10/30/2023 post (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/SPTpYEP7vRg/m/NK_ko8YtAQAJ) which started this thread. His point S3) mentioned possibly considering a SHA2 primitive for use in FIPS 203 and FIPS 204. Of course, we will wait and carefully weigh all the comments received by the deadline, but NIST currently has no plans to consider using a SHA2 primitive for FIPS 203 or FIPS 204 instead of the SHAKE/SHA3 primitives already in the draft FIPS. We feel that would be a significant change from the 3rd round submissions, and want to minimize changes introduced.
Dustin Moody
NIST PQC