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 20240412, plus notes last edited 20240420 20:41: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.
Number of occurrences of tags: 109 #weveshownallourwork. 96 #inconsistency. 93 #error. 62 #needmorerecords. 37 #ftqcic. 36 #scramble. 36 #nsa. 28 #missingclarity. 18 #claimingtransparency. 12 #slowingdownpqcrypto. 9 #ethics.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.
20120620 08:29:33 -0400 file 20240215/Today's PQC meeting summary _ assignments_2.pdf-attachment-SHA3-FR_Notice_Nov07.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
SHA-3 call from Federal Register.
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
2016 file 20231013/IAC2PCABCSMMES5.docx:
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
20160122 08:39:00 UTC file 20231110/FW_ Our Feb 2nd PQC meeting with Michael Groves.pdf-attachment-QSC(16)004006_Quantum_Safe_Primitives.docx:
Notes from djb, last edited 20231110 16:46:46 UTC:
Draft of an ETSI document. ETSI's public version of the document doesn't say it's from GCHQ, NSA's UK partner.
#nsa
Many errors (e.g., "Cryptographic schemes based on LWE or SIS typically have worst-case to average-case reductions") and inconsistencies (e.g., mentions that there have been small improvements in McEliece attacks, while not mentioning that there have been much larger improvements in lattice attacks).
What influence did this document have on NISTPQC? #needmorerecords
20160122 08:40:00 UTC file 20231110/FW_ Our Feb 2nd PQC meeting with Michael Groves.pdf-attachment-QSC(15)004004 (March16)_WI3_Suitability.docx:
Notes from djb, last edited 20231110 16:46:46 UTC:
#nsa
Performance hype, anti-hybrid hype, etc.: e.g., "Hybrid key exchanges are not always allowed by network protocols (e.g. IKE) or they may not fit into the bandwidth currently allocated for handshakes [10]."
What influence did this document have on NISTPQC? #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 file 20230925/FW_ NIST Correspondence 16-0000011-N_2.pdf-attachment-2016_02_01_16_06_18.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Final (?) version of letter from ISPAB chair to Willie E. May and Shaun Donovan.
20160127 01:20:00 file 20231110/FW_ Our Feb 2nd PQC meeting with Michael Groves.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Reminder about upcoming meeting with "Michael Groves, from the UK".
"Note, these documents are for internal use only - not to be shared" #weveshownallourwork
Quotes Groves referring to "your immediate NIST (and IAD) colleagues". IAD is part of NSA; obviously Groves knew NIST was working with NSA on post-quantum cryptography, even though the public didn't know this. Groves is from GCHQ, NSA's UK partner.
#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 file 20240124/PQC slides from various talks the past year_1.pdf-attachment-Ray Code Based Crypto.ppt:
Notes from djb, last edited 20240225 11:49:06 UTC:
Slides.
20160129 01:11:00 UTC file 20230508/PQC NISTIR v3 Ray and Stephen Comments.docx:
20160129 05:56:18 file 20231013/Talk slides.pdf:
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 16:03:20 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-Ray Hash-Based Signatures.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Should compare to separate "Hash-Based Signatures.pptx".
20160129 17:53:42 -0500 file 20231013/Talk slides.pdf-attachment-Maryland 1-27-16.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
On a slide titled "The need for provable randomness", says "Heninger et al. (2012) broke the keys of a large number of SSH hosts".
Criticizes the security of normal RNGs for not being proven; asks whether one can "create a source of provable random numbers (with minimal assumptions)"; portrays quantum devices as solving this problem. Doesn't cite any of the demonstrated security failures in quantum devices.
In fact, the 2012 paper tracked down the vulnerabilities to "specific software behaviors" including "a boot-time entropy hole in the Linux random number generator". This has nothing to do with the security risks arising from unprovability of RNGs.
#error
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 01:57:01 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-Steven - Quantum Computing.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Should compare to "Quantum Computers...When?" in 20160203 slides.
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:
20160201 02:32:36 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-ykliu-pqc-crypto-club-2016.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Should compare to "ykliu-pqc-crypto-club-2016.pdf".
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:35:04 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-Dustin conclusion.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Looks like part of 20160203 slides.
20160202 14:37:13 -0500 file 20240124/PQC slides from various talks the past year_1.pdf-attachment-PQC Crypto Club Talk.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Looks like copy of ykliu-pqc-crypto-club-2016.pdf.
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!"
20160202 19:11:35 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-rene - pqc slides.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Should compare to "Outliers" in 20160203 slides.
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:01:48 file 20230925/FW_ NIST Correspondence 16-0000011-N_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"Our Advisory Committee weighs in on our need to work on quantum. Nice item to keep in our pocket and use as we may."
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:29:00 file 20230925/RE_ NIST Correspondence 16-0000011-N_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"Great, indeed!"
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 08:17:48 -0500 file 20240215/RE_ Vulnerabilities of _McEliece in the World o..._1.pdf-attachment-escher11.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft (?) of public paper.
20160301 08:22:00 file 20240215/RE_ Vulnerabilities of _McEliece in the World o..._1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing mandatory disclaimers for NIST papers.
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
20160303 01:21:06 file 20240124/RE_ PQC forum(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Drafting text for web pages.
20160303 03:43:02 file 20240124/RE_ PQC forum_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing web pages.
20160303 07:18:12 file 20240215/The PQC ir_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"Can u please email a link to the pqc IR to Paul kocher. Also if there are any instructions on how to format comments. Had a good meet with him and he had some good ideas"
What happened at this meeting? #needmorerecords
20160307 12:08:07 file 20240215/Re_ next pqc meeting_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Moody: "Yi-Kai, I scheduled our next PQC meeting for Tuesday the 8th. Hope that is fine. Ray and I (and maybe Daniel) can report on PQCrypto. Can you be ready to help us know what the next steps we need to take on the evaluation criteria are?"
20160308 12:15:00 file 20231219/FIPS 186 notes_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
"I was cleaning out some papers in my office, and I found some papers/notebooks that I think might be yours? Back when we were dealing with the VCAT, I was asked to give a presentation on the history of FIPS 186. I think you gave me some meeting notes from the NIST/NSA TWG meetings that dealt with that. Do you want them back?"
#nsa
The phrase "dealing with the VCAT" sheds a bit of light on NIST's mindset.
20160309 08:10:00 file 20240215/RE_ My Notes from PQCrypto 2016_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
More discussion of PQCrypto 2016 notes.
"We will follow up with a meeting with CAVP/CMVP about how to handle hybrid. I will reach to them." What happened at this meeting? #needmorerecords
Moody: "Everyone, Here’s a quick typed up version of my notes from PQCrypto 2016. The talk summaries probably won’t help you much. I end with the questions people asked me about our quasi-competition."
20160309 08:33:00 file 20240215/RE_ PQC NISTIR Comments_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing review of public comments on NIST IR 8105.
"You can pick any one. Remember, we need on Division reader who should be in the division. Another is WERB reader, we can ask an external. A NSA guy will work."
#nsa
20160309 10:00:07 file 20231219/Links to the docs we discussed_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Sending some public NIST reports to James Schufreider, NIST's Director of Congressional and Legislative Affairs. Apparently this was after a meeting; what happened in the meeting? #needmorerecords
20160310 02:41:28 file 20240215/Re_ Public key hybrid encryption and signature ..._1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"How much would protocols designers/implementers/users (especially the users and implementers) use the post-quantum algorithms that way knowing that they'll pay some performance cost (could be heavy performance cost) (and IPR fee(s) in some cases) and do not know which one(s) will be adopted by standard bodies such as NIST and/or the IETF (adopted by a standard body implies some level of confidence in the security of the adopted scheme(s)) ?"
"Would we like to be in a world where different post-quantum algorithms are supported in different protocols when we decide what algorithm(s) to standardize?"
"Standardized algorithms bring significant interoperability, efficiency and security for the internet. So, I am not sure if all kinds of algorithms being supported or/and used is the best that we are looking for."
20160310 03:28:51 file 20240215/Re_ status_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Moody: "I talked more with Andy, and he really thinks we need to have our draft by April, as we’ll have to run it by the lawyers. Have you thought about assignments? Daniel will be here next week, so we could really focus and work on the technical parts. Tuesday afternoon we will likely have a meeting with some visitors (Jintai and Tsuyoshi), but we could have another meeting to work on the evaluation criteria. What do you think?"
20160310 10:46:21 -0500 file 20231219/[Ispab] NIST response to ISPAB recommendation on Quantum Computing.pdf-attachment-0906_001.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Letter from NIST director to ISPAB.
"In 2015, CSD decided to embark on a standardization plan for post quantum computing (PQC)"
"I'm interested in hearing the Board's opinion on whether NIST has made the necessary investments in human capital in order to execute on the PQC plan"
20160310 11:35:07 file 20231219/[Ispab] NIST response to ISPAB recommendation on Quantum Computing.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
"response from NIST to ISPAB’s recommendation on quantum computing"
20160310 18:49:00 UTC file 20231219/FW_ IPR for PQC Call For Submissions_1.pdf-attachment-CFP v1 RayIPRComments.docx:
Notes from djb, last edited 20240112 23:05:08 UTC:
Early draft of the call for submissions, still using NSA's "quantum-resistant" terminology. Visibly copying and pasting from SHA-3 text.
"NIST envisions a five-year process starting soon and ending with a NIST proposal of a standard for quantum-resistant cryptographic algorithms. We believe the transition to the new algorithms must start soon after this five-year period.": Why not try rolling something out immediately, given that user data is already exposed? #slowingdownpqcrypto
"a preliminary security analysis (including any security reduction proofs or intractability argument from complexity theory?)" #scramble
"a precise security claim against quantum computation": It's interesting to note that this version of the call kept its eye on the ball. Later versions added the distraction of pre-quantum security analyses. How did that change happen? #needmorerecords
"quantum-resistant algorithm search process" with comment from Dustin Moody saying "Any thoughts on a better name?"
"NIST will form an internal selection panel composed of NIST employees to analyze the candidate algorithms. All of NIST’s analysis results will be made publicly available."
20160314 04:14:01 file 20231219/FW_ hybrid mode - ICMC16_1_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Redacts an email address of a recipient. #needmorerecords
20160314 09:15:17 file 20240215/Re_ pqc meetings_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussion of when to meet between 14 and 18 March 2016.
20160314 10:24:36 file 20231219/FW_ IPR for PQC Call For Submissions_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Editing IPR statement.
20160317 02:28:58 file 20240215/Today's PQC meeting summary _ assignments_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Summary of meeting on 17 March 2016.
20160317 02:52:24 file 20240215/RE_ Today's PQC meeting summary _ assignments_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Quoted message shows who did what, starting from the SHA-3 call for proposals.
"Yi-Kai: Re-write section 1: Background"
"Ray: Draft section 4: Evaluation Criteria"
"Dustin: Continue working on 2.D: IPR. Write section 5: Candidate Evaluation Process. Every other section not assigned (which are pretty much done)"
"Daniel: Add more detail to section 2.B.1: Algorithm Specification. Revise section 3: Minimum Acceptability Requirements (not much needed). Revise section 6: Miscellaneous."
"Larry: Add more to section 2.B.2, and 2.C (like 2.C.1, 2.C.2, 2.C.3) as you deem fit. More details about the API."
20160317 16:18:00 UTC file 20240215/Today's PQC meeting summary _ assignments_2.pdf-attachment-CFP outline 2016 march.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Outline of planned call for proposals, and assignments of who will write what.
"1st draft by next Thursday 3/24/16"
"Background -> Yi-Kai"
. "Define: encryption, signatures"
. "Need for PQC"
. "Impact on standards, timeline"
. . "Migration – e.g., hybrid modes are automatically compliant"
. . "Will work with industry and other standards organizations (e.g., stateful hash-based signatures)"
. . "New NIST standards for public key encryption and signatures"
. . "“Pre-quantum” standards are likely to be deprecated"
. "Desirable features"
. . "Drop-in replacement in existing applications, as much as possible"
. . "Secure against classical and quantum computers"
. "“Standardization process”"
. . "Not competition"
"Requirements for candidate algorithm submission packages -> Daniel"
. "Due Nov. 2017"
. "2.B Algorithm specification"
. . "Can call approved primitives, should implement padding, etc., in order to achieve security"
. . "Want weakened versions for cryptanalysis"
. . "Replacing Diffie-Hellman key exchange with key transport"
. . "See Dustin’s draft CFP"
. "2.D Intellectual property -> Dustin"
. "Crypto API -> Dustin"
"Minimum acceptability requirements -> Daniel"
. "See Dustin’s draft CFP"
. "Meet minimum security levels"
"Evaluation criteria (see our old list of topics) -> Ray"
. "4.A. Security"
. . "i. Applications: TLS, IKE (need drop-in replacement for SP800-56A,B, FIPS 186) (use key transport) (code signing)"
. . "ii. Security definitions: IND-CCA, EUF-CMA"
. . . "Perfect forward secrecy? – security can be impacted by performance"
. . . "Crude definitions of number of bits of quantum security?"
. . "iii. Resistance to known attacks"
. . . "Best known attacks"
. . . "Multi-key attacks"
. . . "Side-channel resistance (performance can be affected by security)"
. . "iv. Other factors"
. . . "How well-understood is the cryptosystem?"
. . . . "Security proofs are nice, but not required"
. . . . "How much cryptanalysis has been done?"
. . . . "Want connection to existing literature"
. . . . "Excessive modifications of submissions will be a factor"
"4.B Cost"
. "Computational efficiency"
"Key sizes"
"4.C Implementation characteristics"
. "Ease of implementation and management: idiot-proof"
"Evaluation process -> Dustin"
. "Workshop – March 2018"
. "12-18 month cycle: Submission -> Workshop -> Analysis -> Report"
. "Goal: 3-5 years of evaluation, then 1-2 years to develop standard"
. "Open-ended process, no fixed timeline"
"Miscellaneous -> Daniel"
. "Don’t submit hybrid modes"
. "Don’t invent a new block cipher"
. "Quantum security models"
. "Encourage mergers of similar submissions"
20160317 18:05:00 UTC file 20240215/Today's PQC meeting summary _ assignments_2.pdf-attachment-CFP v2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
20160317 18:51:00 UTC file 20240215/RE_ Today's PQC meeting summary _ assignments_1.pdf-attachment-CFP v2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
20160322 03:06:46 file 20240124/RE_ My write-up in the PQC call(4)_7.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Editing call for proposals.
20160322 08:51:45 file 20231219/Re_ Phone conversation with IETF(1)_2.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
What happened in this "phone conversation with IETF"? #needmorerecords
NSA asks "every week if we have a meeting" #nsa
20160322 11:05:18 file 20231219/Re_ Phone conversation with IETF_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics regarding discussion with someone at IETF.
20160322 11:08:00 file 20240124/RE_ PQC meeting_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"I’ll send a standing invitation to hold for PQC on Tuesday mornings."
In a quoted message: "Are you talking about our internal PQC meeting? Or the conference call with the CRFG chairs?"
20160322 19:03:00 UTC file 20240124/RE_ My write-up in the PQC call(4)_7.pdf-attachment-CFP v2 Ray + Sec4c.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft call for proposals.
20160323 01:52:54 file 20240124/RE_ My write-up in the PQC call(3)_5.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"The ANSI C compiler in the Microsoft Visual Studio 2005 Professional Edition"
20160323 11:49:06 file 20240124/FW_ My write-up in the PQC call_6.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
See attachment.
20160323 15:30:00 UTC file 20240124/FW_ My write-up in the PQC call_6.pdf-attachment-CFP v2- LEB.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft requirements for software.
20160323 18:16:00 UTC file 20240124/Re_ My write-up in the PQC call(4)_3.pdf-attachment-CFP v2-dbm-ray-larry.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Early draft of call for proposals.
20160324 02:11:01 file 20240124/Re_ My write-up in the PQC call(5)_4.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Editing call for proposals.
20160324 02:57:13 file 20240124/Re_ My write-up in the PQC call(4)_3.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Editing call for proposals.
20160324 11:31:40 file 20231219/[Itl_mgmt] Fw_ [Deputies] News Clips for Thursd..._1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Not obviously relevant.
20160324 17:54:00 UTC file 20240124/Re_ My write-up in the PQC call(5)_4.pdf-attachment-CFP v2 - YKL.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft call for proposals.
20160325 07:52:01 file 20240215/RE_ 6 Expert keynotes scheduled_ Reserve now at..._1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Conference logistics.
20160327 03:30:58 file 20240124/Re_ My write-up in the PQC call(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing document edits, planning a meeting.
20160328 04:04:00 file 20240124/RE_ My write-up in the PQC call_1_Redacted.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Editing draft call for proposals. Some interesting comments.
20160329 04:32:51 file 20240124/PQC call for papers v4_3_Redacted.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"Here is an updated version of the call for papers, after our discussion this morning. I cleaned up my section. Could you all take turns revising your sections? If we can get this cleaned up by Friday afternoon, that would be great!"
20160329 05:25:30 file 20240215/RE_ Grover's algorithm_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Surprisingly basic discussion of Grover's algorithm.
#scramble
Peralta: "In Grover's algorithm (for a space of size N) one iterates calls to two operators about sqrt(N) times, then one measures and obtains the target with probability about 1. What happens if you do fewer iterations and then measure? How does the probability decay?"
Liu: "Sorry I didn't have time to reply earlier! Yes, for Grover's algorithm, if you stop the algorithm early, you can calculate what happens -- Grover's algorithm rotates the state of the system so that it overlaps partially with the target state, see equation (11) here: https://courses.cs.washington.edu/courses/cse599d/06wi/lecturenotes12.pdf"
The question was how the probability decays, compared to probability "about 1" for "about sqrt(N)" iterations. The correct answer to the question is that there's a quadratic decay: the success probability is about q2/N after q iterations.
Someone who understands what the variables mean can obtain this with a short calculation from the more complicated rotation formula that's cited. But someone asking such a basic question about Grover's algorithm obviously doesn't have that understanding. Why would someone who does understand what's going on point to the formula and not answer the question?
Liu: "You can also ask a related question: what happens to the quantum query lower bounds, when you are operating in this regime where the success probability is very low? Mark Zhandry has some results about this -- for instance, he shows that for unstructured search over N items using q queries, the best success probability is O(q2/N), see here: https://www.cs.princeton.edu/~mzhandry/docs/talks/QSol.slides.pdf"
Three things are striking here. First, claiming O(q2/N) as a lower bound is meaningless; it shows that the writer doesn't understand what "O" means. #error Zhandry's slides correctly say Theta.
Second, Zhandry's slides credit the Theta(q2/N) result to BBBV'97. Why would anyone claim that Zhandry showed this result? #ethics #error
Third, why would someone who understands that the lower bound of Theta(q2/N) matches Grover's performance at that level of detail not say so? Someone who was asking about Grover's algorithm won't be able to figure out from the reply text that Grover's algorithm has success probability Theta(q2/N) after q iterations, within a constant factor of optimal.
For anyone who does understand Grover's algorithm, this whole reply text looks like the result of someone searching for material online and not taking the time to understand what the search results say about the question at hand. What's weird is how confident the reply text sounds.
20160329 09:50:28 file 20231219/perfect forward secrecy__1_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Various redactions, at least some of them obviously being Daniel Smith-Tone.
Rene Peralta: "I think perfect forward secrecy is overhyped. Long term keys should be both protected and changed with adequate frequency. If you can't do that, then I think you have bigger problems than lack of forward secrecy."
20160329 12:59:33 file 20231219/Here's the reference for the optimal way to par..._1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Sending around a reference on the limits of Grover parallelization.
#scramble
20160330 10:24:12 file 20240124/Re_ PQC call for papers v4_1_Redacted.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing edits to the call for proposals.
"A danger is that different submitters may make incomparable security analyses. If we leave too much complexity people may make mistakes and if we leave wiggle room people will be likely to interpret things in a way that makes their own submission look more favorable, even if they are not doing it consciously."
"Furthermore, our assumptions about the relative cost of quantum vs classical operations can simply be baked into our choices of number bits of security for each rather than leaving this as an aspect of the security definition for the individual teams to decide for themselves."
20160330 10:48:20 file 20240124/Re_ PQC call for papers v4(1)_2_Redacted.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Editing call for proposals.
20160404 04:59:36 file 20240311/Re_ latest cfp_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Hmm, I just looked at the current version of the CFP. Larry asked if we needed any more text from him, but I don't think we do, at least nothing big."
"I haven't heard anything from Daniel. If I have time on Wednesday, I may just rewrite Daniel's section myself."
"Thanks for setting up the meeting on Thursday. We should definitely discuss the second half of the CFP in more detail."
20160404 09:45:57 file 20240311/Re_ latest cfp(1)_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Thursday is fine with me. I'll send out an invite...."
Thread is planning 7 April 2016 meeting.
20160405 09:14:46 file 20240325/Quantum pre-image attacks on SHA-256_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thought you might find this interesting…. http://arxiv.org/pdf/1603.09383.pdf"
20160407 01:46:50 file 20240325/Reference papers on more realistic quantum comp..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"https://cr.yp.to/hash/collisioncost-20090517.pdf"
"http://arxiv.org/pdf/1207.2307v2.pdf"
20160407 03:00:23 file 20240311/Final revisions of the CFP for our first draft_6.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Please use the attached to make your revisions. I believe Ray is going to address some things in Section 3 and 4. Yi-Kai will work on the remaining few comments. They plan on being done by next Monday, COB. Starting next Tuesday, we want everyone to read the CFP and provide feedback by Friday. We can then send the CFP to Andy, Matt, Donna, etc… the following week."
20160407 03:33:33 file 20240318/RE_ PQC webpage(2)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for the heads-up. I’m going to share and chat with Jim Foti about the best approach. I’d like his advice on how to keep the pages streamlined with this round and I’d like to make sure it works with the migration to the new CSRC web site.."
20160407 18:56:00 UTC file 20240311/Final revisions of the CFP for our first draft_6.pdf-attachment-CFP v6.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20160408 02:12:59 file 20240311/RE_ Final revisions of the CFP for our first draft(1)_5.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Here are my edits to section 3 and 4."
20160408 18:02:00 UTC file 20240311/RE_ Final revisions of the CFP for our first draft(1)_5.pdf-attachment-CFP v6 Ray.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20160411 08:24:29 file 20240311/Re_ Final revisions of the CFP for our first draft(3)_4.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I went through the CFP and made a bunch of edits. I think it's in pretty good shape."
"The section on quantum cryptanalysis still needs a bit more work, but I think it is converging to a good solution. Ray, thanks for your work on that!"
20160411 09:17:45 file 20240325/Re_ What next on blockchain_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Blockchain; one content-free mention of "post quantum".
20160412 00:16:00 UTC file 20240311/Re_ Final revisions of the CFP for our first draft(3)_4.pdf-attachment-CFP v6 Ray YKL.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20160412 03:02:59 file 20240311/RE_ Final revisions of the CFP for our first draft_3.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I read through your changes and provided comments. I took your statement that the section on quantum cryptanalysis still needs a bit more work as an invitation to edit it extensively. I also moved a paragraph of text in section 3. I think everything else is intact aside from some comments and replies to your comments."
20160412 19:02:00 UTC file 20240311/RE_ Final revisions of the CFP for our first draft_3.pdf-attachment-CFP v6 Ray YKL RayComments.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20160413 08:20:28 file 20240318/RE_ PQC webpage(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for checking on this. I like www.nist.gov/pqcrypto It would be nice if they can do it, because it’s easier to remember than http://csrc.nist.gov/groups/ST/post-quantum-crypto/ . If they can’t do it, then I think we don’t need a usa.gov alias, we can just use our exisiting /post-quantum-crypto/ directory."
20160413 12:04:33 file 20240311/RE_ FPKI Policy Authority_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Thanks Dustin. I’ve added some comments to Andy’s notes below in green. Also: The discussion yesterday at FPKI-PA was also about the PKI shared service providers who have been testing and planning for migrations to either ECC or RSA 3072+ - for the intermediate CAs etc. The End Entity Certificates (PIV and other person and non-person end entity certs) are governed under Common Policy for the federal agencies, which are aligned with NIST specs. They are currently 2K RSA certs. The question they had, as Dustin said to move to 3K or to ECC."
Earlier in thread: "They recommended that if we want people to implement our PQC algorithms after they are standardized that there needs to be some kind of mandate with a deadline. Otherwise they can’t get their bosses to transition to new algorithms. They thought it a good idea if we could state now that there will be a mandate."
20160414 02:12:12 file 20240311/Re_ Final revisions of the CFP for our first draft_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I've added in some comments. I accepted several of Lily's comments, and tried to clean up portions of the text. Thanks!"
20160414 03:17:53 file 20240318/RE_ PQC webpage_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"No, that would be the link and it would take you direct to: http://csrc.nist.gov/groups/ST/post- quantum-crypto/ Or do you want another page that builds of the “Standardization” only? I have a request in for an alias, that relates the project that would go through 2023-ish. That’s the one we will get an alias to. On that page, we would add more menu links, to whatever is necessary (Federal Register Notices, Submission Requirements, etc.). Here is a link to the Wayback machine to the hash competition stuff in 2008: http://web.archive.org/web/20080307094319/http://www.csrc.nist.gov/groups/ST/hash/sha- 3/index.html"
20160414 12:30:12 file 20240311/Re_ Final revisions of the CFP for our first draft(1)_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Attached please see my comments. I started going through at the beginning of this week. What I commented may not be the latest version. I am impressed about the progress we made."
Earlier message in thread: "I like the new discussion of security against quantum attacks much better. I would even go so far as to say I am pretty happy with it!"
#weveshownallourwork
20160414 16:16:00 UTC file 20240311/Re_ Final revisions of the CFP for our first draft(1)_2.pdf-attachment-llc-CFP v6 Ray YKL.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20160414 18:07:00 UTC file 20240311/Re_ Final revisions of the CFP for our first draft_1.pdf-attachment-CFP v7.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20160418 10:28:47 file 20240318/Re_ PQC CFP(1)_5.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks, both of you, for doing all this work. In particular, thanks, Ray, for all your work on the security requirements!"
20160418 10:55:26 file 20231219/CFP v8 - ready to send on_3.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics regarding CFP editing.
"Yi-Kai did a great job of spearheading this effort, and thanks also to Ray who did more than his fair share of the writing."
20160418 12:16:00 file 20231219/RE_ CFP v8 - ready to send on(1)_2.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Discussing draft CFP.
20160418 12:23:00 file 20231219/RE_ CFP v8 - ready to send on_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics of reviewing draft CFP.
20160418 14:49:00 UTC file 20231219/CFP v8 - ready to send on_3.pdf-attachment-CFP v8.docx:
Notes from djb, last edited 20240112 23:05:08 UTC:
Draft of CFP.
20160422 09:11:26 file 20240215/Re_ Background for Korea Trade Mission_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
General Korea coordination.
"Moving forward in the future we would like to coordinate with Korea in development of new encryption technologies for Quantum Resistant Encryption."
20160422 09:11:26 file 20240325/Re_ Background for Korea Trade Mission_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Adam has more data on Korea specifically but;"
"In reference to cybersecurity, the US and Korea: (My pitch)"
"NIST works with NSRI in Korea and hosts guest researchers at NIST from NSRI in cooperation areas of cryptographic testing, test tools and test metrics. We would like to coordinate with KAT in the US Cybersecurity Framework and is interested in other areas of cloud computing, IOT and mobile security. Moving forward in the future we would like to coordinate with Korea in development of new encryption technologies for Quantum Resistant Encryption."
20160425 08:06:44 file 20240325/RE_ Draft meeting minutes_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Elaine sent out the meeting notes for the NIST-NSA TWG Meeting from last week. Under the section “SP800-56A revision”, the following bullet was included: o The IKE groups will be approved for the ephemeral-ephemeral schemes, probably by listing in FIPS 140 Annex A. I wasn’t sure if this was similar to the XPN issue. Is FIPS140 Annex A supposed to be used for this or is this something that needs to be added to an SP? It’s possible it’s ok, I just wanted to get your opinion. Please let me know what you think."
#nsa
20160425 11:29:00 file 20240325/RE_ PQC updates_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"10am"
Context: A talk by Jerry Solinas on 3 May 2016. #nsa
20160427 01:41:38 file 20240325/X9F1 request_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Heads up: Terence Spies will be contacting you about arranging a webinar (or whatever) for X9F1 on post- quantum activities."
20160427 08:31:42 -0400 file 20221014/NIST.IR.8105.pdf:
20160429 03:51:50 file 20240318/Re_ PQC in the FRN_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Yes, we reached out to the lawyers earlier this week. After some discussion, it would be premature to send them a copy of the draft FRN for review, but we're trying to set up a meeting with them to go over the main points. We think that will speed up the review process."
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
20160502 01:59:00 file 20240318/link regarding ntrumls_pqntrusign_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Sending link to John Schanck's thesis "Practical Lattice Cryptosystems: NTRUEncrypt and NTRUMLS".
20160504 02:12:28 file 20240325/Re_ news_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing the word "boffin".
20160505 01:08:32 file 20240311/Key establishment_agreement_transport in the PQ..._2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Thanks again for your comments on our PQC call for submissions. We’ve been working through the comments, and I wanted to take you up on your offer to help with the terminology we use for key- exchange in the call. We understand that we probably should use the correct terms from 56A/B, however, we worry that many of our target audience are not as familiar with the term key agreement as they are with key exchange. So we wonder what we should do. If would be nice to use key exchange if we can, as more people understand what we mean by that. Also, we are seeking to replace our key establishment algorithms from 56A/B. Currently, there is not a good option for a direct replacement for Diffie-Hellman. We’re still asking for key exchange (key agreement), because it would be nice if someone comes up with a good scheme, however it might not happen. The main reason we’re asking for PQC encryption is to use it for key transport, as we are not sure we will have a good PQC key agreement scheme. We don’t want to standardize PQC encryption for general encryption usage. Having said that, would you mind going through the document once again and suggesting what terms to use for key establishment/agreement/transport? I left your comments about them in place, so you should hopefully be able to find the right spots quickly."
20160505 01:12:45 file 20240325/_Shall_ vs _must_ in the PQC CFP_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"A few of the comments we received back last week dealt with using the terms “shall” and “must”. I believe “shall” has a very strict meaning for our standards documents. To my mind, the word “must” means the same thing, but maybe isn’t quite as strong. In the attached (cleaned-up) version of the CFP, we have 60 uses of “shall” and 19 of “must”. Can everyone search through the document, using CONTROL+F, and see if any of the “shall”s or “must”s cause us any problems? Or if we should switch any of the “shall”s to “must”s, or even to “should”? I read through them all, and they seemed fine to me."
20160505 01:21:53 file 20240325/Re_ quick PQC CFP question_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"You can specify that it should be a plain text file."
20160505 01:36:32 file 20240325/RE_ PQC talks_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I’m not opposed to trying this out. It would be great to spread out the workload. However, I worry that not everyone will read the paper, and then the meeting won’t be very effective. Perhaps we can discuss this on Tuesday, and set a schedule for which papers on which days."
From an earlier message: "We can probably start resuming our meetings with the NSA, where we have someone talk on a topic/paper. They are going to get several talks prepared, and we need to do the same here."
Other comments show that NIST generally expected only one person to go through a paper. No apparent recognition of how error-prone this is.
#nsa
20160505 01:37:00 file 20240311/RE_ Key establishment_agreement_transport in th..._1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"That sounds good."
20160505 03:52:52 file 20240318/PQC_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"There are some issues that I’m not sure about; see my questions."
20160505 10:46:17 file 20240325/Re_ travel to ETSI workshop in Toronto_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Travel approvals.
20160505 11:11:27 file 20240325/Fw_ travel to ETSI workshop in Toronto_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Travel approvals.
20160505 17:00:00 UTC file 20240311/Key establishment_agreement_transport in the PQ..._2.pdf-attachment-CFP v9.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20160505 17:00:00 UTC file 20240325/_Shall_ vs _must_ in the PQC CFP_2.pdf-attachment-CFP v9.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160505 19:50:00 UTC file 20240318/PQC_2.pdf-attachment-ebb suggestions for CFP v9.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160506 02:10:00 file 20240318/RE_ PQC_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for going through it, and helping us with the terminology. I think your suggestions should work pretty well. We (the PQC team) will meet next Tuesday and review them."
20160506 11:05:50 file 20240325/Re_ _Shall_ vs _must_ in the PQC CFP_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"This is more of a stylistic issue, but I think it's not great to overuse "shall" and "must," because then people stop paying attention to them. I wonder if we can use "will" when talking about minor details, and only use "shall" and "must" when it's really important?"
"For instance, in the first sentence of a paragraph, use "shall": submitter SHALL include a complete description of the algorithms. But in the rest of the paragraph, use "will": this description WILL include a list of recommended parameter settings, etc."
"Obviously this is a judgement call..."
"Other specific notes:"
"- On page 1, "Submission packages should be sent to:" -> SHALL"
"- On page 7, "a set of KAT vectors shall be included to exercise every table entry" -> maybe we want to relax this requirement? This requirement makes sense when we're talking about S-boxes, but may be tedious and unhelpful when it's a lookup table for sampling from a gaussian distribution."
"- In general, I think we should leave the designers a fair amount of freedom in how they design the KAT tests, since it will probably vary a lot from one scheme to another. Maybe we can just have one strongly-worded sentence at the beginning: "Each scheme must be accompanied by a complete set of KATs that exercise all functionalities, all parameter settings and all sub-components of the scheme. Completeness of the KATs will be considered in evaluating the suitability of the scheme." After that, we give specific but non-binding advice using the word "should." "
"Obviously this is also a judgement call..."
20160506 12:17:38 file 20240318/RE_ polishing the CFP(1)_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I’ll ask Stephen to polish. I agree with what you said about Shall’s, etc. I will make those changes. As for the key establishment/agreement/exchange, I am waiting to hear Lily’s opinion."
20160506 13:28:00 UTC file 20240318/RE_ polishing the CFP_3.pdf-attachment-CFP v9.1.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160506 18:04:00 UTC file 20240311/FW_ First FRN asking for comments on PQC requir..._1.pdf-attachment-RFC on PQC in FRN.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft Federal Register notice.
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.
20160510 03:23:00 file 20240311/FW_ First FRN asking for comments on PQC requir..._1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I was just checking that you got this. Is there anything I should change? We probably need to move quick on it still, so that it’s in the FRN in June."
Previous message: "Okay, I used the SHA-3 request for comments and the template I had for the FIPS 186 FRN to create the attached document. It basically asks for comments and says the requirements and criteria will be posted at www.nist.gov/pqcrypto. Take a look, and let me know what to change."
20160510 03:28:34 file 20240318/Re_ polishing the CFP(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I have given a once-over to the cfp and attached the result (with changes tracked). Most of the changes were minor, with the most substantial change being to the section about defining bits of quantum security. In that section, some of the sentences seemed extremely confusing, so I simplified the discussion somewhat, at the risk of losing some of the original intended nuance. So, I think, amongst my modifications, those are the ones that should be looked at the most carefully."
"The level of formality still varies somewhat from section to section, but I was reluctant to do too much heavy rewriting at this point considering that many of the sentences are the result of negotiation and consensus-reaching at previous meetings."
This comes from previous discussion of editing the document "so it doesn’t appear so much that it was written by different people".
20160510 08:00:00 file 20240318/RE_ polishing the CFP_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Sending draft CFP upon request.
20160510 19:23:00 UTC file 20240318/Re_ polishing the CFP(1)_2.pdf-attachment-CFP v9.2.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160511 09:50:40 file 20240318/Re_ polishing the CFP_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I see them."
20160512 01:46:47 file 20240325/Target Security Strength section_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Stephen modified the last couple of paragraphs of section 4.A.4. His changes appear fine to me. I’ve included the text of the section below. Let me know if you have any problems with it."
20160512 10:06:01 file 20240311/FRN comments_3.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I've attached a few comments on your RFC. I think it's in pretty good shape. I have a few editorial suggestions, but they're fairly minor. Are you going to send this around to the PQC team?"
20160512 13:59:00 UTC file 20240311/FRN comments_3.pdf-attachment-RFC on PQC in FRN-arr.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Editing draft Federal Register notice.
20160512 15:53:00 UTC file 20240311/Re_ FRN comments_2.pdf-attachment-RFC on PQC in FRN v2.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft Federal Register notice.
20160512 15:53:00 UTC file 20240318/RE_ PQC Request for Comments for the FRN_1.pdf-attachment-RFC on PQC in FRN v2.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FRN.
20160516 07:59:13 file 20240318/Re_ NIST IR 8105_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing reusing the "port-quantum IR" for "a Beacon IR".
20160517 09:12:10 file 20240318/RE_ PQC Request for Comments for the FRN_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Just a reminder – I need any comments back by the COB today."
20160518 07:05:17 file 20240311/Re_ FRN comments_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I didn't too much feedback on the attached RFC for the FRN, but I think it's in good shape. Can you send it to Jennifer? We'd like to have this go out sometime in June."
20160523 09:06:00 file 20240325/Reading Club talk June 8_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here's the abstract:"
"In the last few years multivariate public key cryptography has experienced an infusion of new ideas for encryption. Among these new strategies is the ABC Simple Matrix family of encryption schemes which utilize the structure of a large matrix algebra to construct effectively invertible systems of nonlinear equations hidden by an isomorphism of polynomials. The cubic version of the ABC Simple Matrix Encryption was developed with provable security in mind and was published including a heuristic security argument claiming that an attack on the scheme should be at least as difficult as solving a random system of quadratic equations over a finite field. In this work, we prove that these claims are erroneous. We present a complete key recovery attack breaking full sized instances of the scheme. Interestingly, the same attack applies to the quadratic version of ABC, but is far less efficient; thus, the enhanced security scheme is less secure than the original."
20160524 01:01:00 file 20240318/PQC CFP draft_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for agreeing to re-word the part of the CFP dealing with hybrid modes. It’s in the middle of p3."
20160524 01:09:17 file 20240318/PQC CFP_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here’s what you “volunteered” to take a look at: - The NSA’s comment on section 2.B.1 paragraph 3. I believe you wanted to add something - Section 2.B.1 paragraph 5. Did you want to give any examples of compatibility constructs? - Any changes to the security section that you and Ray come up with."
#nsa
20160524 02:17:23 file 20240318/Minimal edits to make quantum security section ..._3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Editing draft of CFP.
20160524 11:22:04 file 20240325/Raison d'etre Calik_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Dr. Cagdas will leverage his knowledge of complexity theory, algorithmics, and circuit complexity to perform research in support of the following projects: lightweight cryptography, post-quantum cryptography, interactive proofs, and combinational circuit complexity. The outcome of his research will impact the next generation of cryptographic standards and enhance NIST leadership role in these areas."
20160524 16:59:00 UTC file 20240318/PQC CFP draft_4.pdf-attachment-CFP v9.3.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160524 16:59:00 UTC file 20240318/PQC CFP_3.pdf-attachment-CFP v9.3.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160524 18:14:00 UTC file 20240318/Minimal edits to make quantum security section ..._3.pdf-attachment-CFP v9.3_RayEditsOn4a.4.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160525 01:37:51 file 20240318/PQC talk_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Next week I’ll be giving a talk to the automotive industry about post-quantum cryptography. I’ve attached my slides. I was hoping someone could take a quick look through them and make sure I am not saying anything really wrong, since I have a few on quantum computers, which are not my area of expertise. I used our NIST crypto club talk as a source of inspiration, and took some of the slides/ideas from that."
20160525 08:42:25 file 20240318/Re_ PQC CFP draft_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"That makes sense!"
Context is discussion of hybrids.
20160525 17:33:51 UTC file 20240318/PQC talk_2.pdf-attachment-Crypto in PQ world.pptx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Similar to other slides, but has a line "How long will a car in the field?", which makes it a talk for a car conference.
20160526 02:25:42 file 20240325/RE_ Reading Club talk June 8_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks Ray and Morrie!"
20160526 07:08:30 file 20240318/Re_ PQC talk_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for the comments!"
20160526 10:28:09 file 20240325/Re_ PQC API_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Yes, that is correct. Signatures, Encryption, and Key-exchange (for which DH is an example). Ray, correct me if I'm wrong."
20160526 11:03:24 file 20240325/Fwd_ Reading Club talk June 8_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Ray already sent me his abstract, below."
20160527 01:59:41 file 20240318/Re_ Minimal edits to make quantum security sect..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Great! Dustin, could you take Ray and my changes and merge them into the main document?"
20160527 10:12:00 file 20240318/Re_ PQC CFP_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here are my changes. For the quantum security section, Ray sent me some edits, I'm going to look at them now, and will hopefully send them to you soon. Sorry for the delay..."
20160527 12:49:50 file 20240318/Re_ Minimal edits to make quantum security sect...(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I edited the quantum security section some more."
"- I added some simple advice: if you have a quantum algorithm, report both the time and space complexity, and if possible, say what is the tradeoff between them. I tried to keep this separate from the more complicated discussion about how to define quantum bits of security."
"- I said that this is preliminary guidance from NIST, and we will discuss with the community as we go forward."
"- I said some more about the possibility of defining quantum bits of security with respect to SHA-256 rather than AES-128. (Since we are already doing this in some of our target security strengths.) It is problematic because these two definitions (SHA vs AES) are not equivalent."
20160527 14:06:00 UTC file 20240318/Re_ PQC CFP_1.pdf-attachment-CFP v9.3 edited YKL.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
Edit notes have a comment about patents: "However, NIST recognizes that it may be difficult to find a suitable PQC algorithm that is completely patent-free. (This is in contrast to SHA-3 and AES.)" What discussions led to this note? #needmorerecords #slowingdownpqcrypto
20160527 16:38:00 UTC file 20240318/Re_ Minimal edits to make quantum security sect...(1)_2.pdf-attachment-CFP v9.3_RayEditsOn4a.4_YKL-Edits.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160531 14:57:00 UTC file 20240325/Re_ Sample documents for PQC Call For Proposals(10)_4.pdf-attachment-CFP v9.4.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20160602 02:27:00 file 20240325/RE_ Sample documents for PQC Call For Proposals(2)_7.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"sure"
20160602 05:24:56 file 20240325/Re_ Sample documents for PQC Call For Proposals(6)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I just took a quick look at the API. Do we need to provide some mechanism for submitters to specify the lengths of the public keys and secret keys, and the length of the random input? In EBACS, it looks like submitters will define these parameters in a header file, but I couldn't find this in Larry's notes."
20160602 05:28:45 file 20240325/Re_ Sample documents for PQC Call For Proposals(5)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Also, if you forward this to Larry, tell him thanks for putting this together!"
20160602 10:16:57 file 20240325/Re_ Sample documents for PQC Call For Proposals(10)_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for the API page. I'll get Sara to post it when we post the Call For Proposals. Do you have the other files that you are working on? (I think it's the KAT and intermediate values)."
20160602 10:29:11 file 20240325/Re_ Sample documents for PQC Call For Proposals(9)_5.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Great!"
20160603 12:53:37 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-Crypto in PQ world.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Looks like "Crypto in PQ world -DoC.pdf".
20160607 04:04:55 file 20240325/RE_ Sample documents for PQC Call For Proposals(1)_8.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I think the key exchange API can be simplified to four algorithms"
"Initiator_generate should be a randomized algorithm that outputs the Initiator's key exchange message (KEI) and an initiator private key (SKI) Responder_generate should be a randomized algorithm that takes KEI as input and outputs a responder key exchange message (KER) and private key (SKR) Initiator_recover should be a non-randomized algorithm that inputs KER and SKI and generates a shared secret (SS) Responder_recover should be a non-randomized algorithm that inputs KEI and SKR and generates the same shared secret."
"(Actually you could combine Responder_recover and Responder_generate, since all the inputs of the former are inputs or outputs of the latter, and they're done by the same party, but it might be more confusing.)"
20160607 04:40:13 file 20240325/RE_ Updates on NIST Post-Quantum Cryptography S...(4)_5.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I will update the agenda and look out for your slides."
20160607 19:12:49 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-PQCrypto 2016 v3.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Should compare to "PQCrypto 2016.pptx".
20160607 20:50:25 UTC file 20240325/RE_ Reminder_ Crypto Reading Club - June 8_1.pdf-attachment-KRACCABCSMES.pptx:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Key Recovery Attack on The Cubic ABC Simple-Matrix Encryption Scheme"
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.
20160608 02:46:48 file 20240325/Re_ slides for ISPAB_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks, Let's discuss tomorrow."
20160608 06:15:52 file 20240325/Re_ Visit by Gorjan Alagic (June 20-24)_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Maybe we can have him to come June 21, Tuesday, using our regular time holding for PQC meeting."
20160608 09:47:00 file 20240325/RE_ Reminder_ Crypto Reading Club - June 8_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Slides"
20160609 03:03:15 file 20240311/interesting recent paper_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Quantum-Proof Extractors: Optimal up to Constant Factors Kai-Min Chung, Gil Cohen, Thomas Vidick, Xiaodi Wu http://arxiv.org/abs/1605.04194"
20160609 09:20:28 file 20240325/slides for ISPAB_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
No text, just the attachment.
20160609 10:56:42 -0400 file 20240325/RE_ Updates on NIST Post-Quantum Cryptography S...(3)_4.pdf-attachment-ISPAB PQC update2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft (?) ISPAB slides.
20160609 11:02:00 file 20240325/RE_ Updates on NIST Post-Quantum Cryptography S...(3)_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I’m attaching the powerpoint (and pdf) versions I will use for my presentation. As far as advance material, I assume they’ve already seen it, but if not, our Report on Post-Quantum Cryptography (NISTIR 8105) available at http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf would be good."
20160609 11:48:29 file 20240325/RE_ Updates on NIST Post-Quantum Cryptography S...(2)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thank you for sending the presentation. We will provide copies of both NIST IR 8105 and presentation as hand-outs at the meeting."
20160609 13:19:14 UTC file 20240325/slides for ISPAB_1.pdf-attachment-ISPAB PQC update-06092016.pptx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft (?) ISPAB slides.
20160609 14:55:58 UTC file 20240325/RE_ Updates on NIST Post-Quantum Cryptography S...(3)_4.pdf-attachment-ISPAB PQC update2.pptx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft (?) ISPAB slides.
20160613 01:25:35 file 20240325/RE_ Upcoming PQC meetings_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I think we can invite other members to attend for these two talks. How about “internal-crypto” or CRYPTO-CLUB (include externals and need visitor registration)?"
20160613 08:12:00 file 20240325/RE_ Re_ seminars_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Yes, I’ll take care of the room. Thanks."
20160614 08:47:00 file 20240325/RE_ pqcrypto webpage_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Hey Dustin – Thanks for the heads up! The next few days are pretty crazy with getting the EO Commission details out before the meeting at Berkeley next Tuesday. Next week, while everyone is there, it should lighten up a bit."
20160614 09:32:44 file 20240325/Re_ Item to be published in the FRN_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Will do,"
20160614 11:46:34 file 20240325/RE_ Sample documents for PQC Call For Proposals_6.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thank you Larry!"
20160614 11:47:56 file 20240325/FW_ Sample documents for PQC Call For Proposals_6.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Take a look at what Larry sent, and let us know if there is anything that needs to be fixed. Thanks!"
20160614 12:06:00 UTC file 20240311/EXAMPLE FILES - Documents to soon post on PQC w..._1.pdf-attachment-CFP announcement.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft announcement of draft call for proposals.
"It is intended that the new public-key cryptography standards will specify one or more additional unclassified, publicly disclosed digital signature, public-key encryption, and key-establishment algorithms that are available royalty-free worldwide, and are capable of protecting sensitive government information well into the foreseeable future, including after the advent of quantum computers."
20160614 12:41:05 -0400 file 20240325/RE_ Updates on NIST Post-Quantum Cryptography S...(1)_2.pdf-attachment-ISPAB PQC update2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft (?) slides for ISPAB.
20160614 12:42:00 file 20240325/RE_ Updates on NIST Post-Quantum Cryptography S...(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I’ve attached a slightly updated .pdf file for my presentation. Thanks!"
20160614 16:40:39 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-ISPAB PQC update2.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Looks similar to other talks.
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" #claimingtransparency
20160615 09:28:08 file 20240325/Re_ Updates on NIST Post-Quantum Cryptography S..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thank you."
20160616 01:46:47 file 20240325/Re_ another tracker Q..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"This is the outcome for the June FRN. IF you need a date then make it Q4."
20160616 09:55:12 file 20240325/Re_ Sample documents for PQC Call For Proposals_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here’s the updated API file. Give that a read to make sure I didn’t miss anything."
20160617 08:18:29 file 20240325/RE_ fips 186_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Andy probably knows as much as I do, but here’s my take. We opened FIPS 186 for comments, received several, and have had several meetings about what revisions to make. There are some pretty minor ones involving things like prime generation, which nobody seemed to have a problem with. The two more substantive issues were: are we going to add new curves, and if so how/which ones? And also, there seemed support for adding a deterministic signature scheme (but which one?). It seems we’ve decided that we will add the two curves the CFRG is going to standardize (Curve 25519 and Ed448). For now, that’s what we know for sure. We’ve been slowly trying to feel out people’s opinion if that is sufficient. The other thing that we might do is decide to add some pseudorandom curves (like the Brainpool ones, or generate new ones). We don’t yet know if we will do that or not. As for which signature scheme to add, I don’t think our discussions ever settled that. I think several of us wanted to know what you thought, but you were gone when we had a few of the meetings. The main possibilities seem to be a deterministic ECDSA, or a Schnorr-type scheme (of which there are a few). We should probably decide on that. Right now, Andy and Lily are in the process of trying to hire a contractor to help us out with the actual writing. They seem to feel this is necessary. I think the hope is that we can get that finalized sometime this year. It feels to me we are moving pretty slow on all this, but I regularly ask Andy and Lily, who seem okay with the pace. I think some of the wind has gone out of the sails of all this, due to PQC, and the NSA’s pronouncements about ECC. It feels to me a lot of the urgency and animated conversation about new curves seems to have died down a bit, which might explain our slow pace somewhat. Anyway, that’s where things stand with FIPS 186 as I know it. Let me know if you have any other questions about it."
20160617 10:49:45 file 20240311/RE_ First drafts of selection memo for RIT (2) ..._1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Discussing funding for RIT and Wollongong.
"Three reviews together in one email for a given proposal is fine."
20160622 03:38:32 file 20240311/Invite to European PQC meeting_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I’m going to send this letter out to our European colleagues. Can you take a quick look at it first?"
20160622 03:43:39 file 20240311/Re_ Invite to European PQC meeting_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"It looks fine to me."
20160622 19:37:00 UTC file 20240311/Invite to European PQC meeting_2.pdf-attachment-invitation.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Dear colleagues,"
"It was great meeting you last December when our organizations gathered to discuss cryptographic standards and research. Of course, I’d like to thank BSI again for hosting that meeting, as well as Manfred personally for all of his efforts to organize it. We thought this was incredibly valuable discussion and would like to continue these meetings as a forum to discuss our on-going and future work."
"One of the next steps we identified last December was a follow-up discussion focused on quantum-resistant cryptography. I understand many of you will be attending the ETSI/IQC Workshop on Quantum Safe Cryptography in Toronto. I think this will provide a good opportunity for us to meet again."
"We’d like to invite you to participate in a one-day meeting on 22 September, following the ESTI workshop. We’ve reserved a conference room at the Hilton Toronto Hotel, which I hope is a convenient location for all of us. Tentatively, I would propose that we begin at 0900 and finish at 1700."
"As mentioned above, we’d like to focus the discussion on quantum-resistant cryptography. Specifically, discussion topics may include: 1) security requirements and evaluation criteria for quantum-resistant algorithms, 2) the progress of quantum computing technology, 3) current transition plans to quantum-resistant algorithms and standards, and 4) the use of hybrid schemes."
"Of course, additional discussion topics are always welcome. Please let me what other topics you’d like to discuss and I would be happy to work them into the agenda."
"I will send out additional details on the agenda and logistics for this meeting as we get closer to the date. In the meantime, please let me know if you, or others from your organizations, plan to attend."
Obviously this was aimed at Manfred Lochter. Who else? #needmorerecords
20160628 07:14:12 file 20240325/report _ meeting_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"We need to discuss the report – particularly the templates, timeline, and a workshop CFP. I’m on vacation next week, so I’ve proposed a meeting for Tuesday 7/12. If that works for both of you, please send me any comments/changes you’ve made to the report by the morning of 7/11."
20160629 01:42:00 file 20240311/RE_ FRN for Dustin's Post-Quantum Crypto_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I am pretty sure that we haven’t received anything from Melissa yet. Tomorrow, we will ask them when Andy and I go to meet them."
20160629 12:13:02 file 20240311/EXAMPLE FILES - Documents to soon post on PQC w..._1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Logistics of web-page updates.
"I haven't attached the main document, as the lawyers gave me several revisions to make."
20160704 12:05:35 file 20231219/FAQs_4.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Discussing postings.
20160705 04:56:35 file 20231219/FAQ_3_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Redacts the email address of a recipient. #needmorerecords
Editing FAQ entries.
20160705 05:17:53 file 20231219/RE_ FAQ(1)_2_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Discussing FAQ.
20160705 05:30:36 file 20240215/Re_ PQC pdf files_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing file formats.
20160705 05:57:41 file 20231219/RE_ FAQ_1_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Discussing FAQ.
20160705 12:39:25 file 20240215/Re_ PQC main document draft_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Logistics regarding edits to drafts.
"(omitting comment about how much I like lawyers)"
Kerman: "I know it’s not a competition" with a smiley. This sounds like it's alluding to previous discussions where someone was insisting on this not being a competition; what exactly happened in those discussions? #needmorerecords
20160706 04:35:00 file 20231219/FW_ Zhang Tan Paper_1_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Redacted email addresses. One of them looks like Daniel Smith-Tone. #needmorerecords
20160707 08:34:00 file 20231219/Could we set up a meeting with Chuck_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics for meeting with "Chuck" regarding IPR.
20160707 09:02:00 file 20231219/after 11_30 tomorrow meet with Chuck_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics for meeting with "Chuck" regarding IPR. What happened in that meeting? #needmorerecords
20160708 02:25:00 file 20231219/RE_ IPR policy AES vs. SHA-3_1_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
IPR discussion. #needmorerecords
20160713 03:25:14 file 20240215/Updated FAQ document for PQC_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Sending near-final draft of call for proposals, and update of public FAQ.
20160713 03:37:06 file 20240215/RE_ next step_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussion of patent-related scheduling and options.
""Please encourage the lawyers to move quickly! The time they take gets subtracted off of our revision time. Thanks!
Chen: "Could you follow up with Jennifer NIST about the IPR text they promised to provide?"
"We will need to prepare a note for Chuck on the IPR statement."
20160713 17:24:00 UTC file 20240215/Updated FAQ document for PQC_1.pdf-attachment-FAQ v2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of "Frequent Asked Questions"
20160713 19:22:00 UTC file 20240124/RE_ pqc webpage(1)_2.pdf-attachment-PQC-Call for Proposals-Draft v1.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Early draft of the call for proposals.
Comment from "Jillavenkatesa": "This indicates that the RF licensing terms apply only during the search/competition phase. However, para 4 in 2.D.1 seems to indicate that the RF obligation extends in perpetuity if the cryptosystem is selected for standardization. Can NIST dictate such terms?"
"Should my submission be selected for standardization, I hereby agree not to place any restrictions on the use of the cryptosystem, intending it to be available on a worldwide, non-exclusive, royalty-free basis."
"The algorithms shall be publicly disclosed and available worldwide without royalties or any intellectual property restrictions."
#inconsistency
20160713 19:22:00 UTC file 20240215/Updated FAQ document for PQC_1.pdf-attachment-PQC-Call for Proposals-Draft v1.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
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.
20160715 07:49:57 file 20240215/Re_ A couple easy steps toward moving our stuff..._1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussion of some important post-quantum issues. Some quotes here are from messages earlier in thread.
"This motivates my suggestion: when thinking about how our current protocols can be adapted to use new public key algorithms, try to document any hard limits on key sizes and other performance characteristics. What, exactly, could post-quantum crypto do that would really ruin your day?"
The actual answer is that, for the vast majority of protocols, post-quantum crypto doesn't "really ruin your day": it usually just works, and the exceptions are usually easy to fix. NIST's later decisions assumed that various post-quantum performance differences were important for deployment, without using the type of documentation suggested here to justify these assumptions. #inconsistency #ftqcic
"Then communicate this information to the NIST post-quantum crypto team." What about communicating it publicly? #weveshownallourwork
What efforts did NIST make to collect this data? What did it do with the data? #needmorerecords
Delaying quantum breaks: "For ECC, increasing its key sizes are not that effective comparing to RSA and DH." #error
"Ensure that all the protocols and algorithms that we approve in the future at least can support 256-bit security level symmetric algorithms." Later NIST public statements claim, incorrectly, that AES-128 is just fine. #inconsistency
What happened to the suggested 256-bit requirement? #needmorerecords This would have stopped some subsequent attacks.
"Wherever possible, ensure that protocols and such that we approve in the future that use public key algorithms can be adapted to much bigger sizes of key and message, and any other weird behavior that some PQ algorithms need (like stateful signatures or non-negligible error probabilities)."
20160718 08:40:56 file 20231219/[Crypto-club] Google tests PQC_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Sending around a link regarding Google's New Hope experiment.
20160718 11:15:54 file 20240215/Links to FAQ_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing edits to web pages.
20160719 01:21:31 file 20240215/RE_ Update - CFP-PQC(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Moody: "I have some text ready that says we prefer royalty free, but I don't know exactly how I should modify the IPR statements. I will try and do it, and then send it to you and Andy."
Chen: "It turned out that Henry is on leave this week. Instead of waiting, let’s try to generate some text based on Henry’s suggestion to incorporate the option of claiming IPR under the ANSI term. I think Andy has passed the hardcopy of AES draft CFP with the term. We will try to be clear about our strong preference on RF."
20160719 01:32:35 file 20240215/RE_ Update - CFP-PQC_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Approving changes.
20160719 01:54:14 file 20240124/FW_ PQC Project Page Menu_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing web-page update.
20160719 09:29:36 file 20240124/Re_ PQC Project Page Menu_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing web pages.
20160719 11:35:21 file 20240215/RE_ Real world cryptography conference_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing invitation to give RWC 2017 talk.
20160719 11:46:33 file 20240215/RE_ Update - CFP-PQC(2)_3.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Editing regarding patents.
20160719 15:45:00 UTC file 20240215/RE_ Update - CFP-PQC(2)_3.pdf-attachment-PQC-Call for Proposals-Draft v1.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
20160719 17:21:00 UTC file 20240215/RE_ Update - CFP-PQC(1)_2.pdf-attachment-llc-PQC-Call for Proposals-Draft v1.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
20160719 17:31:00 UTC file 20240215/RE_ Update - CFP-PQC_1.pdf-attachment-PQC-Call for Proposals-Draft v2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
20160726 03:13:35 file 20240124/RE_ pqc webpage_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing logistics for call for proposals.
20160726 11:26:57 file 20240124/RE_ pqc webpage(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing web pages.
In a quoted message: "So we just finished meeting with the lawyers, and made really good progress. Henry is going to send us the final text we need for the IPR section, and he already signed the FRN notice. Andy and Matt said that means the FRN will likely be published on Friday, so we need to have the webpage ready for Friday."
20160726 11:44:27 file 20240124/Re_ pqc evaluation criteria doc(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Sharing draft call for proposals.
20160726 11:50:16 file 20240215/Re_ PQC CFP going live Friday_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Moody: "We met with the lawyers today, who promised to give us by the end of the day the text they want for some small changes to the IPR sections. They signed off on the FRN notice, which means that we will be going live on Friday."
"Welcome to Carl Miller, who just started with us at NIST this week, as well as Thinh Dang, a Pathways student."
20160727 02:44:02 file 20240124/Re_ pqc evaluation criteria doc_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"I looked over the stuff at www.nit.gov/pqcrypto, and the slides from your talk at PQCrypto 2016. The competition looks very interesting, and I’m looking forward to finding out more at future meetings. When the CFP goes out I’ll let Chris Peikert at Michigan know (he works on lattice-based cryptography). Talk to you later!"
20160728 08:57:27 file 20231219/An item for the weekly_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Notification of upcoming draft call for submissions.
20160728 09:01:45 file 20240124/Re_ PQC FRN update_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing timing of call for proposals.
20160728 09:05:05 file 20240124/PQC FRN update_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Logistics.
20160728 09:20:18 file 20240215/Re_ PQC FRN - Comment Closing Date_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing timing of public comment period.
20160728 09:47:44 file 20231219/Re_ Post-Quantum Cryptography Requirements and ..._1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics regarding CFP.
20160729 02:14:09 file 20240215/Re_ New IP text_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussion of patent text and other text in call for proposals.
"Henry keeps saying he'll get it to us. Last night he said "first thing in the morning," which has turned into "sometime today." I've been having the other lawyers up there poke him for us whenever they see him today."
"Sara knows this might be something we need to finish on Monday morning. While certainly far from ideal, I think we handle that fine so long as there isn't a big problem with whatever text Henry provides."
20160729 08:28:00 file 20240215/RE_ Per our discussion_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"Still no sign of the CFP from the lawyers?" "None that I have received!"
20160801 02:01:05 file 20240405/RE_ Crypto Reading Club - Aug. 3_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks !"
20160802 02:22:20 file 20240325/Re_ Crypto Rump Session(1)_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"It is in the web. See the link http://csrc.nist.gov/groups/ST/post-quantum-crypto/index.html ."
20160802 02:31:09 file 20240325/RE_ Crypto Rump Session(3)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Sure, why not?"
20160802 04:37:00 file 20240405/Questions for 800-158 Review_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Is it reasonable to limit the scope of the document to “search resistance” (leaving authentication, collision resistance, online attacks, crypto misuse, and quantum-resistance out of scope)?"
20160802 08:01:11 file 20240405/News item for post-quantum crypto_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I’m sure you saw today’s FRN about the post-quantum crypto draft criteria: https://federalregister.gov/a/2016-18150 Besides posting it on the FRN page, could you please also post it as a CSRC News item and send it out via GovDelivery?"
20160802 10:25:07 file 20240325/Re_ Crypto Rump Session(2)_5.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Sure, my calendar is up to date. Or we can play it by ear."
20160803 09:00:00 file 20240325/RE_ Crypto Rump Session(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Made some changes. See attached."
20160803 12:58:38 UTC file 20240325/RE_ Crypto Rump Session(1)_2.pdf-attachment-Crypto2016-rump session-V2.pptx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft (?) slides for Crypto 2016 rump session.
20160804 01:09:51 file 20240405/Re_ News-level events_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing quantum progress, and discussing mechanisms for NIST to be notified of research results before the general public.
#weveshownallourwork
20160804 08:39:15 file 20240405/fortnightly Tuesday meetings_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Carl Miller just joined the Computer Security Division. His areas of research include randomness and quantum information processing. Could you add him to the mailing list for the Tuesday meetings, and grant him access to the shared folder?"
20160805 10:25:06 file 20240325/Re_ Crypto Rump Session_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Fixing typo.
20160805 11:59:59 file 20240405/NIST Seeks Comments for Post-Quantum Cryptograp..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Internal redistribution of public notice.
20160808 01:37:39 file 20240325/an accessible followup to my notes on min-entro..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Quantum information theory.
20160809 01:42:00 file 20240405/RE_ Where Are the Draft Criteria_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"The easiest way to find csd stuff is to be familiar with http://csrc.nist.gov . For the draft requirements and evaluation criteria, visit http://www.nist.gov/pqcrypto If you have any question to locate the stuff, please let me know."
20160809 07:54:26 file 20240405/Re_ Meeting to Discuss PQC Project_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Meeting logistics.
20160811 02:25:29 file 20240405/Re_ quantum information journal club(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Meeting logistics.
20160811 04:33:03 file 20240405/Re_ quantum information journal club_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
IT issues.
20160811 08:12:41 file 20240405/Re_ Can You Sign Me Up to the PQC Draft Proposa..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Yes. I'll do it next week when I am back."
20160815 10:37:00 file 20240405/Mail_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"https://s3.amazonaws.com/files.douglas.stebila.ca/files/research/presentations/20160812-SAC.pdf"
"https://github.com/open-quantum-safe/liboqs"
20160816 11:49:09 file 20240405/Re_ Talking to Outside Parties and Stakeholders_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Lily and Dustin can probably tell you more, but I think the simplest strategy is the following: you should talk with other people from your perspective as an independent researcher, NOT claiming to represent NIST's position."
"So, you can say that you think having more Ring-LWE challenges would benefit the whole PQC research community, which includes NIST. But write it in a way that indicates it is your personal opinion, not an official statement from NIST."
20160823 01:18:56 file 20240405/Re_ Open Quantum-Safe library_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I got it. Just did a quick look at it, but I image we can make them work together. Seems like the interface between the two might be algorithm specific."
20160826 04:16:24 file 20240405/Re_ Number of Papers to Add_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing additions of papers to some list.
#needmorerecords
20160829 02:00:21 file 20240405/RE_ PQC Workshop - 2018(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Conference logistics.
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
20160830 11:53:37 file 20240405/RE_ PQC Workshop - 2018_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Conference logistics.
20160831 04:04:00 file 20240325/Comp Registrations RE_ 2018 PCQ Attendees and ..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Yes, one author/speaker per submission was provided a complimentary registration. FYI - We also provided comp codes to NIST participants (so they were included in the total comp count)."
20160831 04:04:36 file 20240325/RE_ 2018 PCQ Attendees and Hotels_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Yes, one author/speaker per submission was provided a complimentary registration. FYI - We also provided comp codes to NIST participants (so they were included in the total comp count)."
20160831 10:22:00 file 20240325/FW_ 2018 PQC Attendees and Hotels_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"After discussing with the team, and based on the email below with thoughts, we feel good going with 150 attending our PQC Workshop. I was going to go back to Maria with that number. Will cc you. OK?"
20160831 12:45:18 file 20240325/RE_ 2018 PCQ Attendees and Hotels(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I believe they did...I can confirm to be sure, but they may take a day or two."
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.
20160912 18:44:49 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-ETSI-2016-0909dm.pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Looks like ETSI-2016-0909.docx.
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:37:25 file 20231110/Re_ FW_ [csa-announcements] Quantum-Safe Securi...(1)_2.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Politics.
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 11:57:15 file 20231110/Re_ FW_ [csa-announcements] Quantum-Safe Securi...._1pdf.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Politics.
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 file 20240311/Foreign travel trip report_1.pdf-attachment-Foreign Trip Report-ETSI-Quantum-Safe-2016.doc:
Notes from djb, last edited 20240311 19:56:24 UTC:
Same as the other version?
#nsa
20161003 01:19:15 file 20240311/Foreign travel trip report_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Discussing draft of report on foreign travel.
#nsa
20161003 11:51:04 file 20240325/Re_ Foreign trip report_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"No comments from me. This looks good."
20161003 11:59:04 file 20240325/Reminder - internal PQC meeting tomorrow at 9_3..._2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"We will go over the public comments we received on our draft call."
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"
20161004 01:54:22 file 20240325/RE_ Post PQC comments_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I think we shall post the comments we received."
20161004 03:22:45 UTC file 20240311/FW_ First draft_ VCAT Presentation on NSCI_2.pdf-attachment-NSCI_forVCAT.pptx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Slides on public high-performance computing.
20161004 03:27:09 file 20240311/FW_ First draft_ VCAT Presentation on NSCI_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Ronald Boisvert had sent a message to ten NIST people; this is forwarding that message.
20161004 04:22:23 file 20240311/RE_ Re_ randomness at Science Day_4.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Discussing a poster on quantum randomness.
20161004 07:55:22 file 20240318/Re_ Speaker Registration, Agenda, Etc.(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Please begin follow-ups. I can attend the meeting with you on Thursday. We will get back to you later today regarding a time frame for the agenda."
20161004 10:30:34 file 20240318/pqc draft call website_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Pointing to http://csrc.nist.gov/groups/ST/post-quantum-crypto/documents/call-for-proposals-draft-aug-2016.pdf.
20161005 01:08:53 file 20240325/Re_ RNG _ FPGAs_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for the info. I’ll look into it."
20161005 02:16:32 file 20240311/FAQ entry for CCA_CMA query complexity_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft FAQ entry. Looks like what ended up being posted.
20161005 02:40:14 file 20240311/Re_ First draft_ VCAT Presentation on NSCI_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"The slides were pretty good either way and I suspect will be needed again."
20161005 08:48:40 file 20240311/Re_ internal PQC meeting(2)_3.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Sorry I had to miss yesterday. Can I get a brief fill-in on any important decisions etc. that were made?"
20161005 09:41:00 file 20240311/RE_ internal PQC meeting(1)_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Lists (draft) decisions regarding many "minor" issues that had been raised by the public, as the result of a meeting on 4 October 2016.
#weveshownallourwork
"Skipped the IPR/legal stuff. Lily and I have a meeting with the NIST lawyers to address it."
"Submitters don’t have to give parameters for all 5 levels. Especially as parameters for one level are automatically parameters for all lower levels." Later NIST criticized submissions that had gaps in their lists of parameters. #inconsistency
20161005 12:00:29 -0400 file 20230925/revising our PQC paper_4.pdf-attachment-KRACABCSMMES-v2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Draft paper "Key Recovery Attack on the Cubic ABC Simple Matrix Multivariate Encryption Scheme".
20161005 13:40:00 UTC file 20240311/RE_ internal PQC meeting(1)_2.pdf-attachment-final CFP.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20161006 09:38:21 file 20240318/Re_ Speaker Registration, Agenda, Etc._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I just registered using the comp code."
20161006 12:22:43 file 20240325/Re_ chat on Tues re_ quantum crypto_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks. Will do."
20161007 04:05:14 file 20240325/RE_ bullets for crypto_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks Matt."
In previous message: "Engaged and Led International Efforts in QRC at U of Waterloo, QSafe in Fukuoka Japan, BSI and Fraunhofer in Germany."
20161007 10:10:16 file 20240311/latest version of Key Management write-up_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Discussing internal reports.
"The latest version of key management write-up is attached."
"Please finish your reviews and comment makings by the end of this week!"
20161007 14:04:00 UTC file 20240311/latest version of Key Management write-up_1.pdf-attachment-Key Management_version 3.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Text on key management. No obvious connection to post-quantum crypto.
20161010 03:15:26 file 20240325/Re_ Reminder - internal PQC meeting Tuesday 9_3..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Meeting logistics.
20161010 03:21:57 file 20240311/Re_ internal PQC meeting_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Ok, I’ll come for the first hour. (That last meeting wasn’t in my area of expertise but this one might be closer.) See you then!"
Thread is talking about a meeting on 11 October 2016: "A big part of the discussion tomorrow will be on how to define quantum security."
#scramble
#weveshownallourwork
20161012 04:11:07 file 20240325/Re_ Tomorrow's TWG_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I will be there."
20161012 08:46:43 file 20240311/FW_ ITL Science Day_3.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Please notice that two posters from our group will participate in the Science Day poster session. 8:30-12:30 Post-Quantum Cryptography by PQC team 1:20 – 3:20 Lightweight Cryptography by Lightweight Crypto team"
#weveshownallourwork
20161012 13:43:00 UTC file 20240311/FRN for PQC_1.pdf-attachment-final CFP.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20161013 02:35:00 file 20240318/RE_ PQC comments summary_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I don’t have any pre-determined length in mind. It doesn’t need to be long. Just however long it ends up being. I think we also want to avoid naming commenters by name. We just want to summarize what the comments said. Hope that helps."
20161014 09:43:02 file 20240325/Re_ Final versions of pQC and ECC_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I just updated it. I was slow to do so."
20161017 02:39:23 file 20240311/FRN for PQC_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"I don’t want to get delayed again by the FRN, so to get the ball rolling I’ve made a draft for the PQC FRN. I made it very simple, just basically pointing to our webpage for all the details. Let me know if you think I need to add anything. Andy, I’ve also attached the latest version of our Call. I believe you were wanting to strengthen the text where we state our preference for royalty-free. That occurs in the final paragraph before Section 2.D.1. Do you want to edit it? If you want, we can also add a bullet 4.C.3 to list our IPR preference as one of the evaluation criteria. Does that seem a good spot to you?"
20161017 08:48:22 file 20240311/FW_ ITL Science Day Follow-Up - Poster Awards_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Congratulations!"
20161017 10:51:57 file 20240318/post quantum_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I was downstairs chatting with Lisa and Gordon stopped by, so we ended up talking about your competition. Gordon thinks you are free to go free only. He thinks this is a local decision based on your analysis on how to best accomplish your mission. He has talked to Henry about this. He seemed surprised that CSD is going with the compromise position. He doesn’t think this is necessary. Lisa is happy to do anything she can to document this and help you. I am presuming you are lightweight cryptoing. I’ll be around later today. Or talk to Lisa."
Which Lisa and Gordon is this referring to?
One guess is that "free only" means requiring submissions to be patent-free: i.e., this is saying that the computer-security division was allowed to have that requirement but, to the surprise of others in NIST, didn't. If that's the correct interpretation, why didn't the division do this? #inconsistency #slowingdownpqcrypto #needmorerecords
20161017 18:32:00 UTC file 20240311/FRN for PQC_1.pdf-attachment-PQC FRN 2.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Editing draft Federal Register notice.
20161017 18:32:00 UTC file 20240318/PQC FRN_1.pdf-attachment-PQC FRN 2.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FRN.
20161018 01:26:15 file 20240318/Re_ New API_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Mucho gusto"
20161018 01:29:52 file 20240318/FW_ New API_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Sending around API.rtf.
20161019 01:55:36 file 20240318/Please give any comments on the proposed changes_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I’ve attached the latest version of the CFP. Please everybody read it by next Wednesday October 26th, and let me know of any wording changes that you suggest. We very carefully checked our original CFP, and I want lots of eyes on our proposed changes for the revision. Ray is still going to be editing 4.A.5, so don’t worry too much about that section. We’ll also be removing section 4.A.6 to the FAQ. I’ve attached Larry’s API, and the newest FAQ questions that people have written."
20161019 09:57:56 file 20240325/Re_ NIST SP 800-90 series_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Meeting logistics.
20161019 11:53:00 file 20240325/RE_ Typos_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks!"
20161019 12:31:58 file 20240311/FW_ ITL Science Day Follow-Up - Poster Awards(1)_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Congratulations on a great poster and presentation!"
Replying to "Best Poster Award" being given to four posters including: "Post-Quantum Cryptography - Dustin Moody, Lily Chen, Ray Perlner, Rene Peralta, Daniel Smith-Tone, Jacob Alperin-Sheriff, Carl Miller, Yi-Kai Liu and Stephen Jordan"
20161019 17:16:00 UTC file 20240318/Please give any comments on the proposed changes_1.pdf-attachment-new FAQ.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Some FAQ entries.
20161019 17:49:00 UTC file 20240318/Please give any comments on the proposed changes_1.pdf-attachment-final CFP v3.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161024 11:18:00 file 20240325/RE_ PQC Bi-Weekly Meetings into 2017_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"It couldn’t hurt to extend it through April of 2017. Thanks for the reminder on Dec. 9th."
20161024 11:50:00 file 20240318/RE_ Meet today or tomorrow_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Logistics.
20161024 11:50:40 file 20240318/FW_ Meet today or tomorrow_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Logistics.
20161025 12:56:30 file 20240318/PQC docs_9.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Attached are the most recent versions of the FAQ and CFP. Please use them as you edit. Here are the assignments: Daniel – edit your FAQ bullet Ray – write a post summarizing our approach to quantum security in the CFP for the pqc-forum Yi-Kai – edit Ray’s FAQ bullets on quantum security, in addition to 4.A.5 Dustin – write a post summarizing our changes dealing with KEMs, along with the API to be posted in the pqc-forum Jacob – write a summary of the comments and how we responded to them Daniel, Ray, Yi-Kai (and myself). Please get these done this week. Next week we hit November."
20161025 16:23:00 UTC file 20240318/PQC docs_9.pdf-attachment-FAQ 2.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FAQ entries.
20161025 16:52:00 UTC file 20240318/PQC docs_9.pdf-attachment-final CFP v4.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161026 01:41:44 file 20240311/FW_ News Clips from Wednesday, October 26, 2016_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Nothing obviously relevant to post-quantum crypto.
20161026 02:55:29 file 20240318/RE_ PQC website question_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Sorry for the confusion. Yes, the new version of CSRC will have an FAQ “feature” that is particular to a given project, such as PQC. The Answer field will have the superscript and subscript capability, and we can turn on that capability in the Question field if you think you’ll need it. When the new version of CSRC is rolled out early next year, PQC will be there, and anyone going to www.nist.gov/pqcrypto or to http://csrc.nist.gov/groups/ST/post-quantum-crypto/ will automatically be redirected to the new site (which will probably be “csrc.nist.gov/projects/post-quantum-crypto” we can set up additional aliases, too, such as “csrc.nist.gov/projects/pqcrypto”."
20161026 03:08:52 file 20240325/updated pqc-forum post on KEMs_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Does this seem fine to you?"
20161026 03:16:29 file 20240325/updated draft post for pqc-forum on KEMs_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here’s updated text for a post on the pqc-forum to get feedback to our approach with KEMs."
20161026 03:20:16 file 20240325/Re_ Someone from 772 interested in PQC_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I know who he is. He sometimes came to reading club. Meltem knows him as well. His supervisor talked with me a couple of years ago. I told his supervisor that he can attend our meetings and contribute to our project. But he has never directly talked with me."
"Let me talk with him when I am back."
20161026 03:22:07 file 20240318/Re_ PQC docs(4)_7.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I made some edits to the CFP and FAQ, mainly having to do with quantum security."
"Ray, I didn't change any of your meanings, I just revised the text to make it clearer. What do you think?"
"In particular, I'm much more comfortable now with your approach to measuring quantum security. But it really requires a lot of explanation to see why it makes sense. This was hard to follow in the earlier drafts of the CFP and the FAQ, but I think it is much clearer now."
"Lily, sorry I didn't see your comments while I was editing the draft. Anyway, we can still edit some more."
20161026 03:48:36 file 20240318/Re_ PQC docs(3)_6.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Let me try to start reading about it."
20161026 04:30:55 file 20240311/RE_ First cut at a summary of our thinking on s..._1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Important thread shedding light on the major changes in security-level requests between the draft call for submissions and the final call for submissions.
#weveshownallourwork
#scramble
20161026 05:24:22 file 20240318/RE_ PQC docs(1)_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here are my comments on Yi-Kai's edits to section 4.A.5. For the most part, I like them, but I did think some stuff should be moved to footnotes, and there was about a paragraph worth of material in the intro which seemed confusing, and looked like it could be eliminated without doing too much damage. As for the stuff concerning simple heuristics for assigning security categories, if you just know the classical security strength, and that there are only generic quantum speedups, I think it can be moved to the FAQ, but at the same time, I worry that not everyone will read the FAQ, and I'd like to at least allude in the CFP to the fact that, if you're just concerned about making sure you're in the appropriate security strength category, and not about quantifying your security margin, it isn't so hard to do it."
20161026 09:59:54 file 20240325/Proposed post to the pqc-forum on KEMs and the API_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"We’d also like to get some feedback on our approach to using KEMs, as that was the other main area of comments we received. I’ve written a first attempt at such a post to be made on the pqc-forum (see below). Let me know what you think by the end of this week. We also plan to post the updated API, so we can let some of the more knowledgeable people in that field give us their input."
20161026 11:57:33 file 20240318/Re_ PQC docs(5)_8.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Attached please see my comments on CFPv4. I noticed that we added a fairly amount of details and explanations. The details and explanations help people understand what we are asking for. On the other hand, the details often need to be handled more carefully and think about the impacts. Here are two places I feel we shall check. 1. KEM concept. In the current draft, we consider an ephemeral DH like scheme (e.g. New Hope) as a KEM. Then converting KEM to a public-key encryption is not intuitive at all. I cannot see why we need it other than security proofs. The recipient will need to send something in order to receive "public key encrypted" something. Usually, for public key encryption, we use static public key, not ephemeral public key. Furthermore, we have to assume an authenticated encryption (like GCM), which in my opinion, is not very reasonable. What we really need is (1) public key encryption (use either ephemeral or static public key) (2) Key agreement (like ephemeral DH). In practice, we may need to convert (1) to (2) (use one time public key), not from (2) to (1). Please notice that, in 56B KEM-KWS is to use RSA to "encapsulate" a value, then derive a key from the "value" and used it to do key wrap. The KEM in 56B is different from what we called KEM. 2. Quantum security levels (1, 3, 5) vs. (2, 4 ). I understand that for two algorithms A and B with parameter sets providing 128 bit classical security. If A satisfies level 1 quantum security while B satisfies level 2 quantum security, then we are in favor of algorithm B. However, A and B must be from different families, they will not be compared only on quantum security levels in the future but other properties. I also feel that level 2 is a special case of level 1. Level 1 means Groverizer effect less than 100%, assuming 100% is to make square root of classical security level, while Level 2 means Groverizer effect equal to 0% meaning no effect at all. Again, a give algorithm will fit into either (1, 3, 5) or (2, 4) with parameter choices. A given algorithm will never reasonably provide 1, 2, 3, 4, 5 levels with different selection of parameters. Introducing levels 2 and 4 complicated our statement."
20161026 12:00:00 UTC file 20240318/Re_ PQC docs(5)_8.pdf-attachment-llc-final CFP v4.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
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 18:27:00 UTC file 20240318/Re_ PQC docs(4)_7.pdf-attachment-final CFP v4-YKL.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft 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 19:10:00 UTC file 20240318/Re_ PQC docs(4)_7.pdf-attachment-FAQ 2-YKL.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FAQ entries, with editing notes showing more arguments about security levels.
#weveshownallourwork
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.
20161026 21:14:00 UTC file 20240318/RE_ PQC docs(1)_4.pdf-attachment-final CFP v4-YKL-Ray.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
Editing notes discuss security levels. Should compare to other versions around this time.
20161027 02:23:40 file 20240318/Re_ PQC docs(2)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I cleaned up Ray's comments on Yi-Kai's revision, and added references in the footnotes, etc. The ball is back in Yi-Kai's court. Can you take a look at Ray's outstanding comments (there aren't too many), and see if what he proposes is acceptable. Also, decide if the end of 4.A.5 stays or goes in the FAQ. I've also attached the FAQ so you can see what it currently has."
20161027 05:02:57 file 20240318/Re_ PQC docs(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Sure, I am fine with everything Ray has suggested."
"Regarding the 2nd paragraph of 4.A.5, I agree with Ray that it is a bit confusing, however I don't want to delete it entirely, because it explains some of the motivation that is behind the security strength categories. Can we cut the confusing parts but keep the rest, like this? (I also inserted this in the Word document, see attachment.)"
" "Because of these uncertainties, NIST is taking a conservative approach in laying out its security requirements. NIST is formulating these requirements in a way that will ensure security in a variety of scenarios, representing a broad range of possibilities regarding the future development of both classical and quantum computing technologies. In addition, NIST recommends that submitters exceed these minimum requirements by some suitable margin, in order to account for possible uncertainties in their own estimates of security strength." "
20161027 07:52:04 file 20240325/Re_ Real World Crypto_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I will be talking about post-quantum crypto. I am glad you are going too"
20161027 08:10:59 file 20240318/Re_ PQC docs_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Sure, I think that sounds fine. I can live with that."
20161027 18:15:00 UTC file 20240318/Re_ PQC docs(2)_3.pdf-attachment-final CFP v4.3.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
Editing notes include security levels. Looks like a subset of what's in other drafts.
20161027 18:16:00 UTC file 20240318/Re_ PQC docs(2)_3.pdf-attachment-FAQ 2.1.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FAQ entries, with notes showing arguments about security levels.
#weveshownallourwork
20161027 20:56:00 UTC file 20240318/Re_ PQC docs(1)_2.pdf-attachment-final CFP v4.3 YKL.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
Security levels in edit notes. #weveshownallourwork
20161028 01:10:59 file 20240318/Mail_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"We certainly do not intend to disqualify Diffie-Hellman type PQC key exchange algorithms from being submitted to us. If you look at the API we are suggesting to use, we believe that schemes such as New Hope and the SIDH can fit the KEM framework."
20161028 09:41:43 file 20240311/(preliminary) final versions of CFP and FAQ_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Everyone, "Ray and Yi-Kai came to consensus on the quantum security section of the CFP. Yay! As a result, we’ve now resolved all the comments. See the attached versions of the CFP and FAQ. We plan to post on our approach to quantum security, our change regarding KEMs, and the API on the pqc-forum today. We’ll see what feedback we get, which may prompt us to do one more round of editing as a result."
20161028 11:08:25 file 20240311/RE_ (preliminary) final versions of CFP and FAQ_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
"Thanks for noting that. The FAQ will get sent to Sara, and she then formats it and posts it (not as a word document, but on a web page). I’ll try and fix it, and she’ll probably re-format as well."
20161028 12:29:00 UTC file 20240311/(preliminary) final versions of CFP and FAQ_2.pdf-attachment-FAQ 2.2.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft FAQ.
20161028 13:34:00 UTC file 20240311/(preliminary) final versions of CFP and FAQ_2.pdf-attachment-final CFP v4.4.docx:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft CFP.
20161028 13:34:00 UTC file 20240318/PQC FRN_1.pdf-attachment-final CFP v4.4.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161028 13:34:00 UTC file 20240318/PQC forum archive link_2.pdf-attachment-final CFP v4.4.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161028 13:34:00 UTC file 20240318/PQC summary_3.pdf-attachment-final CFP v4.4.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161031 01:55:00 file 20240318/PQC forum archive link_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here’s a link to the archive for viewing the past pqc-forum messages: https://email.nist.gov/pipermail/pqc-forum/"
"Also, Ray told me you’d like to possibly add in some text to the CFP to try and clarify what we’re talking about with KEMs. Feel free to do so. The CFP is attached."
20161031 02:00:00 file 20240318/RE_ PQC forum archive link_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing IT issues.
20161031 02:22:21 file 20240325/Re_ [Pqc-forum] API for PQC algorithms_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I'll subscribe you so you see all the future messages. I don't think we need to respond right away (nor do I think we even have to respond). Just wanted you to be aware."
20161031 03:30:58 file 20240318/Minor Change trying to Clarify the issues raise..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I added a paragraph in Section 2.B.1, pursuant to a discussion Ray and I had today."
20161031 06:26:20 file 20240311/Re_ 2 travel requests for January(1)_2.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Discussing travel to QIP.
20161031 06:33:00 file 20240311/Re_ 2 travel requests for January_1.pdf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Discussing travel to QIP.
20161031 10:45:00 file 20240318/PQC FRN_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Just wanted to check that we will be on pace to get out an FRN by the end of November? The draft FRN I wrote is attached. I made it very simple, just basically pointing to our webpage for all the details. Let me know if you think I need to add anything. I’ve also attached the latest version of our Call. I believe you were wanting to strengthen the text where we state our preference for royalty-free. That occurs in the final paragraph before Section 2.D.1. Do you want to edit it? If you want, we can also add a bullet 4.C.3 to list our IPR preference as one of the evaluation criteria. Does that seem a good spot to you?"
#slowingdownpqcrypto
20161031 10:49:48 file 20240318/PQC summary_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I just wanted to check on how it’s coming with a summary of the comments we received for the CFP (and a summary of our changes). The somewhat finalized CFP is attached. Let me know if you need help with anything."
20161031 10:59:55 file 20240318/Re_ PQC summary(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"It should be done in the next few days (unless I end up getting jury duty tomorrow, in which I will come in on Sunday to finish it up)."
20161031 11:40:34 file 20240318/Re_ PQC summary_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I am also very stuck on how to explain or defend the KEM-oriented changes. We changed key- agreement schemes to KEM, but they’re not the same things at all. It should be KEM = key transport, something else = key agreement."
20161031 12:40:32 file 20240325/Re_ Another question_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Okay, I guess Ray and I can figure it out"
20161031 15:56:00 UTC file 20240124/PQC FRN is almost ready_1.pdf-attachment-Comments to post unformatted.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Unformatted collection of comments on the call for proposals. Should compare to what was posted.
20161031 19:25:00 UTC file 20240318/Minor Change trying to Clarify the issues raise..._1.pdf-attachment-final CFP v4.4[2] tweaks by Jacob.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
"NIST is aware that a number of proposals have been made already for post-quantum key exchange protocols.. NIST expects that any cryptosystems it standardizes will be widely used as building blocks in protocol constructions, and welcomes descriptions of how a submission integrates into existing protocols. As all existing proposals for post-quantum key-exchange protocols that NIST is aware are built around KEM schemes, NIST believes that such key exchange protocols can be submitted in the form of a KEM scheme." #scramble
20161101 08:41:00 file 20240124/RE_ PQC FRN is almost ready_5.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing call for proposals.
20161101 09:14:23 file 20240124/Re_ PQC FRN is almost ready_4.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing call for proposals.
20161101 11:37:48 file 20240215/Re_ Minor Change trying to Clarify the issues r..._1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussion still struggling to understand the basic landscape of security goals for public-key encryption. #scramble
As context, NIST's draft call for proposals a few months earlier asked for "key exchange" without using any of the clearly defined terminology from the literature. In my comments on that draft, I wrote "What I suspect will be most important in the long run is a CCA2-secure 'KEM' ... [explaining what a KEM is and how it simplifies things] ... One can easily combine a KEM with an authenticated cipher to produce a full-fledged public-key encryption scheme. But this understates the utility of a KEM: the same session key can be reused to encrypt any number of messages in both directions, whereas wrapping the KEM in a public-key encryption scheme hides this functionality. Using this public-key encryption scheme to encrypt another level of a shared session key would be frivolous extra complexity. Why not let submitters simply submit a KEM, skipping the cipher? ... What NIST calls 'key exchange' in the draft sounds to me like a poorly labeled KEM with intermediate security requirements: chosen-ciphertext security seems to be required, but the interface sounds like it allows only one message before the key is thrown away. NIST should make clear if it instead meant a full-fledged KEM allowing any number of ciphertexts. ... Calling any of these systems 'key exchange' is deceptive for people who expect 'key exchange' to be a drop-in replacement for DH key exchange." I recommended that NIST allow submissions of public-key encryption schemes, KEMs aiming for IND-CCA2 security, single-message KEMs such as the original version of New Hope, and DH.
"The particular things that have been suggested but were left out were: 1) (what Dan Bernstein calls) DH functions, which were not supported because: a. They fit reasonably well into the KEM framework. (although we did explicitly mention that we would consider additional properties of DH functions, like asynchronous key exchange in section 4.C.1 of our CFP)"
One of the examples of "flexibility" in the draft of 4.C.1 was "optimized or implicitly authenticated" key exchange. But the literature demonstrates a vast range of uses of DH, starting with the original DH paper proposing that each user broadcast a long-term DH public key; with no further communication, each pair of users then has a shared secret, which can then be used for symmetric encryption and symmetric authentication.
This isn't just "optimized". It isn't just "asynchronous". It's a completely different data flow, where a linear number of broadcasts create a quadratic number of shared secrets. If the broadcasts are secure then the public keys authenticate all users.
The "KEM framework" also doesn't provide this. It's easy to convert DH into a KEM, but most proposed KEMs don't seem to correspond to DH.
A different use of DH is for servers to broadcast their public DH keys while each client makes up a short-term DH key to talk to a server. The short-term key no longer identifies the client: that's bad for applications that need client authentication, but it can be good for applications where client identities should be private, such as basic web browsing. This one-sided use of DH is something where KEMs are good enough: the server broadcasts a public KEM key, and each client sends a KEM ciphertext.
Yet another use of DH is for both the client and the server to make up short-term DH keys. (For KEMs, the server makes up a short-term KEM key, and the client sends a KEM ciphertext, or vice versa.) This has the advantage of allowing secret keys to be erased after a little while, so an attacker stealing hardware from both sides can't retroactively decrypt recorded ciphertexts. The disadvantage is that these keys no longer identify either side, so an attacker can jump in the middle. One way to address this is with the server signing the key exchange, as in TLS; an alternative that's usually better is to replace the server's long-term signing key with a long-term encryption key, combining the second and third uses of DH (or these two uses of KEMs).
Is it possible that NIST's perspective on DH is limited to the third use case, and specifically the extreme of having each DH key used just once? That NIST simply doesn't understand the importance, in the literature and in reality, of DH keys as long-term public keys?
This blindness would explain why NIST's KEM decisions have repeatedly highlighted key-generation time plus enc time plus dec time as a performance metric. It would explain why NIST thinks DH fits into "the KEM framework", merely having some "additional properties" that might allow "optimized" key exchange.
Back to this FOIA document: "b. There is no widely accepted security definition. (that we know of)."
#error A call for DH proposals would have cited a security definition from https://eprint.iacr.org/2012/732 (which wasn't the first paper on the topic, but proves relationships between different definitions). Of course, this would have required whoever was writing the call to be aware of the literature.
"Plausible security requirements (e.g. secure static-static key exchange) have not been met by any postquantum DH-like scheme that we know of"
#error As the same paper notes, one can use zero-knowledge techniques to ensure static security. The paper doesn't cover any examples of post-quantum DH, but CRS had already been published years earlier. I had even noted this in my comments: "There is one notable post-quantum example of the DH data flow, namely isogeny-based crypto. Security analysis of isogeny-based crypto is clearly in its infancy, but if isogeny-based crypto does survive then the data flow will be an interesting feature."
Perhaps including DH in the call, rather than forcing DH to be rephrased as KEMs with extra "flexibility", would have usefully triggered submission of, and more attention to, CRS and other proposals for post-quantum DH. Or perhaps, for the sake of simplifying security review, it would have been best to focus from the outset on what I said I suspected would be the the most important target, namely IND-CCA2 KEMs. What's clear is that NIST's rationale for focusing on only three of the targets that I recommended, and excluding DH, consisted of ignorance of the literature.
This wasn't clear from the comments that NIST posted as part of a pqc-forum message a few days later (4 Nov 2016 18:17:28 +0000): "Diffie-Hellman is an extremely widely used primitive, and has a number of potentially useful special features, such as asynchronous key exchange, and secure key use profiles ranging from static-static to ephemeral-ephemeral. However, NIST believes that in its most widely used applications, such as those requiring forward secrecy, Diffie-Hellman can be replaced by any secure KEM with an efficient key generation algorithm. The additional features of Diffie-Hellman may be useful in some applications, but there is no widely accepted security definition, of which NIST is aware, that captures everything one might want from a Diffie-Hellman replacement. Additionally, some plausibly important security properties of Diffie-Hellman, such as a secure, static-static key exchange, appear difficult to meet in the postquantum setting. NIST therefore recommends that schemes sharing some or all of the desirable features of Diffie-Hellman be submitted as KEMs, while documenting any additional functionality."
The added qualifiers in this public text obscure the original mistakes that had led to NIST's decision. "Difficult to meet": sure, most schemes seem unable to do this, and the exceptions such as CRS took a while for the community to come up with; this doesn't capture NIST's actual, secret, rationale ("have not been met by any postquantum DH-like scheme that we know of"). "Everything one might want": well, sure, nothing does everything that one might want. "Potentially useful": the reader thinks that this is acknowledging that any particular application is potentially one of the applications where the extra features of DH are important. The reader doesn't realize that NIST simply doesn't realize the breadth of DH applications and is writing "potentially useful" to mean that some abstract property of DH has been identified that might potentially matter for some application someday.
If NIST had been transparent about what it was actually thinking then the public could have taken steps to correct the underlying errors. Instead NIST edited its text to hide what it was actually thinking.
#weveshownallourwork
20161101 12:39:00 UTC file 20240124/RE_ PQC FRN is almost ready_5.pdf-attachment-llc-PQC FRN 2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft announcement.
20161101 13:13:00 UTC file 20240124/Re_ PQC FRN is almost ready_4.pdf-attachment-PQC FRN 2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft announcement.
20161102 08:39:40 -0400 file 20240124/RE_ PQC Comments that we will want to post(1)_2.pdf-attachment-comments-draft-cfp-aug2016.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Some (?) public comments. Should compare to what ended up being posted.
20161102 08:43:00 file 20240124/RE_ PQC Comments that we will want to post(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing formatting of public comments to post.
20161102 08:54:58 file 20240124/RE_ PQC Comments that we will want to post_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing posting comments.
20161102 11:20:15 -0400 file 20240215/Re_ WERB(1)_2.pdf-attachment-cryptanalysis.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft survey paper.
20161102 11:34:44 file 20240215/Re_ WERB(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Asking for review of a draft paper.
20161102 12:49:03 file 20240215/Summary of Draft Comments and Changes_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Asking for document review.
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."
20161102 16:47:00 UTC file 20240215/Summary of Draft Comments and Changes_2.pdf-attachment-Draft Comments Summary.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of NIST summary of public comments on draft call for proposals.
20161103 08:47:20 file 20240215/Re_ Some rumor about lattice based_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing rumors about Shor attacking lattices.
20161103 10:32:30 file 20240215/Re_ Summary of Draft Comments and Changes_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Approving edits.
20161103 11:23:17 file 20240215/RE_ PQC 2018 - Meeting Purpose_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing statement of "meeting purpose" for "PQC 2018".
20161107 11:05:00 file 20240124/RE_ Quick discussion on PQC security posts in p..._3_Redacted.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing meeting logistics.
20161107 11:35:46 file 20240124/Re_ Quick discussion on PQC security posts in p...(1)_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing meeting logistics.
In a quoted message: "Quick discussion on PQC security posts in pqc-forum"; "I think it would be a good idea to talk about some of the posts we’ve had this last week or two in the pqc-forum."
#weveshownallourwork
20161107 11:59:00 file 20240215/RE_ PQC discusssion_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
In thread: "Let’s meet for a quick discussion on PQC posts. Shouldn’t be a long meeting. We’ll just meet in my office, as I think we’ll only have a handful of us. The main thing we want to discuss are the posts on security (Dan’s and Vadim’s)."
20161108 02:31:02 file 20240124/Re_ PQC FRN is almost ready_3.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"Here are some proposed IPR additions in Sections 2.D and 4.C.3. Let me know what you think. We’re still waiting to hear back the lawyers on the FRN, but as you saw, Jennifer and Henry are fine with our plan for the FRN."
20161108 04:08:15 file 20240124/Re_ PQC FRN is almost ready_2.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Editing call for proposals.
In a quoted message: "Here are some proposed IPR additions in Sections 2.D and 4.C.3. Let me know what you think. We’re still waiting to hear back the lawyers on the FRN, but as you saw, Jennifer and Henry are fine with our plan for the FRN."
In another quoted message: "I believe you were wanting to strengthen the text where we state our preference for royalty-free."
20161108 09:48:27 file 20231219/[Crypto-club] Reminder_ Crypto Reading Club - N..._1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Notice regarding internal talk on cost analysis of hash collisions.
20161108 16:54:00 UTC file 20240124/PQC FRN is almost ready_1.pdf-attachment-FAQ 2.3.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of FAQ.
20161108 19:29:00 UTC file 20240124/Re_ PQC FRN is almost ready_3.pdf-attachment-final CFP v4.4-ipr additions.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
This looks like where the following sentence was added: "For that reason, NIST believes it is critical that this process lead to cryptographic standards that can be freely implemented in security technologies and products."
Also where the following evaluation criterion was added: "4.C.3 Adoption Any factors that could hinder widespread adoption of the algorithm will be considered in the evaluation process, including, but not limited to, intellectual property claims and licenses granted to implementers. NIST will consider the assurances made in the statements by the submitter(s) and any patent owner(s), with a strong preference for submissions as to which there are commitments to license, without compensation, under reasonable terms and conditions that are demonstrably free of unfair discrimination."
Later this was removed as an evaluation criterion, although the text was still present elsewhere.
#inconsistency
20161109 14:12:00 UTC file 20240124/PQC FRN is almost ready_1.pdf-attachment-Draft Comments Summary v2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of NIST summary of comments on call for proposals.
20161109 14:12:00 UTC file 20240124/PQC files_1.pdf-attachment-Draft Comments Summary v2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of NIST summary of comments on call for proposals. Should compare to final public summary.
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
20161109 18:42:00 UTC file 20240124/PQC FRN is almost ready_1.pdf-attachment-final CFP v4.5.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Final (?) call for proposals.
20161109 18:42:00 UTC file 20240124/PQC files_1.pdf-attachment-final CFP v4.5.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Final (?) call for proposals.
20161110 02:18:07 file 20240215/Re_ WERB_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Acknowledging suggestions from internal reviewer of draft paper.
Reviewer: "I was surprised that you do not say much about cryptographic schemes that are resistant to all known quantum algorithms."
Reviewer: "I am not aware of an existing universal quantum computer with tens of qubits. Can you give a citation?"
20161114 10:59:12 file 20231219/PQC Asia forum talk_3_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Draft slides for a public talk.
Redacted email address. #needmorerecords
20161114 11:51:05 file 20231219/RE_ PQC Asia forum talk(1)_2_Redacted_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Discussing draft slides for a public talk.
20161114 12:14:00 file 20231219/RE_ PQC Asia forum talk_1_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Discussing draft slides for a public talk.
20161114 12:28:08 file 20231219/Re_ PQC API(1)_2.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Discussing API details.
20161114 15:41:00 UTC file 20240124/PQC FRN is almost ready_1.pdf-attachment-CFP announcement 2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft announcement of call for proposals.
20161114 15:41:00 UTC file 20240405/Re_ PQC FRN is almost ready(1)_2.pdf-attachment-CFP announcement 2.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft announcement.
20161116 10:15:00 file 20240124/PQC files_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"Attached are the current (final) CFP, as well as the response to comments received."
20161117 10:24:00 file 20240215/RE_ PQC_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussion of not having a "PQC meeting on November 25".
20161121 file 20240124/PQC FRN is almost ready_1.pdf-attachment-API v4.rtf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft API notes.
20161121 08:09:44 file 20231219/FW_ PQC API_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Editing API notes.
20161128 02:13:00 file 20240215/Re_ Can We Look at This Paper by Eldar and Shor..._1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Discussing paper by Eldar and Shor.
20161128 09:45:38 file 20240215/Re_ Meet today or tomorrow_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Logistics of meeting to discuss "our target security strengths".
What happened at that meeting? #needmorerecords
20161128 12:26:45 file 20240124/Re_ Quick discussion on PQC security posts in p..._1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"The paper has in fact been fully withdrawn so we’re not meeting tomorrow morning."
20161128 13:04:12 UTC file 20240124/PQC slides from various talks the past year_1.pdf-attachment-PQC Asia forum [Autosaved].pptx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Should compare to PQC Asia forum talk_3_Redacted.pdf.
20161129 02:52:44 file 20231219/RE_ (1)_2.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Editing FAQ.
20161129 03:02:23 file 20231219/FW_ 1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
FAQ editing.
20161129 03:29:26 file 20240215/trying to adress Yi-Kai's faq concerns_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
No text, just attachment.
20161129 03:43:03 file 20240215/update CFP_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Updating call for proposals.
20161129 05:21:45 file 20240215/Re_ Background reading on crypto_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
"Background reading on crypto"
Quoting Moody: "I’m probably not the best person to ask for symmetric crypto. Even for public key, I’m not sure which books are really good. I used Koblitz’s books, which are all pretty good. I never took a course on “crypto” really. I have heard of the Katz & Lindell book, so it’s probably pretty good. Sorry I’m not more help!"
Miller earlier in the thread: "I’m planning to do some studying of classical crypto, and I’m curious if you have any recommendations for good surveys or textbooks? Where I’m coming from is that I have a strong math background, and I’ve also dealt with the quantum versions of some classical crypto concepts, but I’ve not studied classical crypto formally. Thus something fairly broad/basic may be good to start. So far I’ve found this book: http://www.nowpublishers.com/article/Details/TCS-001 , which looks short and easily digestible. There’s also “Introduction to Modern Cryptography” by Katz & Lindell, but that seems to be very popular and it’s hard to track down a library copy. Talk to you later!"
#scramble
20161129 11:00:06 file 20240124/PQC FRN is almost ready_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Logistics.
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 19:50:00 UTC file 20231219/FW_ 1.pdf-attachment-FAQ 2.3 Ray.docx:
Notes from djb, last edited 20240112 23:05:08 UTC:
Draft of FAQ regarding call for submissions.
20161129 19:52:00 UTC file 20231219/RE_ (1)_2.pdf-attachment-FAQ 2.4.docx:
Notes from djb, last edited 20240112 23:05:08 UTC:
Draft of FAQ regarding call for submissions.
Dustin Moody comment: "This question makes the security strength categories seem somewhat permanent by lumping them with what we will standardize. Like Rene said, these are just our preliminary buckets to start comparing submissions. We don’t know how the categories/levels we want will evolve over the next several years." #inconsistency #weveshownallourwork
Dustin Moody comment regarding "clearly overkill" for categories 4 and 5: "Can we come up with a better phrase? Maybe “excessive”? Also, if we are stating it is overkill, people will wonder why we are asking for it. Need to give a reason why."
Dustin Moody deleting "Flexibility is generally a good thing, but it may be weighed against the complexity of implementing and testing for all available options.": Was this nevertheless used as a secret criterion for evaluating submissions? #needmorerecords
20161129 20:28:00 UTC file 20240215/trying to adress Yi-Kai's faq concerns_1.pdf-attachment-final CFP v4.6 Ray2.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
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.
20161129 20:41:00 UTC file 20240215/update CFP_1.pdf-attachment-final CFP v4.6.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of call for proposals.
20161130 01:23:23 file 20231219/RE_ FAQ Questions(1)_2.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics regarding FAQ.
20161130 01:27:29 file 20231219/RE_ FAQ Questions_1.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Logistics regarding FAQ.
20161130 03:55:15 file 20240215/Updated FAQ questions_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
No text, just attachment.
20161130 11:53:58 file 20231219/Re_ (1)_1_Redacted.pdf:
Notes from djb, last edited 20240112 23:05:08 UTC:
Content discussions of CFP editing. Sheds light on how some changes happened. #weveshownallourwork
20161130 12:02:00 file 20240124/PQC slides from various talks the past year_1.pdf:
Notes from djb, last edited 20240225 11:49:06 UTC:
Forwarding slides of various talks.
20161130 16:54:00 UTC file 20231219/RE_ FAQ Questions(1)_2.pdf-attachment-FAQ 2.4.1.docx:
Notes from djb, last edited 20240112 23:05:08 UTC:
Draft of FAQ regarding call for submissions.
20161130 16:54:00 UTC file 20240405/Re_ PQC FRN is almost ready(1)_2.pdf-attachment-FAQ 2.4.1.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FAQ.
20161130 16:54:00 UTC file 20240405/latest FAQ_4.pdf-attachment-FAQ 2.4.1.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FAQ.
20161130 20:54:00 UTC file 20240215/Updated FAQ questions_1.pdf-attachment-FAQ 2.4.1 Ray.docx:
Notes from djb, last edited 20240225 11:49:06 UTC:
Draft of FAQ.
20161201 09:35:32 file 20240405/RE_ FAQs_5.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Changes have been incorporated. Any word from Melissa?"
20161201 10:37:05 file 20240405/RE_ PQC - FRN Pub Date_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
FRN logistics.
20161201 15:09:00 UTC file 20240405/Re_ PQC FRN is almost ready(1)_2.pdf-attachment-final CFP 4.7 (1).docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161201 15:09:00 UTC file 20240405/latest CFP_1.pdf-attachment-final CFP 4.7.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161202 03:30:32 file 20240405/Welcome to Subversion_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Information about NIST's svn server.
20161202 07:56:56 file 20240325/A quantum talk at 10 today! If like to attend_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
No text.
20161208 02:56:00 file 20240405/PQC Website Menu Items_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Disussing web-page updates.
20161208 08:38:06 file 20240405/Re_ PQC FRN is almost ready(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161208 08:51:30 file 20240405/Re_ PQC FRN is almost ready_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161208 12:08:53 file 20240405/Re_ PQC Final CFP - Remove _Proposed__1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161208 19:44:00 UTC file 20240405/PQC Website Menu Items_2.pdf-attachment-PQC-RFC Screen Shot.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Screenshot of draft web page.
20161209 10:14:50 file 20240405/Re_ PQC Website Menu Items_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161212 01:10:00 file 20240325/CSD WERB Update_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"The following pub went to ITL today for review: NIST SP 800-185: SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash (Pub # 922422)"
20161214 01:30:28 file 20240405/latest CFP_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here you go!"
20161214 09:29:00 file 20240405/RE_ Bill Fefferman's visit -Jan. 11, 2017_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"You are on my list. I sent an update a few minutes ago. Hope you get it this time. The time is 10:00-11:00: Bill will give a talk. 11:00 – 12:00 Bill meet PQC team (Stephen and Carl would not be available that day, rest of us will meet Bill). The room number is A318, Building 222)"
20161214 10:38:25 file 20240325/CFP to be posted soon_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Andy just gave me an update on timing. The FRN should be coming soon, but is not quite ready. But, we’ve received the go ahead to post our CFP on our website tomorrow or Friday. When we do so, we’ll announce it on the pqc-forum, but I wanted to make sure you all knew it’s about to happen. Our deadline for submissions will be November 30, 2017."
20161214 12:32:23 file 20240405/Re_ WERB_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing a paper submission.
20161215 01:56:40 file 20240405/RE_ Final CFP(3)_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 02:32:47 file 20240405/RE_ Final CFP(2)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 02:36:00 file 20240405/RE_ Final CFP(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 02:59:10 file 20240405/RE_ Final CFP_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 03:20:10 file 20240405/Re_ WERB review for Stephen Jordan_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing a paper submission.
20161215 08:39:45 file 20240405/RE_ Final CFP(6)_9.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 09:36:21 file 20240405/latest FAQ_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"The two implementation FAQ questions are at the top. If you can get this back soon, it’d be best. We might post this afternoon."
20161215 09:55:58 file 20240405/Re_ latest FAQ_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing FAQ.
20161215 10:37:00 file 20240405/RE_ One addition to an FAQ question_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 11:42:00 file 20240405/RE_ Final CFP(5)_8.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 11:49:49 file 20240405/FW_ Final CFP(1)_7.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Changing CFP based on feedback from NIST lawyers.
20161215 11:53:56 file 20240405/FW_ Final CFP_6.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Per a previous email from Andy, I believe all headings and titles should have “proposed” removed. Final CFP 4.9 attached."
20161215 11:54:00 file 20240405/RE_ Final CFP(4)_5.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161215 13:31:00 UTC file 20240405/FW_ Final CFP(1)_7.pdf-attachment-final CFP 4.8 tracked changes.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161215 13:31:00 UTC file 20240405/FW_ Final CFP_6.pdf-attachment-final CFP 4.8 tracked changes.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161215 13:32:00 UTC file 20240405/FW_ Final CFP(1)_7.pdf-attachment-final CFP 4.8.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161215 13:32:00 UTC file 20240405/FW_ Final CFP_6.pdf-attachment-final CFP 4.8.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161215 14:53:00 UTC file 20240405/Re_ latest FAQ_3.pdf-attachment-FAQ 2.4.1-LB.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft FAQ, adding an entry on multiple cores.
20161215 16:52:00 UTC file 20240405/FW_ Final CFP_6.pdf-attachment-final CFP 4.9-proposed removed from headings.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft CFP.
20161216 02:21:59 file 20240405/xxx____1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Why does our final call for proposals say “Dated: xxx” at the bottom?"
20161218 01:35:00 UTC file 20240405/Re_ Project Summaries for Division Yearly -- Yo...(2)_3.pdf-attachment-quantum_randomness_summary.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Template for project summary.
20161219 08:31:52 file 20240405/RE_ one small fix_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing edit to published CFP.
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.
20161220 09:08:00 file 20240405/RE_ FRN - PQC Nominations_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
DIscussing web-page updates.
20161220 10:15:00 file 20240405/Re_ Project Summaries for Division Yearly -- Yo...(2)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here is a project summary about randomness for the quantum information section."
20161220 12:51:58 file 20240405/Re_ PQC Timeline_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20161220 21:42:00 file 20240412/Checklist and Evaluation Procedures from SHA-3_5.pdf-attachment-submission eval procedure (used for SHA-3).doc:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Hash Submissions Evaluation Procedure"
20161221 06:35:08 file 20240405/Re_ Project Summaries for Division Yearly -- Yo...(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Reporting two quantum-related projects.
20161221 07:00:37 file 20240405/Re_ Project Summaries for Division Yearly -- Yo..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Here is one more project summary, on "post-quantum cryptography." Thanks again, and sorry for being a bit late with this."
20161221 07:12:33 file 20240405/IEEE Software Magazine CFP_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Pointing to call for papers on software security. Not clear why this was included for this FOIA.
20161221 23:27:00 UTC file 20240405/Re_ Project Summaries for Division Yearly -- Yo...(1)_2.pdf-attachment-ykliu-project-summaries-2016.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Summaries of two Yi-Kai Liu quantum projects.
20161221 23:55:00 UTC file 20240405/Re_ Project Summaries for Division Yearly -- Yo..._1.pdf-attachment-pqc-project-summary-2016-final.docx:
Notes from djb, last edited 20240417 22:58:35 UTC:
Internal reporting of NIST's post-quantum project.
"While large quantum computers have not yet been built, they are believed to be a potential future threat to information security": So we can't say they are a potential future threat, but they're believed to be a potential future threat? Maybe?
"For this reason, NIST is taking steps to standardize new cryptosystems that are secure against quantum attacks": Where did the public CFP say that NIST specifically wanted new cryptosystems? #inconsistency
"NIST has identified a set of core requirements for post-quantum cryptosystems, including digital signatures, and various forms of key encapsulation, key exchange and key transport. This was done in order to focus attention on those functionalities that are the most useful for providing long-term security for commonly used Internet applications. In addition, NIST has proposed a technical approach for measuring the security of these schemes against quantum attacks.": If NIST had simply stuck to what the literature said, instead of making up its own path here, then it wouldn't have been able to advertise this activity in this report. Did this influence NIST to not stick to what the literature said? #needmorerecords
20161230 09:00:28 file 20240405/Re_ Visiting CalTech_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Travel approvals.
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
20170106 11:14:22 file 20240405/Re_ NAS forum for cyberresiliency(2)_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Talk logistics.
20170108 04:41:39 file 20240405/Re_ NAS forum for cyberresiliency(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Talk logistics.
20170109 02:05:00 file 20240405/PQC talks_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Now that we’re in a new year, we can start back up our pqc seminar. We don’t have anybody scheduled for any talk’s right now, so we need some volunteers. Please let me know if you have a paper/topic you’d like to speak on, and we can start creating a schedule."
20170110 05:37:03 file 20240405/Re_ NAS forum for cyberresiliency_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks, Lily. I think the audience is fairly technical and some people like Paul Kocher have the background for a deep dive while others like Bob Blakely understand the issues. Does that help? I would be happy to discuss this with the three of you if you like."
20170111 08:40:00 file 20240405/RE_ Inquiries about PQC competition_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Sounds to me like you got it."
In response to: "I just wanted to know if there’s any pitfalls that I should watch out for if someone is asking information about one of our competitions. ... And that we need to watch out for any unfair influence on the outcome of the competition."
20170111 09:41:00 file 20240412/RE_ PQC relevant talk_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Seminar logistics.
20170112 11:49:00 file 20240412/RE_ PQC post_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Discussing web-page updates.
20170116 04:43:00 file 20240412/Save the date_ QuICS Stakeholders Day Feb 28_3.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"The NIST/UMD Joint Center for Quantum Information and Computer Science (QuICS) will be holding its annual Stakeholders Day the morning of Tuesday February 28 in College Park."
20170117 05:29:41 file 20240412/Re_ Save the date_ QuICS Stakeholders Day Feb 28(1)_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Event logistics.
20170119 03:23:47 file 20240412/Re_ Save the date_ QuICS Stakeholders Day Feb 28_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Event logistics.
20170127 02:37:45 file 20240405/Re_ National Security Hires_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Sounds like "national security" exceptions were being made to normal NIST hiring procedures.
#nsa #needmorerecords
20170127 05:16:07 file 20240405/Re_ Multivariate crypto_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Ok, thanks a lot for the references. I may give a talk on this topic in the PQC seminar (it will be challenging to give a talk as a beginner in front of people who already know the subject, but I figure it’s a good way to learn :)). Suggestions for topics are also welcome. Talk to you later!"
20170131 03:22:44 file 20240412/Slides update_3.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Editing slides.
20170131 04:06:00 file 20240412/RE_ Slides update(1)_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Editing slides for upcoming talk.
20170131 04:41:00 file 20240412/RE_ Slides update_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Talk logistics.
20170131 05:08:00 file 20240405/RE_ IEEE S_P_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks for the samples. It will help a lot. I will need to submit the one with post-quantum crypto special issue before the end of February. If I submit a draft for the general issue, I will need to make a different angle, I guess. Let me think about. When I am working on special issue article, I might be able to get some ideas."
20170131 20:21:18 UTC file 20240412/Slides update_3.pdf-attachment-PQC-NAF-01312017.pptx:
Notes from djb, last edited 20240420 20:41:56 UTC:
Slides. Should compare to other version.
20170131 21:06:36 UTC file 20240412/RE_ Slides update(1)_2.pdf-attachment-PQC-NAF-01312017A.pptx:
Notes from djb, last edited 20240420 20:41:56 UTC:
Slides.
"Post-Quantum Cryptography and NIST Standardization"
"Lily Chen and Dustin Moody"
Where was this talk given? Was it public? #needmorerecords
"2012 – NIST begins PQC project"
"Research and build NIST team"
"NIST PQC team – The most significant in the first mile"
"Consists of 10 NIST researchers in cryptography, quantum information, quantum algorithms"
"Hold bi-weekly seminars (internal and invited speakers)" #weveshownallourwork
"NIST sees its role as managing a process of achieving community consensus in a transparent and timely manner" #claimingtransparency
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.
20170403 01:22:11 file 20230925/Re_ API_2_Redacted_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Quoted message: "I believe internally we've at least implicitly determined that we will be fine with non-NIST approved DRBG' s, as long as they are in fact sufficient for the randomness needs of the algorithm in question. This is why we're requiring a separate explanation of why a non-NIST DRBG will be used (whereas for a NIST-approved DRBG, we don't need a separate explanation because we've already authorized it essentially universally for DRBG needs)."
What ended up in the call for proposals was different: "If the scheme uses a cryptographic primitive that has not been approved by NIST, the submitter shall provide an explanation for why a NIST-approved primitive would not be suitable."
Asking for an explanation of why NIST primitives are not suitable is much more restrictive than asking for an explanation of why a non-NIST primitive is sufficient.
#inconsistency
20170403 02:02:41 file 20230925/FW_ API_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Secret discussion of randomness-generation issues. Was this ever made public? #weveshownallourwork
20170403 08:50:37 file 20230925/RE_ PQC seminar - talk about quantum cryptanaly..._3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Talk logistics, scheduling 12 May 2017 talk by Yi-Kai Liu on quantum cryptanalysis of block ciphers.
20170403 08:52:02 file 20230925/FW_ new paper.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Snap evaluation of Picnic vs. SPHINCS+. Was this ever made public? #weveshownallourwork
20170405 04:33:00 file 20231110/RE_ Selection Memo for the proposal of Universi...._1pdf.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Bureaucracy for a grant proposal from the University of South Florida.
20170406 08:45:11 file 20230925/pseudorandom generators with exponential security.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussing slow conversions of one-way functions to ciphers.
20170406 08:45:11 file 20240405/pseudorandom generators with exponential security_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussion of theoretical PRG construction.
20170407 02:55:00 file 20231013/RE_ Draft Fun Fact Friday for next week.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Proposing wording for a "Fun Fact Friday" hyping the cost of breaking RSA-2048: "A desktop computer would take a quadrillion (10^15) years–more than the age of the universe–to factor a 2048-bit integer (used) as RSA public-key used for Internet security."
Special-purpose attack hardware is much more effective per dollar than a desktop computer. Large-scale attackers have billions of dollars to spend on hardware every year. The computation required for breaking one RSA-2048 key is similar to the computation that Bitcoin carried out in 2022. Breaking many RSA-2048 keys isn't much more expensive than breaking just one.
One would think that an agency running a competition to protect against future quantum computers would understand enough about attack costs in 2017 to say "Wait a minute, RSA-2048 is very close to breakable already even without quantum computers, and this 'fact' is misleading our readers".
#scramble
20170407 11:43:35 file 20240412/Re_ Someone Is Testing Our DRBG requirements(1)_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Just let me know – or Dustin."
20170410 02:19:01 file 20240412/Re_ Someone Is Testing Our DRBG requirements_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"We are allowing a non-NIST-approved DRBG if they give a rationale for it. In that case, we need the max value we specify to get some sort of timing data for whatever they use. Let’s talk briefly tomorrow."
In fact, NIST punished submissions that used non-NIST symmetric crypto, even when rationales were given. #inconsistency
20170411 10:13:08 file 20230925/FAQ Q15 -- RE_ update PQC_3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussing web-page update regarding randombytes().
20170411 10:13:08 file 20240405/FAQ Q15 -- RE_ update PQC_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Yes. Only the first paragraph was modified."
20170411 10:38:44 file 20230925/RE_ update PQC.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Logistics of FAQ update.
20170411 10:38:44 file 20240412/RE_ update PQC_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Discussing web-page updates.
20170411 10:51:00 file 20230925/RE_ [Pqc] no PQC seminar this Friday_4.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Talk logistics, mentioning 31 March 2017 talk by Carl Miller on multivariate crypto.
20170411 10:51:00 file 20240405/RE_ [Pqc] no PQC seminar this Friday_4.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Are you good to speak this Friday? Let me know the topic, so I can send out an announcement."
20170412 02:45:59 file 20230925/[Pqc] PQC seminar this Friday__3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Internal talk logistics.
20170412 02:45:59 file 20240405/[Pqc] PQC seminar this Friday_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"The plan was to have a PQC seminar this Friday, at 10am. I have yet to confirm with the speaker, so this might end up being cancelled. I will provide an update once I know more."
20170412 03:05:00 file 20230925/RE_ PQC seminar this Friday__2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Scheduling meeting to discuss randombytes(). Was this ever made public? #weveshownallourwork
20170412 05:19:29 file 20240405/Re_ Getting into more detail_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Neural-network discussion.
20170412 12:11:49 file 20231013/Re_ DRBG-AES based implementation.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Describes eprint 2017/298 as showing "AES CTR DRBG is faster than Cha-Cha", and describes this as "interesting".
The cited paper is not, in fact, a study of AES performance or ChaCha performance. It's a paper on "An Investigation of Sources of Randomness Within Discrete Gaussian Sampling", briefly surveying 12 different software options. One option was AES-256 CTR-DRBG running at 383.69 megabytes/sec on a 3.4GHz Intel Core i7-6700 (Skylake), almost 9 cycles per byte. Another option was a very slow C implementation of ChaCha20 running at 106.07 megabytes/sec, i.e., 32 cycles per byte. Readily available benchmarks show publicly available ChaCha20 software running at 1.17 cycles/byte on Skylake (and ChaCha8 software running at 0.53 cycles/byte).
#scramble #weveshownallourwork
20170412 15:33:21 file 20230925/RE_ Document_2_Redacted_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Partially redacted discussion of an attack paper. #needmorerecords
20170413 03:16:00 file 20230925/revising our PQC paper_4.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussion of an attack paper.
20170413 12:25:52 file 20230925/[Pqc] PQC seminar postponed til next Friday_2.pdf:
20170413 12:25:52 file 20240405/[Pqc] PQC seminar postponed til next Friday_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"We will postpone our PQC seminar until next Friday, April 21st. Jacob will speak on “Discrete Gaussian Sampling-Techniques and Dangers”."
20170414 file 20230925/Re_ revising our PQC paper(1)_2.pdf-attachment-References.bib:
20170414 file 20230925/Re_ revising our PQC paper(2)_3.pdf-attachment-References.bib:
20170414 08:04:45 file 20240405/Re_ meeting recap_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing random-number generation for post-quantum systems.
#weveshownallourwork
20170414 08:16:00 file 20230925/FW_ PQC seminar postponed til next Friday_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Logistics regarding Alperin-Sheriff talk "Discrete Gaussian sampling—techniques and dangers". Was this talk made public? #weveshownallourwork
20170414 08:20:42 -0400 file 20230925/Re_ revising our PQC paper(2)_3.pdf-attachment-IAC2PCABCSMMES5.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Draft paper "Improved Attacks for Characteristic-2 Parameters of the Cubic ABC Simple Matrix Encryption Scheme".
20170414 08:28:06 file 20230925/Re_ revising our PQC paper(2)_3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussing an attack paper.
20170414 11:34:17 file 20230925/Re_ Trustworty Quantum Information conference.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussing a quantum-information conference.
20170414 11:34:17 file 20240412/Re_ Trustworty Quantum Information conference_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"I think that arXiv:1702.05178 would be excellent material for the audience at TYQI. I also don’t know if there’s a mechanism for contributed talks (in the past, it’s been most or all invited speakers). You could contact the organizers and see if they’re interested. I won’t get directly involved (to avoid any appearance of conflict of interest) but I’d be very interested to know the outcome. [smiley]"
20170417 file 20230925/Re_ revising our PQC paper(1)_2.pdf-attachment-IAC2PCABCSMMES5.tex:
20170417 file 20230925/Re_ revising our PQC paper(2)_3.pdf-attachment-IAC2PCABCSMMES5.tex:
20170417 01:34:46 file 20230925/Re_ CTR_DRBG for PQC.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussion of how to fit randombytes() into NIST's more complicated RNG interfaces.
"Do you know if all that PQC algorithms at least know how many RNG calls they’re going to need? If so, it would be really simple to just request enough bytes to meet them all (perhaps with two or three Generate requests)."
20170417 01:34:46 file 20240405/Re_ CTR_DRBG for PQC_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"If we implement the Instantiate function, then we need to provide Update with some provided_data from randombytes(). The other place we use Update is within the Generate function. Since we’re not going to accept any additional input, we would in principle call it only once, at the end of a Generate request. There, the provided_data is set to a block of zero bits."
"The Generate function is only allowed to generate up to 4096 bytes per call. So if you’re implementing a smart buffered form of Generate, you need to take this into account."
"Do you know if all that PQC algorithms at least know how many RNG calls they’re going to need? If so, it would be really simple to just request enough bytes to meet them all (perhaps with two or three Generate requests)."
20170417 03:40:00 file 20230925/RE_ revising our PQC paper_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussing paper-submission logistics.
20170417 10:14:42 file 20230925/Re_ Open Quantum Safe(1)_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"I'll look into it."
Quoted message: "I hope what we do is still compatible with the Open Quantum Safe project as well (https://openquantumsafe.org/). It says they use liboqs, which also includes common routines available to all liboqs modules, including a common random number generator and various symmetric primitives such as AES and SHA-3. Do they already have a NIST DRBG can you tell? From my un-expert eyes, it seems they might be using AES Ctr DRBG? See https://github.com/open- quantum-safe/liboqs"
20170417 10:14:42 file 20240405/Re_ Open Quantum Safe(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"I'll look into it."
Context: OQS RNG.
20170417 10:44:38 file 20230925/Re_ Open Quantum Safe_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"Given your last email about Open Quantum Safe I won’t spend too much time looking at what they have now. We can discuss internally the _KAT to _deterministic change."
20170417 10:44:38 file 20240405/Re_ Open Quantum Safe_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Given your last email about Open Quantum Safe I won’t spend too much time looking at what they have now. We can discuss internally the _KAT to _deterministic change."
20170417 11:58:32 -0400 file 20230925/Re_ revising our PQC paper(1)_2.pdf-attachment-IAC2PCABCSMMES5.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Draft paper: "Improved Attacks for Characteristic-2 Parameters of the Cubic ABC Simple Matrix Encryption Scheme"
20170417 11:59:53 file 20230925/Re_ revising our PQC paper(1)_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussing an attack paper.
20170418 03:18:42 file 20230925/Re_ MIT Club_3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
External talk logistics.
20170418 03:18:42 file 20240405/Re_ MIT Club_3.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Talk logistics.
20170418 03:34:45 file 20230925/RE_ MIT Club and Blockchain_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
External talk logistics.
20170418 03:34:45 file 20240405/RE_ MIT Club and Blockchain_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Talk logistics.
20170418 10:36:49 file 20230925/[Pqc] PQC seminar this Friday_1.pdf:
20170418 10:36:49 file 20240405/[Pqc] PQC seminar this Friday_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"We have a PQC seminar this Friday, April 21st. Jacob Alperin-Sheriff will speak on “Discrete Gaussian Sampling-Techniques and Dangers”."
20170418 12:23:28 file 20230925/Re_ annual report welcome letter.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"I think this is good. I would not be too concerned about including everything here but, if IDM and automation are future items, then perhaps a nod to what we are looking forward to along with PQC."
20170419 10:05:43 file 20230925/Update PQC forum.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"Now that we’ve heard back from Dan, it would be good to provide an update on the pqc-forum about the randomness issues (unless there is still something that needs to get ironed out with Dan)."
20170419 10:05:43 file 20240412/Update PQC forum_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Now that we’ve heard back from Dan, it would be good to provide an update on the pqc-forum about the randomness issues (unless there is still something that needs to get ironed out with Dan). The last we said on the forum is shown below:"
"Do you think you could write something we could post to let people know what we’re planning on?"
20170420 03:23:29 file 20230925/Re_ Slides for Talk(2)_3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Slides for internal talk.
20170420 03:23:29 file 20240412/Re_ Slides for Talk(2)_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Sending seminar slides.
20170420 03:57:43 file 20230925/Re_ Slides for Talk(1)_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Talk logistics.
20170420 05:49:53 file 20230925/Re_ Slides for Talk_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Talk logistics.
20170420 05:49:53 file 20240412/Re_ Slides for Talk_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Seminar logistics.
20170420 09:12:16 file 20231013/Re_ Conference Registration_1.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Discussing a conference.
20170420 15:19:36 -0400 file 20240412/Re_ Slides for Talk(2)_2.pdf-attachment-sample_slides.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"By Jacob Alperin-Sheriff"
"Discrete Gaussian Sampling-Techniques and Dangers"
Reviewing issues in miscellaneous samplers to use in signature systems.
20170421 file 20230925/Re_ Slides for Talk(2)_3.pdf-attachment-sample_slides.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Slides "Discrete Gaussian sampling—techniques and dangers".
Discussing sampling algorithms.
20170421 01:30:14 file 20230925/BERB review_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussion of a QCRYPT paper.
20170421 01:30:14 file 20240405/BERB review_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing QCRYPT submission.
20170421 02:51:26 file 20230925/Re_ BERB review_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussion of quantum randomness.
20170421 02:51:26 file 20240405/Re_ BERB review_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing QCRYPT submission.
20170421 12:09:22 -0500 file 20230925/BERB review_2.pdf-attachment-3764_001.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Internal review of a paper on quantum randomness aimed at QCRYPT.
20170421 12:09:22 -0500 file 20240405/BERB review_2.pdf-attachment-3764_001.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Scanned review form for QCRYPT submission.
20170424 03:53:34 file 20230925/Presentation_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"Thanks so much for once again presenting NIST's work in quantum resistant crypto to the MIT alumni club. They thoroughly enjoyed the briefing. I appreciate your time to do this. Your expertise and leadership in this space come out every time you talk with a group."
20170424 03:53:34 file 20240405/Presentation_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thanks so much for once again presenting NIST's work in quantum resistant crypto to the MIT alumni club. They thoroughly enjoyed the briefing. I appreciate your time to do this. Your expertise and leadership in this space come out every time you talk with a group."
20170424 11:54:49 file 20230925/RE_ Conference on IAC Calendar.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussion of naming and advertisement of the ""1st NIST PQC Standardization Conference”".
20170424 11:54:49 file 20240405/RE_ Conference on IAC Calendar_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Thank you. I can’t really think of other crypto sites."
20170425 03:20:00 file 20231110/University_of_South_Florida_Project_Description_1.pdf:
Notes from djb, last edited 20231110 16:46:46 UTC:
Bureaucracy for a grant proposal from the University of South Florida.
20170425 11:06:17 file 20230925/RE_ [nist-ai] Wiki address.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
NIST AI discussion.
20170425 11:06:17 file 20240405/RE_ [nist-ai] Wiki address_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
AI discussion.
20170426 03:10:00 file 20230925/RE_ FAQ small revision(1)_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussion of removing the following sentence from NIST's FAQ: "Randombytes should only be used to seed a NIST-approved DRBG."
20170426 03:15:00 file 20230925/RE_ FAQ small revision_1.pdf:
20170426 03:15:00 file 20240405/RE_ FAQ small revision_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discussing web-page updates.
20170426 19:09:00 UTC file 20230925/RE_ FAQ small revision(1)_2.pdf-attachment-FAQs-Historical. v3.docx:
20170428 02:02:02 file 20230925/Re_ People's Thoughts on Doing a Reddit AMA on ...(1)_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"Hey, that's an interesting suggestion. I'd be a bit concerned about doing this as an official outreach activity by NIST, because these long online conversations can generate a lot of vaguely-worded text that can later be taken out of context and misinterpreted by other people."
"However, I wonder if you can do this as a voluntary effort by a private citizen, not connected with NIST?"
20170428 02:02:02 file 20240405/Re_ People's Thoughts on Doing a Reddit AMA on ...(1)_2.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discouraging transparency: "these long online conversations can generate a lot of vaguely-worded text that can later be taken out of context and misinterpreted by other people"
#weveshownallourwork
20170428 02:11:10 file 20230925/Re_ People's Thoughts on Doing a Reddit AMA on ...._1pdf.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"I looked at the site you pointed. It is a good site for people to learn something casually. However, I do not feel it is necessary to put our PQC procedure there because maintaining could be resource consuming. It is also challenging to manage answering all the questions without risking certain bias or accidently misleading at this stage of our procedure."
"I feel that we have obtained sufficient publicity through research community, industry groups, as well as government agencies. If someone hasn’t heard us and our effort before, it is unlikely that they have been engaged in the mainstream research and practice in this area."
"On the other hand, it is worth to observe the discussions there since some opinions may be valuable and we haven’t had thought about."
20170428 02:11:10 file 20240405/Re_ People's Thoughts on Doing a Reddit AMA on ..._1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Discouraging transparency: "maintaining could be resource consuming. It is also challenging to manage answering all the questions without risking certain bias or accidently misleading at this stage of our procedure"
#weveshownallourwork
20170605 10:12:21 file 20240412/FAQ Update - FW_ [Pqc-forum] Clarifications Reg..._1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Discussing web-page updates.
20170616 03:03:48 file 20240412/checking in_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Did John send you what you needed to send to Dan?"
20170703 01:41:07 file 20240412/A few PQCrypto tidbits_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Internal followups to PQCrypto 2017 discussions.
#weveshownallourwork
20170706 02:56:21 file 20240412/Annual Repot Item_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Asking whether it's true that NIST's internal FY 2016 seminars included "a synopsis of security analyses".
#weveshownallourwork
20170707 08:56:11 file 20240412/RE_ Annual Repot Item_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Discussing internal NIST report.
20170717 09:18:16 file 20240412/Albrecht's estimator_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"I learned about this “estimator” "
"https://bitbucket.org/malb/lwe-estimator"
"Which is starting to be used by some to estimate parameters for providing concrete levels of security. Thought you’d be interested."
20170802 02:26:58 file 20240412/aes ctr drbg in openssl_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Quoting text on "FIPS Mode" from https://wiki.openssl.org/index.php/Random_Numbers.
20170809 02:48:43 file 20230925/Re_ API doc_1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Quotes various discussion of randomness. For example: "As a side note, is there any way we could convince Dan and/or the open quantum safe guys to write a script to generate KATs automatically, or write one ourselves?" In fact, SUPERCOP already did much more than this. #scramble
20170809 02:48:43 file 20240412/Re_ API doc_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"I think so. Like I said they will cover the generic tests."
20170809 11:12:24 file 20230925/API doc_3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Discussion of API documentation.
20170809 12:09:14 file 20230925/Re_ API doc(1)_2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
"Ok, sounds good. By the way, Ray is working a response to the API, because he doesn't think it does what we discussed."
20170809 12:09:14 file 20240412/Re_ API doc(1)_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Ok, sounds good. By the way, Ray is working a response to the API, because he doesn't think it does what we discussed."
20170814 04:32:03 file 20230925/Re_ Any updates we like to announce at crypto 2...(2)_4.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Planning rump-session announcements.
"For PQC, we can remind people of the “competition” and the dates Sept. 30 and Nov. 30. Submissions received by Sep 30 will get a quick review letting submitters know if they are missing anything. Nov. 30 is the final deadline. Full details at www.nist.gov/pqcrypto, including instructions how to sign up for the mailing list."
20170814 04:32:03 file 20240412/Re_ Any updates we like to announce at crypto 2...(2)_3.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Planning Crypto 2017 announcements.
20170815 20:09:11 UTC file 20230925/RE_ Any updates we like to announce at crypto 2..._2.pdf-attachment-Crypto Rump Session.pptx:
20170816 08:47:28 file 20230925/RE_ Any updates we like to announce at crypto 2...(1)_3.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Planning rump-session announcements.
20170816 08:47:28 file 20240412/RE_ Any updates we like to announce at crypto 2...(1)_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Planning Crypto 2017 announcements.
20170816 09:18:25 file 20230925/RE_ Any updates we like to announce at crypto 2..._2.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Planning rump-session announcements.
20170816 09:27:40 file 20230925/Re_ Any updates we like to announce at crypto 2..._1.pdf:
Notes from djb, last edited 20231001 22:32:48 UTC:
Planning rump-session announcements.
20170816 09:27:40 file 20240412/Re_ Any updates we like to announce at crypto 2..._1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Planning Crypto 2017 announcements.
20170816 12:45:59 UTC file 20230925/RE_ Any updates we like to announce at crypto 2...(1)_3.pdf-attachment-pqc crypto rump slides condensed.pptx:
20170816 12:45:59 UTC file 20240412/RE_ Any updates we like to announce at crypto 2...(1)_2.pdf-attachment-pqc crypto rump slides condensed.pptx:
Notes from djb, last edited 20240420 20:41:56 UTC:
Announcement slides.
20170830 02:25:20 file 20240412/FW_ Checklist and Evaluation Procedures from SHA-3_4.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"I modified similar documents Shu-Jen used for SHA-3. We will follow these to check submissions for being “complete and proper”. Yi-Kai, if you can, it might be nice to check that I didn’t miss anything in my checklist."
20170830 03:11:33 file 20240412/RE_ Checklist and Evaluation Procedures from SHA-3(2)_3.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"You’re not going to lock it all up?!?! [smiley]"
"I only changed my name from the old to the new procedure doc (replace with attached)."
20170830 03:19:02 file 20240412/RE_ Checklist and Evaluation Procedures from SHA-3(1)_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
Discussing (lack of) security for submission documents.
20170830 03:35:52 file 20240412/RE_ Checklist and Evaluation Procedures from SHA-3_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Do we need to indicate to them that even the current submission is complete and proper, you can modify and re-submit before 11/30 or we just do not say anything unless they ask? We certainly can worry this when we send the acknowledgement."
20170830 10:44:00 file 20240412/Checklist and Evaluation Procedures from SHA-3_5.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Here are a couple of things Shu-jen put together for SHA-3. Not sure if you’ve already thought about something along these lines or if these could be helpful in sorting submissions."
20170830 16:36:00 file 20240412/Checklist and Evaluation Procedures from SHA-3_5.pdf-attachment-Submission Checklist (used for SHA-3).doc:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Hash Candidate Submission Checklist"
20170830 18:40:00 file 20240412/FW_ Checklist and Evaluation Procedures from SHA-3_4.pdf-attachment-PQC submission eval procedure.doc:
Notes from djb, last edited 20240420 20:41:56 UTC:
"PQC Submissions Evaluation Procedure"
20170830 20:20:00 file 20240412/FW_ Checklist and Evaluation Procedures from SHA-3_4.pdf-attachment-PQC Submission Checklist.doc:
Notes from djb, last edited 20240420 20:41:56 UTC:
"PQC Candidate Submission Checklist"
20170830 20:59:00 file 20240412/RE_ Checklist and Evaluation Procedures from SHA-3(2)_3.pdf-attachment-PQC submission eval procedure.doc:
Notes from djb, last edited 20240420 20:41:56 UTC:
"PQC Submissions Evaluation Procedure"
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:
20171211 09:00:00 file 20240412/Another submission_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"I just uploaded a submission that was mailed here, and arrived on time. It’s got a long name, but I’m abbreviating it Asymmetric QCMDPC."
20171212 01:50:00 file 20240412/RE_ BIKE Submission_3.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"Okay, give me a few minutes and I’ll exit it."
20171214 09:39:17 file 20240412/BIKE review_2.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"I'm assuming you did it and it passed, but in looking at the checklists, I didn't see anything written down for the optical media portion on BIKE. Just double checking."
20171219 03:07:00 file 20240412/RE_ BIKE - 30 .pdf files_1.pdf:
Notes from djb, last edited 20240420 20:41:56 UTC:
"I don’t see DAGS in the Upload folder. It has a KATs folder, but not the DAGS folder"
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:25:04 -0500 file 20231110/LEDAcrypt_attack.pdf:
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:
20200806 13:10:01 UTC file 20231013/ledacrypt attack crypto.pptx:
20200806 13:10:15 UTC file 20231013/ledacrypt attack crypto final.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.
20200817 21:15:15 UTC file 20231013/ledacrypt attack crypto short.pptx:
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:
20230914 13:00:34 UTC file 20230925/[Pqc] PQC seminar this Friday_1.pdf-attachment-ATT00001.txt:
20230914 13:01:04 UTC file 20230925/[Pqc] PQC seminar postponed til next Friday_2.pdf-attachment-ATT00001.txt:
20230914 13:01:28 UTC file 20230925/[Pqc] PQC seminar this Friday__3.pdf-attachment-ATT00001.txt:
20230919 08:18:00 UTC file 20230925/API doc_3.pdf-attachment-API_080917.rtf:
20230919 10:35:36 UTC file 20230925/FW_ PQC seminar postponed til next Friday_1.pdf-attachment-ATT00001.txt:
20231115 15:05:00 UTC file 20231219/[Ispab] NIST response to ISPAB recommendation on Quantum Computing.pdf-attachment-ATT00001.txt:
20231204 09:16:40 UTC file 20231219/[Crypto-club] Reminder_ Crypto Reading Club - N..._1.pdf-attachment-ATT00001.txt:
20231204 09:19:42 UTC file 20231219/[Crypto-club] Google tests PQC_1.pdf-attachment-ATT00001.txt:
20231204 10:55:46 UTC file 20231219/[Itl_mgmt] Fw_ [Deputies] News Clips for Thursd..._1.pdf-attachment-ATT00001.txt:
20231215 09:57:00 UTC file 20231219/FW_ PQC API_1.pdf-attachment-API4.rtf:
20240123 09:35:44 UTC file 20240124/FW_ PQC Project Page Menu_1.pdf-attachment-image001.png:
20240123 09:36:12 UTC file 20240124/Re_ PQC Project Page Menu_2.pdf-attachment-image001.png:
20240207 12:29:04 UTC file 20240215/Re_ New IP text_1.pdf-attachment-image001.png:
20240207 12:33:50 UTC file 20240215/RE_ Per our discussion_1.pdf-attachment-image001.png:
20240307 08:53:40 UTC file 20240311/EXAMPLE FILES - Documents to soon post on PQC w..._1.pdf-attachment-API (1).rtf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Draft document on API.
20240307 08:53:40 UTC file 20240311/EXAMPLE FILES - Documents to soon post on PQC w..._1.pdf-attachment-IntermediateValues_2048.rtf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Intermediate test values for RSAES-OAEP-ENCRYPT.
20240307 08:53:40 UTC file 20240311/EXAMPLE FILES - Documents to soon post on PQC w..._1.pdf-attachment-KAT.rtf:
Notes from djb, last edited 20240311 19:56:24 UTC:
Test data for RSA.
20240307 08:53:40 UTC file 20240311/EXAMPLE FILES - Documents to soon post on PQC w..._1.pdf-attachment-VariableLabel_2048.txt:
Notes from djb, last edited 20240311 19:56:24 UTC:
Test data for RSAES-OAEP-ENCRYPT.
20240307 08:53:40 UTC file 20240311/EXAMPLE FILES - Documents to soon post on PQC w..._1.pdf-attachment-VariableMsg_2048.txt:
Notes from djb, last edited 20240311 19:56:24 UTC:
Test data for RSAES-OAEP-ENCRYPT.
20240307 12:21:10 UTC file 20240311/FW_ News Clips from Wednesday, October 26, 2016_1.pdf-attachment-ATT00001.txt:
Notes from djb, last edited 20240311 19:56:24 UTC:
Label for "Deputies mailing list".
20240313 14:11:12 UTC file 20240318/FW_ New API_1.pdf-attachment-API.rtf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft (?) API file.
20240314 09:20:58 UTC file 20240318/Please give any comments on the proposed changes_1.pdf-attachment-API.rtf:
Notes from djb, last edited 20240417 22:58:35 UTC:
Draft (?) API file.
20240318 12:13:24 UTC file 20240325/Re_ PQC API_1.pdf-attachment-image001.png:
20240318 14:18:46 UTC file 20240325/Re_ Sample documents for PQC Call For Proposals_1.pdf-attachment-API.rtf:
Notes from djb, last edited 20240417 22:58:35 UTC:
API notes.
20240318 14:21:12 UTC file 20240325/FW_ Sample documents for PQC Call For Proposals_6.pdf-attachment-API.rtf:
Notes from djb, last edited 20240417 22:58:35 UTC:
API notes.
20240318 14:21:12 UTC file 20240325/FW_ Sample documents for PQC Call For Proposals_6.pdf-attachment-IntermediateValues_2048.rtf:
Notes from djb, last edited 20240417 22:58:35 UTC:
RSAES-OAEP computer output.
20240318 14:21:12 UTC file 20240325/FW_ Sample documents for PQC Call For Proposals_6.pdf-attachment-KAT.rtf:
Notes from djb, last edited 20240417 22:58:35 UTC:
KAT overview.
20240318 14:21:12 UTC file 20240325/FW_ Sample documents for PQC Call For Proposals_6.pdf-attachment-VariableLabel_2048.txt:
20240318 14:21:12 UTC file 20240325/FW_ Sample documents for PQC Call For Proposals_6.pdf-attachment-VariableMsg_2048.txt:
20240401 13:25:43 -0400 file 20240405/FAQ-another modification to the pqc page_1.pdf:
Notes from djb, last edited 20240417 22:58:35 UTC:
"Ray would like FAQ #2 “Why are hash functions assigned fewer bits of quantum security than classical security?” and it’s answer put in the archive, instead of being one of our current FAQ."
20240402 07:43:36 UTC file 20240405/Re_ PQC FRN is almost ready(1)_2.pdf-attachment-API v4.rtf:
Notes from djb, last edited 20240417 22:58:35 UTC:
API notes.
20240403 11:38:50 UTC file 20240405/[Pqc] PQC seminar this Friday_1.pdf-attachment-ATT00001.txt:
20240403 11:39:06 UTC file 20240405/[Pqc] PQC seminar postponed til next Friday_2.pdf-attachment-ATT00001.txt:
20240403 11:39:22 UTC file 20240405/[Pqc] PQC seminar this Friday_3.pdf-attachment-ATT00001.txt:
