The FOIA request "NSA, NIST, and post-quantum cryptography" was filed in March 2022. A lawsuit was filed in August 2022; an accompanying blog post gives more background. The U.S. government began delivering some records in September 2022.
This page is an index of the records delivered by 20230915, plus notes last edited 20230915 23:13:56 UTC. Records are ordered chronologically by dates listed on the records, or by date estimates for records not providing dates.
Comparing NIST's claims of transparency to the facts. The call for submissions for NIST's Post-Quantum Cryptography Standardization Project stated that "NIST will perform a thorough analysis of the submitted algorithms in a manner that is open and transparent to the public": https://web.archive.org/web/20220119113311/https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/call-for-proposals-final-dec-2016.pdf
Matthew Scholl, Chief of the Computer Security Division in NIST's Information Technology Laboratory, claimed in October 2021 regarding the same project that "We operate transparently. We've shown all our work": https://web.archive.org/web/20211115191840/https://www.nist.gov/blogs/taking-measure/post-quantum-encryption-qa-nists-matt-scholl
In fact, many of the records below were hidden from the public until this lawsuit forced their disclosure. Some of the records show critical decision steps, including outright errors that could have been corrected if they hadn't been concealed. It's clear that NIST's non-transparency was intentional; some of the records are even marked "not for public distribution".
Some information was available. For example, various submissions and "KAT" files sent to NIST were promptly posted on NIST's web site, already starting in 2017. NIST has padded its FOIA responses by including copies of various records that were already on its web site, even though, for such records, the FOIA request had asked for specific URLs, not copies.
Patterns observed in the records delivered so far. The notes below use hash tags for some recurring themes:
There is also a #needmorerecords hash tag for questions that one can reasonably hope will be answered by further FOIA records. Questions about whether particular documents were public might be resolved through separate searches and are marked with #weveshownallourwork rather than #needmorerecords.
20100716 14:48:42 -04 file 20230315/quantum-feistel.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Paper showing how to break a particular type of cipher if the cipher user has a quantum computer that applies the cipher to quantum inputs from the attacker.
20130123 15:10:00 -0500 file 20230619/quantumisogenies.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Talk slides. Were these slides public before this FOIA lawsuit? #weveshownallourwork
Rostovstev–Stolbunov cryptosystem: "Mainly of theoretical interest"
"Flaws of previous system: Not very efficient ... Subexponential attack"
(For comparison, FrodoKEM is broken in time subexponential in the key size. Has NIST ever described this as a "flaw" in FrodoKEM? #inconsistency)
Regarding SIKE: "New supersingular isogeny-based cryptosytem: Way more efficient ... No subexponential attack known"
"Conclusion: wait and see"
20130315 13:01:49 UTC file 20230619/Differential Invariants.pptx:
Notes from djb, last edited 20230622 22:46:00 UTC:
Talk slides about an aspect of security analysis of MQ cryptosystems.
20130909 02:03:10 -0400 file 20230619/13371.SmithDaniel.Slides.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Talk reviewing various MQ cryptosystems. Were these slides public before this FOIA lawsuit? #weveshownallourwork
20131205 file 20230315/20131205-lecture.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Public lecture notes.
20140506 08:19:06 -0400 file 20230619/dings crypto club talk.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Talk on Rainbow and other MQ systems. Similar to slides from some public talks on other occasions.
"The security analysis has solid theoretical support"
201410 file 20230206/ETSI-workshop-LilyChen.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of an external talk in 2014.10.
"Quantum Resistant IKE": "It is very likely that a quantum resistant encryption scheme will be used to establish keys"; "Require a fast key pair generation"
This seems to be claiming that a quantum-resistant variant of IKE can't work without fast key generation. But that's not true. #error
20141112 file 20230517/Fwd Four decks for NIST.msg:
Notes from djb, last edited 20230608 22:17:45 UTC:
Email to "Michaela Iorga" and "Meltem Sonmez Turan" with "slide decks for today".
Four PDFs. Hash-based "keyless signatures".
20150216 file 20230517/Third Draft NIST ITL Patent Process for Its P.docx:
Notes from djb, last edited 20230608 22:17:45 UTC:
Third secret draft of a policy document.
20150313 19:36:00 UTC file 20230517/Fourth Draft NIST ITL Patent Process for Its .docx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Fourth secret draft of a policy document. Authorship is not clearly indicated but "Mike Hogan" is listed as a contact.
"Our preference is to develop ITL publications that do not include patent concerns in order to not encumber the development and implementation of our publications. In some instances, such as NIST cryptographic competitions, we require that the candidate cryptographic algorithms to be offered on a Royalty Free (RF) basis. In general, the use of an essential patent claim (one whose use would be required for compliance with the guidance or requirements of the publication) may be considered if technical reasons justify this approach. In such cases, a patent holder would have to agree to either Royalty Free (RF) or Reasonable and Non-Discriminatory (RAND) licensing to all interested parties."
If patent holders do not agree to RF or RAND: "In such case, NIST shall determine if the patent claim appears to be pertinent. If the patent claim appears to be pertinent to NIST, the publication shall not include provisions depending on that patent."
The specific provision requiring royalty-free submissions to "competitions" is in line with NIST IR 7977, which clearly states that, for a NIST competition, winners relinquish intellectual property rights so that the winner can be used royalty-free.
For comparison, NIST avoided calling NISTPQC a "competition"; avoided requiring submissions to be royalty-free; and drastically slowed down development and implementation of its post-quantum encryption standards by selecting a cryptosystem in the middle of a patent minefield. #inconsistency #slowingdownpqcrypto
Furthermore, after NISTPQC was underway, NIST quietly posted a toothless policy saying "In the case of NIST ITL cryptographic competitions, ITL may require that candidate cryptographic algorithms be offered on an RF and RAND basis" and saying that ITL "may" exclude material if patent holders do not agree to RF or RAND. #inconsistency
20150622 10:04:39 +0200 file 20230508/QuantumSafeWhitepaper.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Public white paper from ETSI.
20151130 17:26:16 UTC file 20230508/PQC at UMD.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Filename indicates that this was (a draft of?) a slide set for a talk at UMD. Was this talk public?
"For most of the potential PQC replacements, the times needed for encryption, decryption, signing, verification are acceptable": Acceptable for what? How was this evaluated? For comparison, NIST later used timings as a major deciding factor. #missingclarity #ftqcic
"Some key sizes are significantly increased": Significant for what? How was this evaluated? #missingclarity #ftqcic
"Some ciphertext and signature sizes are not quite plausible": Plausible for what? How was this evaluated? #missingclarity #ftqcic
"Key pair generation time for the encryption schemes is not bad at all": Not bad for what? How was this evaluated? #missingclarity #ftqcic
"No easy “drop-in” replacements": How was this evaluated? #missingclarity #ftqcic
"The NIST PQC Project ... Biweekly seminars since 2012" #weveshownallourwork
"Cannot use general lattices, key sizes are too big!": Too big for what? How was this evaluated? #missingclarity #ftqcic
20151202 20:29:36 UTC file 20230508/Challenges in PQC standardization - 11302015 .pptx:
Notes from djb, last edited 20230608 22:17:45 UTC:
Draft of "Challenges in PQC standardization - 12102015.pdf".
20151210 file 20230105/Challenges in PQC standardization - 12102015.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a talk. Was this talk public? #weveshownallourwork
"We have more than 20 years experience in PKC standardization"
"Will the experience be sufficient for developing PQC standards?"
"Shortest Vector Problem (SVP) is NP-hard under randomized reductions": Why did NIST praise lattice-based cryptography on the basis of irrelevant NP-hardness results while not praising other types of cryptography on the basis of irrelevant NP-hardness results? #inconsistency
"The original version of the McEliece cryptosystem has a key length of million of bits": Half a million, not millions. #error
20160106 file 20230315/ACMD News (Vol. 5, No. 1).pdf:
20160106 10:00:00 file 20230619/RE_ some comments(1).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email scheduling internal discussion of NIST report. #weveshownallourwork
20160106 10:12:49 file 20230508/Re_ are you around today_.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Email from Donna Dodson (NIST higher-up) asking for a discussion of an upcoming NIST report.
20160106 10:17:00 file 20230619/RE_ some comments.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email scheduling internal discussion of NIST report. #weveshownallourwork
20160107 file 20230315/ISPAB_ Draft Recommendation Letter re. Quantum ...(1).pdf:
Notes from djb, last edited 20230321 15:29:09 UTC:
Refers to "ISPAB Ltr to NIST on Quantum Computing 20160106-1a.docx" attachment including "tracked changes for easy readability".
20160107 07:11:00 file 20230619/Re_ post quantum stuff.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
"It will be similar to, but NOT, a competition"
For comparison, the Dual EC post-mortem said that NIST's VCAT "strongly encourages standard development through open competitions, where appropriate". #inconsistency
20160107 19:27:00 UTC file 20230315/ISPAB Ltr to NIST on Quantum_Computing_201601.docx:
Notes from djb, last edited 20230622 22:46:00 UTC:
Draft of letter from "Peter Weinberger, Ph.D., Chair, Information Security and Privacy Advisory Board" to NIST director "Dr. Willie E. May" and OMB director "The Honorable Shaun Donovan". Edits from Sokol.
"At our meeting October 21, 2015 we had presentations by employees of National Institute of Standards and Technology (NIST) and National Security Agency (NSA) related to quantum computing. We discussed the critical concerns that would arise from the development of a cryptographically capable quantum computer, including making insecure all present and future uses of current public key cryptography. ... A plan for quantum resistance should provide a roadmap and timeline for getting to generally accepted standards, protocols, and, perhaps, competitions for necessary algorithms. Unfortunately not enough is known to lay out such a plan. The Board urges the creation of a strategy to develop such a plan."
What exactly did NSA say? Some digging finds partial information: minutes and slides from a presentation "NIST and NSA Future Plans for Quantum Resistant Cryptography".
One interesting comment in the slides is "Don’t force elliptic curve transition (resources)". For comparison, NSA subsequently announced that it wants everybody to finish moving to post-quantum encryption by 2035. That's twenty years after this ISPAB presentation.
The minutes say, regarding NSA's "announcement in August 2015 on quantum computers", that "The announcement was also abruptly made owing to a mandate for NSA to transition to strictly elliptic curve protocols for public key cryptography in October 2015. NSA felt an obligation to make the announcement prior to the October deadline and because some of their partners would conscientiously move forward with the transition on their own."
Other interesting comments in the minutes: "NIST is further working with the international community for general acceptance of Product Quality Characteristic (PQC) standards. ... The Chair noted that the early uses of public key had many algorithms that were not truly secure and suggested there may be a need for several algorithms."
#nsa
20160108 16:36:23 file 20230517/Re_ Keyless signature infrastructure.pdf:
20160111 09:54:54 file 20230619/Re_ Your visit to NIST .pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Chen, Lily" and "Scott Simon (scott.b.simon@gmail.com)" about "an internal PQC meeting tomorrow". #weveshownallourwork
Quotes email from "Chen, Lily" to the same "Scott Simon" about Simon's upcoming visit to NIST on 12 January 2016.
(NIST SP 800-56B lists two coauthors identified as "NSA", one of them being "Scott Simon", presumably the same person visiting NIST.)
What exactly was communicated between NSA and NIST during this visit? #needmorerecords #nsa
20160112 11:45:16 file 20230517/Re_ meeting at RSA.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Planning meeting with Paul Kocher.
20160113 09:01:31 file 20230619/RE_ PQC timeline.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email on general planning of the competition.
Quotes draft email proposing "We can accept submissions on ongoing basis anytime after our deadline, but we won't promise when we'll get to them". This is very different from what NIST ended up doing. #inconsistency
20160113 14:26:37 file 20230619/Re_ PQC meeting tomorrow(1).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Logistics email about internal NIST content discussions. #weveshownallourwork
Quoted email from Moody says "I appreciated the feedback from the NSA and Donna, as they gave us a perspective I think we were lacking" and "NSA wants to coordinate with us before PQCrypto". Also refers to "our NSA friends". #nsa
20160114 file 20230315/Outline for PQC announcement.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email to "Liu, Yi-Kai" and "Perlner, Ray" and "Peralta, Rene" and "Chen, Lily" and "Bassham, Lawrence E" and "Jordan, Stephen P" and "Daniel C Smith" saying "I'm going to start working on the slides for our announcement at PQCrypto".
"Mention NSA's statement? (not sure about this) EU's project?"
"Should we try to 'fast-track' those proposals that seem more mature?"
"pqc@nist.gov - NSA gets this email as well"
#nsa
20160114 01:57:24 file 20230508/Re_ Outline for PQCrypto announcement.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Moody, Dustin" suggesting questions to pose to the public.
"How can we encourage more work on quantum cryptanalysis?" (NIST did pose this question, but NIST's "categories" discouraged work on quantum cryptanalysis. #inconsistency)
"If we want to standardize some post-quantum cryptosystem that has worse parameters (such as key length) than our currently-deployed crypto, this may have consequences for higher-level protocols and applications. How can we encourage people to study these issues? For instance, I would feel more confident if we had some more prototype implementations of post-quantum TLS and IKE protocols."
20160114 09:31:00 file 20230517/RE_ Latest version of NISTIR and other document...(3).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Acknowledgment.
20160114 09:38:12 file 20230508/PQC NISTIR version 2.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"I’ve incorporated the revisions and edits we discussed regarding the comments received from Donna and the NSA." What was the NSA input? #nsa #needmorerecords
20160114 10:50:35 file 20230508/PQC Crypto Club Talk(3).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Perlner, Ray" and "Liu, Yi-Kai" and "Jordan, Stephen P" and "Peralta, Rene" and "Chen, Lily" and "Daniel C Smith" and "Bassham, Lawrence E".
"We're going to give the crypto-club talk on Feb. 3rd, at 10am, on our PQC project and its upcoming plans. I'm thinking we should plan for roughly 90 minutes of talking, which would leave ample time for questions. To ease the burden of preparing, I would like to break up the presentation, and have several of us give different parts of it. Here's my initial thought for how we could do this:"
"1) (10 min) Yi-Kai Introduction. Impact of quantum on PKC/NIST standards. What are quantum computers, Shor's algorithm, Grover's algorithm. What is post-quantum crypto. Difference with quantum crypto/QKD. NIST project/team. Why this all matters right now. Then lead into broad overview of the main candidates."
"2) (10 min) Yi-Kai or Ray Lattice-based crypto summary"
"3) (10 min) Ray Code-based crypto summary"
"4) (10 min) Ray Hash-based signatures"
"5) (10 min) Rene Multivariate crypto summary"
"6) (5 min) Rene Other candidates (isogeny-based, maybe braid groups?)"
"7) (5 min) Rene Overall summary. Our table of key sizes / timings. No obvious drop-in replacement. Which criteria are most important?"
"8) (10 min) Stephen State of quantum computing. Recent advances. Estimates of future progress (time/cost)"
"9) (20 min) Dustin NIST's plans. Workshop recap. NSA announcement. Transition importance. NISTIR. Call for Proposals. Evaluation criteria. Process. Timeline. How this will affect the group."
"Does this make sense to everyone? Any suggestions. Yi-Kai, Ray, Rene, Stephen, are you good to cover these topics on Feb. 3rd? I think everyone should make their own slides using powerpoint, and then we can combine them all into one. I've attached a few resources that might be helpful. Also, on our wiki page we have slides from most of our past presentations: http://nistpqc.wikispaces.com/" #needmorerecords
Were "key sizes" and "timings" the reason for NIST claiming "No obvious drop-in replacement" in 2016? #needmorerecords
20160114 11:33:00 file 20230517/RE_ Latest version of NISTIR and other document.(2).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Scheduling.
20160114 12:31:09 file 20230619/RE_ PQC Crypto Club Talk(2).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email about NIST talks. Were the slides public before this FOIA lawsuit? #weveshownallourwork
20160114 12:32:00 file 20230508/PQC talk on Feb 3rd.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Email to "Daniel C Smith" asking for a short talk on multivariate crypto.
20160114 14:04:27 file 20230619/Re_ PQC Crypto club talk(3).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email planning talk. Was this talk public before this FOIA lawsuit? #weveshownallourwork
"Maybe we can borrow some text from the ETSI white paper?"
20160114 14:30:00 UTC file 20230315/PQC NISTIR v2.docx:
Notes from djb, last edited 20230608 22:17:45 UTC:
Draft report.
20160114 14:30:00 UTC file 20230508/PQC NISTIR v2.docx:
20160114 14:30:00 UTC file 20230517/PQC NISTIR v2.docx:
20160114 14:30:00 UTC file 20230619/PQC NISTIR v2.docx:
20160115 file 20230508/PQC crypto club talk(1).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Email to "Peralta, Rene".
"I was hoping you could speak on multivariate crypto, and the miscellaneous systems which don’t fall into one of the main families."
"We have lots of slides that we can use, since Daniel has given several talks on multivariate, and I’ve given a talk on isogeny-based systems." [Presumably referring to Daniel Smith-Tone.]
20160115 14:28:12 file 20230619/Re_ PQC Crypto Club Talk(1).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email agreeing to give a talk about lattices. Was this talk public before this FOIA lawsuit? #weveshownallourwork
20160119 file 20230315/Fwd_ feistel cipher and quantum.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Liu, Yi-Kai" saying "Have you seen this paper? Do you know what to make of it?". Refers to "quantum-feistel.pdf" attachment. #scramble
20160119 09:35:00 file 20230508/RE_ Outline for PQC announcement.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Forwarded email from Moody says "By the way, our next meeting with the NSA PQC folks is Jan 26th." This email approves disclosing NIST's plans to NSA. #nsa
What exactly happened in NIST's discussions with NSA? #needmorerecords
20160120 file 20230315/Japan Trip for Dr. Smith-Tone Passport Request..pdf:
20160120 file 20230315/One more set of slides.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Peralta, Rene" saying "I've also found some slides for an introductory talk by Tanja Lange on multi-variate crypto." #scramble
20160120 file 20230315/crypto-club talk.pdf:
Notes from djb, last edited 20230321 15:29:09 UTC:
Email to "Sonmez Turan, Meltem" with a talk title ("Post-Quantum Cryptography: NIST's plan for the future") and abstract.
20160120 09:17:00 file 20230619/Slides for Crypto Club talk.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email forwarding miscellaneous slides. #weveshownallourwork #scramble
20160120 09:21:00 file 20230508/PQC crypto club talk.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Jordan, Stephen P" asking for a short talk on quantum computing. #scramble
20160120 15:00:36 -0500 file 20230619/CNSA-Suite-and-Quantum-Computing-FAQ.pdf:
20160121 file 20230315/Crypto Reading Club - February 3, 2016.pdf:
Notes from djb, last edited 20230321 15:29:09 UTC:
Email to "CRYPTO-CLUB": "Our post-quantum cryptography group (Yi-Kai Liu, Ray Perlner, Rene Peralta, Stephen Jordan, Dustin Moody, and possibly Daniel Smith-Tone) is going to present the talk titled 'Post-Quantum Cryptography: NIST's plan for the future'."
20160121 12:20:04 file 20230508/pqc stuff.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email to "Liu, Yi-Kai".
"Our next meeting with the NSA, we'll also tell them of our plans. ... Hopefully they have some good pointers. ... Feb 2nd, we have Michael Groves from the CESG in UK coming. He's one of the guys behind the soliloquy stuff. We met him on our trip to Germany last month, and invited him."
#nsa
20160121 17:05:43 UTC file 20230508/PQCrypto 2016.pptx:
Notes from djb, last edited 20230608 22:17:45 UTC:
Draft of slides for a public talk.
20160121 17:15:17 file 20230508/PQCrypto slides.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Next Tuesday (1/26) we'll go over our PQC plans with the NSA." #nsa
What exactly happened in NIST's discussions with NSA? #needmorerecords
20160125 15:11:21 file 20230508/Re_ Crypto Reading Club - webpage .pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Email chain shows various talks given to NIST:
20160125 20:59:57 file 20230619/Re_ PQC NISTIR version 2(3).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email with comments on a report. #weveshownallourwork
20160126 file 20230315/FW_ PQC NISTIR version 2.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Grance, Tim" forwarding email from "Moody, Dustin" saying "I’ve incorporated the revisions and edits we discussed regarding the comments received from Donna and the NSA." What was the NSA input? #nsa #needmorerecords
20160126 01:57:00 UTC file 20230619/difference-detected-PQC NISTIR v2.docx:
Notes from djb, last edited 20230622 22:46:00 UTC:
Supplied as "PQC NISTIR v2.docx".
Draft with some internal editing notes. #weveshownallourwork
20160126 10:10:14 file 20230915/Re_ PQC NISTIR version 2(2).pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
More followups to "I’ve incorporated the revisions and edits we discussed regarding the comments received from Donna and the NSA."
#nsa
20160127 08:36:44 file 20230517/Re_ Latest version of NISTIR and other document...(1).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Replying to 25 January email that said "It has a bunch of comments by Donna and the NSA people, and I remember we discussed those comments at one of our meetings, but I don't know if we updated the NISTIR after that discussion?" #nsa
Earlier in the thread, 12 January email said "The latest version of the PQC NISTIR (with comments from NSA and Donna) is attached."
20160127 09:30:01 file 20230619/Slides for our Crypto Club talk.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Logistics email about NIST post-quantum talks and internal NIST discussions of an upcoming report. Were the talk slides public before this FOIA lawsuit? #weveshownallourwork
"We were going to meet with the NSA yesterday ... The NSA still wants to meet with us soon ... I'm still checking with them, but it might work out for us to meet tomorrow (Thursday) at 1pm, right before we all meet with Carl Miller. This is just a heads up that we might have a last minute meeting at that time." #nsa
20160127 16:28:18 file 20230517/Re_ Latest version of NISTIR and other document....pdf:
20160127 21:24:00 UTC file 20230517/PQC NISTIR v2 YKL.docx:
Notes from djb, last edited 20230608 22:17:45 UTC:
A few comments from "yikailiu".
20160128 file 20230315/Final call for changes to NISTIR.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Daniel C Smith" and "Perlner, Ray" and "Peralta, Rene" and "Chen, Lily" and "Liu, Yi-Kai" and "Jordan, Stephen P" with last call for comments "before Monday" on a NISTIR draft. "Jim Foti" would prepare the draft for publication; "Matt" (presumably Matthew Scholl) suggested 30 days of public comments.
Email also includes a reminder that "next Tuesday we meet with Michael Groves". Michael Groves is from GCHQ, NSA's UK partner. What did GCHQ tell NIST? #nsa #needmorerecords
20160128 file 20230315/NISTIR ready for WERB_.pdf:
Notes from djb, last edited 20230321 15:29:09 UTC:
Email to "Chen, Lily" cc'ing "Liu, Yi-Kai" regarding publication procedures for NISTIR. Refers to "WERB" procedures and suggestion from "Donna" (presumably Donna Dodson) to have "Ed Roback" (Treasury) as an external reviewer.
20160128 09:20:00 file 20230619/RE_ PQC NISTIR version 2(1).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email about report editing. #weveshownallourwork
20160128 10:29:35 file 20230517/RE_ NISTIR ready for WERB_.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Deciding whether to ask for public comments.
20160128 14:17:00 UTC file 20230619/PQC NISTIR v3.docx:
20160128 14:21:00 UTC file 20230315/PQC NISTIR v3.docx:
Notes from djb, last edited 20230608 22:17:45 UTC:
Draft report.
20160128 16:21:08 file 20230508/RE_ Final call for changes to NISTIR(5).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Attaching comments on report.
20160128 20:14:10 file 20230508/Re_ Final call for changes to NISTIR(4).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
"I have also added my comments. The attached file should have both mine and Ray's."
20160128 21:19:00 UTC file 20230508/PQC NISTIR v3 Ray Comments.docx:
20160129 file 20230315/Fw_ Final call for changes to NISTIR.pdf:
Notes from djb, last edited 20230321 15:29:09 UTC:
Email to "Regenscheid, Andrew" with last call for comments on draft NISTIR.
20160129 file 20230508/Re_ Final call for changes to NISTIR(3).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Email about scheduling.
20160129 01:11:00 UTC file 20230508/PQC NISTIR v3 Ray and Stephen Comments.docx:
20160129 10:16:49 file 20230508/Re_ Final call for changes to NISTIR(1).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email to "Moody, Dustin".
"On page 6 you referred to changes to “Suite B.” If they didn’t comment on this, then I have no problem with it. But, until yesterday it escaped me that they’re not calling the new guidance “Suite B” anymore. Did they want to change it something else? Guidance on the use of public cryptographic algorithms for protecting national security systems?": #nsa
The "If they didn't comment on this" wording appears to indicate that Regenscheid knew that NSA had an opportunity to comment but didn't know if they had commented on this in particular. What exactly did NSA tell NIST? #needmorerecords
"First, while we might informally say it, I don’t think we usually formally refer to ourselves as “judges” in our crypto competitions. And in any event, I think what you describe about NIST’s role is pretty much the same thing we do in competitions."
20160129 10:21:02 file 20230508/Re_ PQC NISTIR version 2.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Email regarding publication logistics (and non-publication of NIST's comments on drafts).
20160129 10:24:01 file 20230508/Re_ Final call for changes to NISTIR(2).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Acknowledging "Re_ Final call for changes to NISTIR(1).pdf" comments.
20160129 10:27:19 file 20230508/RE_ Final call for changes to NISTIR.pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
Comments on draft report.
20160129 10:56:23 file 20230517/Re_ IPR question for PQC (1).pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
"This is draft but has some good thoughts on this issue IMO. "
Beginning of thread was from "Moody, Dustin": "We have (it seems to me) two possible ways we can approach the IPR issue in our call: 1) Require that there is no royalties, no IPR, require patent disclosures, etc.. during our process. Right will be returned to the submitters if we do not standardize their algorithm. This is similar to what was done with SHA-3, which then returned the rights to the submitters of the algorithms that weren't selected. If we do it this way, when would we return the rights? We're describing this as kind of like the modes process, where even if we don't initially choose to standardize an algorithm, it doesn't meet that it is "out". 2) We could ask for patent disclosures, but not require algorithms be royalty-free. We would need to warn submitters that it is obviously a big advantage to submit IPR free algorithms, as it will be a big factor in our decision. Any thoughts? Do we need to get the advice of Matt/Donna/lawyers?"
20160129 12:50:04 file 20230517/Re_ IPR question for PQC(2) .pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
"My understanding of the SHA-3 competition, and the AES competition before it, is that the IPR rights were only waived conditionally, e.g., for the purposes of vetting, and in the event that NIST standardized the algorithm. (We also requested that submitters disclose IPR that they thought might read on other candidates, although I don’t think we had any way of enforcing this request.) Therefore, the question of “returning” the rights should’t arise—my intuition is that something like Option 1 should be workable even for an informal, ongoing process."
"The main issue is whether we can expect to obtain acceptable algorithms under Option 1. The block cipher modes process operates under Option 2, because the possibilities for modes are more limited than for the underlying block cipher, and we don’t always know in advance what properties will be required of the mode. For example, we’re about to approve modes for format-preserving encryption that are encumbered by IPR, because we don’t have any good, royalty-free methods that achieve the same properties."
"For PQC, perhaps it would be useful to examine the scope of existing patents (e.g., NTRU’s, I assume?) to help inform this decision."
20160129 15:14:00 UTC file 20230508/PQC NISTIR v3-arr.docx:
Notes from djb, last edited 20230622 22:46:00 UTC:
Comments from "Regenscheid, Andrew".
"See my note in my email about this. Did NSA comment on this?" #nsa
"I don't think we typically refer to our role as judges, even if it is a fairly descriptive term."
20160129 15:22:00 UTC file 20230508/llc-PQC NISTIR v3 Ray and Stephen Comments.docx:
Notes from djb, last edited 20230608 22:17:45 UTC:
Draft report, with comments from Jordan, Perlner, and Chen.
20160129 16:03:20 UTC file 20230105/Hash-Based Signatures.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
A few comments on hash-based signatures.
20160129 19:16:56 file 20221003/CodeCryptoShort.ppt:
Notes from djb, last edited 20221005 15:48:18 UTC:
Summary of some code-based cryptosystems.
20160131 16:31:15 file 20230517/RE_ IPR question for PQC .pdf:
Notes from djb, last edited 20230608 22:17:45 UTC:
"Following up with Henry Wixon got away from me but I’m going to bring this up with him tomorrow. Since the attached is still a draft, I would keep it inside NIST for now. But I’ll make it a priority to get NIST clearance for us to post a finalized copy on our ITL web pages and letting everyone know."
Replies to message from "Scholl, Matthew": "We have some generic language on an IPR call that we adapted from ANSI (I think). If there turns out to be IPR then we can decide how to handle it from there. We have done the range of not taking it or negotiating an open license or something that is Reasonable and Non-Discriminatory (RAND). Mike hogan worked up both the language and the steps to go through in making the decision. I will find it for your consideration (or ask mike for another copy)"
20160131 21:32:54 -0500 file 20230619/ykliu-pqc-crypto-club-2016.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Talk slides. Were the slides public before this FOIA lawsuit? #weveshownallourwork
For some reason the overview slide on "Lattice-based" and "Code-based" and "Multivariate" describes the trapdoor for "Code-based" and "Multivariate" as "Linear transformations that reveal structure" but describes the trapdoor for "Lattice-based" as "Nice basis for the lattice (short, almost-orthogonal vectors)". Why not consistently say "Linear transformations that reveal structure" for all three?
"Hash-based signatures": "Caveat: signing algorithm has to update an internal data structure every time it signs a message". This is true for some hash-based signature systems but not for others. #error
"Regev's encryption scheme": "Theoretical security guarantees". No, theory does not guarantee security of this scheme. #error
"Provably secure variant of NTRUSign": No, that variant has not been proven secure. #error
"Signatures using Fiat-Shamir heuristic": "Provably secure based on hardness of SIS problem": No, these signatures have not been proven secure, and some of them have been broken. #error Furthermore, SIS hardness is merely conjectured, and some cases of SIS have been broken. #error Furthermore, even if the intention was merely to say that if SIS is hard then these signatures are secure, that's an exaggeration of what has been proven. #error
"Quantum attack on the Soliloquy cryptosystem": Cites "Commentary" downplaying this line of attacks. When the main lines drawn in that "Commentary" were broken by subsequent attacks, did NIST retract this citation? #needmorerecords
"Worst-case to average-case reduction doesn't say anything meaningful in this regime": Then why did NIST later use these reductions as a basis for selecting some cryptosystems in this regime? #inconsistency
20160131 21:37:16 file 20230619/Re_ PQC Crypto Club Talk.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Email sending slides for a talk. Was this talk public before this FOIA lawsuit? #weveshownallourwork
20160201 02:32:36 UTC file 20230619/ykliu-pqc-crypto-club-2016.pptx:
20160202 09:10:39 file 20230727/RE_ NISTIR # request.pdf-attachment-RE_ NISTIR # request.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Assigning publication number IR 8105.
20160202 09:42:47 file 20230727/Re_ FW_ new NISTIR for post-quantum cryptography.pdf-attachment-Re_ FW_ new NISTIR for post-quantum cryptography.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Discussing publication plans for NIST IR 8105.
20160202 12:08:25 file 20230915/Re_ PQCrypto slides_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"ETSI's process is sort of a "path of least resistance" to establishing a consensus on post-quantum technologies."
"An example of this would be my comment about the gap between theory and practice in the state-of-the-art lattice reduction algorithms. If we face a situation in which we choose lattice signatures but choose parameter sizes that have a more concrete justification, it would be nice (for political reasons) to be able to refer to an ETSI document admitting that the discrepancy between their recommended parameters and justified parameters exists."
"I'm sorry to be so paranoid, but I am skeptical that ETSI's process is accurately reflecting the state of knowledge in PQ, even though I think that the recommendations they are making are reasonable from their claimed standpoint."
Quoting "How are we going to collaborate with other standards organizations?"
Quoting "In the next 5-7 years, when we are working on PQC standards, I am sure other standards will work on PQC as well. What we can do to collaborate with other standards organizations."
Quoting "Between slides 6 and 7: I think it might be helpful to add a slide saying that there is no "silver bullet" for post-quantum cryptography, i.e., there is no one candidate that will satisfy everyone. Every candidate has some disadvantages: McEliece has giant keys, hash based signatures are prone to accidental misuse, NTRUSign leaks some information, etc. And, above all, there hasn't been enough research on quantum algorithms to be really confident about the security of some of these schemes."
Quoting "As a result, I think that post-quantum cryptography is a much more complicated situation than AES or SHA-3. It may be impossible to achieve consensus on which candidate is "the best." Instead, I think our goal should be to pick a candidate that is "well rounded" in the sense that it meets everyone's minimum requirements. (This is elaborating on some of your comments on slide 7.)"
Quoting "Maybe instead of calling this a "competition," we could say that this is a "standards development process"?"
Quoting "On slide 8: Under "minimal acceptability requirements," I would add "theoretical and empirical evidence that provides justification for claims about security." "
Quoting "On slide 15: Under the question "How is the timeline? Too fast? Too slow?" maybe add another question "Should we do this only once, or have an ongoing process to standardize technologies as they become mature?" "
Quoting "Next Tuesday (1/26) we'll go over our PQC plans with the NSA."
20160202 14:53:00 file 20230815/RE_ FW_ Reminder_ Crypto Reading Club - TOMORROW_Redacted.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Email from "Chen, Lily" to, presumably, Jacob Alperin-Sheriff, regarding logistics for attending an internal NIST talk.
#weveshownallourwork
20160202 15:46:01 file 20230727/Crypto Club Talk Combined Slides.pdf-attachment-Crypto Club Talk Combined Slides.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
"Here is a pdf file with all our slides combined. Thanks everyone for all your hard work!"
20160203 file 20230727/Crypto Club Talk Combined Slides.pdf-attachment-Crypto Club Talk Combined Slides.pdf-attachment-PQC Crypto Club Talk.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Talk slides. Were the slides public before this FOIA lawsuit? #weveshownallourwork
First part looks like 20230619/ykliu-pqc-crypto-club-2016.pdf, including the same errors.
Regarding hash-based signatures: "Leighton-Micali is old enough that it can’t still be in patent, although I think XMSS is not patented."
Isogeny-based encryption: "Less studied and do worse than lattice based." It's unclear what these claims mean. There are many papers on various aspects of lattices, but there are also many papers on various aspects of isogenies. There have been important security losses for isogeny-based cryptosystems, but there have been many more security losses for lattices. #missingclarity
"We propose to ignore them." Was this proposal internally rejected? Was it internally approved but kept secret? For comparison, NIST later called for submissions and asked for public evaluations, not saying that it had decided to ignore some classes of cryptosystems. #needmorerecords
Braid-group cryptography: "Some proposals have been shown insecure. We propose to ignore them." Some lattice proposals have also been shown insecure. #inconsistency
Regarding key size, key-generation time, etc.: "Which are most important in practice? ... Not a lot of benchmarks in this area" How did NIST end up deciding that most of these metrics were important decision-making factors? #needmorerecords
Incorrect benchmarks, incorrect asymptotics, and unclear claims about importance of various metrics. See notes on 20230105/Crypto in PQ world -DoC.pdf. #error #inconsistency #missingclarity #ftqcic
"The NIST PQC Project": "Biweekly seminars since 2012"
"Minimal acceptability requirements" starting with "Publicly disclosed and available with no IPR". How did this change? #needmorerecords
"Correct security definitions? ... CK best for key exchange?": #scramble
"Many proposals for post-quantum crypto, but no drop-in replacement"
"NIST is going to call for quantum-resistant algorithms"
"Hope to have standards ready within 10 years"
"This will take a lot of resources"; "Not (quite) as much as SHA-3"; "We will need more help"; "Post-docs/guest researchers wanted" #scramble
20160204 09:13:40 file 20230619/Re_ Improved Timing and Cyber.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Logistics discussion regarding NIST advertisement to Congress.
20160204 09:45:35 file 20230619/Re_ Improved Timing and Cyber(1).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Logistics discussion regarding NIST advertisement to Congress.
20160204 12:54:39 file 20230727/RE_ pqcrypto video recording.pdf-attachment-RE_ pqcrypto video recording.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Discussing conference videotaping.
20160211 14:48:44 file 20230727/IPR for PQCrypto Call for Proposals.pdf-attachment-IPR for PQCrypto Call for Proposals.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
"After further discussion in our PQC group, we think the best course for IPR for the PQCrypto Call For Proposals is to use the same language as in the SHA-3 competition: ..."
The SHA-3 competition required blanket patent giveaways: "I ... do hereby agree to grant to any interested party if the algorithm known as ... is selected for SHA-3, an irrevocable nonexclusive royalty-free license to practice the referenced algorithm, reference implementation or the optimized implementations. Furthermore, I agree to grant the same rights in any other patent application or patent granted to me or my company that may be necessary for the practice of the referenced algorithm, reference implementation, or the optimized implementations."
How did NIST end up allowing patents in NISTPQC? #needmorerecords
"Similar to the modes process, we want quantum-resistant algorithms to be able to be considered (and standardized) even after our competition-like search process ends."
20160215 13:06:10 file 20230727/Do you know this guy_.pdf-attachment-Do you know this guy_.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Email to "Dodson, Donna F" about "http://scienceforglobalpolicy.org/staff/dr-george-h-atkinson/".
"Met him at GMU thing and he was interested in what the world is thinking and planning for PQC. I think he wants to do a workshop or something on it."
20160216 16:13:01 file 20230727/Hash based signatures.pdf-attachment-Hash based signatures.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Email to "Scholl, Matthew A. (Fed); Dodson, Donna F; Regenscheid, Andrew R. (Fed); Dworkin, Morris J. (Fed)" cc "Moody, Dustin (Fed); Liu, Yi-Kai (Fed)".
"Some hash-based signature schemes are relatively mature in the sense of algorithm security and based on well-understood assumptions. Shall we go ahead to standardize those schemes (without waiting to go through 5-7 year procedure)?"
"It is a good exercise for post quantum cryptography standardization." This is a strange comment. Anyone studying the previous literature would have seen that the security of post-quantum cryptography needed much more research (also illustrated over the next five years by half of the submissions to NISTPQC being publicly broken), but that hash-based signatures were an exception with a stable security picture. If "standardization" refers to a process of NIST writing a specification then, sure, hash-based standardization looks very much like standardization of other areas of post-quantum cryptography; but if security is job #1 then hash-based signatures are a misleading exercise, missing how difficult it is to figure out which cryptosystems are safe to standardize in the first place.
"Hash-based signatures may not serve well for entity authentication in many-to-many protocols such as IKE. Other signature schemes (not hash based) are needed in the future." Why exactly did NIST believe this? #needmorerecords
"Compared with encryption/key establishment, signatures in general are less urgent in preparing quantum time for backward secrecy. Do we really have the urgency to standardize hash-based signature, other than code signing?"
20160216 16:41:05 file 20230727/shall it be an FRN - call for PQC proposals_ .pdf-attachment-shall it be an FRN - call for PQC proposals_ .pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Email to "Scholl, Matthew A. (Fed); Dodson, Donna F; Dworkin, Morris J. (Fed); Regenscheid, Andrew R. (Fed)" cc'ing "Moody, Dustin (Fed); Liu, Yi-Kai (Fed)" about an important procedural issue:
There is a government journal, the Federal Register, for U.S. government agencies to issue public proposals and ask for comments. Comment periods are generally required to be at least a month, except in emergencies.
In August 2016, NIST issued a Federal Register notice announcing draft submission criteria and soliciting public comments on the draft.
In December 2016, NIST issued a Federal Register notice announcing its final submission criteria.
Later NIST deviated from those criteria, without first issuing Federal Register notices proposing the changes and requesting public comment. Sometimes it even applied its new criteria retroactively.
This email, from February 2016, was asking "whether this formal “call for proposals” must be an FRN". Reasons stated in the email to avoid a Federal Register notice:
"PQC standardization is not a competition."
"Modes of operations in 800-38 series are selected without an FRN."
"It will take painfully long time to get an FRN approved."
"We may change the requirements and the rules in the middle of the procedure. It will provide us a lot flexibilities if we can announce it without an FRN."
At no moment does the email recognize the public interest in (1) being notified of the government's plans and (2) having at least a month to comment on those plans before they take effect.
What happened in response to this email?
#inconsistency #needmorerecords
20160217 03:07:41 file 20230915/RE_ Conference information from Allen_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"Aren’t Paulo Barreto and Anderson Nascimiento in Tacoma now? (Oh, I see that they are the organizers.) Anderson is more into information theoretic security, if I remember, and Paulo into post-quantum. I think that Anderson is getting into post-quantum right now, too, and I think that it’s likely that there will be somewhat more attention paid to pq for this conference. I can ask them what their guess is about the extent to which pq will be a topic."
20160217 20:29:18 UTC file 20230727/RE_ PQC forum.pdf-attachment-RE_ PQC forum.pdf-attachment-PQCrypto 2016 v3.pptx:
Notes from djb, last edited 20230727 19:57:07 UTC:
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" [boldface in original] #claimingtransparency
"Minimal acceptability requirements" including "Publicly disclosed and available with no IPR" #inconsistency
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" [reiterated] #claimingtransparency
"Wanted: Postdocs, guest researchers at NIST" #scramble
20160222 10:06:40 file 20230727/April 12th brief.pdf-attachment-April 12th brief.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Planning presentation to the Federal PKI Policy Authority (FBKIPA).
20160222 16:15:34 file 20230727/Comments NISTIR 8105.pdf-attachment-Comments NISTIR 8105.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
"Please consider authentication as one of the rows in table 1."
20160224 16:04:00 file 20230727/pqc workshop in 2018.pdf-attachment-RE_ pqc workshop in 2018(1).pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Planning public meetings for 2018.
20160224 16:06:39 file 20230727/pqc workshop in 2018.pdf-attachment-RE_ pqc workshop in 2018.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Planning public meetings in 2018.
20160226 09:50:07 file 20230619/Re_ Improved Timing and Cyber Initiative(1).pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Logistics discussion regarding NIST advertisement to Congress.
20160226 09:59:44 file 20230619/Re_ Improved Timing and Cyber Initiative.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
Logistics discussion regarding NIST advertisement to Congress.
20160229 11:37:44 file 20230727/RE_ PQC forum.pdf-attachment-RE_ PQC forum.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Planning web pages.
20160229 13:01:27 file 20230727/NIST PQC Workshop - Email Listserve Information.pdf-attachment-NIST PQC Workshop - Email Listserve Information.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Email to "Liu, Yi-Kai (Fed)" saying "PQC Workshop Attendees, NIST has set up a pqc-forum@nist.gov mail listserve" etc.
20160229 15:01:00 file 20230727/RE_ pqc notes.pdf-attachment-RE_ pqc notes.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Self-email with one line "Visitors – Daniel, Oscar, Tsuyoshi, Jintai, (Ludovic)" followed by a copy of another self-email with a "PQCrypto 2016 quick report" raising many obvious questions. #needmorerecords
"Peter Campbell (ETSI/GCHQ): will our IPR approach work? What happens with IPR after analysis phase? Are there IPR-free algorithms that can be standardized?" This question is particularly interesting because of the context, including GCHQ's role as an NSA partner and GCHQ's subsequent appearance in four years of litigation attempting, unsuccessfully, to invalidate patent 9094189. What did GCHQ, NSA, and NIST know about the patent situation in 2016? #needmorerecords #nsa
20160229 15:48:00 file 20230727/API for post-quantum.pdf-attachment-API for post-quantum.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
Internal email passing along public suggestion from Tanja Lange to align NIST's API with the SUPERCOP API.
20160301 12:25:40 -0500 file 20221014/pqcrypto-2016-presentation.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Public announcement of this NIST project.
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" (boldface in original) #claimingtransparency
"Disclose known patent information": This is better than nothing, but it falls short of NIST's official competition procedures stated in NIST IR 7977, "NIST Cryptographic Standards and Guidelines Development Process": "The winning submitters are recognized, but agree to relinquish claim to intellectual property rights for their design so that the winning candidate can be available for royalty-free use."
The Dual EC post-mortem said that NIST's VCAT "strongly encourages standard development through open competitions, where appropriate". For some reason, NIST avoided calling this project a "competition". #inconsistency
20160427 08:31:42 -0400 file 20221014/NIST.IR.8105.pdf:
20160429 15:10:16 UTC file 20221003/AWACS-PQC-2016-04282016 RayComments.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Draft slides for a public talk. Includes a few editing comments from Ray Perlner.
"Since 2012": "Bi-weekly post-quantum cryptography seminars"; "Guest researchers and invited speakers"; "Research publications and presentations"; "Participation in international projects and activities" #weveshownallourwork
"It will be an open procedure": In fact, the public wasn't able to see the bi-weekly seminars, the invited talks, the NSA input, etc., before or after the competition began. #claimingtransparency
20160508 file 20230105/AWACS-PQC-2016-05082016.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a public talk given 2016.05.08.
"It will be an open procedure" #claimingtransparency
"NIST will encourage public analysis on the submitted algorithms"
"For interoperability reasons, we do not want to select too many algorithms for each function"
"Quantum Security" of "80 bits" for "SHA256/SHA3-256 (collision)": #error NIST radically changed this evaluation later.
20160608 file 20230105/Asia-PQC-2016-06082016.pdf:
Notes from djb, last edited 20230125 23:38:54 UTC:
Slides of a public talk given on 2016.06.08. Similar to the 2016.05.08 talk, although some edits.
20160714 07:32:37 -0400 file 20221014/intermediate-values-2048.pdf:
Notes from djb, last edited 20221018 10:44:20 UTC:
Exact copy of https://csrc.nist.gov/csrc/media/projects/post-quantum-cryptography/documents/example-files/intermediate-values-2048.pdf.
20160829 14:25:59 UTC file 20230915/ITL Science Day poster_4.pdf-attachment-pqc-poster-2016.pptx:
Notes from djb, last edited 20230915 23:13:56 UTC:
Poster summarizing fragments of post-quantum cryptography. #scramble
20160901 09:11:03 file 20230816/today-1.pdf:
20160902 09:53:14 file 20230915/Re_ Request for info on planned major announcem....pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Discussing possible advertisements by executive-branch higher-ups.
20160903 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..6.pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov, cc'ing pqc-forum.
Proposed requiring, rather than just encouraging, specification of scaled-down parameter sets. Proposed encouraging attacks to be demonstrated on the scaled-down parameter sets.
"In the heat of the debates and the competition, there will be a lot of overrated attacks that actually are not so efficient as the attackers would claim."
20160903 file 20230210/Two Suggestions - Liu, Yi-Kai (Fed).pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov. Looks like this was then resent to pqc-comments@nist.gov and pqc-forum, with a different subject line.
20160904 file 20230210/Comment on Post-Quantum Cryptography Requirements and E...pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov.
"What is the rationale for not letting the adversary make essentially as many queries as the target security?"
"Clearly, the classical and quantum bit security of a given scheme can differ. But why are the ratios 1/2 and 2/3 put forward as targets?"
20160906 04:39:58 file 20230915/Re_ ITL Science Day, October 13, 2016 - Posters_5.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Discussion of a poster on "Quantum Randomness Certified by the Impossibility of Superluminal Signaling".
20160906 07:16:42 file 20230915/RE_ Alias request.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"Thanks for the clarification. Looks like the alias is working properly again…"
20160907 file 20230210/RE_ Comment on Post-Quantum Cryptography Requirements a...pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Email from NIST back to Damien Stehlé. What happened to "open and transparent"? Why did some submitters get to see this information while the general public didn't? #inconsistency #weveshownallourwork
(This round of comments to NIST was put online three months later, but replies from NIST appear to have been kept secret.)
"As a side note, if we do consider 2^64 online queries to be a realistic attack model, one of the first things we would need is a block cipher with a larger block size than 128 bits.": No. #error There are well-known AES-based constructions (and SHA-3-based constructions) that remain secure for this number of queries. (They aren't as efficient as ChaCha20, but that's a separate issue.)
"Our target security strengths are designed so that, if we need to transition to higher security strengths, as we did when moving from 80 bits to 112 bits of security, starting around 2010, we can time transitions for the new algorithms to coincide with those for algorithms we have already standardized (in particular AES, SHA2, and SHA3.)" Was this rationale ever made clear in public? If so, where? #needmorerecords
This NIST email pointed to a NIST FAQ, but this FAQ did not say that the point of NIST's security categories was to synchronize the timing of future public-key transitions with future AES/SHA transitions.
Meanwhile NIST was making public comments such as "we'd expect security strengths 2 on up to be secure for 50 years or more, and we wouldn't be terribly surprised if security strength 1 lasted that long as well" (2016.11.22). If NIST thought AES-128 and SHA-256 were so strong, why was NIST worrying about the timing of transitions away from those standards? This doesn't make sense. #inconsistency Meanwhile it doesn't seem that the public was being given an opportunity to understand NIST's rationale and to comment upon the rationale before these "categories" were set in stone.
NIST's final public call for submissions gave a different story for the purpose of the security "categories": "The goals of this classification are: 1) To facilitate meaningful performance comparisons between the submitted algorithms, by ensuring, insofar as possible, that the parameter sets being compared provide comparable security. 2) To allow NIST to make prudent future decisions regarding when to transition to longer keys. 3) To help submitters make consistent and sensible choices regarding what symmetric primitives to use in padding mechanisms or other components of their schemes requiring symmetric cryptography. 4) To better understand the security/performance tradeoffs involved in a given design approach."
The second part claims that the "categories" will help NIST make "prudent" decisions regarding transitions, but says nothing about synchronizing the timing of future public-key transitions with future AES/SHA transitions. The third part is about helping submitters, not about NIST's future transitions. The first and fourth parts are about security/performance tradeoffs and comparisons. #inconsistency
"Given the poor parallelization of Grover‐like attacks, the difficulty of constructing quantum computing hardware, and the overhead associated with reversibility and fault tolerance, it seems likely that in practice, the security of postquantum schemes will still be limited by the best classical attack." Where are the calculations that led NIST to this claim? #needmorerecords
For comparison, NIST in 2023 publicly wrote "in the likely scenario where the limiting attack on AES128 is Grover’s algorithm, this would further increase the security margin of Kyber512 over AES128 in practice." So the best attack against AES-128 changed from "likely ... classical" to "likely ... Grover"? What happened to the "the poor parallelization of Grover‐like attacks, the difficulty of constructing quantum computing hardware, and the overhead associated with reversibility and fault tolerance"? #inconsistency
20160907 02:13:25 file 20230915/Science Day Poster_3.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I made the changes you recommended. I decided just to remove isogeny-based schemes, and stick with the main ones."
20160907 02:42:17 file 20230915/PQC annual report_15.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"As the fiscal year ends, we have to submit our write-up of the PQC project for the Annual Report. I’ve attached a draft. Let me know if you have any comments/suggestions. Thanks!"
20160907 03:00:35 file 20230915/Re_ PQC annual report(1)_14.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Logistics.
20160907 03:09:00 file 20230915/RE_ Science Day Poster_2.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Poster discussion.
Quoting "I decided just to remove isogeny-based schemes, and stick with the main ones."
20160907 12:05:51 file 20230915/ITL Science Day poster_4.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I’ve attached the ITL Science Day poster for PQC. I modified the one we’ve used in the past to have some details about our standardization plan. Let me know if you want anything changed."
20160907 18:10:12 UTC file 20230915/Science Day Poster_3.pdf-attachment-pqc-poster-2016.pptx:
20160907 18:40:00 UTC file 20230915/PQC annual report_15.pdf-attachment-pqc annual report 2016.docx:
Notes from djb, last edited 20230915 23:13:56 UTC:
"NIST researchers have held regular seminars throughout FY 2016. The presentation topics include the latest published results, synopsis of security analysis, and status reports in the areas of quantum computation, hash-based signatures, coding-based cryptography, lattice-based cryptography, and multivariate cryptography. Through these presentations and discussions, the team has made significant progress in understanding the strengths and weaknesses of the existing cryptographic schemes in each category."
"Email project team: pqc@nist.gov" #nsa
20160908 23:39:00 UTC file 20230915/2016 Annual Report - Write-up to Update (POST ..._12.pdf-attachment-Post Quantum_DMoody-YLiu-LChen.docx:
Notes from djb, last edited 20230915 23:13:56 UTC:
"The focus of the Post-Quantum Cryptography project is to identify candidate quantum-resistant systems that are secure against both quantum and classical computers, as well as the impact that such post-quantum algorithms will have on current protocols and security infrastructures."
In fact, the project didn't investigate the impact on protocols and security infrastructures. #inconsistency
"In FY 2015, NIST researchers held regular seminars. The presentation topics included the latest published results; a synopsis of the security analysis; and status reports in the areas of quantum computation, hash-based signatures, coding-based cryptography, lattice-based cryptography, and multivariate cryptography. Through these presentations and discussions, the team made significant progress in understanding the strengths and weaknesses of the existing cryptographic schemes in each category. The project team is planning to create evaluation criteria for post-quantum cryptography schemes for standardization." What happened in these seminars? #needmorerecords Was any of this shown to the public? #weveshownallourwork
"Email project team: pqc@nist.gov" #nsa
20160909 04:41:28 file 20230816/Slides for ETSI workshop-2.pdf:
20160909 11:29:00 file 20230915/RE_ PQC annual report_13.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"It will be great if you can start to summarize the comments when we receive more comments, at least, to group them together and pick some critical issues. Actually the week after the deadline, Dustin and I will be at ETSI Quantum- Safe workshop. You and Ray will be in the office. We will communicate through e-mails."
20160909 20:37:54 UTC file 20230816/Slides for ETSI workshop-2.pdf-attachment-ETSI-2016-0909.pptx:
20160912 06:07:31 file 20230915/Re_ randomness at the optics teleconference(2)_4.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Logistics.
20160912 06:09:38 file 20230915/Re_ randomness at the optics teleconference(1)_3.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Meeting logistics.
20160913 file 20230210/Comment on Post-Quantum Cryptography Requirements and ...pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov pointing out that the claimed collision-search costs listed by NIST in its draft call for submissions had been debunked in 2009.
20160913 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..2.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email from patent troll ISARA to pqc-comments@nist.gov with various suggestions. For example: "It is unclear the reason to include optimized source code within the submission package. Typically, optimizations are a way for industry to differentiate product offerings from each other and as such should be considered out of scope for the standardization process."
20160913 04:54:25 file 20230816/Thoughts on How I'm Compiling Comments So Far_-1.pdf:
20160913 08:09:51 file 20230815/pqc mailing list-4.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
"Can you give me a list of who receives mail sent to the pqc@nist.gov address?"
#nsa
20160913 09:05:58 file 20230815/Re_ pqc mailing list(1)-3.pdf:
Notes from djb, last edited 20230910 09:53:01 UTC:
Saying that pqc@nist.gov currently contains the following names (and suggesting "add Jacob Alperin ? add Carl Miller ? remove Adam O'neill ?"):
For comparison, https://web.archive.org/web/20230910091944/https://csrc.nist.gov/CSRC/media/Events/ISPAB-MARCH-2014-MEETING/documents/a_quantum_world_v1_ispab_march_2014.pdf lists its authorship as "Post Quantum Cryptography Team, National Institute of Standards and Technology (NIST), pqc@nist.gov" and keeps NSA's presence on "NIST's" post-quantum team secret.
20160913 09:24:50 file 20230815/Re_ pqc mailing list-2.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Saying names have been added to pqc@nist.gov:
#nsa
20160913 09:26:40 file 20230815/pqc mailing list-1 .pdf:
20160913 20:52:00 UTC file 20230816/Thoughts on How I'm Compiling Comments So Far_-1.pdf-attachment-Organizing Comments on Draft.docx:
20160914 file 20230210/[Pqc-forum] Implementation Issues - Liu, Yi-Kai (Fed).pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Public email to pqc-forum with same comments sent to pqc-comments@nist.gov.
20160914 01:41:01 file 20230915/Re_ BF crypto - resources(1)_2.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"That's CWE-327 Use of a Broken or Risky Cryptographic Algorithm (2.9)"
"One can Google CWE and key word, and one often gets a hit."
20160914 19:16:00 UTC file 20230210/Comments on the NIST call for PQC standards (1).docx:
Notes from djb, last edited 20230218 16:05:01 UTC:
"what if the submission infringes on others’ patent or patent application and does not disclose it?"
"Must each submission submit at least one set of parameters for each security target?"
"If an attack on a scheme requires an tremendous memory, can it be considered secure?"
"What is the threshold for decryption failure?"
20160914 19:16:00 UTC file 20230210/Comments on the NIST call for PQC standards.docx:
Notes from djb, last edited 20230218 16:05:01 UTC:
Not byte-for-byte identical to "Comments on the NIST call for PQC standards (1).docx", but no evident differences in the text.
20160915 file 20230210/About stateful hash-based signatures - Liu, Yi-Kai (Fed).pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov asking about stateful hash-based signatures.
20160915 file 20230210/Comment - Liu, Yi-Kai (Fed).pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov suggesting a change from "should" to "required" regarding analysis of how security and performance depend on parameters.
20160915 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..3.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov.
"I do not understand the relationship that is drawn between the security of public key primitives and brute‐force attacks on SHA/AES. Unlike SHA/AES, the best attacks against public key primitives are not brute force, so there is no reason to assume that the effect of Grover’s algorithm on the quantum security of such primitives is analogous to its effect on symmetric ones such as SHA/AES. ... But just because one needs to increase the security of the hash function does not imply that anything needs to be increased in the rest of the construction. For example, there are no known quantum algorithms for lattice reduction that outperform classical ones by any significant margin. ... I believe that it would be very wasteful to set parameters so that the whole public key scheme is 256‐bit secure classically when what we really want is that the scheme cannot be broken in 2128 time on a quantum computer."
20160915 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..4.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov.
"I would like to see assembly optimizations (at least inline ASM) allowed for the optimized implementation, because otherwise the implementation would not be representative of real‐world conditions, especially for number‐theoretic cryptography which relatively speaking benefits more from assembly optimization than other families of cryptosystems."
"It is not clear what security model NIST is proposing for key establishment."
20160915 file 20230210/comments-pqc-call.txt:
20160915 02:15:30 file 20230815/Re_ PQC comments(2)-4.pdf:
20160915 02:19:40 file 20230815/Re_ PQC comments(1)-3.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Email about reminding Jonathan Katz of NIST's deadline for comments. Quoted email says "Just a reminder the comment period for our draft PQC requirements ends tomorrow. If you know anyone who you think needs a reminder, then let them know. ... Please don’t worry about responding back to the authors of the comments we receive. We don’t usually write individual responses when we make a public call for comments. We will discuss the comments together, and if we feel we want to reply back to anyone, we can then do so at that point."
20160915 05:13:50 file 20230915/Re_ BF crypto - resources_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"This is a very good point. Using plain RSA may be considered using an adequate algorithm, namely, RSA, without a crucial additional step that is needed for making the whole process adequate. This may be considered a different type of weakness than using an encryption algorithm that is not adequate."
20160915 06:35:46 file 20230815/Re_ MC of the Counting function (8,4) is 6.(1)-2.pdf:
20160915 09:31:00 file 20230815/RE_ PQC comments-5.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Logistics.
20160915 12:18:40 file 20230815/pqc hash signatures-1.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
"Do you want to respond, since you are our contact with the IETF? The best person for him to contact might be Andreas Hulsing. As for our part, we don’t have a timeline. We are largely following the IETF as you know."
20160915 15:31:22 -0400 file 20230815/Re_ MC of the Counting function (8,4) is 6.(1)-2.pdf-attachment-MultComp3.pdf:
20160915 18:14:00 UTC file 20230815/Re_ PQC comments(2)-4.pdf-attachment-Organizing Comments on Draft.docx:
20160916 file 20230206/ETSI-2016-0916R1.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of an external talk on 2016.09.16.
Are these the final slides? "Received comments from N individuals/teams"
"The following metrics are considered as the minimum security strength at different levels to enable transition from one security level to another"
"Quantum Security" of "80 bits" for "SHA256/SHA3-256" collisions. #error
"Hybrid mode may not be considered as a long term quantum resistant solution for its implementation burden (a double edge sword)": This comes right after saying what NIST "will" do, so readers could read "may not" as "shall not" rather than as "perhaps will not". #missingclarity
20160916 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..5.pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov requesting a separation between signature modes and underlying primitives.
20160916 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..7.pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov suggesting that passive security be allowed as a target and suggesting that "128‐bits of pre‐quantum and post‐quantum security" be allowed as a target.
20160916 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..8.pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov suggesting 8-bit and 16-bit microcontrollers as targets and suggesting an API that dynamically allocates memory for keys and signatures.
20160916 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..9.pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Email to pqc-comments@nist.gov.
"I suggest omitting security levels below 128 bits of quantum security."
"It would be unfortunate if promising submissions were disqualified because of cryptanalytic advances shaved e.g. 10 bits of security off of a 128‐bit‐level submission."
"2) Royalty‐free"
20160916 file 20230210/NIST PQC Comments from Microsoft.pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Letter to NIST.
"... an open and transparent process with clear technical guidelines and evaluation criteria will help ensure that the results of this process are trusted and credible"
"It is critical that NIST maintain the same intellectual property rights disclosure and release requirements that were set out for the SHA-3 competition, namely that all submitters be required to release any and all IP claims as a condition of entry, and that each submitter agree to unrestricted, royalty-free use of their work."
"Additionally, we note that the proposed approach to Intellectual Property Rights for this competition conflicts with NIST’s stated commitment in NISTIR 7977 on this specific issue."
"This process is clearly a competition as defined in NISTIR 7977, so NIST must adhere to the IPR commitments it made for competitions in that document."
"To ensure that “optimized implementations” reflect what would be deployed, and to enable apples-to-apples comparisons, all “optimized implementations” submitted for this effort should be designed to be constant-time. Second-round updates to submissions may make updates to fix constant-time-related bugs in first-round submissions."
"The performance evaluation of “optimized implementations” must be done by NIST directly or by an independent and neutral third party not affiliated with any party involved in any submission. The tools used in this evaluation must be open, independent, auditable and neutral, their code must be freely published for inspection, and must not be owned by or affiliated with any party involved in any submission. No submitter can be involved in performance evaluation in any capacity."
"The performance evaluation should cover the following platforms at a minimum: a 64-bit processor “server class” and a 32-bit processor “mobile class”. In addition, testing should be conducted on 8-bit and 32-bit microcontrollers, and be evaluated on at least one alternative hardware platform (e.g., FPGA)."
"We suggest that NIST remove target levels (1), (2) and (3) and replace them with a target level of 128 bits classical security / 128 bits quantum security, and that this new level be the minimum target level."
20160916 file 20230210/Re_ [Pqc-forum] Comment on Post-Quantum Cryptography Re...pdf:
Notes from djb, last edited 20230218 16:05:01 UTC:
Public email to pqc-forum, pointing out a way that submitters could evade the goal of a requirement to provide scaled-down parameters.
20160916 file 20230915/ETSI-2016-0916.pptx:
Notes from djb, last edited 20230915 23:13:56 UTC:
"After about four years of preparation, NIST published a Federal Register Notice (FRN) August 2, 2016"
Claims that SHA3-256 has only "80 bits" collision resistance. #error
20160916 08:36:37 file 20230815/Re_ MC of the Counting function (8,4) is 6-1..pdf:
20160916 09:37:37 file 20230816/Slides foe ETSI Workshop-1.pdf:
20160916 10:15:35 file 20230915/quantum_tps.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"Here is my start and I will finish these in the morning."
20160916 11:18:00 file 20230815/next pqc talk_-2.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Asking for a 2016.09.30 talk on "Ding’s extension field ideas".
20160916 11:44:00 file 20230815/RE_ next pqc talk_-1.pdf:
20160916 13:35:28 UTC file 20230816/Slides foe ETSI Workshop-1.pdf-attachment-ETSI-2016-0916.pptx:
20160916 15:44:57 UTC file 20230105/ETSI-2016-0916 Ray.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Draft slides for a public talk.
20160917 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..11.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov.
"Unfortunately, standardization committees in general have suffered from a decline in credebility in the past years. Many people think that the standardization process can be manipulated by powerful industry lobbying and governmental intrests. We think, that a modern standardization should include the maximum amount of transparency possible."
20160917 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..12.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov.
"Maybe NIST could consider another set of evaluation critera, resistance against traditional physical attacks."
20160917 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..13.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov. Author put these comments online on 2016.10.30.
20160917 02:14:00 UTC file 20230915/quantum_tps.pdf-attachment-Quantum talking points.docx:
20160917 23:48:50 UTC file 20230816/NIST PQC Comments from Microsoft-2 copy.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Public comments from Brian A. LaMacchia on behalf of Microsoft.
"It is critical that NIST maintain the same intellectual property rights disclosure and release requirements that were set out for the SHA-3 competition, namely that all submitters be required to release any and all IP claims as a condition of entry, and that each submitter agree to unrestricted, royalty-free use of their work."
"This process is clearly a competition as defined in NISTIR 7977, so NIST must adhere to the IPR commitments it made for competitions in that document."
"To ensure that “optimized implementations” reflect what would be deployed, and to enable apples-to-apples comparisons, all “optimized implementations” submitted for this effort should be designed to be constant-time."
"The performance evaluation of “optimized implementations” must be done by NIST directly or by an independent and neutral third party not affiliated with any party involved in any submission. The tools used in this evaluation must be open, independent, auditable and neutral, their code must be freely published for inspection, and must not be owned by or affiliated with any party involved in any submission. No submitter can be involved in performance evaluation in any capacity."
"First, some proposed quantum-resistant schemes may have benefits when combined with certain classical schemes ... For a practical example of such ancillary benefits see C. Costello, P. Longa and M. Naehrig, Efficient Algorithms for Supersingular Isogeny Diffie-Hellman, recently presented at Crypto 2016 and available online at http://eprint.iacr.org/2016/413. In this paper the authors present a post-quantum key agreement scheme based on supersingular isogenies, and in Section 8 they present a strong ECDH+SIDH hybrid (“BigMont”) that leverages the underlying field arithmetic of the post-quantum scheme to provide a parallel ECDH key exchange for very little overhead. NIST’s current proposed language would prohibit NIST from considering hybrid benefits from such schemes."
20160919 08:05:46 file 20230816/Received Comments 9_1-18-6-1.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
"The main commented areas are (in order of the number of comments). I think we will need to further separate the comments to the each topics. 1. Quantum security strength 2. Key exchange (KEM vs. DHish) 3. IPR 4. Hybrid mode"
Includes copies of various public comments.
20160919 08:09:07 file 20230816/Fw_ Received Comments 9_1-18-5.pdf:
20160919 09:03:41 file 20230815/Re_ Received Comments 9_1-18(3)-4.pdf:
20160919 09:07:44 file 20230815/Re_ Received Comments 9_1-18(2)-3.pdf:
20160919 10:16:08 file 20230815/Re_ Received Comments 9_1-18(1)-2.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
"The following two documents contain 1. [Bernstein and Lange] the comments by the dynamic duo of D.J. Bernstein and Tanja Lange, whose complete comments are put together one after another in a separate file per Lily’s request 2. [Organized Draft Comments] All of our received comments (including those of Bernstein and Lange, as well as the nonsensical comments by our buddy Mr. W1SD0M) have been organized to the best of my ability by which part of the draft they refer to, and should make it a little easier to wade through them and incorporate the good ones over the next few months. "
20160919 10:18:31 file 20230815/Re_ Received Comments 9_1-18-1.pdf:
20160919 14:13:00 UTC file 20230815/Re_ Received Comments 9_1-18(1)-2.pdf-attachment-Organized Draft Comments.docx:
20160919 14:15:00 UTC file 20230815/Re_ Received Comments 9_1-18(1)-2.pdf-attachment-Bernstein and Lange.docx:
20160920 06:56:46 file 20230815/Re_ minimum uncertainty wavepackets(1)-2.pdf:
20160920 06:59:58 file 20230815/Re_ minimum uncertainty wavepackets-1.pdf:
20160920 08:34:13 file 20230816/PQC comments-2_with_Comments.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
"I'm attaching an updated version which has a couple of comments she missed. The most important of which is Jintai Ding's. (The other ones were basically spam or not serious ones)."
20160920 09:08:15 file 20230815/Re_ PQC comments-1.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
"Let us agree that we don't need to discuss "Know's", "Wisdom",. Any other than we can dispose of quickly ?"
Quoted email says "I'm attaching an updated version which has a couple of comments she missed. The most important of which is Jintai Ding's. (The other ones were basically spam or not serious ones)."
20160920 19:37:00 UTC file 20230915/2016 Annual Report - Write-up to Update (POST ..._12.pdf-attachment-2016_Annual-Report-OUTLINE_template.docx:
Notes from djb, last edited 20230915 23:13:56 UTC:
Reporting template.
20160921 12:53:37 file 20230915/2016 Annual Report - Write-up to Update (POST ..._12.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"As mentioned in yesterday’s email, attached you will find last year’s annual report (2015) write-up for your project/program submission (Post Quantum Cryptography). Please review last year’s write-up, make necessary updates to match your project’s accomplishments/highlights for this past year (October 1, 2015 to September 30, 2016)."
20160922 05:24:15 file 20230816/RE_ VCAT cyber convening-1.pdf:
20160923 file 20230915/Foreign Trip Report-09232016dm-ykl.doc:
Notes from djb, last edited 20230915 23:13:56 UTC:
"Created: 03/23/2023, 20:20:00, mcooley"
"Modified: 03/23/2023, 20:20:00, Scholl, Matthew A. (Fed)"
"Name of Traveler(s): Lidong Chen, Dustin Moody, Andrew Regenscheid, and Yi-Kai Liu"
"Purpose of trip: To speak and serve as panelists at the 4th ETSI/IQC Workshop on Quantum-Safe Cryptography, and to meet with European Government Representatives to discuss strategies and technical issues on post-quantum cryptography."
Contacts include "Colin Whorlow, Head of International Standards, CESG, UK" #nsa
"On September 22, Andrew Regenscheid, Dustin Moody, and Lidong Chen met with European government agencies, including BSI (Germany), ANSSI (France), CESG (UK), NSM (Norway), and NCSA (Sweden). At this meeting, each agency updated their progress in quantum related projects. The representatives also discussed confidence and developments for each of the primary PQC families. It is a common understanding among the agencies that QKD cannot replace post-quantum cryptography, and shall not be considered as a standalone solution. The agencies also verbally discussed their comments and suggestions on NIST’s call for proposals." What exactly happened at these meetings? #needmorerecords
20160923 file 20230915/Foreign trip report_2.pdf-attachment-Foreign Trip Report-09232016.doc:
20160923 file 20230915/Re_ Foreign trip report_1.pdf-attachment-Foreign Trip Report-09232016dm-ykl.doc:
20160925 01:54:41 file 20230915/Re_ randomness at the optics teleconference_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Meeting logistics.
20160925 01:54:41 file 20230915/Re_ randomness at the optics teleconference_2.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Logistics.
20160926 file 20230210/Re_ A few more PQC comments - Liu, Yi-Kai (Fed).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
#weveshownallourwork
Email to eight other NIST people (Moody, Chen, Perlner, Peralta, Liu, Jordan, Miller, Smith) regarding how to pick numerical security targets. Quotes email from Moody, which in turn quotes Peter Campbell from CESG and alludes to input from ANSSI.
20160926 01:07:29 file 20230915/Re_ [Itl_mgmt] Due Monday_ FY17 Critical Miles....pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Discussion related to "milestones", the first being the following: "Initiate Open Competition for Quantum Resistant Cryptographic Algorithms. Finalize types of algorithms for development, requirements for external submissions and evaluation criteria for next generation Quantum Resistant Cryptography. FY17 Q3 [CYB 15 Initiative]"
20160926 01:28:52 file 20230815/PQC file on webpage-1.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Email about further fixes to documents NIST had released.
20160926 02:08:16 file 20230915/Re_ ACMD SEMINAR SERIES_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Seminar logistics.
20160926 02:11:54 file 20230815/PQC FAQ update-3.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
"I made some small fixes in the FAQ document on our PQC webpage. ... Wiener was misspelled, and one of the links didn’t work."
I had pointed out these errors in my 2016.09.17 email to NIST, saying that the draft "needs a general round of proofreading".
20160926 11:33:11 file 20230915/FW_ ACMD SEMINAR SERIES_2.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Seminar announcement.
20160926 12:57:41 file 20230915/Re_ A few more PQC comments.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I know the 2^64 question was already asked by at least one person (I think Vadim)."
"But I don’t think the “very long term" thing is relevant, unless there are any concrete uses for signatures that don’t involve some sort of certificate with an expiration date."
"Otherwise (if all concrete uses do involve a certificate), it should be much easier to upper bound the maximum number of possible chosen messages one could realistically expect by answering: 1. What is the NIST standard on lifecycle length for a certificate? Is it a year? Six months? Two years? 2. What are the maximum number of signatures any given entity (that is to say, holder(s) of a specific signing key) issues per second in today’s world? Then note that ~ 2^25 seconds/year, and add some padding of 1000 or so, and end up with a bound that should hold."
20160926 18:10:00 UTC file 20230815/PQC FAQ update-3.pdf-attachment-FAQ v2.docx:
20160926 18:42:00 UTC file 20230915/RE_ 2016 Annual Report - Need Project List Updated(2)_11.pdf-attachment-pqc annual report 2016.docx:
20160926 18:49:00 UTC file 20230915/RE_ 2016 Annual Report - Need Project List Updated(2)_11.pdf-attachment-ecc annual report 2016.docx:
20160927 10:30:00 file 20230815/RE_ PQC FAQ update(1)-2.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Conference logistics and web-page logistics.
20160928 03:29:00 file 20230915/Foreign trip report_2.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"This is a rough draft to start with. Please look into it, fill in content, and make changes."
20160928 03:50:02 file 20230815/RE_ PQC FAQ update-1.pdf:
Notes from djb, last edited 20230909 22:51:01 UTC:
Conference logistics.
20160929 01:33:21 file 20230915/Re_ 2016 Annual Report - Need Project List Updated(2)_9.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
More annual-report logistics.
20160929 02:43:30 file 20230915/Re_ 2016 Annual Report - Need Project List Updated(1)_8.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"Here is my key-management report. It¹s quite long after beefing it up with more information and a couple of figures. The others I have to do should be considerably shorter. Lily: Please read the 56A and 56C topics carefully to see if I¹ve included everything."
Quoting more annual-report email.
20160929 02:52:47 file 20230915/Re_ 2016 Annual Report - Need Project List Updated(7)_7.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"Attached is write-up for light-weight crypto project."
20160929 02:53:24 file 20230915/Re_ Foreign trip report_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I added a couple of details about QCrypt and QKD."
20160929 03:17:23 file 20230915/Key Management Figures_6.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"Attached are the two figures for the key-management part of the annual report."
Quotes email regarding further text collection for annual report.
20160929 09:38:22 file 20230915/Re_ PQC talk.pdf:
20160929 09:41:53 file 20230915/RE_ 2016 Annual Report - Need Project List Updated(2)_11.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I’ve attached write-ups for PQC and ECC."
Quoting more annual-report email.
20160929 11:38:12 file 20230915/Re_ 2016 Annual Report - Need Project List Updated(3)_10.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"The TLS writeup is attached."
20160929 15:34:00 UTC file 20230915/Re_ 2016 Annual Report - Need Project List Updated(3)_10.pdf-attachment-fy2016-Transport Layer Security_KMcKay-LChen.docx:
20160929 16:15:29 UTC file 20230915/Key Management Figures_6.pdf-attachment-Key Agreement example[.pptx:
20160929 16:32:47 UTC file 20230915/Key Management Figures_6.pdf-attachment-Key Transport example.pptx:
20160929 18:38:00 UTC file 20230915/Re_ 2016 Annual Report - Need Project List Updated(1)_8.pdf-attachment-Key Management_EBarker-LChen-QDang-DMoody-RPe.docx:
20160929 18:49:00 UTC file 20230915/Re_ 2016 Annual Report - Need Project List Updated(7)_7.pdf-attachment-LWC_AnnualReport_FY16.docx:
20160930 04:21:38 file 20230915/Re_ randomness at Science Day_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
Logistics for "Quantum Randomness Certified by the Impossibility of Superluminal Signaling" poster.
20160930 08:50:07 file 20230915/RE_ 2016 Annual Report - Need Project List Updated(1)_4.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I am not worrying to beat the deadline. But I concerned that the way we worked did not consider every one’s schedule. Our team members are busy with extremely heavy load. People cannot wait for each one to come in, comment it and then send to you in one day’s working hours. It has become a mass unspecified multiple party protocol and people have no way to follow. The purpose to assign one person, which is you, to organize it is to collect all the draft, put them together, send to the group to review as we did in the previous years. Even for me, digging out every one from the mass e-mails has been a very time consuming work. Don’t send more e-mails. Wait my next e-mail."
Quoting more report-collection email.
20160930 09:04:58 file 20230915/Re_ 2016 Annual Report - Need Project List Updated(6)_3.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I read your message and worried that other people could feel the same way you did, so I clarified."
20160930 09:25:44 file 20230915/RE_ 2016 Annual Report - Need Project List Updated_2.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
More annual-report logistics.
20160930 09:26:09 file 20230915/Re_ 2016 Annual Report - Need Project List Updated(5)_1.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"No problems. Watch for emails from me. Please send your comments to the submitter of each section separately (cc me and Liy) so that it would be more efficient for the submitter to resolve the comments."
20160930 12:08:53 file 20230915/Re_ Reminder - PQC meeting this Friday at 1pm.pdf:
Notes from djb, last edited 20230915 23:13:56 UTC:
"I'll have to miss this. But it looks like your work is having some impact. That's great!"
Quoting email about "a PQC talk next week, on Friday, Sept. 30th, at 1pm. Note - this is after lunch, and not before lunch like we typically do. Daniel Smith-Tone will talk on some of Jintai Ding's ideas on extension field schemes."
Ending says "Brad/Dave/Jerry, let me know who I need to register" #nsa
20161003 20:38:45 +0000 file 20230210/Comment on Post-Quantum Cryptography Requirements and E..10.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Email to pqc-comments@nist.gov.
"1. Submitted algorithms must be usable without compensation to patent holders (RAND-Z, not only RAND) and implementations must bear an open-source license"
"2. Algorithms need to be evaluated as they will be used"
20161026 18:27:00 UTC file 20230210/final CFP v4-YKL.docx:
Notes from djb, last edited 20230218 16:05:01 UTC:
Draft of call for submissions, including editing notes.
"NIST understands that this will require submitters to perform a more thorough analysis than has been done in most previous research."
"Move to FAQ? This sounds more like informal advice to submitters, rather than a formal part of the CFP. Also, if there is disagreement about this, I’d rather have it be in the FAQ, not the CFP."
20161026 19:10:00 UTC file 20230210/FAQ 2-YKL.docx:
Notes from djb, last edited 20230218 16:05:01 UTC:
Draft of NIST's FAQ with editing notes. Some interesting points: e.g., Yi-Kai Liu deleting "The best we can hope for is to offer selections that most experts can agree are good options, since there will likely be no consensus of what constitutes a best option".
20161026 21:14:00 UTC file 20230210/final CFP v4-YKL-Ray.docx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Draft of call for submissions, including editing notes.
"Is this really true. Yes, if submitters want to precisely quantify their security margin, they will need to do a detailed security analysis. If they just want to make sure they have some margin, it shouldn’t be so hard."
"I feel like a little paranoia about community nitpicking is healthy.": So NIST isn't driven by a desire to do its job correctly, but by fear of having errors publicly exposed? Is this why NIST carried out almost all of its evaluation process in secret? Is this why NIST illegally stonewalled this FOIA request until NIST was dragged into court? #weveshownallourwork
As for "nitpicking": Small-sounding mistakes ended up cascading into years of delay in post-quantum deployment, exposing years of user data to large-scale attackers. NIST should not have assumed that it could tell which mistakes would matter; it should have worked hard to get everything right, and should have enthusiastically enlisted the help of the community in checking every detail.
20161102 14:12:21 file 20221003/Demystifying Quantum Computing.ppt:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Develop Public Key algorithms not based on factoring, discrete logs, (or anything else a quantum computer can do easily.)": Why "develop"? What about using algorithms that are already available? #scramble
"Quantum Key Exchange/Distribution a.k.a. Quantum Cryptography may be part of the solution."
20161109 18:27:39 UTC file 20221003/Cost analysis of hash collisions.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"If you assume (as you should) that memory access times scale with distance": For comparison, in the competition, NIST sometimes allowed submissions to account for the costs of memory inside attacks. #inconsistency
20161129 17:41:00 UTC file 20230210/final CFP v4.5-YKL.docx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Draft of call for submissions, including editing notes.
"NIST expects that categories 1, 2 and 3 will provide sufficient security for a variety of cryptographic applications. Categories 4 and 5 are of interest for research purposes, as a hedge against the possibility of a future breakthrough in cryptanalysis." See comments elsewhere on handling of 5. #inconsistency
20161129 19:32:00 UTC file 20230210/final CFP v4.6.docx:
Notes from djb, last edited 20230218 16:05:01 UTC:
Draft of call for submissions, including editing notes.
"Took out a large block of text here. I think we will get in trouble by calling our approach “bits of security” and would rather simply avoid the term. As for the rest, I think it should be covered in the FAQ."
20161129 20:41:00 UTC file 20230210/final CFP v4.6 (1).docx:
Notes from djb, last edited 20230218 16:05:01 UTC:
Draft of call for submissions, including editing notes.
20161219 09:56:56 -0500 file 20220914/call-for-proposals-final-dec-2016.pdf:
Notes from djb, last edited 20230125 23:38:54 UTC:
This is exactly the final public version of the call for proposals from NIST's web site. (NIST had also published a marginally different "final" version before that, and a considerably different draft version months earlier.) For documents already on NIST's web site, the FOIA request had specifically asked for URLs, not copies. Some other documents below were also public previously.
2017 file 20230105/Crypto in PQ world -DoC.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a talk. Was this talk public? The "DoC" part of the filename suggests that this was a presentation at a Department of Commerce event. (NIST is one part of the Department of Commerce.) #weveshownallourwork
QKD: "Security can be proven without imposing any restrictions on the abilities of the eavesdropper, which isn't possible with classical crypto" #error
Various incorrect cryptosystem benchmarks and incorrect asymptotics labeled as "rough estimates for comparison purposes". #error The magnitude of the error varies from one system to another, spoiling many comparisons.
Regarding large public keys: "For most protocols, if the public keys do not need to be exchanged, it may not be a problem". For comparison, NIST's eventual selections ended up being driven primarily by performance in poorly optimized protocols that constantly exchange public keys. #inconsistency
"Some ciphertext and signature sizes are not quite plausible": Which sizes are not quite plausible for what? #missingclarity #ftqcic
"No easy 'drop-in' replacements" #missingclarity #ftqcic
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" (boldface in original) #claimingtransparency
"~ 2012 — NIST begins PQC project"
"Possible third round of evaluation, if needed"
"Not exactly a competition - it is and it isn't"
"Minimal acceptability requirements" including "Concrete values for parameters meeting target security levels": For comparison, NIST subsequently dropped many submissions in response to attacks that appear to violate the target security levels, but allowed some submissions to change parameters in response to such attacks. #inconsistency
For example, it appears that the round-1 and round-2 versions of Kyber-512 are easier to break than AES-128 after various advances in lattice attacks, meaning that Kyber-512 flunked this "minimal acceptability requirement". The round-3 version of Kyber-512, which NIST claims is as difficult to break as AES-128, is not the same as the round-2 version: the Kyber team modified the cryptosystem parameters, and claimed that the modification gained security. (The round-2 version is also not the same as the round-1 version.)
For comparison, the official version of this "requirement" is effectively meaningless, since it includes a "to the best of the submitter’s knowledge" qualifier. The different version of this "requirement" that NIST advertises in its talk makes it sound as if simply showing that the original Kyber-512 doesn't meet its security target would be enough to remove Kyber-512 from consideration. #inconsistency
20170322 file 20230105/Asia-PQC-3rd-03222017-p.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a public talk given on 2017.03.22.
"2012 - PQC project begins"
Repeats mid-2016 claim of "Quantum Security" of "80 bits" for "SHA256/SHA3-256 (collision)". #error
"Other properties": "Drop-in replacements - Compatibility with existing protocols and networks"
20170331 file 20221014/PQC Seminar 3-31-17.pdf:
Notes from djb, last edited 20230125 23:38:54 UTC:
Describes a few features of an old attack against one of the first multivariate cryptosystems. Why is this called a "hack"?
20170331 file 20221107/PQC Seminar 3-31-17.pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20170912 13:48:58 -0400 file 20221014/kat.pdf:
Notes from djb, last edited 20221018 10:44:22 UTC:
Exact copy of https://csrc.nist.gov/csrc/media/projects/post-quantum-cryptography/documents/example-files/kat.pdf.
20170912 13:50:01 -0400 file 20220901/api-notes_1.pdf:
20170913 file 20230206/ETSI-2017-update-09132017.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of an external talk on 2017.09.13.
"Submitters are not required to provide different parameters for all five security categories": Then why did NIST later complain about, e.g., round-1 Classic McEliece providing only category 5? And about New Hope providing only category 1 and 5 and not providing 3? Meanwhile NIST never complained about Kyber not providing categories 2 and 4, and never rewarded NTRU for the amply documented flexibility of providing many different security levels. #inconsistency
20170929 20:25:22 UTC file 20221003/Brownian.pptx:
20171204 14:07:53 -0500 file 20220901/asiacrypt-2017-moody-pqc_1.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a public talk.
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" (boldface in original) #claimingtransparency
"~2012 – NIST begins PQC project": Note the "~", meaning approximately.
"Hold bi-weekly seminars (internal and invited speakers)" #weveshownallourwork
"Be prepared to transition to new algorithms in 10 years": This was a 2017 talk, so it's referring to a transition in 2027. That's remarkably lethargic, given that attackers were already well known to be intercepting traffic for future decryption. Where does this 10-year number come from? Was NIST in 2017 already planning a slow transition? (It doesn't seem plausible in context that "new algorithms" was referring to a new generation of algorithms beyond the algorithms in this NIST project.) #needmorerecords #slowingdownpqcrypto
20171205 21:33:47 UTC file 20230118/Thermodynamic_Analysis_of_Classical_and_Quantum_Search.pptx:
20171229 15:11:27 UTC file 20230118/Thermodynamic_Analysis_of_Classical_and_Quantum_Searchsr2-1.pptx:
20171229 15:42:14 UTC file 20230118/Thermodynamic_Analysis_of_Classical_and_Quantum_Search_retry.pptx:
20171229 15:49:06 UTC file 20230118/Thermodynamic_Analysis.pptx:
20171229 20:52:38 UTC file 20230118/Thermodynamic_Analysis_sr3-1.pptx:
20171229 21:02:08 UTC file 20230118/Thermodynamic_Analysis_final.pptx:
20180103 18:48:55 UTC file 20230118/Thermodynamic_Analysis_final2.pptx:
20180105 file 20230105/ICHFEVVP_JD_RP_AP_DCST-1.pdf:
20180212 file 20230105/AAAS-chen-02122018.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of an external talk. Was the talk public? #weveshownallourwork
"2012 - NIST begin PQC project"
"May take third analysis phase if needed"
20180212 file 20230105/AAAS-chen-02122018.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Slides of a public talk. Looks the same as the PDF.
20180309 file 20221014/PQC Seminar 3-9-18.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"A security proof based on a simple problem" (listed as the top advantage of MQDSS): No, anyone who reads the proof sees that the proof does not rule out the possibility of MQDSS being much easier to break than the simple MQ problem. NIST trusted and internally repeated the provable-security advertising, instead of doing the work to check what had actually been proven. #error
Later, when an attack showed that MQDSS was much easier to break than any known attack against the MQ problem, NIST removed MQDSS from consideration. NIST should have publicly rejected all proofs having the same basic flaw (including various frequently advertised lattice proofs), but does not appear to have done so.
Before this NIST project, there was already some literature (notably the "Another look at provable security" series of papers from Koblitz and Menezes) pointing out errors in provable-security advertising. There was also occasional discussion of such errors during the NIST project, and much more effort could have been mobilized to force correction of the errors. However, because of the lack of transparency, the public was not able to see the extent to which these errors were influencing NIST's evaluations. #weveshownallourwork
20180309 file 20221107/PQC Seminar 3-9-18.pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20180309 file 20230105/Equivalent Key for pqsigRM -- Sage.pdf:
Notes from djb, last edited 20230125 23:38:54 UTC:
Sage script published on pqc-forum on 2018.03.09.
20180323 13:54:58 UTC file 20221107/WalnutDSA.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Review of WalnutDSA. #weveshownallourwork
"Team has a lot of experience with braid crypto, going back to at least ’99"; later, "various indications that authors don't understand crypto": Is NIST supposed to be evaluating contributions of the people on submission teams, as opposed to the contents of the submissions? How is this permitted under the official evaluation criteria? #inconsistency
20180403 file 20221014/PQC Seminar 4-3-18.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"It's proved to be IND-CPA": No. If certain assumptions hold then HQC is IND-CPA; it is not clear whether the assumptions hold. #error
"Reduction to well-studied problem (syndrome decoding)": This falls short of a clear, accurate statement of what had been studied. NIST appears to be conflating the general problem of syndrome decoding with the ring-structured syndrome-decoding problem that appears in HQC. There are, in fact, many more papers studying the general problem. One hopes that the ring structure in HQC is safe, in much the same way that one hopes that the module structure in Kyber is safe, but "hope" and "well-studied" are not the same status. #error
20180403 file 20221107/PQC Seminar 4-3-18.pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20180418 15:36:11 -0400 file 20221014/PQCrypto-April2018_Moody.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a public talk.
"2012 – NIST begins PQC project"
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" (green and boldface in original) #claimingtransparency
"The Selection Criteria": "Security", then "Performance", then "Other properties" including "Drop-in replacements - Compatibility with existing protocols and networks". In this list, compatibility was one of many third-level desiderata within "other properties", which were less important than "security" and "performance".
(For comparison, NIST's 2022 report claimed that "the goal" of post-quantum cryptography "is to develop schemes that can be deployed in existing communication networks and protocols without significant modifications". #inconsistency This change of mission was pointed out in https://cr.yp.to/talks.html#2022.12.29, which added the following comments: "Deployability on the Internet is an important feature of post-quantum cryptography. The exact extent of protocol modifications is much less important.")
Regarding "Intellectual Property": "In Round 1, all submissions should be evaluated on their technical merits." For comparison, NIST claimed in October 2021 that "we have not been discouraging public discussion on patent issues that may be relevant to the PQC standardization process". #inconsistency
"We will continue to work in an open and transparent manner with the crypto community for PQC standards" (red in original) #claimingtransparency
20180503 file 20221014/PQC Seminar 5-3-18 (McNie).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
McNie is a rank-based cryptosystem. Its initial security analysis missed an important attack and was thus too optimistic, as promptly pointed out in December 2017 by designers of other rank-based cryptosystems.
In this talk, NIST highlights (1) the designers at first missing the attack and (2) the designers then increasing their key sizes. This change seems to have been enough reason for NIST to disqualify McNie. The talk doesn't bother comparing the new key sizes to other proposals.
The call for submissions considered changes in security levels ("submitters of algorithms where the complexity of the best known attack has recently decreased significantly, or is otherwise poorly understood, should be especially conservative"), but did not make clear how to account for this. This is important because most submissions made quantitative security claims in 2017 that were subsequently shown to be too optimistic. Did NIST formulate and apply quantitative criteria regarding how much security loss is acceptable? #needmorerecords
20180503 file 20221107/PQC Seminar 5-3-18 (McNie).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20180504 file 20230118/phoenix copy.pdf:
20180601 file 20221014/PQC Seminar 6-1-18.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
"The [QROM] security proofs are based on a few assumptions, including the hardness of their version of Ring-LWE. (Question: What hardness assumptions are made about the hash function?)"
The parenthetical hash-assumptions question is surprising for two reasons. First, it appears that NIST raised the question selectively for some submissions and not others. For example, NIST does not appear to have asked what hardness assumptions Kyber is making regarding its selected hash function. #inconsistency
Second, the question also appears to indicate a failure to understand the definition and usage of QROM. QROM proofs, by definition, model the hash function as a uniform random function. The whole point is that this model allows various proofs that are not known to be doable for the actual hash function. #scramble
20180601 file 20221107/PQC Seminar 6-1-18.pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20180615 13:41:21 UTC file 20221107/NewHope.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Review of round-1 New Hope. #weveshownallourwork
Incorrectly states "Quadratically shorter keys" compared to "LWE". Optimized LWE-based systems (starting with 2011 Lindner–Peikert) have exponent 3/2+o(1), not 2+o(1). #error
"SECURITY PROOFS" item #1: "Recall: hardness of SVP on ideal lattices implies DRLWE assumption." No, no such theorem applies to New Hope. #error This was already clear from the literature at submission time. NIST should have known this and explicitly rejected the inapplicable theorems, rather than repeating false advertising and adding mild disclaimers such as "I’m not sure if the proofs hold for the actual parameters selected in the submission".
20180622 file 20230105/Defense-Cyber-06222018.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a talk. Was this talk public? The "Defense" part of the filename suggests that this was a presentation at a Department of Defense event. #weveshownallourwork
"Nearly all commercial laptops, cellphones and ATMs use NIST Cryptography"
"2012 - NIST begin PQC project"
"NIST team has been reviewing and evaluating the first round candidates through internal seminars": What happened to "open and transparent"? #weveshownallourwork
"May take third analysis phase if needed"
20180713 file 20221014/PQC Seminar 7-13-18 (BIG QUAKE).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
20180713 file 20221107/PQC Seminar 7-13-18 (BIG QUAKE).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20180802 20:32:26 UTC file 20221003/BIKE.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
"Similar submissions":
"All known IND-CPA attacks are well-understood information set decoding type attacks."
20180807 13:39:54 UTC file 20230118/LEDAkem and LEDApkc.pptx:
20180814 file 20221014/PQC Seminar 8-14-18 (Lizard).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
"LWE is at least as hard as determining the length of the shortest vector in a lattice." As stated, this is content-free, since the shortest vector in a lattice has length 0. If "shortest vector" is corrected to "shortest nonzero vector" then the statement is much more interesting but also unjustified. #error
There was already public advertising that tended to deceive people into believing that such a statement had been proven. It would appear that NIST fell for, and internally redistributed, this advertising. Presumably this helped tilt NIST's evaluations towards lattice-based cryptography.
20180814 file 20221107/PQC Seminar 8-14-18 (Lizard).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20180814 14:13:57 UTC file 20221107/Kyber.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Reviewing round-1 Kyber. #weveshownallourwork
Incorrectly says that Module-LWE has "similar performance to Ring-LWE but a bit less structure (in the direction of plain LWE)". #error
Incorrectly says "Kyber (vs Ring-LWE, e.g., NewHope): easier to scale up security strength, a bit less structure". #error
Incorrectly says "Kyber (vs NTRU): more efficient, fewer known attack approaches". #error
20180814 14:13:57 UTC file 20230105/Kyber.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Not byte-for-byte the same file as the other "Kyber.pptx", but the only evident difference in contents is a change in spacing.
20180907 13:16:14 UTC file 20230105/LAC.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
#weveshownallourwork
Reviews LAC.
"Advantages/Limitations": "Mostly same as other Ring LWE schemes."
"Additional Advantages": "Fast when AVX instructions are available."; "Small public key size (even for RingLWE)"
"Additional Limitations": "Not quite as fast without AVX (Can’t do NTT.)"; "Ciphertext size is not quite as good."; "ECC adds memory complexity"; "256-bit parameters may be susceptible to CCA attack.".
20180907 13:47:56 UTC file 20221107/NTS-KEM.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Review of round-1 NTS-KEM. #weveshownallourwork
Incorrectly equates the Classic McEliece Comparison Task Force with one person, and uses this incorrect equation to dodge reviewing the content of the comparison. #error This illustrates the broader pattern of errors (1) driving NIST's evaluation process and (2) remaining uncorrected exactly because of NIST's secrecy. This specific error no longer mattered after Classic McEliece and NTS-KEM merged, but the lack of transparency is a much broader problem.
20180911 file 20230105/Giophantus copy.pdf:
Notes from djb, last edited 20230125 23:38:54 UTC:
Summary of Giophantus.
20181016 09:54:10 -0400 file 20230118/NISTPQCMPKCSurvey.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Mentions on page 32 that the selected MQDSS parameters "do not satisfy the requirements of the security proof"; also mentions this later. In other words, the "security proof" claimed for MQDSS did not apply to the version of MQDSS that was being proposed for usage.
Why didn't NIST reject this "security proof"? Why were other secret NIST documents the next year praising MQDSS as "provably secure"? #inconsistency
20181019 file 20221014/PQC Seminar 10-19-18 (comparison - QC-LDPC schemes).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
"Patents": The call for submissions in 2016 had described free usability as "critical". However, NIST subsequently discouraged public patent analysis: for example, writing "In Round 1, all submissions should be evaluated on their technical merits". The "patents" slide in this talk shows that, at the same time, NIST was internally using patents to criticize some submissions. #inconsistency
20181019 file 20221107/PQC Seminar 10-19-18 (comparison - QC-LDPC schemes).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20181019 file 20230206/FutureTPM-chen-10192018.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides for an external talk on 2018.10.19.
"NIST Crypto program started to build a research team since 2012"
"In 2015 -2016, we started to prepare for PQC standardization"
"We do not expect to 'pick a single winner' ": "Ideally, several algorithms will emerge as 'good choices' "
20181030 01:39:56 UTC file 20221107/MLWE-comparison.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Reviews Kyber (similarly to separate Kyber.pptx), KINDI, SABER. #weveshownallourwork
Red note "Jacob's cycle counts seem quite different from this".
Regarding KINDI: "Putting message into error: I’m not sure how revolutionary this idea is. Paper appeared in Financial Crypto ’15, and has 4 citations. It doesn’t seem to affect security negatively (asymptotically.) In practice?" There's actually a much longer history of this idea; NIST should have known this whether or not a submission said it. #scramble
"Things that make me nervous: new idea, one team member, few citations, no comments…" Is NIST supposed to be evaluating contributions of the people on submission teams, as opposed to the contents of the submissions? How is this permitted under the official evaluation criteria? #inconsistency
Regarding SABER: "Bonus points: they actually realized they were basing security on LWR…" The official evaluation criteria include "the quality of the analysis provided". However, this advantage of SABER over Kyber does not seem to be reflected in NIST's public reports. #inconsistency
20181031 file 20230206/ETSI-IQC-chen-10312018.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2018.10.31.
"NIST team will announce the second round candidates in early spring of 2019": Later NIST said that it would announce at RWC 2019, which was 2019.01.09–11. This was delayed a few weeks because of a government shutdown.
"An encryption and a signature recently announced 'merging' ": Why the quotes around "merging"? NIST had inflated its submission counts in the first place by splitting the pqRSA submission into two "submissions", an encryption "submission" and a signature "submission".
20190211 07:32:59 -0500 file 20221014/PQCarticle.pdf:
Notes from djb, last edited 20221018 16:07:20 UTC:
Draft of a paper.
20190220 file 20230206/OSA-02202019.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2019.02.20.
"NIST has started to grow expertise in post-quantum cryptography since 2009"
20190304 15:16:40 -0500 file 20220914/PQC_and_PKI.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
This talk focused on signatures,
Page 10 says "Don't rush". This is older and less strongly worded than various mid-2021 statements by the U.S. government opposing deployment of post-quantum cryptography. #slowingdownpqcrypto
20190307 file 20230105/Re new PQC talk 2019-03-07 1212.eml:
Notes from djb, last edited 20230125 23:38:54 UTC:
Email to Dustin Moody with comments on some slides.
"Should there be some mention of public key size and signature/ciphertext size? Performance in terms of run time did not play a major role, since we didn't have optimized implementations, so couldn't know the "true" performance of the algorithms. However, better implementations won't affect the sizes of public keys and signatures/ciphertext, and as others have commented, in many cases the communication costs associated with these sizes may have a greater impact on overall performance than the costs of the internal computations."
20190429 15:19:02 UTC file 20221213/GeMMS and MQDSS.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
#weveshownallourwork
"GeMMS retains the conservative parameter selections of round one, but at our request, also provides parameters leaning in the direction of the Gui submission, enhancing performance."
"The selected parameters do not adhere to this proof because of the cost. ... To match the current state-of-the-art, the number of iterations should be about 30 instead of 4 for the proof to be valid." For comparison, NIST continually credits lattice submissions with proofs that, in fact, don't apply to the selected parameters for those submissions. #inconsistency
MQDSS: "Provably secure multivariate signature scheme based on a 5-pass identification scheme. Identification scheme has security depending directly on the MQ Problem (NP-complete)." For comparison, MQDSS was subsequently shown to not meet its security claims. #error
20190429 20:57:38 UTC file 20221213/LUOV and Rainbow.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Summarizes LUOV and Rainbow. #weveshownallourwork
"Admit that the Valgrind test fails specifically by leaking number of signing attempts made". Why is this labeled "admit"? Did NIST criticize lattice submissions with rejection-sampling loops? #inconsistency
"Offline Signing Precomputation": "Probably a bad idea." Why exactly does NIST think this is a bad idea?
Also, the "idea" wording is puzzling. Does NIST realize that NIST's 1998 "Digital Signature Standard", FIPS 186-1, has a section "3.2. ALGORITHM FOR PRECOMPUTING ONE OR MORE k AND r VALUES"? #scramble
"New Variants" of Rainbow: "We basically asked for these." And again later: "Cyclic and compressed versions we asked for"
"Improved Key Generation. Basically the direct analogue of what LUOV does. (Ironic since the argument for this technique provided in Round 1 LUOV comes from the principal submitter of Rainbow which didn’t do it in round 1.)"
20190430 19:13:29 UTC file 20221003/BIKE and HQC [Autosaved].pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Looks like preliminary version of "BIKE and HQC.pptx".
20190514 07:17:50 -0400 file 20221014/pqcrypto-may2019-moody (1).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a public talk.
"Principles: Transparency, openness, balance, integrity" etc. #claimingtransparency
"2012 - NIST begins PQC project"
"NIST lacked full confidence in security of: CFPKM, Compact-LWE, DAGS, DME, DRS, GuessAgain, Giophantus, Lepton, McNie, pqsigRM, RaCoSS, RLCE, Walnut-DSA" (blue in original): Does this mean that NIST was fully confident in the security of, e.g., GeMSS, MQDSS, qTESLA, Round2, and SIKE? #needmorerecords
"Intellectual Property": "For Round 1 – schemes evaluated on their technical merits": This is not true. NIST was internally using patents to criticize some submissions. (See, e.g., 20181019 talk.) It's true that NIST discouraged public patent analysis, but NIST's secret procedures weren't in line with this. #weveshownallourwork #error
"Later on in process, IP concerns may play a larger role"
"Jan to Sep 2018 – Detailed internal presentations on submissions": None of this was shown to the public. #weveshownallourwork
"Sep to Nov 2018 – Review and make preliminary decisions": None of this was shown to the public. #weveshownallourwork
"We will continue to work in an open and transparent manner with the crypto community for PQC standards" (red in original) #claimingtransparency
20190515 file 20230206/ICMC2019-chen-05152019.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2019.05.15.
Looks similar to (and was earlier than) ETRI-chen-09122019.pdf.
20190521 file 20221014/PQC Seminar 5-21-19 (Frodo-KEM).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
20190521 file 20221107/Interim_Response_5_Responsive_Document_1_Redacted.pdf:
Notes from djb, last edited 20221110 10:21:15 UTC:
This is almost a copy of a previously delivered document, except that this version frivolously redacts email addresses in quoted messages to pqc-forum, a public mailing list.
20190522 15:35:39 UTC file 20221003/Code based Crypto in the NIST competition.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Transparency, openness, balance, integrity, technical merit, global acceptability, usability, continuous improvement, innovation and intellectual property" #claimingtransparency
"2012 - NIST begins PQC project"
"A competition by any other name": This NIST project does not comply with NIST's previously announced rules for competitions. (For example, NIST IR 7977 clearly states that, for a NIST competition, winners relinquish intellectual property rights so that the winner can be used royalty-free. NISTPQC is not called a "competition" and did not require this. Some NISTPQC submitters did it anyway.) Presumably the reason for NIST to avoid calling the competition a competition was to avoid following these rules. #inconsistency
"NIST asked submitters to focus on levels 1,2, and 3. (Levels 4 and 5 are for very high security)" For comparison, NIST later retroactively criticized submissions for not having level 5. #inconsistency
"The original McEliece cryptosystem using a hidden Goppa code has remained secure since 1979". The actual publication date was 1978. #error
"The original McEliece cryptosystem has decent performance and good ciphertext size, but its public key size is enormous!" How did NIST evaluate "decent", "good", and "enormous"? #missingclarity #ftqcic
"Key Size Reduction (Continued)"
"Is there any strong theoretical reason why Goppa codes are safe but e.g. GRS codes are not?" (These constructions were unified years ago into "Wild McEliece", allowing the attack boundary to be measured. GRS is degree 1; the Classic McEliece submission cited an attack reaching degree 2; the original McEliece parameters from 1978 used degree 10.) #scramble
"Limited avenues for cryptanalysis", stated as an advantage of some systems. For comparison, NIST has not downgraded lattice systems that have many more avenues for cryptanalysis. #inconsistency
"(Non-tight) Search/Decision, Worst/Average case reductions" stated as an advantage of lattices. In fact, none of the submitted lattice proposals have worst-case-to-average-case reductions. The reductions need larger parameters; the proposals decided to throw this away in favor of efficiency. #error
20190606 file 20230105/Defense-Cyber-06062019.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a talk. Was this talk public? The "Defense" part of the filename suggests that this was a presentation at a Department of Defense event. #weveshownallourwork
"A problem is hard if no polynomial time algorithm is known to solve it": No, this is incorrectly equating hardness with a particular model of hardness. #error
"NIST team had seminars to present each candidate by team members to understand how it works, look into security analysis provided by the submitters, raise questions, discuss pros and cons, etc.": What happened to "open and transparent"? #weveshownallourwork
"Selection of second round candidates": "Candidates which were broken, significantly attacked, or difficult to establish confidence in their security were left out"; "Candidates which provided clear design rationale and reasonable security proofs to established reasonable confidence in security are advanced"
"It is vendors/users decision whether to implement hybrid mode"
20190606 file 20230206/esCar2019-0606.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of an external talk on 2019.06.16.
"Gain first-hand experience through trial implementations e.g. hybrid mode or dual signatures as a temporary solution"
"Do not commit to a specific candidate for long-term products until NIST makes its selection for standardization"
The recommendation to roll out "trial implementations", merely avoiding any commitment to "long-term products", is strikingly different from the NSA/NIST/DHS mid-2021 blanket opposition to post-quantum deployment (e.g. "Don't let folks start to buy and implement unstandard, unknown, potentially unsecured implementations before we as a general community have agreed upon standardization"). #inconsistency
20190609 file 20230206/NCISSE-06092019.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2019.06.09.
20190613 16:04:42 UTC file 20221107/McEliece.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Reviewing round-1 McEliece. #weveshownallourwork
"More like classic Niederreiter": This is correct from an efficiency perspective (the efficiency improvement of sending syndromes is due to Niederreiter), but incorrect from a security perspective. Classic McEliece uses binary Goppa codes as in McEliece's original paper, whereas Niederreiter proposed RS codes.
(The official call for submissions says that "The security provided by a cryptographic scheme is the most important factor in the evaluation", but the secret NIST documents include many examples of NIST putting more emphasis on performance than on security. #inconsistency)
"* submitters have a sketched proposal for extending the SXY proof to CM, but it doesn’t seem to be a complete proof, and I have not checked it": The submission stated "Expected Theorem 1" for the ROM; gave a sketch of a (correct) proof; gave a sketch of a (correct) proof of a QROM statement; and stated "we expect that complete proofs will be written and checked by the community in under a year". (See 2018 paper for a complete proof of a stronger ROM statement, and 2019 paper for a proof of a stronger QROM statement, one that remains unmatched by most submissions.) By writing "doesn't seem to be a complete proof", NIST incorrectly portrays the submission as misrepresenting the proof status. #error
20190614 15:23:24 UTC file 20221107/RQC and qTesla.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Review of round-2 RQC and round-2 qTESLA. #weveshownallourwork
"Good team" for RQC (as one of the "positives"), vs. "it seems unclear if the submitters understand their security" for qTESLA: Is NIST supposed to be evaluating contributions of the people on submission teams, as opposed to the contents of the submissions? How is this permitted under the official evaluation criteria? #inconsistency
20190703 18:46:48 UTC file 20230118/MinRank Problems Arising from Rank-based Cryptography1.pptx:
20190710 18:59:41 UTC file 20230118/MinRank Problems Arising from Rank-based Cryptography.pptx:
20190723 file 20221014/PQC Seminar 7-23-19 (ThreeBears).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
20190723 file 20221107/PQC Seminar 7-23-19 (ThreeBears).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20190903 11:50:55 -0400 file 20220914/moody-opening-remarks.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Says "2012 - NIST begins PQC project". (Page 4.)
Claims "Open and transparent process". (Page 5.) #claimingtransparency
Says "Jan to Sep 2018 - Detailed internal presentations on submissions". (Page 10.) "Internal" means that the public wasn't able to see these presentations, right? #weveshownallourwork
Claims "We will continue to work in an open and transparent manner with the crypto community". (Page 23, red in original.) #claimingtransparency
20190912 file 20230206/ETRI-chen-09122019.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of an external talk on 2019.09.12.
"The comments received on draft requirements and criteria focused on quantum security": That was one topic, yes, but "focus" is overstating the case. #error
"NIST team held internal seminars to present each candidate to understand how it works, look into security analysis provided by the submitters, raise questions, discuss pros and cons, etc.": What happened to "open and transparent"? #weveshownallourwork
"Security analysis": "Research publications at conferences and journals (e.g. PQCrypto)"; "Official comments - Over 300 official comments in the first round evaluation"; "E-mail discussions at pqc-forum - 926 posts"
(It's interesting that NIST sometimes uses the volume of public comments to advertise NIST's process as attracting extensive public review, and sometimes uses it to personally attack the most productive public reviewer. #inconsistency)
"NIST's internal testing with submitters' code": What happened to "open and transparent"? #weveshownallourwork
"the original 1979 McEliece cryptosystem": 1978. #error
"Gain first-hand experience through trial implementations"
"Introduce hybrid mode and/or dual signature in the current protocols and applications"; "Prevent crashing from single security failure"
"We will have many decisions to make" including "Shall we start from the most conservative algorithms?": For comparison, the call for submissions said "The security provided by a cryptographic scheme is the most important factor in the evaluation." #inconsistency
201910 file 20221003/Dagstuhl Slides.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Schloss Dagstuhl events are small (a few dozen people) and invitation-only.
Renames NTRU as "Quotient LWE". This renaming violates the ethical requirement to "use no language that suppresses or improperly detracts from the work of others". Typical readers will have heard that LWE was introduced by Regev in 2005, will have no idea that "Quotient LWE" goes back to the 1990s, and will have no easy way to look it up. #ethics
Regarding fixed-weight vectors in various systems, including the NTRU submission: "Seems to protect against failure boosting attacks. How effectively?" In fact, the NTRU submission has no decryption failures, so it is structurally immune to such attacks, so NIST was wrong to present this as an open question regarding that submission. #error
"For lattice product LWE, there is essentially no performance penalty for choosing module over ring": No, the applicable literature at the time already made clear that there is a performance penalty. #error
In the real world, this performance penalty doesn't seem to matter next to communication costs. But NIST's praise for Kyber's performance frequently uses metrics that suppress communication costs, so it is inconsistent for NIST to not admit that Kyber is behind the state of the art in those metrics. #inconsistency
Regarding the choice of a field: "Is it meaningful when modulus switching is possible?" #error The mistake that NIST is making here was already pointed out in "NTRU Prime: reducing attack surface at low cost":
It is sometimes claimed that 'modulus switching' makes the choice of q irrelevant, but an attacker switching from q to another modulus will noticeably increase noise, interfering with typical attack algorithms.
"No known reduction from LWE to LWR, but no known attacks on normal parameter ranges for LWR KEMs." See footnote 12 of "Risks of lattice KEMs". #inconsistency
20191011 20:58:01 UTC file 20230118/ledacrypt attack.pptx:
20191015 13:14:05 UTC file 20221107/Dagstuhl-19.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Very short review of Classic McEliece, NTS-KEM, Dilithium, qTESLA. #weveshownallourwork
20191118 22:59:36 UTC file 20230118/NewMinRank.pptx:
20191119 file 20230118/NewMinRank11192019.pptx:
20191124 file 20230206/ICISC-chen-11242019.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2019.11.24.
Similar to ETRI-chen-09122019.pdf.
2020 file 20221003/end2ndrounCodes.pptx:
2020 file 20221003/end2ndrounCodes_v3.pptx:
2020 file 20221003/end2ndrounCodes_v4.pptx:
2020 file 20221003/end2ndrounCodes_v6.pptx:
20200211 file 20221014/PQC Seminar 2-11-20 (Fiat-Shamir).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
Reviews a 2019 paper.
20200211 file 20221107/PQC Seminar 2-11-20 (Fiat-Shamir).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20200211 15:33:30 -0500 file 20230118/LEDAcrypt_attack Anon.pdf:
20200214 11:29:00 UTC file 20221213/Quantum Cyrpto Ricadela V6.docx:
Notes from djb, last edited 20221220 22:47:49 UTC:
Draft of an article that Oracle paid Forbes to publish in February 2020, apparently first sent to NIST for review.
This draft says, e.g., "A third family of algorithms for digital signatures, called multivariate cryptography, rests on the difficulty of reverse-engineering quadratic functions [[CHECK]] that form a parabola" where the final version says "A third family of algorithms for digital signatures, called multivariate cryptography, rests on the difficulty of reverse-engineering quadratic functions of a large number of variables".
Various other errors in the draft (e.g., "current RSA and elliptical curve keys contain 200 to 300 bits") persisted in the final article.
202003 file 20221213/PQ-signature-compare-presentation.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Remaining PQ Signatures": Dilithium, Falcon, SPHINCS+, Picnic, GeMSS, Rainbow. Lists qTESLA, LUOV, and MQDSS as "Broken".
"Can we make PQ signatures work in current world? ... To answer this: compare with RSA and EDDSA"
Does not address the possibility of type-1 errors: applications that can afford more than RSA and EdDSA, perhaps much more. #ftqcic
"We know we can make stuff work with RSA-sized PKs and sigs": in other words, says there are no type-2 errors. Where's the evidence? #ftqcic
Presents various tables showing sizes relative to RSA (and cycle counts relative to EdDSA).
"Comparing with RSA"; "SK size matters for implementations" #ftqcic; "All applications care about sig size" (obviously false: many applications sign large documents #error); "Most care about PK" (some do, but where's the evidence for "most"? #ftqcic); "Cert chains care about PK+sig" (certificate chains include public keys and signatures, yes, but the leap to "care" is unjustified: many applications send much larger amounts of data #ftqcic).
"Performance on Intel/AMD Desktop Machines": "Averaged from 37 machines". Presumably this means 37 different up-to-date machines in SUPERCOP, meaning that NIST was ignoring frequent warnings about the submitted software not being optimized for most of those machines. #error
20200309 20:53:00 -0400 file 20221003/2002.08322 (1).pdf:
20200309 20:53:00 -0400 file 20221003/2002.08322 (2).pdf:
Notes from djb, last edited 20221005 11:37:19 UTC:
This is an exact copy of "2002.08322 (1).pdf".
20200312 15:13:46 -0400 file 20221003/2002.08322.pdf:
20200407 file 20221213/PQC KEM Benchmarks 20200407.pdf:
Notes from djb, last edited 20230125 23:38:54 UTC:
Lists "Second Round KEM Candidates" as Kyber, Saber, Frodo, NewHope, Three Bears, NTRU, NTRU Prime, SIKE, Classic McEliece, BIKE, and HQC, while crossing out Round 5, LAC, NTS-KEM, LEDAcrypt, ROLLO, RQC. (Classic McEliece and NTS-KEM had announced a merger before this.)
"KEM Summary": comparison uses "bandwidth cost of 2000 cycles/byte"; "Saber provides best overall performance"; "Kyber best for constrained devices"; "BIKE-2 probably least bad non-lattice submission".
Reports various numbers selected from eBACS, "Jacob's Numbers (Code-based Only)", "Performance Numbers from Submissions", pqm4, "More Cortex-M4 Numbers", and "NewHope on ARM Cortex M0 and M3".
Highlights 1280 bytes as a "Size Constraint" from IKEv2. Says that "1,472 byte public keys and ciphertexts" from BIKE-2 "wouldn't fit in a single packet". Says "4 KB RAM" is "max. RAM in payment cards".
20200417 11:42:21 -0400 file 20221003/Cryptanalysis_of_LEDAcrypt__reorg_.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Describes an attack that breaks unlucky keys using 264 bit operations. About 1 out of every 248 keys is unlucky, so this is comparable to an attack using 2112 bit operations. Describes this as "a major, practical break" and a "real-world attack".
For comparison, NIST continues to allow 2112 security in various standards. NIST requires a higher security level for NISTPQC, but has been inconsistent in enforcing this requirement. #inconsistency
20200420 16:41:57 -0400 file 20221003/Cryptanalysis_of_LEDAcrypt__reorg.pdf:
20200422 16:03:09 -0400 file 20230118/NewRankArticle.pdf:
20200430 13:27:45 UTC file 20221003/BIKE and HQC.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"New Submitter (Valentin Vasseur) for BIKE – Probably added for BIKE-CCA decoder". Is NIST supposed to be evaluating contributions of the people on submission teams, as opposed to the contents of the submissions? How is this permitted under the official evaluation criteria? #inconsistency
"Complexity of known attacks (ISD) on codes is easier to quantify and stabler than for lattices": For comparison, NIST's public reports downplay the instability of lattice attacks. #inconsistency
"BIGQUAKE survived round 1 cryptanalysis, but didn’t get that much key size reduction, and the attacks used to set its parameters are quite new"
20200430 16:27:48 UTC file 20221213/Performance of Rainbow Quynh.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"For internal use only." What happened to "open and transparent"? #weveshownallourwork
Quotes various performance numbers.
"Signing and verifying times are good for standard Rainbow." What are the criteria being used to judge "good"? #missingclarity #ftqcic
"Signing and verifying times are acceptable for Compressed Rainbow for level 1." What are the criteria being used to judge "acceptable"? #missingclarity #ftqcic
"Key generation is not fast, but acceptable because keys are not generated regularly." What are the criteria being used to judge "fast" and "acceptable"? #missingclarity #ftqcic For comparison, NIST puts much higher weight on key-generation time for KEMs. #inconsistency
Quotes the "Performance on Intel/AMD Desktop Machines" slide from "John's talk".
"Constrained devices may have some performance impact from storing the private key."
"The public key size is a seriously significant cost for protocols/applications which require a key (or its certificate) or more to be sent regularly." What are the criteria being used to judge "seriously significant"? #missingclarity #ftqcic
Quotes https://eprint.iacr.org/2020/071 reporting times ranging from 0.015 seconds to about 0.1 seconds for TLS handshake times with various choices of signature algorithms. Does not explain why this difference is supposed to matter. #ftqcic Ignores 2020/071's admission that it used implementations that "were not optimized". #error Ignores another major 2020/071 benchmarking error pointed out on pqc-forum in February 2020. #error
"If only Rainbow is standardized, TLS can still work. But, some changes need to be made in order to reduce the performance penalty from big public keys". Except for fixing a specific client bug (which obviously would be done at the same time as adding Rainbow support), no explanation of why these changes "need" to be made. #ftqcic
VPNs: "However, these connections usually stay up for a long period of time. Therefore, the impact of big certs is not big." #missingclarity #ftqcic
20200512 file 20221014/PQC Seminar 5-12-20 (Lattice Signatures).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Patents: "Jacob noticed they include a 'hint' that could conceivably be taken by Ding to be reconciliation." Apparently NIST believed that there was a "reconciliation" dividing line between Ding's patent and unpatented systems. This belief was introduced in a paper "NewHope without reconciliation", but the dividing line has never been given a clear definition, never mind the question of whether any such dividing line can hold up in court. The big issue here, going beyond this particular patent, is that NIST was not following robust procedures for evaluating patent threats. #slowingdownpqcrypto
There's also a striking contrast between (1) NIST internally discussing patent threats and (2) NIST continuing to discourage public analysis of patent threats. #inconsistency
"Strong team": Again, is NIST supposed to be evaluating contributions of the people on submission teams, as opposed to the contents of the submissions? How is this permitted under the official evaluation criteria? #inconsistency
20200512 file 20221107/PQC Seminar 5-12-20 (Lattice Signatures).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20200514 18:10:50 UTC file 20221213/Rainbow.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"For internal use only... unlike a hairdryer." What happened to "open and transparent"? #weveshownallourwork
"Rainbow Band Separation Attack (something new, probably breaks Ia slightly)"
"The complexity matches that of direct attack closely. (Very interesting.)"
"Rainbow looks fairly solid, but there have been a few sloppy mistakes. ... On the bright side, these analyses seem fairly tight now."
20200514 18:19:34 UTC file 20221213/GeMSS.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"For internal use only... unlike a hairdryer." What happened to "open and transparent"? #weveshownallourwork
"Large 'attack surface' = good reason for skepticism". Where are the records of NIST applying this skepticism to lattice submissions with a large attack surface? #inconsistency
"IP STATUS" with some comments on patent 7158636, patent 7961876, patent application 15/562034. For comparison, NIST was discouraging public patent analysis. #inconsistency
"GeMSS looks fairly solid"
"Plus is that parameter selection is fairly conservative"
20200515 file 20221213/Performance of Gemss Quynh.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"For internal use only." What happened to "open and transparent"? #weveshownallourwork
GeMSS: "Public keys are gigantic"; "Private keys are big (better than Rainbow’s)"; "Signatures are small". How did NIST evaluate "small" and "gigantic"? #missingclarity #ftqcic
GeMSS "has much worse performance impacts for TLS, IKE2/Ipsec and SSH than Rainbow does". How did NIST evaluate how bad the impact is? #missingclarity #ftqcic
The smaller private key for GeMSS "helps some constrained devices; it requires less space/memory to hold the private key". Where's the evidence of applications where the smaller GeMSS key matters? #ftqcic
Quotes "Comparing with RSA" slide from "John's talk", including the claim that "SK size matters for implementations". #missingclarity #ftqcic
"Gemss128’s private key is about 9 times smaller than Rainbow1a’s private key. This fact helps some constrained devices; it requires less space/memory to hold the private key." #ftqcic
Procedurally, it is striking how much emphasis this secret NIST document was placing upon secret-key size. For comparison, the "cost" section of the call for submissions lists "Public Key, Ciphertext, and Signature Size" (note the word "public"); "Computational Efficiency of Public and Private Key Operations"; "Computational Efficiency of Key Generation Schemes"; and "Decryption Failures". There was also a catch-all comment that "NIST will continually seek public input regarding which performance metrics and which applications are most important", but when did NIST officially inform submitters that it was adding secret-key size as an important evaluation criterion? #inconsistency
"Gemss128’s signature is about ½ of Rainbow1a’s signature. Rainbow1a’s signature is very small. Therefore, this size improvement would not help much in practice": What was NIST's basis for deciding that some performance improvements are important and others aren't? Why not describe all of the cryptographic costs as "very small"? #missingclarity #ftqcic
"Gemss’s key generation is about 4 times faster than Rainbow at level 1 security. This is not significantly important because key pair is not generated regularly." #missingclarity #ftqcic
"Gemss’s signing and verifying operations are orders of magnitudes slower than Rainbow’s. Signing and verifying have much more impacts than key generation." #missingclarity #ftqcic
"Remark: Rainbow has much better performance than Gemss." #missingclarity #ftqcic
20200610 19:59:00 UTC file 20221213/HQC_Round_2(draft).docx:
Notes from djb, last edited 20221220 20:33:13 UTC:
Two paragraphs with an early draft of the text regarding HQC for NIST's report on the second round, followed by four paragraphs with a subsequent draft (close to the final text).
20200622 16:50:56 -0400 file 20221003/Cryptanalysis_of_LEDAcrypt622.pdf:
20200622 19:03:38 -0400 file 20221003/Cryptanalysis_of_LEDAcrypt622New.pdf:
20200702 23:36:48 -0400 file 20221003/Cryptanalysis_of_LEDAcrypt07022020.pdf:
20200720 10:55:00 UTC file 20221014/nistir 8309 pqc report on round 2 final.docx:
Notes from djb, last edited 20221018 10:45:43 UTC:
Looks like draft of July 2020 report NIST IR 8309.
20200723 17:16:00 UTC file 20221014/Round 3 Announcements.docx:
Notes from djb, last edited 20221018 10:44:11 UTC:
Text looks like the email dated 22 Jul 2020 20:51:25 +0000 to pqc-forum.
202008 file 20221003/cost models.pptx:
20200810 file 20221003/cost models 8.10.2020.pptx:
20200817 file 20230206/ICT-Hardware-Chen-08172020.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2020.08.17.
20200817 16:34:25 UTC file 20221003/cost models forum.pptx:
Notes from djb, last edited 20221005 13:12:23 UTC:
This is not exactly the file posted to pqc-forum on 2020.08.17.
20200825 file 20221014/PQC seminar 8-25-20 (Fujisaki-Okamoto).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
Reviews a 2020 paper.
20200825 file 20221107/PQC seminar 8-25-20 (Fujisaki-Okamoto).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20200826 file 20221213/QROM stuff.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"NIST internal": What happened to "open and transparent"? #weveshownallourwork
"The trouble: proving security for systems involving hashing seems hard (impossible?)". This is then followed by an argument specific to hash collisions. #error
Claims falsely that all "known strategies" for attacks are simply plugging inputs into the hash function and seeing "what comes out", and "would work equally well" for uniform random functions given oracle access. #error In fact, there is an extensive literature on attacks against specific hash functions.
Claims falsely that, within "all interesting quantum attacks against hashing", Grover "does provably better than any strategy that makes only classical queries". In fact, many known attacks against specific hash functions are faster than Grover's method. #error
Claims that "We still don’t know of any examples 'in the wild' where QROM is an issue." Does not define what an "issue" would be, and does not reconcile this with the Grover speedup. #missingclarity
20200831 20:53:58 UTC file 20230105/failure survey.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Looks like early draft.
20200902 18:57:11 UTC file 20230105/failure survey recovered.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Looks like a near-final draft.
20200910 15:14:15 -0400 file 20230105/failure survey .pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
#weveshownallourwork
This talk asks whether BIKE's estimates of decryption-failure rate are correct, and surveys what is known about the topic. The talk acknowledges that, because of a lack of certainty on the topic, the BIKE team claims only IND-CPA security.
For comparison, there are many reasons to question claims of IND-CCA2 security made by other submissions. Where are the NIST investigations of the basis for those claims? #inconsistency
"For category 1 BIKE parameters this means the DFR is at least 2−346": No, it doesn't mean that. #error The conclusion might be correct but the logic is wrong. What's missing here is an analysis of whether BIKE can in fact generate these failing error vectors.
20200910 15:22:25 -0400 file 20221003/articlev2.pdf:
20200910 19:15:23 UTC file 20230105/failure survey .pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Looks similar to PDF.
20200930 08:49:59 -0400 file 20221014/pqcrypto-sept2020-moody.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides for a public talk.
"Principles: Transparency, openness, balance, integrity" etc. #claimingtransparency
"Throughout the 2nd round, NIST regularly met and reviewed the submissions and research results" #weveshownallourwork
"Starting in April 2020, we began more frequently meeting to review each submission in detail and start to make decisions" #weveshownallourwork
"Long discussions and back and forth. Changed our minds often." #weveshownallourwork
"The feedback received (from the NSA) did not change any of our decisions and did not substantively change our 2nd Round Report": Where are the records of the feedback? Where are the records of NSA's frequent meetings with NIST? #nsa
20201020 14:26:07 UTC file 20230118/Minrank in Cryptography and Cryptanalysis v2.pptx:
20201021 16:09:55 UTC file 20230118/Minrank in Cryptography and Cryptanalysis v3.pptx:
20201026 file 20230206/IEEE-SA-10262020.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2020.10.26.
"NIST team has started conducting research on PQC since 2011"
20201113 file 20221014/PQC seminar 11-13-20 (SIKE, Frodo).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"?
Regarding Frodo: "The authors claimed that since their encryption scheme is OW-CPA, its Fujisaki-Okamoto transform is IND-CCA. D. Bernstein said he couldn't find that fact in the cited paper. Round 3: The authors give a new and more detailed analysis": No. #error Here are the facts:
Six weeks after objections were raised to the Frodo submission's claim of a "theorem" obtaining IND-CCA from OW-CPA, the Frodo team withdrew the theorem and replaced it with a different theorem (loosely) obtaining (ROM) IND-CCA from IND-CPA. The Frodo team claimed that "the change in hypothesis from IND-CPA to OW-CPA was a typo".
The "typo" claim, in turn, was analyzed on page 20 of a paper "Comparing proofs of security for lattice-based encryption", which traced how the Frodo submission had consistently changed IND-CPA to OW-CPA at four locations and added a footnote "OW-CPA is for example defined in [63] and is implied by IND-CPA".
There's also a straightforward explanation for why Frodo had changed from making an IND-CPA assumption to making an OW-CPA assumption: Frodo was also making a "divergence" argument that produced an OW-CPA conclusion suitable for applying the claimed theorem from OW-CPA, and did not produce an IND-CPA conclusion. The problem is that the Frodo submission never had a proof of its claimed theorem from OW-CPA.
The call for submissions said that NIST would evaluate "the quality of the analysis provided by the submitter". Clearly there was a severe quality-control failure in Frodo, a submission that (1) highlighted provable security, (2) claimed a security theorem, and (3) withdrew the theorem after the theorem was challenged. Instead of accurately reporting this failure (and giving proper credit to the discoverer), NIST's slides portray the problem as a mere lack of "detail" in the "analysis". #inconsistency
Another NIST employee had previously attempted to publicly downplay the same failure. For example, in response to the question "Has this theorem in fact been proven?" and an accompanying citation of a proof of the different theorem from IND-CPA, that employee wrote "Sure, let's verify it together" (falsely telling most readers that there was no issue) and then outlined the same proof of the different theorem from IND-CPA (failing to address the issue). It's still surprising to see that, several months later, another NIST employee was presenting slides misrepresenting the facts.
"Guo et al. (2020) claimed a general timing attack on all Fujisaki-Okamoto schemes": No. #error The Guo–Johansson–Nilsson paper
said that FO is breakable if there is a timing leak in the FO ciphertext-comparison step, and
broke the official Frodo software by exploiting such a timing leak, even though the Frodo submission had claimed that the official software was constant-time.
Many other FO-based submissions had avoided such timing leaks from the outset. NIST's description of the attack is incorrect, and hides the fact that there was a mistake in some submissions, such as Frodo.
20201113 file 20221107/PQC seminar 11-13-20 (SIKE, Frodo).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20201120 file 20230118/Updated Presentation on KYBER _ SABER from Danniel Smith Tone 11_20_2020 (3).pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
What happened to "open and transparent"? #weveshownallourwork
"KYBER SECURITY"
"Reduction from MLWE Assumption in ROM (tight)"
"Reduction from MLWE Assumption in QROM (non-tight)"
"Reduction from MLWE Assumption in QROM under non-standard assumption (tight): a deterministic CPAPKE is prseudo-random in QROM."
"UPDATE: Discuss “beyond ‘core-SVP’ hardness” attacks and attacks using decryption failures"
"Classical core-SVP hardness (118, 182, 256) (actually uses an LWR assumption for these figures). A conservation estimate for Kyber512 because the total variance of each coefficient is greater then 3/2 which was used for the estimate."
"Classical gate count estimates (151.5,215.1,287.3)"
"KYBER CHANGES FROM ROUND 2"
"Increased the noise parameter for KYBER512 to increase core-SVP hardness": No mention here of the flaws found in Kyber's previous security claims, and of lattice attacks getting better. For comparison, NIST didn't allow most other submissions to increase parameters after attacks improved. #inconsistency
"Now say that core-SVP is a bad measure of security"; "Added a “Beyond core-SVP hardness” section including a more careful gate-count estimate": When other submissions use larger security metrics than Core-SVP, NIST complains. When those submissions then switch to Core-SVP, NIST pretends that there was a security problem in those submissions. When Kyber switches from Core-SVP to a larger metric, NIST doesn't complain; it praises Kyber for being "careful". #inconsistency
Various slides about SABER.
"KYBER AND SABER PERFORMANCE COMPARISONS" highlighting SABER using roughly 40% extra cycles, and then highlighting Kyber using roughly 10% extra bytes. Highlighting 40% extra for SABER and 10% extra for Kyber makes Kyber sound like the winner. That's an incorrect conclusion from a flawed performance-comparison methodology. #ftqcic
Slide adding NTRU sizes to the comparison, highlighting ntruhps509 being 10 bytes smaller than saber512 and ntruhrss701 being 868 bytes larger than saber512 (in pk+ct). Doesn't mention that ntruhrss701 is at a much higher security level than saber512. Doesn't point out similarly large Kyber/Saber options. Doesn't mention ntruhps2048677 as a smaller option. #inconsistency
Another slide with NTRU cycle counts, putting double emphasis on NTRU's key-generation time ("k" and "t" columns), rather than putting lower weight on keygen time as per the official evaluation criteria. #inconsistency
Various pqm4 numbers, again highlighting NTRU's key-generation time, this time for unoptimized software. #inconsistency
20201122 file 20230206/ICISC2020-11222020-chen.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2020.11.22.
20210107 18:49:01 UTC file 20230118/MinRank and its apllications to cryptanalysis.pptx:
20210107 19:32:56 UTC file 20230118/MinRank and its applications to cryptanalysis.pptx:
20210222 18:44:25 UTC file 20230105/lattice-overview.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Could be an early draft of "lattice-overview-3.1.2021.pptx".
20210301 file 20230105/lattice-overview-3.1.2021.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"NIST internal talk": What happened to "open and transparent"? #weveshownallourwork
"This talk series": "We want to internally distribute expertise on cryptanalyzing lattices"
"Why? Every Finalist in Round 3 is a lattice, or it’s not* subject to cryptanalysis"
"*meaning it’s McEliece or SPHINCS+, where we don’t expect big breaks…"
"We wanted to force most people to give one “hard” talk on lattices. Seems the best way to ensure everyone gains some familiarity."
"What are our main goal(s)? Everyone learns how to calculate concrete bit-security of lattice schemes. Maybe spawn some of our own research into lattice cryptanalysis…"
(For comparison, here is a quote from Daniel Apon in email dated 11 Nov 2020 17:29:56 +0000: "I'm confident that the NIST PQC team members are familiar with e.g. LLL/BKZ (and at least reasonably familiar with all of the technical minutiae regarding more modern tweaks to lattice reduction algorithms and algebraic cryptanalysis of lattices over various number fields)." Why would the NIST team members need introductory talks on BKZ in 2021 if they were already familiar with BKZ in 2020? #scramble)
"Widely cited ADPS 2016 estimates are based on the Geometric Series Assumption ... Some newer estimates, e.g. https://eprint.iacr.org/2020/1308.pdf , instead use simulations": No credit given to NTRU Prime for already using BKZ simulations (specifically, using the 2011 Chen–Nguyen simulator) for security estimates four years before 2020. #ethics
"Howgrave-Graham (2007) combined this with lattice reduction to create an improved hybrid attack using a technique I will refer to as “magic”" #scramble
20210301 17:39:30 UTC file 20230118/lattice-overview-draft.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Draft of "lattice-overview-3.1.2021.pptx".
20210301 17:57:01 UTC file 20230118/lattice-overview-draft-updated.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Draft of "lattice-overview-3.1.2021.pptx".
20210301 23:32:16 UTC file 20230118/lattice-overview-combinedupdate.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Looks like "lattice-overview-3.1.2021.pptx". Haven't checked for differences.
20210302 04:50:17 UTC file 20230118/lattice-overview-now-with-incredulity.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Draft of "lattice-overview-3.1.2021.pptx".
20210302 18:15:46 UTC file 20230118/lattice-overview-now-with-incredulity-and-corrections.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Draft of "lattice-overview-3.1.2021.pptx".
20210304 18:19:10 UTC file 20230118/lattice-overview-mostly-fixed.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Draft of "lattice-overview-3.1.2021.pptx".
20210315 18:18:20 UTC file 20221003/BDGL.pptx:
20210316 16:13:14 UTC file 20221003/BDGL-final .pptx:
20210326 15:53:50 UTC file 20221213/DimensionsForFree.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"For internal use only... unlike a hairdryer." What happened to "open and transparent"? #weveshownallourwork
Reviews a paper under the same name.
20210326 15:53:50 UTC file 20230105/DimensionsForFree.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Frivolously repeated copy of previously delivered document.
20210521 file 20230206/LISA21-Chen-05212021B.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2021.05.21.
20210610 10:15:51 -0400 file 20221014/session-1-moody-nist-round-3-update.pdf:
Notes from djb, last edited 20221018 18:07:11 UTC:
Slides of a public talk.
20210630 13:53:37 UTC file 20230118/LatticeOverviewReadingClub.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
Important difference from "lattice-overview-3.1.2021.pptx": there are some extra slides in the middle summarizing approaches to the SVP subroutine. #scramble
Sieving is "universally used fo lattice security estimates now": False. #error For example, the NTRU Prime documentation presents lattice-security estimates using sieving and lattice-security estimates using enumeration. In some cases, the enumeration estimates beat the sieving estimates.
It is clear from the asymptotics that sieving outperforms enumeration for large enough sizes. However, as explained in the NTRU Prime submission, the cutoff is extremely sensitive to improvements in sieving algorithms, improvements in enumeration algorithms, accounting for the costs of memory (this favors enumeration), and switching to quantum computation (this favors enumeration).
These effects have an interesting interaction with NIST's recent efforts to change security definitions so that Kyber meets its claimed security targets. Specifically, NIST is now advocating
accounting for the costs of memory ("it seems unlikely that the cost of memory access will ever become small enough to cause Kyber-512 to fall below category 1 security, in realistic models of security that take these costs into account") and
switching to quantum computation ("in the likely scenario where the limiting attack on AES128 is Grover’s algorithm, this would further increase the security margin of Kyber512").
NIST doesn't seem to have noticed that these changes reward enumeration, undermining Kyber's arguments for dismissing enumeration. It seems likely that enumeration outperforms sieving in this context, but properly evaluating this will require that NIST stop dodging clarification questions regarding how it is accounting for the costs of memory. #inconsistency
20210811 19:40:32 UTC file 20221003/BIKE rowhammer.pptx:
Notes from djb, last edited 20221005 12:17:50 UTC:
Looks like a very early draft.
20210813 file 20221014/NIST Crypto Short Talk 8-13-21.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"For internal use only – not for public distribution": What happened to "open and transparent"? #weveshownallourwork
A few "takeaways" from a 2019 National Academies report on quantum computing and from a 2021 Google report on quantum computing.
Also a surprisingly basic question "Are there any fundamental obstructions to QC?" with no references to the relevant literature. #scramble
20210813 file 20221107/NIST Crypto Short Talk 8-13-21.pdf:
Notes from djb, last edited 20221110 07:08:40 UTC:
Frivolously repeated copy of previously delivered document.
20210813 file 20230118/NIST Crypto Short Talk 8-13-21.pdf:
Notes from djb, last edited 20230125 23:38:54 UTC:
Frivolously repeated copy of previously delivered document. (Third copy of this particular document.)
20210914 file 20221014/PQC Seminar 9-14-21 (Dilithium and Falcon).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
Slides review some qualitative features of security assumptions in proofs related to two lattice-based signature schemes.
20210914 file 20221107/PQC Seminar 9-14-21 (Dilithium and Falcon).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20210920 02:45:00 UTC file 20221003/cleaned up keccak description.docx:
20211005 file 20230206/IEEE-CNS-10052021.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2021.10.05.
20211025 17:29:43 UTC file 20230105/KSN Document.docx:
Notes from djb, last edited 20230625 17:50:02 UTC:
#inconsistency #weveshownallourwork
Comparison table for Kyber, Saber, and NTRU according to the following list of criteria (which deviates in many ways from the public list of evaluation criteria):
"3rd round tweaks?" One of the comments on NTRU: "Level 5 parameters added after our workshop (after declining to earlier)"
"Security categories offered": Here NIST lists the selected parameter sets and ignores NTRU's much longer list of available parameter sets. #inconsistency
"Best security estimate of parameter levels (using coresvp?)": Includes a comment on Kyber: "Questions were raised on the pqc-forum about whether or not Kyber meets the security categories. Kyber provided more explanation, and we seem to accept their arguments. (It is possible Kyber’s parameters fall short, but if so, so would several of the other lattice candidates (see e.g. NTRU): Kyber’s best estimate of their security clearly meets the claimed categories, although the declared uncertainty in this estimate would be enough to leave open the possibility that they are slightly below.)"
Why is NIST arguing that it's okay for Kyber to violate NIST's announced security requirements? How is a claimed NTRU violation supposed to justify this? #inconsistency
The claim also doesn't stand up to examination. NTRU provides many more choices of security levels than Kyber does. #error
"State of security proofs": This describes Kyber's proof status in a way that sounds better than NTRU's. In fact, Kyber's proof status is worse than NTRU's. #error
The same mistake ended up in NIST's round-3 report, and was pointed out in an "OFFICIAL COMMENT" dated 27 Jul 2022 08:31:51 +0200. NIST never replied to that comment.
"Known attack analysis or complexity (both classical and quantum)": For Kyber, NIST says "Many attacks covered (side-channel, multi-target, misuse, primal, dual, algebraic, failure boosting)" and "Argue memory costs would be extremely high."
Meanwhile NIST's summary of the NTRU attack analysis sounds much less positive: "Discussion of local vs non-local models, states quantum attacks don’t seem to be relevant to NTRU in practice, primal, and hybrid attacks, reaction, key-reuse".
There is a similar gap, with less explanation, in NIST's subsequent round-3 report, which praises Kyber's "thorough and detailed security analysis" and sounds far less enthusiastic about NTRU's security analysis.
However, a closer look shows that NTRU's attack analysis has three major advantages over Kyber's attack analysis:
Hybrid: This is a large gap in the Kyber attack analysis, whereas it's covered in the NTRU attack analysis. NIST does list this as something covered by NTRU but clearly doesn't understand how important it is.
Failure boosting: NTRU has no decryption failures, so NTRU is immune to failure attacks. It makes no sense to credit Kyber for analyzing known failure attacks without giving NTRU more credit for eliminating the entire class of attacks.
Memory costs: The Kyber documentation simply asserts that costs are higher because of "massive memory requirements", whereas the NTRU documentation does the work of presenting quantitative estimates of how much higher (the "local" estimates vs. the "non-local" estimates). NIST's description makes it sound as if Kyber does real work to argue that memory costs for Kyber attacks would be "extremely high" while NTRU is merely engaging in discussion of the "models".
Furthermore, while it's true that the Kyber table of contents lists subsections on "side-channel attacks" and "multi-target attacks" and "misuse resilience", these are not in the attack-analysis section; they are in Kyber's discussion of "additional security properties".
Anyone who reads, for example, Kyber's "Multi-target attacks" section immediately finds the statement "Our security analysis makes no formal claims about security bounds in the multi-target setting." The Kyber documentation points to two design features that might improve multi-target security, but the only multi-target attack analysis that it presents is for failure attacks, which, again, is something where NTRU should receive more credit than Kyber.
As for dual attacks, it's correct that Kyber summarizes dual attacks while NTRU doesn't. But Kyber then gives an argument that dual attacks are "significantly more expensive" than primal attacks; and, based on this, gives gate-count details only for primal attacks. So both submissions were in agreement that dual attacks didn't matter; the difference is merely between (1) omitting a detailed analysis of dual attacks and (2) omitting any analysis of dual attacks.
(Subsequent literature blew holes in Kyber's argument and reported hybrid dual attacks faster than the primal attacks that Kyber had considered. This was before NIST's round-3 report, but perhaps after this NIST document.)
Kyber's comments on "algebraic" attacks are even shorter and even more dismissive. For people who see this as a deeply concerning line of attacks, the comments are far too short; for people who don't, why is including those comments supposed to be an important advantage for Kyber?
NIST's evaluation here seems to be based primarily on counting how many types of attacks are listed in boldface in the documentation, rather than on digging into the content of the attack analysis. How is this allowed by the official evaluation criteria? #inconsistency
"PK and ciphertext sizes for each parameter set"
"Cycle counts, or other efficiency metrics, for KeyGen, Enc, and Dec"
"Any implementation issues to be aware of? Decryption failures?"
"Efficiency in hardware?" This is missing an NTRU entry, which is unfortunate since the applicable literature gives clear reasons to believe that NTRU ASICs are more efficient than Kyber ASICs. #error
A bizarre feature of this table row is that it lumps Cortex-M4 software performance into "hardware". Also, for some reason NIST doesn't report the attractive Cortex-M4 numbers that had been demonstrated for NTRU enc+dec. (NTRU keygen didn't have Cortex-M4 code yet.) #error
"Used in any experiments?" Starts with an astonishing error, namely claiming that Kyber was used in "CEPQ2". In fact, the Google–Cloudflare CECPQ2 experiment was an experiment with NTRU (specifically ntruhrss701) and with SIKE, not with Kyber. #error
If NIST thought third-party choices of experiments were important for the Kyber-SABER-NTRU decision, why wasn't NIST bothering to collect correct data regarding those choices?
In general, this row makes Kyber sound like a bigger target of experiments than NTRU. The reality is that the Google–Cloudflare experiment collected and published extensive information on NTRU's real-world Internet deployability. Did NIST see anything similar for Kyber?
"Stated advantages": This is unskeptically repeating the lists of advantages from submissions, so it penalizes the NTRU submission for being honest. How is this allowed by the official evaluation criteria? #inconsistency
"Known disadvantages": Similar.
"IP issues": Given the real-world importance of patents, why is this item buried at a hard-to-notice position inside this list?
(For comparison, NIST's call for submissions in 2016 had described free usability as "critical". Nothing else was listed as "critical". #inconsistency)
Mentions "CNRS patent, Jintai’s?" for Kyber; "CNRS patent, Jintai’s" for SABER; "Patents expired/released" for NTRU. Doesn't discuss the other five patent families that have been identified that potentially threaten Kyber and SABER. #error
"Side-channel analysis or resistance?"
"Simplicity": Nothing listed.
"Clarity of specification or other documentation": Nothing listed.
"Flexibility properties": Correctly credits NTRU for providing "hundreds of options" regarding "size vs. security trade-offs". Why was this excluded from "Security categories offered" near the top of the list?
"Miscellaneous"
"Unresolved issues we want answers for?"
"Any important research papers during 3rd round"
"Official comments and relevant pqc-forum discussion"
After the table, a few paragraphs with further notes:
"For KEMs want to minimize cycle counts (keygen+encaps+decaps)+n*(public key+ciphertext size)." What exactly is NIST's basis for giving keygen the same weight as encaps and decaps, and giving key size the same weight as ciphertext size?
The call for submissions correctly notes that the performance picture changes "if applications can cache public keys". Having many ciphertexts sent to a public key puts lower weight on key-generation time and on public-key size than on enc time, dec time, and ciphertext size. By choosing a metric that eliminated this speedup, NIST was deviating from the call for submissions and unfairly punishing NTRU. #inconsistency
"David’s end of round 2 PQC KEM benchmarks presentation concludes Saber is more efficient overall, Kyber better for constrained devices since it use little memory." Here NIST was unfairly rewarding Kyber for using "little memory", which was not one of the cost metrics listed in the official evaluation criteria. #inconsistency
"(Quynh) Over all, I lean towards Kyber for performance based on AVX2 and pqm4’s data accounting for sizes with an important point being that a few extra bytes are not worth a sizable cycle count because the users (clients and servers) are pretty much not paying for the cost of transmitting the bytes over the wire (the internet provider(s) does/do)." #missingclarity #ftqcic
In an open and transparent project, the public would have had an opportunity to ask (1) why NIST believed that communication costs weren't passed along to users, (2) why NIST believed that this justified making a selection on the basis of cycle counts with communication costs ignored, and (3) why this was being given higher weight than the analogous argument in the opposite direction, namely that the user has spare CPU cycles so cycle counts should be ignored.
Previous public analyses had already taken a principled approach of collecting real-world data regarding the costs of computation and communication, and had consistently concluded that the costs of these systems are dominated by communication, not computation.
More fundamentally, there is overwhelming evidence that all of these systems are easily affordable in typical applications. NIST decided to select only one KEM, a KEM in the middle of a patent minefield; it is horrifying to see secret documents where NIST is highlighting minor performance differences as a basis for this decision. #slowingdownpqcrypto
20211027 13:27:50 UTC file 20230105/KSN Comparison.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
#weveshownallourwork
"Which of Kyber, Saber, and NTRU do we prefer?"
"If IP were not an issue, which one would we prefer?": Wow.
NIST's call for submissions had labeled free usability as "critical". This issue should have driven NIST's Kyber-SABER-NTRU decision (given that those were the options NIST was considering), already producing an announcement in 2021 that NIST was selecting NTRU as the patent-free option.
Asking how to make decisions when a critical issue is ignored means assigning lower weight to the issue. This was a critical decision-making error by NIST. Is there any documentation showing how this error happened? #inconsistency #slowingdownpqcrypto #needmorerecords
Lists "Evaluation Criteria" somewhat out of whack with the official evaluation criteria:
#inconsistency
Goes through details similarly to "KSN Document.docx". (See notes on "KSN Document.docx".)
Includes some numbers and graphs that aren't in "KSN Document.docx". These have the effect of putting even more emphasis on keygen speed, punishing NTRU, whereas the call for submissions put lower weight on keygen. #inconsistency
Completely fails to account for the keygen speedup demonstrated and implemented in the OpenSSLNTRU paper. #error The paper used NTRU Prime (which has a larger speedup) as its case study, but also estimated a speedup around 2x for NTRU.
For Cortex-M4, highlights timings of unoptimized software for NTRU keygen, grossly overestimating the times that users would end up seeing. #error
The content of the graphs is obviously wrong, not matching the labels. #error If the most obvious error in the labels is corrected (to multiply the sizes by 1000 or 2000, not the times) then the content of the graphs is still obviously wrong. #error
20211029 13:46:08 UTC file 20230118/NTRU (1).pptx:
20211104 file 20230105/AmazonCryptoCon-11042021.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of an external talk on 2021.11.04. Was the talk public? #weveshownallourwork
Covers NIST projects on post-quantum cryptography, lightweight cryptography, et al.
"NIST developed the first encryption standards in 1970s, Data Encryption Standard (DES)": Actually, DES was developed by IBM and NSA. #error
"Nearly all commercial laptops, cellphones, Internet routes, VPN servers, and ATMs use NIST Cryptography": This leads the reader to believe that nearly all usage of cryptography is using "NIST Cryptography". #error This was already false at the time of this talk: for example, most HTTPS connections had already switched from NIST P-256 to Curve25519. As for the label "NIST Cryptography", NIST P-256 was actually developed by NSA, AES was actually developed by Daemen and Rijmen, etc. #error
"Continue to enhance open and transparency"
"Historically, NIST has guided many transitions ... DES → Triple DES → AES ... SHA-1 → SHA-2 and SHA-3 ... 1024 bits → ≥ 2048 bits": In fact, NSA's secret policy regarding DES was as follows:
Narrowing the encryption problem to a single, influential algorithm might drive out competitors, and that would reduce the field that NSA had to be concerned about. Could a public encryption standard be made secure enough to protect against everything but a massive brute force attack, but weak enough to still permit an attack of some nature using very sophisticated (and expensive) techniques?
DES was successful in driving out competitors and in creating decades of delay before the world transitioned to stronger alternatives. NIST's SHA-1 standard (also designed by NSA) similarly slowed down upgrades to better hash functions. As for RSA, the main drivers of RSA size upgrades appear to have been
The most obvious obstacles in all of these transitions were NIST's low-security standards, giving companies an excuse to delay upgrades that security experts had for years been saying were necessary. It's astonishing to see NIST claiming that it "guided" these transitions.
20211109 file 20230105/Dillithium_Falcon-finalish.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Only for internal use": What happened to "open and transparent"? #weveshownallourwork
"Falcon is very complicated. Probably difficult to protect against side channels"
"The complexity is about how to make everything efficient"
"Other than that, this is basically NTRU. It lives and dies by the NTRU assumption."
Dilithium: "Looks less 'structured' to me."
"Practical parameter comparison": Various "Core-SVP" numbers, with the lowest, 120, marked in red.
20211112 file 20221014/PQC Seminar 11-12-21 (Classic McEliece).pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for public distribution." What happened to "open and transparent"? #weveshownallourwork
"Some options for us"
"Prove that the scheme is IND-CCA2 secure. The following paper finishes off the proof": No. That paper proves sqrt(eps)-tight QROM IND-CCA2 under certain assumptions, and this is better than previous results, but QROM IND-CCA2 is still a narrower class of attacks than IND-CCA2. #error
(The issue here isn't that there are other submissions with better proofs. There aren't. For most submissions, the proof picture is much worse. The issue here is NIST exaggerating what proofs say.)
"The authors imply that step 2 is made easier by the fact that their OW-CPA scheme is deterministic and has no decryption failures": Why is NIST talking about the "authors" here? The theorem statement requires knowing the advantage of an "FFC" adversary, which is 0 by definition when there are no decryption failures; requires knowing the non-"injectivity" probability, which is also 0 by definition when there are no decryption failures; and structurally requires a "dPKE", which is deterministic by definition. Four months before this talk, there was a paper giving counterexamples to the idea that such tight theorems can be proven for randomized PKEs. #scramble
20211112 file 20221107/PQC Seminar 11-12-21 (Classic McEliece).pdf:
Notes from djb, last edited 20221110 07:13:09 UTC:
Frivolously repeated copy of previously delivered document.
20211119 file 20221107/Frodo-final.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Why is it interesting? It's the most conservative lattice-based KEM."
Repeats the core of FrodoKEM's provable-security advertising, and categorically dismisses objections as "a lot of DJBFUD about the relevance of asymptotic security reductions to security". Meanwhile the same slide set admits that "not all of this applies for practically relevant parameters", which is exactly the central objection. #inconsistency
(FrodoKEM's claim of a "large" security margin was publicly smashed in 2022. The attack exploits one of the security gaps that had been hidden by the provable-security advertising. Incentives for this cryptanalysis would have been earlier and larger if NIST had been transparent about trusting the provable-security advertising. #weveshownallourwork At the time of this writing, the FrodoKEM team has not yet withdrawn its claim.)
Incorrectly claims "tight" implication from "FrodoPKE CPA (pseudorandom) in ideal cipher / QROM" to "FrodoKEM CCA2 in ROM". #error
Incorrectly describes the "plausible" column in Table 10 as being "based on 'known unknowns' discussion in Kyber round 3 spec". #error
Compares costs to some other candidates. Doesn't compare costs to application requirements. #ftqcic
20211119 11:28:25 -0500 file 20230118/SIKE-2021-November.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for distribution": What happened to "open and transparent"? #weveshownallourwork
"Running on ARM Cortex-M4 w/o assembly code is way too slow!": Way too slow for what? And why will the user care about non-assembly performance on Cortex-M4 if an assembly implementation is available? #missingclarity #ftqcic
"Security is not completely understood?"; "Torsion-point attacks on variants of SIKE: these seem both new and fundamental? ... Currently, these attacks don't affect SIKE. If they do in the future, there are plausible countermeasures: Costello (2021)"
For reference, Costello's statement was as follows: "It must also be stressed that if torsion point attacks are improved to the point where they do become relevant for SIKE, the protocol can be tweaked so the endomorphism ring of the starting curve is kept hidden to the adversary ... To my knowledge, none of the attacks in this line of work remain applicable if the endomorphism rings of both curves in the statement of the SSI problem are hidden."
20211202 file 20230206/Glombcom-12022021.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2021.12.02.
20211203 09:40:33 -0500 file 20230118/NTRUPrime-2021-November.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
In these notes, 99R refers to the 99-page risk analysis "Risks of lattice KEMs" from the NTRU Prime Risk-Management Team.
It appears that NIST's decisions regarding lattice KEMs did not account for the content of 99R. NIST's public report does not address the content of 99R. Instead the report uses marketing tricks to try to convince readers not to read 99R: "designers ... advocated ... subjective" etc.
Since 99R was filed in time for the deadline that NIST had set, NIST was obliged to take it into account. It appears that, internally, NIST delegated review of 99R to a single employee. This internal NIST presentation is most straightforwardly summarized as that employee providing other NIST employees excuses not to read 99R.
The presentation is structured primarily as screenshots with small amounts of added text, and could have been prepared in about 15 minutes of work. #scramble
"Not for distribution": What happened to "open and transparent"? #weveshownallourwork
"Some of these design choices can both help and hurt security...": Did NIST consider the evidence provided in 99R in favor of these design choices? If NIST believed it had evidence to the contrary, where was that evidence presented for public review? #needmorerecords
"Different ways to define and analyze the 'attack surface'": Where are the records of NIST's alternative analysis of the attack surface? How exactly does NIST's alternative "way" produce different results from 99R? Could it possibly be that NIST's alternative analysis doesn't exist? #needmorerecords
"Security reductions, security proofs": What the reader learns from this, in context, is that 99R isn't accounting for security reductions/proofs. But that's not true. The question of exactly what has been proven plays a major and explicit role in 99R. The risks analyzed in 99R come from aspects of security that have not been proven. #error
(Plus patent risks. Subsequent NIST actions perfectly illustrate how patents can create years of security damage. NIST could have announced in 2021 that it was taking NTRU as the patent-free option; instead NIST delayed and then selected Kyber, where NIST's patent license won't activate until 2024. The problem could be even worse: there are five further patent families that have been identified as potentially covering Kyber. #slowingdownpqcrypto)
"Taxonomies of possible attacks and counter-measures": Here NIST is suggesting an incompatibility between (1) accounting for proofs and (2) considering possible attacks and countermeasures. #error There is no incompatibility: 99R does both.
Under "NTRU Prime - Security", lists only "Big picture: Choice of the ring". #error In fact, the ring choice is only one of several ways that NTRU Prime reduces the attack surface.
(Imagine a system taking 7 unnecessary risks, each having probability 25% of disaster. The overall chance of disaster is 87%. Considering only one risk is botching the risk analysis.)
Says "Contrast with cyclotomic rings, which have more known attacks (but also easier to analyze)": What is the basis for this positive "easier to analyze" claim? Did NIST consider the evidence laid out in 99R (see Sections 1.2, 2.4, and 2.6) that cyclotomic rings are a security problem? #needmorerecords
Lists two papers specifically attacking cyclotomics. Are these supposed to be evidence of cyclotomics being "easier to analyze"? Does NIST think that papers attacking the RC4 cipher are evidence that RC4 is easy to analyze? #needmorerecords
Regarding 99R: "Some of these risks are larger than others". Where is the documentation of the weights that NIST is assigning to risks? Could it possibly be that this documentation doesn't exist? Did NIST read what 99R says about weights? #needmorerecords
"Some of these risks can be mitigated easily, some cannot": What exactly is NIST referring to here, and how is this supposed to be relevant to evaluating submissions? #needmorerecords
"This table does not include all possible risks to PQC": The 99R title is "Risks of lattice KEMs". Does NIST think something is missing within this scope? If so, where's NIST's explanation of what's supposedly missing? Where's NIST's risk analysis? #needmorerecords
"Originally claimed advantages in both security and performance": The word "originally" tells the reader that NTRU Prime has dropped claims of advantages. That's not true. #error How did NIST arrive at this misinformation? #needmorerecords
"But, had to add larger/slower parameter sets in rounds 2 and 3": This tells the reader that a weakness was discovered in NTRU Prime, forcing NTRU Prime to compensate by adding larger parameter sets (and dropping claims of performance advantages). This is also not true. #error The facts are as follows:
The only attack advances against NTRU Prime have been general advances also applicable to Kyber, SABER, NTRU, etc. (The opposite is not true: for example, the first version of the "Round5" submission was broken by a decryption-failure attack.)
NIST's first-round report (1) wrote that NTRU Prime "may wish to consider adding other parameter sets for other security levels" and (2) was obviously rewarding various submissions for providing a spectrum of options. NTRU Prime then added a selection of smaller and larger parameter sets, while continuing to recommend the original parameter set.
Kyber, SABER, and NTRU have always included proposals of bleeding-edge parameter sets: kyber512, saber512, and ntruhps2048509. Even after selecting a smaller parameter set, NTRU Prime has never cut things so close. The smallest selected NTRU Prime parameter sets, sntrup653 and ntrulpr653, have a larger security margin than kyber512, saber512, and ntruhps2048509.
NIST complained at the time about NTRU Prime using a security metric that assigned higher security levels than the "Core-SVP" metric. (Core-SVP was introduced in New Hope and copied into various other submissions.) Why, then, did NIST not complain about Kyber switching in 2020 to a new security metric that assigned higher security levels than the "Core-SVP" metric? And why did NIST in 2022 start trying to add memory costs into the Kyber security level? #inconsistency
"Recent arguments in favor of NTRU Prime put more emphasis on security": This again tells the reader that NTRU Prime has dropped claims of performance advantages. This again is not true. #error The facts are as follows:
The original 2016 NTRU Prime paper made clear that the goal was to reduce attack surface, and then reported that this had surprisingly low cost: "To summarize, our security recommendations do not create a large speed penalty."
The 2017 version of the paper even put this into the title: "NTRU Prime: reducing attack surface at low cost".
The NTRU Prime submission was also completely clear about this: "The point of this submission is that the attack surface in lattice-based cryptography can be significantly reduced with only a minor loss of efficiency."
"Estimates of security strength have changed quite a bit, see table": The reader understands this as saying that the submission failed to account for attacks. That's not true. #error
NIST left giant ambiguities in its pseudo-definitions of security "categories". NIST then weaponized those ambiguities to punish some submissions and reward others. NTRU Prime took the safe response of downgrading its "category" assignments; that's what this NIST "table" shows. NIST then pretended that this was a security failure in the submission.
Given that NIST in 2016 officially asked submitters to provide "preliminary" assignments of parameters to "categories", and stated "We’re not going to kick out a scheme just because they set their parameters wrong", why was NIST writing a secret document five years later complaining about NTRU Prime's original assignments of parameters to "categories"? This is a glaring violation of NIST's announced procedures. #inconsistency
The original NTRU Prime parameter selection was explicitly designed for "more than 2128 post-quantum security" and considered the costs of memory in the attack analysis. The actual technical content of NIST's complaint is that these NTRU Prime parameters aren't as hard to break as AES-256 according to a pre-quantum metric that ignores the costs of memory, namely pre-quantum Core-SVP. For comparison, if Kyber-512, Kyber-768, and Kyber-1024 are measured the same way, then they fail to meet their currently claimed security targets. NIST doesn't complain about this; instead it continues changing its "category" boundaries to rescue Kyber. #inconsistency
"Why? Mistakes, confusion about NIST security categories, recent research progress": If NIST thought there was a "mistake" in the NTRU Prime submission, where did they publicly report the details and request a response from the NTRU Prime team? As for "confusion", NIST should take responsibility for its own failure to issue clear definitions. As for "recent research progress", is this referring to something other than attack advances that are
also applicable to Kyber, and
more dangerous for Kyber because Kyber has a smaller security margin?
#inconsistency
"We should probably do a more detailed comparison of security/performance with NTRU, Kyber, Saber...": Here the slides hide the fact that 99R includes a series of easy-to-use security-performance graphs comparing NTRU Prime, NTRU, Kyber, and SABER in various scenarios.
(Section 6 of 99R begins by explaining why a thorough risk analysis has to consider performance. For anyone who reads through 99R, the security-performance graphs are impossible to miss.)
Why is NIST suppressing a comparison that it says is important? Could this have something to do with those graphs making it easy to see that other candidates are competitive with Kyber, often even outperforming Kyber? #inconsistency
"The case for NTRU Prime is based on security, not performance": In context, this again tells the reader that NTRU Prime has dropped performance arguments. That's again not true. #error
"Most of the evidence is negative (i.e., against Kyber and Saber, rather than for NTRU Prime)": This is a puzzling comment. When the topic is a risk analysis identifying ways that X is riskier than Y, how does NIST imagine that being "against" X is different from being "for" Y? #missingclarity
"If we standardize Kyber or Saber, we should address these criticisms in our report": This would have required understanding and responding to the content of 99R. Even better would have been to first understand the risks and then make a decision. #scramble
Regarding 99R giving a "simple example where NTRU Prime has the best performance": "Small differences (but can be important?)". Here NIST suppresses the text from 99R right before the example:
NTRU Prime reduces the attack surface at surprisingly low cost. Sometimes NTRU Prime outperforms all of the other submissions.
99R clearly states what's important: NTRU Prime's security features are affordable. Instead of recognizing this, NIST falsely portrays NTRU Prime as claiming important performance wins. #error
Regarding one of NTRU Prime's parameter-selection examples, "fitting a client's public key into a single Internet packet": "Question: How important is this?" Again NIST falsely portrays NTRU Prime as claiming important performance wins. #error Again NIST suppresses the NTRU Prime text explaining the actual goal, namely reducing security risks:
Our general strategy for evaluating and selecting parameter sets is as follows: ... This type of limitation was already used in ... and provides a principled way to reduce concerns about an attacker potentially choosing parameters from a large set to target a secret weakness.
"NTRU Prime - Implementations": Screenshot from NTRU Prime's software overview. Followup slides are screenshots from a related software-verification talk and the NTRU Prime software-speed page.
NIST includes an arrow highlighting the keygen column in the NTRU Prime software-speed page. This highlighting has three problems:
NIST is suppressing the sntrup keygen speedups (around 5x faster) from the OpenSSLNTRU paper.
The NTRU Prime software-speed page highlighted those speedups at the top in boldface: "2020.04 news ... 166000 Haswell cycles to generate a new sntrup761 public key for each TLS 1.3 session."
NIST scrolled down, hiding this news, before taking a screenshot of the page. #error
Under the official evaluation criteria, keygen time should have been given lower weight than enc time and dec time, whereas NIST's highlighting ends up giving it higher weight. #inconsistency
All available evidence says that the dominant cost in these lattice systems is communication, not computation. 99R covers this in detail. Highlighting the computation costs, without putting them into perspective as being minor next to the communication costs, is deceiving the reader. #ftqcic
The next slide says "Strategies to improve performance: FPGAs, batch key generation". Very few readers will understand this as saying "The previous slide was lying to you".
"NTRU Prime - 'Official Comments'": List obviously designed to avoid addressing content.
The rest of the talk, slightly over half of the talk slides, is on S-unit attacks. Like the rest of the talk, this is structured primarily as screenshots, with a few added notes from NIST.
"Folklore?": No. S-unit attacks were introduced in a public "S-unit attacks" posting that NIST is not properly crediting. #ethics
"Rigorous analysis by Pellet-Mary et al": No, PHS19 isn't rigorous. PHS19 assumes a large pile of heuristics, and the lower-bound claims in PHS19 are simply wrong (even provably wrong in many cases). #error
"Improved by Bernard and Roux-Langlois": It's true that BR20 states a better algorithm than PHS19, but it's not true that this algorithm originated with BR20. #ethics
"Dan Bernstein (2021): Conjecture ...": NIST's choice of attribution here is in violation of scientific ethics rules. The talk that NIST is citing began by stating that it included joint work and telling readers to see the forthcoming paper for credits. (This turned into an ongoing series of papers, some of which are online.) #ethics
"Limited evidence for this conjecture": Limited compared to what? Many statements that have been uncritically repeated by NIST are, in fact, conjectures with far less evidence than this one. #inconsistency
"Hard to see asymptotic scaling from numerics": Here NIST is telling the reader that the conjecture is an extrapolation from small examples. #error This is not true; how did NIST arrive at this misinformation? #needmorerecords The conjecture comes from an asymptotic analysis of a model of the computation; numerical examples are used to test the accuracy of the model and the analysis.
"Preprint ... claims that the analysis by [PHS19], applying the Gaussian heuristic to the log-unit lattice, is not accurate": The paper in question, BL21, includes eight case studies of the Gaussian heuristic failing. Two of the case studies rely on a standard number-theoretic conjecture backed by extensive evidence; aside from this, the paper does not rely on any conjectures or heuristics. Seven of the case studies are analyses for arbitrary sizes, tested by extensive numerical double-checks; only one of the case studies relies directly on computations. The paper includes a particularly simple debunking of the PHS19 analysis, not relying on the conjecture and not relying on the computations. Why does NIST describe the untested heuristic analysis of PHS19 as "rigorous", while describing BL21's bulletproof debunking of that analysis as a "claim"? #error
"Also thinks the [BR20] algorithm is better than [PHS19]; thinks they should have cited him": Yes, the 2019 and 2020 papers on S-unit attacks were both ethically obliged to give proper credit to the 2016 posting that introduced S-unit attacks. Also, the "main contribution" claimed in the 2020 paper was already in the 2016 posting.
"[PHS19] version of the log-S-unit lattice": No, this lattice is much older than PHS19. #ethics #scramble
"[BR20] and [BL21] versions of the log map": No, this map is much older than BR20 and BL21. #ethics #scramble
"Note: #(R/P) = infinity? Should be the algebraic norm N(P)?": This is next to a screenshot from Section 5 of BL21. That section defines n as a power of 2, and P as a nonzero prime ideal of the ring R = Z[x]/(xn+1). R/P is the quotient ring, a finite field, so its cardinality #(R/P) is a power of a prime; NIST is wrong in suggesting that #(R/P) is infinite. #error Furthermore, this cardinality is exactly the norm of P; NIST is wrong in suggesting that replacing #(R/P) with the norm would make a difference. #error
For a number theorist, this is really basic material, and it is astounding to see the comment "Note: #(R/P) = infinity? Should be the algebraic norm N(P)?" from NIST's designated S-unit-attack reviewer. #scramble
Continuing through the NIST slides: Various screenshots from BR20 and DPW19; on the side, NIST asking some basic questions without displaying any understanding of what the literature says about those questions. #scramble
"[PHS19] wanted to show an upper bound" (underline rather than italics in original): This deceives the reader into believing that PHS19 didn't claim lower bounds. #error The facts are as follows:
PHS19 treated its analysis as the actual algorithm cost, meaning an upper bound on cost and a lower bound on cost. Examples of quotes from PHS19 that are visibly claiming lower bounds: "the time/quality trade-offs obtained by our algorithm are worse than the ones obtained using Schnorr's hierarchy of algorithms" in various scenarios (because of main-computation time); "the concrete impact is limited" (because of precomputation time).
In August 2021, a few days after a talk explained better-optimized S-unit attacks, Ducas and Pellet-Mary repeated the PHS19 lower-bound argument to claim that the success probability of these S-unit attacks would be "*ridiculously* small".
On this basis, NIST leapt into action four days later to publicly dismiss the same optimized S-unit attacks. #error
However, the PHS19/Ducas–Pellet-Mary lower-bound argument started from an untested guess that S-unit lattices behave like random lattices. BL21 then appeared, debunking this guess.
(The talk had already briefly summarized the BL21 results, saying that S-unit lattices have special analytic features. Perhaps Ducas and Pellet-Mary missed this comment, or perhaps they missed its importance.)
NIST never admitted its error. Internally, it switched to the irrelevant point that the PHS19 analysis seems okay as an upper bound.
More broadly, R99 includes a review of a long series of claims of barriers for unit attacks and S-unit attacks, with one barrier after another broken.
NIST next gives four slides with screenshots from BL21, saying "Question: Do any of the examples in [BL21] disprove any of the assumptions made in [PHS19]?" #scramble
The correct answer is yes. In particular, Section 7 of BL21 highlights the following direct contradiction:
An S-unit attack with database size #S1+o(1) has success probability converging to 1 as S increases.
The PHS19 analysis says, incorrectly, that the success probability converges to 0.
The source of this PHS19 error, in short, is that PHS19 applied a previous heuristic analysis that was explicitly for random lattices, without ever checking for the possibility of S-unit lattices being better than random lattices. In other words, PHS19 was assuming that S-unit lattices were no better than random lattices; this assumption is disproven by BL21.
"Take-away message: we are starting to understand these attacks?": Taken literally, "we are starting to understand" has remarkably little content. More interesting is the marketing choice of saying "we are starting to understand" rather than "we don't completely understand". Why is NIST downplaying security risks? What role did this "take-away message" end up playing in NIST's decisions? #needmorerecords
20211210 file 20230105/Improving_Support_Minors_rank_attacks__applications_to_and_Rainbow.pdf:
20211213 21:23:04 UTC file 20230105/GeMSS and Rainbow.pptx:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Not for Distribution": What happened to "open and transparent"? #weveshownallourwork
"GeMSS (Alternate) is extremely broken"
"Rainbow (Finalist) is slightly broken"
"Nonetheless, it’s worrying that a novel and relatively simple attack was found this late in the process"
"Ongoing analysis suggests that a proper accounting of memory costs likely increases the complexity of both the old and new attacks, but not enough for Rainbow’s parameter sets to meet security targets": For comparison, has NIST required Kyber to use the same "proper accounting" in claiming security from memory costs? #inconsistency
This question became particularly important in 2022 when advances in lattice attacks pushed Kyber-512's security level below its AES-128 security target, according to the best available bit-operation estimates. Alleged memory costs are now the reason that Kyber-512 claims to meet its security goal. Similar comments apply to Kyber-768 and Kyber-1024.
"But Memory! Questionable assumptions": For comparison, has NIST been criticizing the "questionable assumptions" that Kyber-512, Kyber-768, and Kyber-1024 are making in claiming to meet their security targets because of memory? #inconsistency
Specific issues that NIST raises regarding the "assumptions":
Probably should assume "Some use of 3rd dimension": In fact, the chips used to calculate the relevant estimates make some use of the 3rd dimension (contrary to NIST claiming that the estimates assume "strictly" 2-dimensional memory), but limit this to a few layers to avoid running into problems with energy input and energy output. #error
"Lower fiber optic communication costs (when memories are in petabyte range or bigger)": Fiber optics don't magically avoid the basic problem of costs increasing with distance. Fiber optics appear to be a step backwards from state-of-the-art circuit designs for the algorithmic tasks at hand, such as sorting large volumes of data. #error
"Flash/HDD densities (when latency doesn’t matter, or for exascale+ memories)": Flash is definitely a step backwards for the algorithmic tasks at hand. The only reason flash can use many layers without catching on fire is that very little of the data is being used at any moment. Similar comments apply to hard drives. #error
"The flurry of attacks in the 2nd/3rd round may bring the maturity of Rainbow into question": And it doesn't bring NIST's evaluation process into question? It's not as if Rainbow is the only example of NIST advancing submissions that turned out to have security problems. #inconsistency
"Options: Let's Discuss": "Standardize Rainbow Now!" or "Make Rainbow an Alternate" or "Pre-admit Rainbow to OnRamp" or "remove current submission from consideration"
20211213 21:24:47 UTC file 20230118/RainbowEndRound3.pptx:
Notes from djb, last edited 20230125 23:38:54 UTC:
Not byte-for-byte identical to "GeMSS and Rainbow.pptx", but no evident differences.
20220310 10:19:50 -0500 file 20220914/pkc2022-march2022-moody.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
"Our role: managing a process of achieving community consensus in a transparent and timely manner." (Page 10, boldface in original.) #claimingtransparency
Second picture on page 17 was copied from the artists without credit. #ethics
"Serves as a reminder to not put candidates into products until the standard is done." (Page 20, regarding Rainbow attack.) Starting in mid-2021, there was a striking volume of comments of this type from NIST, NSA, and DHS, telling users to not even try to protect themselves against the threat of quantum computers. #slowingdownpqcrypto
Page 23 contains performance graphs in which NTRU's smallest parameters outperform Kyber. For comparison, NIST's final round-3 report suppressed NTRU's smallest parameters (see, e.g., Figure 2 in that report) by setting inconsistent rules for NTRU and Kyber: allowing Kyber to count the attacker's memory costs (page 28), and not allowing NTRU to count the attacker's memory costs (page 39). #inconsistency
"The 3rd Round will end any day now!" (Page 26, red emphasis in original.) This was in March 2022. NIST actually ended the 3rd round in July 2022. #inconsistency
"Feedback received will be made public". (Page 27.) What about feedback received earlier in the process, for example from NSA? #inconsistency
20220415 file 20230118/Economist-04152022-Note.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a short talk. Was this talk public? #weveshownallourwork
20220418 file 20230206/NICE-04-18-2022 A.pdf:
Notes from djb, last edited 20230218 16:05:00 UTC:
Slides of an external talk on 2022.04.18.
20220624 16:29:20 UTC file 20220901/4th_NIST_PQC_Workshop_Call.docx:
20220823 19:01:00 UTC file 20221014/LEDAcrypt_KAT.zip:
20220823 19:01:00 UTC file 20221014/LEDAcrypt_NOKATS.zip:
20220823 19:01:00 UTC file 20221014/NTRU.zip:
20220823 19:01:00 UTC file 20221014/ntruprime-20190330.zip:
20220823 19:02:00 UTC file 20221014/NTSKEM_KAT.zip:
20220823 19:02:00 UTC file 20221014/nts_kem_12_64_KAT.zip:
20220823 19:02:00 UTC file 20221014/nts_kem_13_136_KAT.zip:
20220823 19:02:00 UTC file 20221014/nts_kem_13_80_KAT.zip:
20220823 19:04:00 UTC file 20221014/NTSKEM_noKATS.zip:
20220823 19:04:00 UTC file 20221014/Picnic_KAT.zip:
20220823 19:04:00 UTC file 20221014/Picnic_NOKATS.zip:
20220823 19:04:00 UTC file 20221014/RainbowKAT_IIIc_Classic.zip:
20220823 19:04:00 UTC file 20221014/RainbowKAT_IIIc_CompressedCyclic.zip:
20220823 19:04:00 UTC file 20221014/RainbowKAT_IIIc_Cyclic.zip:
20220823 19:04:00 UTC file 20221014/RainbowKAT_Ia_Classic.zip:
20220823 19:04:00 UTC file 20221014/RainbowKAT_Ia_CompressedCyclic.zip:
20220823 19:04:00 UTC file 20221014/RainbowKAT_Ia_Cyclic.zip:
20220823 19:04:00 UTC file 20221014/RainbowKAT_Vc_Classic.zip:
20220823 19:04:00 UTC file 20221014/qTESLA.zip:
20220823 19:05:00 UTC file 20221014/RainbowKAT_Vc_CompressedCyclic.zip:
20220823 19:05:00 UTC file 20221014/RainbowKAT_Vc_Cyclic.zip:
20220823 19:05:00 UTC file 20221014/RainbowTESTED04052019.zip:
20220823 19:05:00 UTC file 20221014/Round5_submission(oscar.garcia-morchon@philips.com).zip:
20220823 19:05:00 UTC file 20221014/ThreeBears.zip:
20220823 19:17:00 UTC file 20221014/CRYSTALS_Dilithium.zip:
20220823 19:17:00 UTC file 20221014/FrodoKEM-20190331.zip:
20220823 19:17:00 UTC file 20221014/classicmceliece_KAT.zip:
20220907 21:42:21 -0400 file 20230206/Feasibility and Infeasibility0407.pdf:
Notes from djb, last edited 20230625 17:50:02 UTC:
Slides of a talk. Was this talk public? #weveshownallourwork
"To make the PKC system secure, worst case to average case reduction is needed"
#error The available evidence says that the existence of worst-case-to-average-case reductions is negatively correlated with security. Maybe it does not exclude security, but it is unnecessary and insufficient.
NTRU "is not provably secure" whereas its "provably secure version is less efficient": No, the variants of NTRU hyped as "provably secure" have not been proven to be secure. If NIST is fooled by hype from academics, what chance does it have to resist attack by NSA? #error
20220907 21:48:32 -0400 file 20230206/Matt-RSA-2019 (1).pdf:
20221014 13:48:47 UTC file 20230105/KSN comparison.xlsx:
Notes from djb, last edited 20230126 20:17:09 UTC:
Spreadsheet with various performance numbers copied from SUPERCOP and pqm4, plus a column from NIST tallying keygen+enc+dec+1000*(pk+ct).
This file's modification date says that the file was edited in October 2022. That's after NIST was sued. The same comment applies to various PDF files.
20230111 07:30:01 -0500 file 20230727/API for post-quantum.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 07:30:16 -0500 file 20230727/April 12th brief.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 07:35:54 -0500 file 20230727/Comments NISTIR 8105.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 07:45:11 -0500 file 20230727/Crypto Club Talk Combined Slides.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 07:55:11 -0500 file 20230727/Do you know this guy_.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 08:52:52 -0500 file 20230727/Re_ FW_ new NISTIR for post-quantum cryptography.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 08:57:15 -0500 file 20230727/Hash based signatures.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:02:15 -0500 file 20230619/Improved Timing and Cyber.pdf:
Notes from djb, last edited 20230622 22:46:00 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:07:23 -0500 file 20230727/IPR for PQCrypto Call for Proposals.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:15:25 -0500 file 20230727/NIST PQC Workshop - Email Listserve Information.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:15:39 -0500 file 20230727/RE_ NISTIR # request.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:21:49 -0500 file 20230727/RE_ PQC forum.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:24:31 -0500 file 20230727/RE_ pqc notes.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:26:55 -0500 file 20230727/pqc workshop in 2018.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:28:10 -0500 file 20230727/RE_ pqcrypto video recording.pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230111 09:43:37 -0500 file 20230727/shall it be an FRN - call for PQC proposals_ .pdf:
Notes from djb, last edited 20230727 19:57:07 UTC:
This is a "portfolio" of documents created by NIST during FOIA processing; it is not an original document.
20230216 15:19:00 UTC file 20230619/Improved Timing and Cyber.pdf-protected:
20230323 18:28:00 UTC file 20230915/Quantum talking points.docx:
20230608 16:16:42 UTC file 20230508/OutlookEmoji-_amp;#X1f60a.png:
20230622 19:54:17 UTC file 20230619/CNSA-Suite-and-Quantum-Computing-FAQ.pdf-protected:
20230622 19:54:17 UTC file 20230619/quantumisogenies.tex:
20230814 08:17:36 UTC file 20230816/Fw_ Received Comments 9_1-18-5.pdf-attachment-com9_1-18.zip:
20230815 06:42:46 UTC file 20230816/PQC comments-2_with_Comments.pdf-attachment-Comments9-1-18.zip:
20230815 10:15:28 UTC file 20230816/Received Comments 9_1-18-6-1.pdf-attachment-com9_1-18.zip:
20230912 08:04:38 UTC file 20230915/Re_ ACMD SEMINAR SERIES_1.pdf-attachment-image001.png:
20230912 08:04:38 UTC file 20230915/Re_ ACMD SEMINAR SERIES_1.pdf-attachment-image002.png:
20230912 08:04:58 UTC file 20230915/FW_ ACMD SEMINAR SERIES_2.pdf-attachment-image003.png:
20230912 08:04:58 UTC file 20230915/FW_ ACMD SEMINAR SERIES_2.pdf-attachment-image004.png:
