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 20240716, plus notes last edited 20240726 21:43:58 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: 130 #weveshownallourwork. 105 #inconsistency. 99 #error. 86 #needmorerecords. 43 #scramble. 38 #nsa. 37 #ftqcic. 28 #missingclarity. 20 #claimingtransparency. 14 #slowingdownpqcrypto. 11 #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.
20160721 05:12:22 file 20240716/RE_ Final Agenda for Vint Cerf Visit - Friday, ..._1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Lots of redactions. What happened here? #needmorerecords
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 !"
20160801 03:10:10 file 20240716/Re_ [Crypto-club] Crypto Reading Club - August 3.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Thanks." Regarding Miller being added to crypto-club mailing list.
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 09:56:00 file 20240716/FW_ [Crypto-club] Reminder - TODAY _ Crypto Rea....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Daniel Smith-Tone will give a talk titled Multivariate Cryptography with “Big” Algebraic Structures. Abstract: Since near the beginning of the history of multivariate public key cryptography there have been two basic strategies for constructing multivariate digital signatures and multivariate public key encryption schemes. These classes are often characterized as “Big Field” or “Small Field” schemes. Relaxing the definitions slightly we can encompass some more recent constructions, changing the moniker “Big Field” schemes to “Big Structure” schemes. We will discuss some of the basic techniques used to construct multivariate schemes, some of the new ideas for potentially achieving efficient encryption, and the main cryptanalytic techniques in this area. If there is sufficient time for preparation, we can play around with some computational examples."
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."
20160816 15:47:33 -0400 file 20240716/[Crypto-club] QCrypt public lecture - _Cryptogr....pdf-attachment-QCrypt_lecture_email.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Advertisement for lecture by Mosca.
20160817 11:57:45 file 20240716/[Crypto-club] QCrypt public lecture - _Cryptogr....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"As part of the QCrypt conference next month, we're having Michele Mosca give a public lecture on "Cryptography and Cybersecurity in the Quantum Era." If you're at all interested in this topic, I really recommend going. Michele is an excellent speaker, as well as an accomplished researcher."
20160818 01:52:39 file 20240716/Re_ [Crypto-club] QCrypt public lecture - _Cryp....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Discussing conference registration.
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.
20161028 13:34:00 UTC file 20240617/FW_ PQC forum archive link_1.pdf-attachment-final CFP v4.4.docx:
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.
20161123 08:34:15 -0500 file 20240507/PQC slides_1.pdf-attachment-PQC Asia forum.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"2012 – NIST begins PQC project"
"Much broader scope – three crypto primitives"
"Continue to categorize submissions into 5 rough security strength categories": "Allows for more meaningful performance comparisons"; "Helps us make decisions on transition to longer keys"
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.
20161219 10:15:00 file 20240716/RE_ another modification to the pqc page(1).pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Web-page modification. Why was this PDF edited after the lawsuit was filed?
20161219 14:22:00 file 20240716/RE_ another modification to the pqc page.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Why was this PDF edited after the lawsuit was filed? #needmorerecords
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
20170103 10:37:34 file 20240716/RE_ [Itl_mgmt] FW_ News Clips from Tuesday, Jan....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Thanks for catching that one! I’ll have to be one the lookout for articles from other places I’d never expect."
20170104 09:17:23 file 20240716/FW_ [Itl_mgmt] FW_ News Clips from Tuesday, Jan....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Down thread: "Hey Look! Nigeria Today. That’s a new one for us."
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."
20170116 04:43:09 file 20240716/[Itl_mgmt] Save the date_ QuICS Stakeholders Da....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
No evident post-quantum content.
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.
20170119 05:58:25 file 20240716/Re_ [Itl_mgmt] Save the date_ QuICS Stakeholder....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
No evident post-quantum content.
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
20170202 09:04:00 file 20240516/RE_ More for publishing_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing web pages.
20170208 09:49:00 file 20240426/FW_ hash-based signatures_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Here’s what Quynh said. Do we need to do anything, or just wait for the IETF?"
20170210 12:40:00 file 20240617/RE_ right contact for quantum_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"The NIST effort of developing quantum resistant cryptography standards are for data in motion and in storage. Please let them look at www.nist.gov/pacrypto for our process. I am one of the contact person together with Dustin Moody and Yi-Kai Liu (math division)."
20170210 14:40:06 UTC file 20240507/PQC isogeny schemes slides_1.pdf-attachment-PQC Isogeny Sigs.pptx:
Notes from djb, last edited 20240511 21:52:47 UTC:
Basically just copying and pasting pieces from three papers listed at the beginning.
20170210 21:53:00 UTC file 20240617/Asia PQC_5.pdf-attachment-NIST Post-Quantum Cryptography Standradizatio.docx:
20170213 10:01:17 file 20240507/PQC isogeny schemes slides_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Here you go!"
20170214 09:48:03 file 20240516/Re_ Collaboration_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Ray and Jacob also mentioned to me about their trip to UMBC. In general, we welcome them to come NIST for seminars if they like. They can jointly write papers with any of our team member. But for students, I think it must go with SURF or pathway program, if they will come to NIST. For joint workshops, I am not sure because we have our workshop planned for 2018. During the procedure for PQC standardization, we have our own workshop to run. We need to be very clear that we have a plan as outlined in our website and we have our objectives, which are what we must focus on in the next few years."
20170216 10:28:56 file 20240507/RE_ Migration of PQC Pages(1)_2.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Planning web pages.
20170216 11:34:17 file 20240507/RE_ Migration of PQC Pages_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Sounds good. You’ve got it all covered!"
20170221 02:08:25 file 20240516/RE_ request for travel Univ. of Malaga - Eurocr..._1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Travel planning.
20170224 08:42:00 file 20240617/the link for PQC discussion_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"http://www.databreachtoday.com/post-quantum-crypto-dont-do-anything-a-9737?rf=2017-02-23_ENEWS_SUB_DBT_Slot1&mkt_tok=eyJpIjoiWTJObVpUZGtOMk0wWkRkaCIsInQiOiJNNDVJZkdRQmdFUmJyNFVzNkR6YVwvcXpUNjFLZmFKb2NTbTgrS0sweWt0QXJMOGx0MFZcL2lwaDdmajJ0VVV6ekxLQlQrcWtvZGRKUXJTWFlpQnNKZnM2bFJCdGRVSEhyWmEzWWp6RksxWUZXMGZQNzZsalc3MVwvSjBGNnA4cTE4XC8ifQ%3D%3D"
20170301 03:19:02 file 20240617/RE_ Review and Conflict form for Grant Proposal..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thank you Dustin!"
20170301 08:01:00 file 20240617/RE_ March 23, 2017_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Planning talk to NAS committee.
"Yes, I can do it. Who exactly is the talk being given to? Do you more info on when, where, how long, etc?"
20170302 04:31:00 file 20240621/Review Request_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Would you be available to help review a paper for PQCRYPTO? The paper is on a modular lattice signature scheme. If you are able to help, I would need the review by about the 20th to be able to input it into the system before my deadline. Please let me know. Thanks."
20170302 05:05:00 file 20240617/Asia PQC_5.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
No text, just attachment.
20170306 12:14:48 file 20240621/Re_ WERB review(3)_3.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Discussing quantum key distribution.
20170307 13:01:52 -0500 file 20240617/Fwd_ Sigma Xi Katharine B. Gebbie Young Investi..._1.pdf-attachment-Stephen Jordan (YI poster).pdf:
20170309 03:23:36 file 20240617/The Third Asia PQC forum slides_4.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing slides for Third Asia PQC Forum.
20170309 04:32:20 file 20240621/Re_ WERB review(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Discussing quantum key distribution.
20170309 05:20:00 file 20240617/RE_ The Third Asia PQC forum slides(2)_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Here are my comments."
20170309 08:52:33 file 20240617/BITS PQC presentation_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Adam told me to have a 15-20 minute presentation for BITS (Banking IT Standardization) next Thursday. I've attached some slides I used at a talk I gave at a workshop for people involved with security for vehicles. I got good feedback from that talk, that is was very understandable, so I thought it would work well for this. Let me know if you have any comments or suggestions."
20170309 10:59:00 file 20240617/About conference attendance_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"CFRG (IETF Crypto Forum) will have a one day meeting before Eurocrypt. We will not send any one specifically for this one-day meeting."
"I have included you in an e-mail string on conference attendance. I like to make sure that my decision is not too harsh on the individual. The cost is only one factor in making the decision. I heard the concerns about the arguments we made at CFRG. The arguments are not completely wrong. But I think we shall play a role of contributor at the standard organizations and enhance NIST crypto standards acceptance through contributing to different standard development procedure. Some of the arguments may not help us to be a good player in the standard organizations."
"I stopped by your office after TWG meeting and saw that you have a rather full schedule today. If you have advise on this please send by e-mail."
What happened here? #needmorerecords
20170309 11:28:00 file 20240617/RE_ NIST-NSA TWG notes_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"When IETF work on hash based signature is finalized NIST is planning to pull in them to a SP and look into issues. It is still open on which hash based signature among XMSS and LMS or both will be included."
"We will give presentations at BITS (March 16, 2018), National Academy of Science (March 24), ICMC (May 17), IAS (June 18-21), PQCrypto (June 26-28)"
"NISTIR 8114 is a technical report on lightweight cryptography. It will be published in the next few days. We have call for proposals on profiles. The algorithms will be required to target specific profiles."
20170309 11:35:00 file 20240617/RE_ BITS PQC presentation_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"The slides are good. I am sure the talk will be well received."
"I am supposed to give a talk at ICMS “crypto module” community in May, which would be a talk in between, some very technical people and some IT secure people."
20170309 11:51:26 file 20240716/a few thoughts for the _theory_ component of th....pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
No evident post-quantum content.
20170309 13:45:27 UTC file 20240617/BITS PQC presentation_2.pdf-attachment-Crypto in PQ world -BITS.pptx:
20170309 20:22:38 UTC file 20240617/The Third Asia PQC forum slides_4.pdf-attachment-PQC Asia -03092017.pptx:
20170309 22:19:31 UTC file 20240617/RE_ The Third Asia PQC forum slides(2)_3.pdf-attachment-PQC Asia -03092017Ray.pptx:
20170310 10:06:52 file 20240617/RE_ The Third Asia PQC forum slides(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Attached please see a version after incorporate in Ray’s comments. Thank you, Ray."
"Ray added page 8. I added some details. There are certain redundancies with page 14 and page 17. But I think it may be okay because page 8 is about requirements, page 14 is a summary on what talked, page 17 is implementation details."
"Any more comments, please let me know. Thanks,"
20170310 14:10:20 UTC file 20240617/RE_ The Third Asia PQC forum slides(1)_2.pdf-attachment-PQC Asia -03102017.pptx:
20170313 03:30:00 file 20240617/RE_ The Third Asia PQC forum slides_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Sorry I didn’t respond sooner. The slides look good to me, and I have no suggestions for any changes!"
20170313 04:07:00 file 20240716/RE_ FW_ Review Request_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Short review of a paper.
20170315 12:36:04 file 20240621/words_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Post quantum secure method for generating a key pair"
"(in case you forgot….)"
20170316 02:11:40 file 20240617/Fwd_ Sigma Xi Katharine B. Gebbie Young Investi..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Announcing internal talk about quantum algorithms for physics simulation.
20170316 09:21:19 file 20240617/Re_ API stuff_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"What time and where?"
20170317 01:00:26 file 20240617/Re_ 1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Intern supervision.
20170317 02:11:28 file 20240716/Re_ Slides for RWC talk_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"This is a very old email I never commented on but it came up when I was searching for something else in my past e-mails, but I figured I would point out that it’s obviously not known whether NP=EXPTIME, as by the various time-hierarchy theorems we have that P is a proper subset of EXPTIME, meaning that resolving NP?=EXPTIME would mean resolving P?=NP."
The "obvious" logic here is invalid. The usual conjectures are that P is strictly smaller than NP, which is strictly smaller than EXPTIME; but if P is equal to NP then NP is also strictly smaller than EXPTIME. One cannot use these facts, and the knowledge that NP is strictly smaller than EXPTIME, to resolve the question of whether P=NP. #error
Down-thread comments are even more confused. For example: "Why aren't there polynomial-time quantum algorithms that solve problems where the best classical algorithm is exponential-time?" #error #scramble
20170320 10:57:43 file 20240621/RE_ WERB Review_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Thanks! I’ll drop it off!"
20170321 02:29:01 file 20240617/Multivariate crypto_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Hope you’re doing well – sorry I missed your talk last week (I was visiting CalTech). I have a quick question for you, if you have a minute:"
"I’m planning to give a talk in the postquantum crypto seminar next week. The goal is to help me to get more deeply into classical crypto and hopefully in the process show the audience something new."
"Given my background (algebraic geometry & quantum crypto) I think multivariate crypto is probably the best topic. So, the question is: can you think of any topics within multivariate crypto that might be good material? An ideal topic would be one that hasn’t been covered before and that’s fairly accessible (and it’s even better if it happens to have some algebraic geometry in it)."
20170321 02:33:00 file 20240617/RE_ next PQC seminar_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Yep."
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"
20170323 07:58:53 file 20240716/Re_ Multivariate crypto(1)_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently to Daniel Smith-Tone. "Ok, thanks – I was able to find the book. I appreciate the help."
20170323 10:19:11 -0400 file 20240507/PQC slides_1.pdf-attachment-PQC-NAS.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Hold bi-weekly seminars (internal and invited speakers)" #weveshownallourwork
"Gaussian simulation"
20170324 04:34:59 file 20240716/Re_ PQC seminar_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Here’s my abstract for the talk next week. (Apologies that it is fairly broad – I can make it more specific if you’d like after I’ve developed the talk a little more.)"
20170324 04:55:49 file 20240716/Re_ Multivariate crypto_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently from Daniel Smith-Tone. Explaining what the degree of regularity is.
20170324 05:37:55 file 20240617/Re_ MIT Club(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thank you very much Dustin."
20170327 11:03:52 file 20240617/API meeting_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"If you’ve noticed, we’ve had a lot of discussion on the pqc-forum about API’s. Dan Bernstein just posted a lengthy post this morning as well. We’re planning on holding a short informal meeting about this at 3pm in B-341 for anyone who would like to attend. If you’re busy, or don’t want to come, that’s fine. We just wanted to make sure everybody knows. Thanks,"
20170329 file 20240621/RE_ some small PQC updates(2)_3.pdf-attachment-FAQ-randomness.rtf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Q: How does a submission obtain secure randomness?"
20170329 file 20240621/some small PQC updates_4.pdf-attachment-API_032917.rtf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"PQC - API notes"
20170329 file 20240621/some small PQC updates_4.pdf-attachment-FAQ-randomness.rtf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Q: How does a submission obtain secure randomness?"
20170329 03:52:59 file 20240617/Re_ MIT Club_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"That works – I will send out an updated agenda."
20170329 08:22:26 file 20240617/FYI_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Security Innovation announced they are releasing their patents:"
"https://globenewswire.com/news-release/2017/03/28/945815/0/en/Security-Innovation-Makes- NTRUEncrypt-Patent-Free.html"
20170329 12:12:37 file 20240621/some small PQC updates_4.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Discussing FAQ updates.
20170329 12:26:36 file 20240621/RE_ some small PQC updates(2)_3.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Discussing FAQ updates.
20170329 12:34:32 file 20240621/RE_ some small PQC updates(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"I think it is probably v5, if that matters."
20170329 12:56:00 file 20240621/RE_ some small PQC updates_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Discussing web-page updates.
20170330 file 20240617/Re_ Change FIPS citing in SPHINCS paper_1.pdf-attachment-simpira-pq.pdf:
20170330 04:31:16 file 20240617/Re_ Change FIPS citing in SPHINCS paper_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks for letting me know about this."
"I've corrected the references according to your suggestions, see attachment."
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
20170428 11:31:28 -0400 file 20240617/Carl Miller's WERB Paper_2.pdf-attachment-MILLER_Graphical Methods Quantum Crypto.pdf:
20170502 02:04:27 file 20240617/PQC Reference Platform_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
" “The above tests will initially be performed by NIST on the NIST PQC Reference Platform, an Intel x64 running Windows or Linux and supporting the GCC compiler.” "
20170503 05:44:58 file 20240621/What we decided today_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"This is what I think we agreed on today:"
"a. For random number generation, we want the performance tests to use AES CTR DRBG exactly as it appears in 90A—each request for random bytes leads to a Generate() call, and thus costs three extra AES encryptions and one AES key scheduling."
"b. We will explicitly allow the submitters to use a “seed expanding” algorithm to expand the RNG output to a larger number of bytes in some more convenient way."
"c. We will define a seed-expanding algorithm based on AES CTR mode, and one based on KMAC. We could also provide one based on SHA2."
"d. We will encourage submitters to allow flexibility in their seed-expanding algorithm, so that changes are possible."
"e. We will provide some reference code for these things, and also will provide some code to Dan and the open quantum safe people as needed. We’ll also ask Dan and the OQS people to make sure submissions have access to fast implementations of AES, SHA2, or SHA3 as needed."
Also a proposed API for seed expansion.
20170504 02:32:49 file 20240617/FW_ PQC forum archive link_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Forwarding attachment.
20170504 08:30:42 file 20240621/SUPERCOP architecture_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"I spent a couple hours looking at the SUPERCOP source code, but for the life of me I can’t figure out what’s going on with even simple things. I’m hoping you can help figure out the basic stuff."
#scramble
20170505 12:44:39 file 20240617/Re_ Attention Authors (WERB)_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing internal paper reviewing.
Inside quoted thread: "I’m not sure about Dustin, but my impression is that the majority of people involved in the postquantum crypto project specialize in classical cryptography, and that a minority (including Stephen & Yi-Kai) supply the quantum expertise. I could be wrong though. (I asked Jacob Alperin- Sheriff to do a WERB of a previous quantum paper, and he said he was a “novice when it comes to quantum” but was happy to write a review anyway.)"
20170505 12:57:12 file 20240617/Carl Miller's WERB Paper_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Reviewing internal quantum-cryptography paper.
20170508 03:26:13 file 20240716/Re_ PQC Forum content_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Discussing announcement regarding software rules.
20170508 09:56:56 file 20240621/Re_ stock slides(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Presentation at National Academy of Science – This is a more general report (i.e. for audience who may not have followed NIST process)."
"Presentation at the 3rd PQC Forum – This is for audience who have followed NIST process."
Thread mentions a "BSI event in Germany". #needmorerecords
20170508 12:57:00 file 20240621/RE_ Seed expanding and random number generation(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Discussing PRNGs.
20170508 12:59:00 file 20240621/RE_ Seed expanding and random number generation_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Whoops, meant to reply all"
20170509 01:46:22 UTC file 20240621/Re_ stock slides(1)_2.pdf-attachment-Asia-PQC-3rd-03222017-p.pptx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"NIST PQC Standardization ⎼ Process, Issues and Strategies"
"Lily Chen"
"Properly handling security implementation issues are critical to make an algorithm a strong candidate for standardization, e.g."
"Public key validation"
"How efficient or inefficient it can be"
"What is the risk of not doing it"
"Decryption failure"
"Probability"
"How to prevent security flaws brought about by decryption failure"
"Countermeasures to side-channel attack"
"Auxiliary functions"
"Misuse resistance, e.g."
"Details determine success or failure – General strategy to win"
#inconsistency
20170509 01:48:18 UTC file 20240621/Re_ stock slides(1)_2.pdf-attachment-PQC-NAF-02062017-with notes.pptx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Post-Quantum Cryptography and NIST Standardization"
"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)"
"NIST sees its role as managing a process of achieving community consensus in a transparent and timely manner"
20170509 09:14:16 file 20240621/Re_ stock slides_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"These are perfect. I think the wording of these are much better than the ones I tried this weekend."
20170511 12:39:54 file 20240617/Re_ Quantum conference(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Conference planning.
20170511 12:42:03 file 20240617/Re_ Quantum conference_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Conference planning.
20170517 16:32:02 UTC file 20240617/ICMC-PQC_1.pdf-attachment-PQC-ICMC-05172017.pptx:
20170518 04:41:41 file 20240617/Re_ annual report welcome letter(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"This looks good. I have two comments and one suggestion as attached."
20170518 11:41:10 file 20240617/ICMC-PQC_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
No text, just attachment.
20170518 12:34:18 file 20240617/Re_ Carl Miller's WERB Paper_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing internal paper reviewing.
20170518 18:58:00 UTC file 20240617/Re_ annual report welcome letter(1)_2.pdf-attachment-PQC-inAnnual.docx:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Looking ahead is vital in the realm of cybersecurity. Knowing that if large-scale quantum computers are ever built they will be able to break many of the public-key cryptosystems currently in use and compromise the confidentiality and integrity of digital communication on the Internet and elsewhere, NIST is working closely with the academic community and industry to develop protective cryptographic standards that we all rely upon. Building on its successful tradition of worldwide, open competitions, in 2016 NIST called for submissions for quantum-resistant public-key cryptographic algorithms for standards. These algorithms must be secure against both quantum and classical computers, and should interoperate with existing communications protocols and networks. NIST plans to select a winning entry after all entries are received late in 2017 and thoroughly analyzed."
Comment from Chen on "competitions": "We have tried very hard to avoid using “competition” for the PQC standardization. I hope this will not be understood that way but referring to AES and SHA3 competition."
Comment from Chen on "a winning entry": "This will not be one winning entry but multiple entries. We will select entries for signatures, for encryptions and key agreements."
Comment from Chen: "How about “After submissions are received late in 2017, NIST plans to spend 3-5 years to work with research community and industry to analyze the candidates before selecting algorithms for standardization. “ "
20170519 06:58:57 file 20240716/RE_ FW_ MinRank Paper_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Unclear what the redacted address is here. #needmorerecords
20170520 02:28:02 file 20240716/MinRank_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently sent by Daniel Smith-Tone.
20170520 03:18:50 file 20240716/experiments_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Comments on cost of MinRank attacks. Looks like this was from Daniel Smith-Tone.
20170522 09:40:47 file 20240716/Re_ Reserve conference room, next week (May 22 ..._Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Discussion of a NIST meeting with Jintai Ding. #weveshownallourwork
20170523 06:14:35 file 20240716/Re_ New Version of Paper(1)_2.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Quantum cryptography.
20170523 11:37:50 -0400 file 20240716/Re_ New Version of Paper(1)_2.pdf-attachment-graphicalcrypto3.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Quantum cryptography.
20170523 11:42:06 file 20240617/RE_ annual report welcome letter_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"It reads good."
20170524 10:36:46 file 20240617/Re_ Reminder_ Crypto Reading Club - May 24 - @N..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Logistics regarding talk by Jintai Ding.
20170525 09:40:41 file 20240617/Re_ New Version of Paper_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing internal paper reviewing.
20170530 03:27:54 file 20240617/Re_ Let us meet(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Here’s a short description of the work that we’re thinking of doing for the randomness beacon. (See attachment.) Basically, Paulina and I are considering doing some local quantum crypto experiments, and a nice byproduct might be an initial quantum source to plug into the randomness beacon."
"This is just preliminary – we haven’t had the chance yet to talk to the other quantum randomness folks in Gaithersburg, like Josh and Michael. In any case, comments are welcome."
20170530 05:20:36 file 20240617/Re_ Let us meet_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Looks like really good stuff to me."
20170530 15:26:46 -0400 file 20240617/Re_ Let us meet(1)_2.pdf-attachment-Bell.pdf:
20170531 08:37:47 file 20240716/Hash-based Signatures_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Sending a few links regarding hash-based signatures. #scramble
Who else was this sent to? #needmorerecords
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.
20170607 03:52:39 file 20240516/RE_ CSRC - PQC FAQs_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing editing procedures for web pages.
20170608 11:36:39 file 20240507/Re_ Published paper(1)_2.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Discussing forms for publication of a paper.
20170608 11:38:04 file 20240507/Re_ Published paper_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Discussing forms for publication of a paper.
20170612 08:40:50 file 20240516/Re_ pqc surveys_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Thank you!"
#scramble
20170614 11:54:03 -0400 file 20240617/WERB review(1)_4.pdf-attachment-Bell.pdf:
20170614 11:54:03 -0400 file 20240617/WERB review_3.pdf-attachment-Bell.pdf:
20170615 10:41:02 file 20240617/WERB review(1)_4.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing internal paper reviewing.
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?"
20170616 10:41:46 file 20240617/WERB review_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing internal paper reviewing.
20170616 11:37:24 file 20240617/Re_ WERB review(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing internal paper reviewing.
20170617 19:40:32 UTC file 20240426/FW_ IAS slides_1.pdf-attachment-PQC-IAS-06162017.pptx:
20170617 19:40:32 UTC file 20240507/IAS slides_1.pdf-attachment-PQC-IAS-06162017.pptx:
20170619 04:44:29 file 20240617/Re_ WERB review_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing internal paper reviewing.
20170621 08:54:35 file 20240507/PQC randomness notes_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Did you send Larry some notes on what we want to send in response to Dan regarding PQC randomness implementations? I think that’s what we had decided to do when we met last week."
20170622 02:01:58 file 20240516/Re_ idea for next year's SURF students_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"I think you list what I can think about. I will be happy to do the first one."
"The only thing we might need to do before hand is to coordinate about the content. For example, in asymmetric key based crypto, you may talk about hard problems like factorization, discrete log. When Dustin or Ray talk about post-quantum crypto, he will review RSA and DH and may start from some other hard problems. We also talk about NIST standards like 56A/B and also FIPS 186. Then when whoever talks about TLS or IKE or IPsec, they will use asymmetric key crypto. So the students can make connections."
20170622 02:28:00 file 20240516/RE_ did it work_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing isogeny basics.
20170622 16:06:07 -0400 file 20240531/Re_ Your talk_1.pdf-attachment-signature.pdf:
20170623 11:25:21 file 20240531/Re_ Your talk_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"I should have put a weight constraint on the quasi-cyclic syndrome decoding problem (QC- SDP)."
20170628 06:10:07 file 20240617/SIDH quantum security_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Figuring out where SIKE was getting exponent 1/6.
#scramble
20170630 04:10:49 file 20240531/Re_ Thermodynamic analysis of brute force Key S..._1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"I don't know about the quantum aspect as much as the rest of you, but I would be interested in working on this in regards to the consequences for SIDH. The quantum security for SIDH pretty much depends directly on the claw finding algorithm. The complexity is O(log p)^(1/6). If the quantum algorithm for claw finding becomes O(log p)^(1/4) as Ray thinks might be the case, then key sizes for SIDH can be shrunk 33%, as then both the best classical and quantum attacks would be O(log p)^(1/4). Instead of needing to choose your parameter p = 6 * (security level) as is currently done, it would be p = 4 * (security level)."
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.
20170709 01:17:35 file 20240531/Re_ Simple QRNG for randomness beacon_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Sounds good. Actually hooking it up to the Beacon will have to wait until we have a healthy pulse. The Beacon is currently broken."
20170710 11:40:00 file 20240716/RE_ Thermodynamic analysis of brute force Key S..._Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Discussion of energy requirements for search problems.
20170711 04:19:47 file 20240507/Re_ another paper that probably breaks it_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Actually, looking at Section 1.2, they clearly have no clue what’s going on, as they seem to be trying to prove invulnerability to attacks."
20170717 04:16:21 file 20240516/Re_ Bill Fefferman's working schedule_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Thanks Lily and all good with me."
20170717 08:59:43 file 20240507/IAS slides_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"This is what we will use for 7/20 lunch talk."
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."
20170717 09:52:39 file 20240507/RE_ 2nd NIST PQC standardization workshop_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Conference planning.
20170717 13:15:15 UTC file 20240507/PQC slides_1.pdf-attachment-PQC-IAS-06162017.pptx:
20170718 05:16:40 file 20240426/Here's text summarizing what we said in our mee..._4.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
Drafting FAQ text on choosing symmetric algorithms.
20170718 05:22:00 file 20240716/RE_ Schloss Dagstuhl Quantum Cryptanalysis Seminar_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Travel planning for Daniel Smith-Tone and Ray Perlner.
20170719 01:03:00 file 20240531/RE_ Here's a second draft_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"I do not have further comments."
20170719 02:45:23 file 20240426/Dan has a new blog post on PQC benchmarking, wi..._2.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
Sending link to https://blog.cr.yp.to/20170719-pqbench.html.
20170719 05:16:02 file 20240426/Re_ Here's text summarizing what we said in our..._1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Is there anything about this guidance we no longer agree with? It seems like the actual guidance we want to give now is more-or-less the same. Specifically, we want randombytes() to be AES CTR DRBG, we provide an AES seed expander that we explicitly say isn’t random-oracle-like but should work when the key is unknown, and we say to use KMAC when random-oracle-like behavior is needed."
"Is there anything else we need to specify?"
20170719 08:35:17 file 20240426/FW_ Here's text summarizing what we said in our..._3.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Everyone okay with Ray’s write-up? We probably need John’s write-up explaining his AES seed- expander before we post this…"
20170719 09:05:12 file 20240426/Re_ Here's text summarizing what we said in our...(1)_2.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Okay."
20170719 09:06:00 file 20240716/FW_ Schloss-Dagstuhl_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Who was this sent to beyond Daniel Smith-Tone? #needmorerecords
Discussing trying to obtain an invitation for Alperin-Sheriff to attend an invite-only workshop.
20170719 09:45:00 file 20240516/RE_ did it work_001_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Supervising intern.
20170720 11:27:00 file 20240516/RE_ new FAQ question for our PQC page_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing web pages.
20170720 12:02:32 file 20240516/RE_ List Numbering Question_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing web pages.
20170724 11:01:45 file 20240426/Dan's blog posts recently regarding PQC_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
Linking to https://blog.cr.yp.to/20170719-pqbench.html and https://blog.cr.yp.to/20170723-random.html.
20170725 01:04:11 file 20240516/Re_ Providing VMs_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Windows and/or Linux. We can talk next week. Just planting the seed."
20170725 02:23:00 file 20240426/FW_ Can I Go Ahead and Ask the PQC forum to let..._1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Go ahead then. Perhaps send us your message before you post."
20170801 11:05:27 file 20240426/FW_ IAS slides_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"These are 20-page slides. I can manage it in 30-40 minutes. If you hope that we leave more time for questions I can skip a few."
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.
20170802 03:36:54 file 20240617/RE_ Response on Library Usage(2)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I’m good with it. Thanks for writing it."
"Larry – is this fine by you?"
20170802 09:50:00 file 20240516/RE_ Proposals (draft; please comment!)_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Ok – thanks! I don’t want you to worry about work on vacation, but anything you can do would be great. We want to send something to Dan and OpenQuantumSafe pretty soon."
20170803 03:38:00 file 20240531/RE_ New Draft of FAQ Update on Assembly etc and...(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"I took care of that – Me and Sara manage it. I sent her an email already, and she’ll probably have it updated by tomorrow. But you can post the message today and say it will soon be updated on our FAQ."
20170803 10:38:00 file 20240617/RE_ Response on Library Usage_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Do you want to send new draft text?"
"(and that’s what we’d decided at our previous meeting – but we’re now changing our minds!)"
20170803 11:38:00 file 20240516/RE_ New PQC FAQ_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Thanks!"
20170804 08:21:21 file 20240507/PQC forum_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"We hope you'll be part of our post-quantum crypto project, and I'd be happy to get you up to speed on that whenever. Our webpage for it is at www.nist.gov/pqcrypto, and on that website you should be able to easily see the instructions for how to sign up for the pqc forum. I recommend you do so - we post announcements there, and people ask us questions and discuss the pqc project. Submissions are due to us by Nov. 30th, so things will start to heat up pretty quick here. We've told anyone who submits by Sep. 30th that we'll also do a quick look over to make sure they have everything they are supposed to."
"Anyway - let me know if I can help you in any way, or if you have any questions. I've added you to the email alias "internal-pqc@nist.gov" which we use to send PQC stuff to all the other members of the project (all NIST people). We usually meet every other week, but during the summer we have slowed down a bit. We will probably have some impromptu meetings come up over the next few weeks, but we have nothing currently scheduled at this moment."
20170804 12:59:53 file 20240531/Re_ New Draft of FAQ Update on Assembly etc and..._1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Did you post it? I haven't seen it yet..."
20170807 01:33:00 file 20240507/PQC slides_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"I’m attaching 3 sets of slides. They’re probably all quite similar, and they talk about the submission requirements, evaluation criteria, and some of the issues we’ve been working on for this project."
20170807 01:53:02 file 20240426/FW_ Paper accepted at SAC_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"You may want to get this paper - Total Break of the SRP Encryption Scheme - into NIKE for review (Div Reader and Outside Reader needed) since the conference is next week."
20170807 02:01:22 file 20240516/Re_ comments on proposal_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing symmetric primitives to use in post-quantum crypto.
#weveshownallourwork
20170807 09:55:40 file 20240617/RE_ revise a couple of PQC FAQ's_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing FAQ updates.
20170807 11:06:33 file 20240617/VMs_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"A few things..."
"1) I'll take back the server that Supriya was using to do the RFID property stuff. I'd like to get a laptop configured to do all of that directly (all the WAMP stuff on it). The RFID project wants to use a USB port and that doesn't seem to be something we can pass through the hypervisor. Mike, can get together to discuss this?"
"2) I can use the same server to start getting set up for PQC submissions acceptance. On that topic, can I get a Linux VM? Do you have any of them lying around?"
20170807 11:43:00 file 20240507/PQC project_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"We hope you'll be part of our post-quantum crypto project, and I'd be happy to get you up to speed on that whenever. Our webpage for it is at www.nist.gov/pqcrypto, and on that website you should be able to easily see the instructions for how to sign up for the pqc forum. I recommend you do so - we post announcements there, and people ask us questions and discuss the pqc project. Submissions are due to us by Nov. 30th, so things will start to heat up pretty quick here. We've told anyone who submits by Sep. 30th that we'll also do a quick look over to make sure they have everything they are supposed to."
20170807 12:39:17 file 20240507/Re_ [Nistbeacon] NIST Randomness Beacon Meeting_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Planning meeting regarding a public RNG.
20170807 12:44:22 file 20240426/FW_ Future of Quantum Randomness IMS_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Having a similar conversation with Ron, they are working him too."
20170807 13:54:00 UTC file 20240617/RE_ revise a couple of PQC FAQ's_3.pdf-attachment-A16.docx:
Notes from djb, last edited 20240624 05:27:25 UTC:
Editing FAQ entry regarding software libraries.
20170808 10:44:52 file 20240516/RE_ checking in(1)_2.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing isogeny basics.
20170808 11:51:09 file 20240426/FW_ API changes_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"I’m forwarding these notes from our last meeting to you. I think we’ve covered most of it (at least 1- 4 already), but if you see anything that we already have decided and haven’t let the forum know, we probably should. The KAT calls are from 6. Below. I think we’re waiting on 5 still until Larry is ready…."
20170808 11:56:23 file 20240531/Re_ summary of our quick meeting_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"We are saying, “use it if you want” for MFPQ but it needs to be included in the build? I think that’s reasonable but I just want to clarify it’s that versus “Don’t use it.” And I thought Larry still needs to check whether that Keccak package is “good” or not …"
20170808 12:47:25 file 20240426/RE_ draft PQC-Forum post_ Planned API change to...(1)_2.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
Draft posting regarding an API change.
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."
20170810 01:09:56 file 20240516/Re_ interesting conversation on SRDs at ITL MC mtg_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
High-level NIST planning. No obvious post-quantum content.
20170810 03:55:33 file 20240617/RE_ revise the PQC FAQ(2)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"'Yes, I can still post the new ones….and I’ll need to go back through the changes and figure out a way to organize them. Maybe like a comment template table or something.""
20170811 03:25:54 file 20240516/Re_ Do We Want to Individually Have At Least On..._1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"I agree with you, and can be the one to acknowledge the submissions received."
"To date, this is the 2nd submission received."
20170811 09:14:00 file 20240617/RE_ revise the PQC FAQ_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I agree that it is good that we are doing it, even if it is unobserved."
20170811 10:01:02 file 20240426/Re_ draft PQC-Forum post_ Planned API change to..._1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"I agree"
20170814 01:28:25 file 20240426/RE_ CFRG_ The Transition from Classical to Post..._2.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Thanks Quynh. It seems accurate enough – doesn’t say too much. Probably just intended to give people who haven’t been paying attention a heads-up, or quick update."
In fact, the document in question (https://tools.ietf.org/html/draft-hoffman-c2pq-02) is full of unjustifiable comments aimed at slowing down post-quantum adoption, such as "the properties of those algorithms make them onerous to adopt before they are needed" and "there is a large sustained cost in using those algorithms" and "It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed".
#slowingdownpqcrypto
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 02:58:04 file 20240516/RE_ CFP Sept. 2016 version and received comments_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Pointing to NIST's public URL for NIST's draft call for proposals.
20170815 05:08:51 file 20240716/[Cmvpwg] CVP Industry WG - Accreditation Overview.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Automated Cryptographic Validation Testing (ACVT)"
20170815 08:17:12 file 20240531/RE_ PQC API_randomness meeting(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Yes, I’ll get a conference line. I know people might be at Crypto, but we are running out of time to settle this by Sept. 1st."
20170815 10:02:43 file 20240507/RE_ Next week's meeting_2.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"I think it will work. I have a NIST phone. We can get together in the dorm lounge."
20170815 10:20:00 file 20240426/FW_ CFRG_ The Transition from Classical to Post..._1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
Forwarding a message.
20170815 20:09:11 UTC file 20230925/RE_ Any updates we like to announce at crypto 2..._2.pdf-attachment-Crypto Rump Session.pptx:
20170815 21:00:00 UTC file 20240716/[Cmvpwg] CVP Industry WG - Accreditation Overview.pdf-attachment-Accreditation Overview.docx:
20170815 21:02:00 UTC file 20240716/[Cmvpwg] CVP Industry WG - Accreditation Overview.pdf-attachment-HB150_17 ACVT Annex.docx:
20170816 02:36:00 file 20240617/RE_ RVB response_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Also, keep in mind that we left ourselves some flexibility for backburnering things we think aren’t well studied enough."
20170816 04:39:13 file 20240516/Re_ ETSI Quantum meeting(1)_4.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"I certainly can and think it’s a good opportunity for me to get closer to this set of folks. I am happy to do either or both sessions Not sure about the executive steering committee and not sure what that entails. Let me know and I will make travel arrangements and coordinate with Lily as well"
20170816 04:46:27 file 20240516/FW_ ETSI Quantum meeting_3.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Planning travel to ETSI meeting, including event chaired by Michael Groves from NSA's UK partner. Were there also side meetings with Groves etc.?
#nsa
20170816 05:23:38 file 20240516/Re_ ETSI Quantum meeting_2.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Were you not going at all? If so, I will use your travel approval and justification."
"Purpose: Attend the Quantum Safe Workshop"
"Benefit to NIST: Meet with international leaders in Quantum Resistant Cryptography to discuss NIST work in this space and obtain collaborators for future standards in cryptography."
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.
20170818 03:46:50 file 20240507/Next week_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Ray, Quynh, John, Rene, Jacob, Cagdas, Luis, Gorjan and I will attend crypto. Gorjan will present his paper. Crypto group is planning to provide an update on PQC, LWC, TDEA, 56A/C and Beacon at the Rump session."
"There is no managers’ meeting Monday."
20170821 04:26:54 file 20240426/Dan's quantum pre-image paper_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
Reporting abstract of https://eprint.iacr.org/2017/789, and misattributing to just one author. #ethics
20170822 08:06:42 file 20240516/Re_ Best utilization of ITL's investments in ne..._1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Thank you very much for this information, Quynh." Context: Quynh Dang recommending Thinh Dang.
20170822 08:07:06 file 20240716/FW_ Rump session slides, Rene and John take over_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Planning rump-session presentation at Crypto.
Who was this sent to? #needmorerecords
20170823 12:27:23 file 20240531/RE_ NIST PQC 2019(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
Planning conference organization.
20170823 12:27:31 file 20240531/RE_ NIST PQC 2019_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
Planning conference organization.
20170824 10:11:36 file 20240516/Re_ ESTI quantum safe workshop_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing conferences.
20170828 08:37:28 file 20240507/Meeting Today Or Tomrrow_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"To discuss what we got from talking to people at crypto and deal with some of the new things that came up last week?"
"Also, we need to get a move on in terms of specifying which directories the various libraries will be installed on the reference platform, as it’s nearly September 1st."
20170828 20:03:00 UTC file 20240507/FW_ Mark your calendars for ITL Science Day!(1)_3.pdf-attachment-PosterJudgingCriteria2017.docx:
20170828 20:03:00 UTC file 20240507/FW_ Mark your calendars for ITL Science Day!_2.pdf-attachment-PosterJudgingCriteria2017.docx:
20170829 01:02:29 file 20240507/Re_ Mark your calendars for ITL Science Day!_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Poster planning.
20170829 01:30:45 file 20240426/Re_ Draft response on benign malleability_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"I would remove the comma from "literature, where" "
20170829 11:59:34 file 20240507/FW_ Mark your calendars for ITL Science Day!(1)_3.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"We had very successful posters in the previous years. Thank the group members for the effort. Science Day is a great opportunity not only to introduce team project like PQC and LWC but also to present individual (collaborated) research. Notice that the visual art unit will be very busy before the Science Day (Nov.2) for the large amount of print work orders. Don’t wait to the last few days if you can prepare earlier."
20170829 12:05:08 file 20240507/FW_ Mark your calendars for ITL Science Day!_2.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"How are things with you? I am considering options for the ITL science day, and am curious about us presenting our work on graphical quantum cryptography – what do you think?"
20170830 file 20240531/Re_ formal evaluation of the two submissions_1.pdf-attachment-PQC Submission Checklist_RLCE.doc:
Notes from djb, last edited 20240624 05:27:28 UTC:
NIST internal checklist for RLCE submission.
20170830 file 20240531/Re_ formal evaluation of the two submissions_1.pdf-attachment-PQC Submission Checklist_RVB.doc:
Notes from djb, last edited 20240624 05:27:28 UTC:
NIST internal checklist for RVB submission.
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:18:29 file 20240531/Re_ formal evaluation of the two submissions(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Sure."
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 03:53:36 file 20240531/Re_ formal evaluation of the two submissions_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"So assuming I’ve been thorough enough at checking submissions quality, I’ve finished both."
"Basically I scanned through the code for violations (where the Roellgen submission is clearly in full- fledged C++ for reasons not relying on the NTL, and the build script (if it works at all) requires some external package, big violations which I noted)"
"and then tested compilation (the Wang submissions doesn’t fully compile, but only because it needs to link against the random_bytes that we’ve promised to provide [AFAIK we don’t have a version of that yet I can put in to test stuff?])."
"Is there anything else I should do for ensuring “ANSI C?” Our definition is basically a “I know it when I see it one” after all …"
20170830 10:40:06 file 20240507/FW_ [Itl_supervisors] News Clips from Wednesday..._2.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Discussing news about voting systems. No evident connection to post-quantum crypto.
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 11:23:23 file 20240507/Re_ [Itl_supervisors] News Clips from Wednesday..._1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Discussing voting news. No evident connection to post-quantum crypto.
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"
20170831 10:07:22 file 20240507/Re_ Old RNG_RBG web pages_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"STS is 800-22 (or an implementation of the tests described in 800-22). I think all the errata stuff has been incorporated into the document now. Don't need that file."
20170831 10:27:00 file 20240516/RE_ checking in_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Intern supervision.
20170831 12:57:00 file 20240507/PQC evaluation procedures and submission checkl..._2.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"In the last three months before the deadline, we will probably start receiving submissions at a quicker pace. I’m attaching two documents (also available on the sharepoint site) which should help us stay organized with this. The “PQC submission eval procedure.doc” explains the procedure I’ll follow upon receiving a submission. For those submissions which we receive in the month of September, we’ll need to use the other document “PQC Submission Checklist.doc” to help us determine if the submission is “complete and proper”, or if it isn’t, which requirements the submitter needs to fix."
"To evaluate this, I’ll probably assign out reviewing the technical requirements that need to be checked to various people. For reviewing the optical media requirements, I’ll probably assign Jacob or Larry (unless somebody else wants to volunteer). For this initial check, we are pretty much checking if the submitters appear to have complied with our requirements – we won’t be doing a detailed analysis at this stage. The checklist walks you through it."
20170831 12:59:00 file 20240507/RE_ PQC evaluation procedures and submission ch..._1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Thanks, Jacob."
20170905 02:09:12 file 20240621/[Pqc] PQC seminar_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Now that the summer is over L, we’d like to have some more talks on PQC. If you would be able to speak, or have a topic/paper you’d like covered, please let me know. We’ve typically met every other Friday, at 10am. If anybody really isn’t happy with that time, feel free to propose a new time."
20170907 01:37:31 file 20240716/RE_ All KAT and RNG and API files(1).pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Logistics regarding API details.
20170907 03:51:01 file 20240716/RE_ All KAT and RNG and API files.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Planning posting API information.
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
20170913 10:34:29 file 20240716/Re_ Dagstuhl_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Clearly to Daniel Smith-Tone. Travel logistics.
20170918 09:48:55 file 20240621/[Pqc] No PQC seminar this Friday_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"The speaker’s schedule didn’t work out for this Friday (9/22), so we will not have a PQC seminar. As usual, let me know if you would like to give a talk sometime. We will probably not have too many more opportunities until events overtake us, and we will be too busy to continue with the seminar."
20170921 03:29:05 file 20240621/Another checklist for you_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Can you do the checklist for the optical media part of Post-Quantum RSA (Dan’s template which he just submitted)."
20170921 11:17:36 file 20240716/Dan's skeleton package_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Dan has submitted a “skeleton package” that he is suggesting can be a template for other submitters, and asked for a quick review from us. I’ve looked at it, and it looks good to me. Larry has also looked at the KAT files and thinks they look fine. Please let me know any comments you have today, as I’m going to reply by the end of the day on the forum."
20170929 20:25:22 UTC file 20221003/Brownian.pptx:
20171002 02:16:18 file 20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO...(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Quoted email lists the following as one of the "top two FY2018 milestones" for division 773: "Post Quantum Cryptography: Complete the first round of public submissions for PQC Standardization. Present submissions for public review at an open workshop and start cryptographic analysis on all accepted cryptographic submissions. Completion: 6-18"
20171002 03:10:54 file 20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"7731010 CYB15 – Cryptographic Initiative for Post Quantum Cryptography."
20171002 08:51:12 file 20240617/hash based paper_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"https://eprint.iacr.org/2017/938.pdf"
20171002 11:13:27 file 20240621/Reminder - After Preliminary Deadline_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"First, thank Jacob, Larry and Dustin for diligently handling the submissions before the preliminary deadline. Now all the scanned submissions are stored the sharepoint."
"Dustin will bring this up tomorrow at the meeting. It is always cautious to remind everyone that at this stage, the submissions are still confidential to external of “internal-pqc”. Please make sure that we do not mention who submitted what at this stage and do not discuss any pros and cons on any submitted algorithm with ANY external personal. Some of our team members are traveling and may be asked about the preliminary submissions. When we mention the number of submissions, we need to make sure to tell this is not a final number since people do not have to submit before preliminary deadline and may withdraw before the final deadline. If any of you can think anything else to remind the team, please share."
20171003 02:31:05 file 20240617/Re_ Only Checking KAT Correctness if They Follo..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I did the noting, just didn’t try to get it working to verify things."
20171003 11:23:00 file 20240716/PQC reviews(5)_10_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Maybe redacted address is Daniel Smith-Tone again?
Assigning Smith-Tone to review "STRPI and TPSig", "Post Quantum RSA", "Chrysalis (Enjoy)", "LedAkem", and "DAGS".
20171004 07:43:07 file 20240617/RE_ Are We Requiring NIST API to Get Randomness_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"If everyone but them did it the way we want, I think we were clear enough. We can ask them to make changes."
20171004 10:03:38 file 20240617/Intel x64 processor_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Our CFP says that they need to give us performance/memory measurements on our system platform which is an Intel x64. Forgive me for being computer illiterate, but how can I check if a processor meets that? I’ve seen i7’s and Xeon X5335 and others. Does it just mean it’s an intel processor that is 64-bit?"
20171005 11:55:00 file 20240617/RE_ DON'T DO WHAT I DID_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"It’s been working well for me to click: edit document -> edit in word. It then pops open the document in word. You make your changes. Then click save when you are done, and it saves it to the sharepoint site."
20171010 03:19:02 file 20240716/etsi papers_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Sending pointers to ETSI "quantum safe" white papers. Who was this message sent to? #needmorerecords
20171010 03:24:09 file 20240617/another one_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"https://www.ncsc.gov.uk/whitepaper/quantum-safe-cryptography"
20171010 05:22:38 file 20240617/Re_ NTRUprime_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"AFAIK yes."
20171010 08:59:00 file 20240617/RE_ PQC_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks – no worries on the checklists. I’m sure it’ll all work out fine."
20171013 12:56:51 file 20240716/Re_ Reminder - PQC checklists_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Sorry I've been slow in responding... some other stuff came up this week, and it was urgent. I should be able to do the checklists by COB on Tuesday. I'm sorry for the delay!"
20171016 03:25:00 file 20240621/SIKE_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Do you want to look at SIKE? Rene’s done all his checklists, except that one, and I think perhaps he might have forgotten it. I’m pretty sure it’s not missing anything (besides a problem with the KATs that you already noted). Let me know if you see anything else."
20171016 07:45:00 file 20240617/RE_ memory requirements statement in PQC submis..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I’ve been mostly focusing on the sizes of inputs and outputs. It’d be nice if they addressed how much memory the algorithm used, but I haven’t seen many which do that. But since our CFP says the sizes of inputs and outputs, I think that’s what we should be checking for."
20171016 07:55:31 file 20240617/RE_ Just checking in_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks – I’ll take a look and let you know if I have any questions."
20171016 10:33:00 file 20240621/What does NC stand for_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"In the SRTPI/TPSig checklist, you have several NC’s listed on the optical media checklist. What does that stand for?"
20171017 01:40:31 file 20240617/RE_ KATs on SIKE(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Noted."
20171017 01:41:30 file 20240617/RE_ KATs on SIKE_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing superficial details of the SIKE implementation.
20171017 03:34:00 file 20240617/RE_ Public list_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"10 signature schemes (3 lattice, 3 multivariate, 1 hash based, 3 other)"
"26 KEM/Encryption schemes (12 lattice, 7 code-based, 1 multivariate, 1 isogeny, 5 other)"
20171017 05:06:42 file 20240617/Re_ Ramstake Attack_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing details of Ramstake security.
#weveshownallourwork
20171017 10:15:00 file 20240617/RE_ ramstake checklist_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
" “Both the reference implementation and the optimized implementation shall adhere to the provided API. Separate source code for implementing the KATs shall also be included and shall adhere to the provided API.” "
"To me, this seems to want code for the KATs that follows our instructions. On the other hand, if we can easily verify everything, then that’s probably what is what counts? So, in that regard, Ramstake is fine, right?"
20171017 15:16:00 UTC file 20240617/FW_ 2017 ITL Cybersecurity Program Annual Repor..._9.pdf-attachment-Annual Report Instruction Sheet FY17.docx:
20171018 02:19:00 UTC file 20240617/FW_ 2017 ITL Cybersecurity Program Annual Repor..._9.pdf-attachment-Post Quantum_2017-Annual-Report.docx:
20171018 03:58:58 file 20240716/Re_ Completeness checklists completed(9).pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Is it GeussAgain or GuessAgain?"
20171018 04:25:35 file 20240617/Re_ Post Quantum Initial Submissions_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks!"
20171018 04:58:57 file 20240716/Re_ Completeness checklists completed(7).pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Ok -- I’ll look over the Word doc you sent. Thanks!"
20171019 10:16:46 file 20240716/Re_ Completeness checklists completed(5).pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Discussing feedback to early submitters.
20171019 12:41:29 file 20240716/Re_ Completeness checklists completed(2).pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Down thread: "Also, we might want to remind the submitters that we're also interested in qualitative statements about the possible tradeoffs between security and efficiency. That is, in addition to hitting those security goals (levels 1-5), we're also interested in what kind of flexibility they have when they adjust the parameters in their cryptosystem." #inconsistency
Down thread: "There were a couple of things I recall finding somewhat suspect about pqRSA’s security analysis. – in particular the decision to completely ignore quantum attacks with a depth even slightly greater than 2^64, and the assumption that multiplication circuits must be implemented in a fully two dimensional arrangement, despite the fact that modern supercomputers, for example, have significant 3-dimensional connectivity, and therefore look like they could compute a multiplication circuit with about 30 times less latency than he assumes." #error #weveshownallourwork
20171020 03:24:00 file 20240617/RE_ This is the attack I was looking for based ..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks. Reading further in the submission, they explicitly say they are checking this."
20171020 03:46:10 file 20240617/RE_ A new PQC FAQ_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing FAQ updates.
20171020 03:56:41 file 20240617/Re_ Draft Slides for Dagstuhl_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Hey! Can you make a poster on "thermodynamic analysis of quantum and classical search" for ITL science day? Let me know if you'd like me to help? (Though I'll also be busy presenting another poster on "quantum system tomography.") Probably you can just use Powerpoint to make the poster. I think the posters have to be sent to the printing office by next Tuesday."
20171020 12:30:00 file 20240617/RE_ A new PQC FAQ(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Ok, thanks. No rush on it."
20171023 01:59:24 file 20240617/PQC annual report_8.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Let me know if you have any suggestions."
20171023 02:19:25 file 20240617/Annual Report Time_7.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"You got this email because Lily identified you all to work on the Annual Report by updating or drafting a new write-up. Please try to refreain FROM using a lot of the same information provided in last year’s write-up."
"I know in year’s past you guys worked together on this and sent the write-ups to Quynh. I’m presuming that Quynh is still taking on this responsibility? I’m sure Lily will have somebody in place to collect all write-ups from your group and make the needed edits."
"Attached is the updated list of projects/programs with POC that Lily provided for me for the 2017 Annual Report – if you feel something is amiss, please talk it over with Lily – I just went by the list she provided."
"Thank you in advance for your help & time on the Annual Report."
20171023 12:01:59 file 20240617/FW_ 2017 ITL Cybersecurity Program Annual Repor..._9.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I am reaching out because you have been identified by your group manager, Lily Chen; as the SME/POC for your program that should be responsible for providing content for our FY2017 NIST ITL cybersecurity program Annual Report. The annual report is often used as a great marketing tool to showcase all the great work CSD & also includes all ITL cybersecurity programs has done during a particular year."
20171023 17:56:00 UTC file 20240617/PQC annual report_8.pdf-attachment-Post Quantum_2017-Annual-Report.docx:
20171023 18:15:00 UTC file 20240617/Annual Report Time_7.pdf-attachment-CT-Group_2016-2017-List-of-Projects_LILY-upda.docx:
20171024 06:55:22 file 20240617/Re_ Annual Report Time_6.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Discussing annual reports.
20171025 10:51:46 file 20240617/Re_ PQC annual report(1)_5.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks! I think it looks good. I just made a few minor suggestions."
20171026 02:49:00 UTC file 20240617/Re_ PQC annual report(1)_5.pdf-attachment-Post Quantum_2017-Annual-Report-YKL.docx:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Post-Quantum Cryptography"
"In recent years, there has been a substantial amount of research on quantum computers – machines that exploit quantum mechanical phenomena to solve problems that are difficult or intractable for conventional computers. If large-scale quantum computers are ever built, they will be able to break the existing infrastructure of public-key cryptography (see Table 1). The focus of the Post-Quantum Cryptography (PQC) 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."
"NIST researchers have held regular seminars throughout FY 2017. The presentation topics included the latest published results and security analyses, as well as status reports on quantum computation, hash-based signatures, coding-based cryptography, lattice-based cryptography, and multivariate cryptography. Through these presentations and discussions, the project team has made significant progress in understanding the strengths and weaknesses of the existing cryptographic schemes in each category."
"The NIST team also continues to be productive in post-quantum cryptography research. The results have been published at major conferences, such as Number Theory Methods in Cryptography (NuTMiC), Selected Areas in Cryptography (SAC), PQCrypto, and AsiaCrypt. NIST researchers have given many presentations at venues such as the ETSI Quantum-Safe Workshop, to increase awareness of the upcoming migration to post-quantum cryptography, and to engage with stakeholders in the US and other countries. NIST has also sponsored other research, education, and research events."
"In 2016, NIST published NISTIR 8105: Report on Post-Quantum Cryptography, which shared the team’s current understanding about the status of quantum computing and post-quantum cryptography. Shortly thereafter NIST began the Post-Quantum Standardization Process, a thorough multi-year effort with the objective of creating new quantum-resistant cryptographic standards for public-key encryption and digital signatures (see www.nist.gov/pqcrypto). These functionalities are much more complex than AES or SHA-3, and will require fundamentally new techniques to address several open research questions in this area (for example, how to measure security against quantum attacks when a quantum computer has not yet been built). Submitters from around the world are invited to propose quantum-resistant cryptosystems for consideration by NIST as part of the PQC standardization process. In early FY 2017, after receiving and assessing public comments, NIST issued the final submission requirements and evaluation criteria. NIST has received several proposals, and the final submission deadline is in early FY 2018."
"In FY 2018, NIST will continue to explore the security and feasibility of purported quantum-resistant technologies submitted to the Post-Quantum Standardization Process. NIST will hold a public workshop in April 2018, co-located with the PQCrypto conference, during which submitters will be invited to present their algorithms. The Post-Quantum Standardization Process will proceed with multiple rounds of public evaluation and analysis, with the goal of selecting algorithms for standardization by NIST after three to five years."
20171026 10:12:23 file 20240617/Re_ PQC annual report_4.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"As for the table, I was considering adding it because Patrick asked for more graphics and tables to be in the Annual Report. Maybe we could say "larger key sizes may be needed" instead of just "larger key sizes needed" (and similar for hash functions). If we have the table in there, I don't want to have a long explanation with it."
20171030 01:36:00 file 20240617/RE_ PQC and ECC 2017 Annual Reports(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thank you!"
20171030 03:03:00 file 20240617/RE_ PQC and ECC 2017 Annual Reports_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thank you."
20171030 11:19:28 file 20240617/PQC and ECC 2017 Annual Reports_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I’m attaching the write-ups for PQC and ECC. Let me know of any comments or suggestions."
20171030 15:09:00 UTC file 20240617/PQC and ECC 2017 Annual Reports_3.pdf-attachment-Elliptic Curve Cryptography_2017-Annual-Repor.docx:
Notes from djb, last edited 20240624 05:27:25 UTC:
"In FIPS 186-4, NIST recommends fifteen elliptic curves of varying security strengths for use in these elliptic curve cryptographic standards. However, the provenance of the curves is not fully specified in the standard, leading to recent public concerns that there could be a hidden weakness in these curves. NIST is not aware of any vulnerability in these curves when they are implemented correctly and used as described in NIST standards and guidelines."
20171030 15:09:00 UTC file 20240617/PQC and ECC 2017 Annual Reports_3.pdf-attachment-Post Quantum_2017-Annual-Report.docx:
20171030 18:54:00 UTC file 20240617/Annual reports for PQC and ECC_3.pdf-attachment-Post Quantum_2017-Annual-Report.docx:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Post-Quantum Cryptography"
"In recent years, there has been a substantial amount of research on quantum computers – machines that exploit quantum mechanical phenomena to solve problems that are difficult or intractable for conventional computers. If large-scale quantum computers are ever built, they will be able to break the existing infrastructure of public-key cryptography (see Table 1). The focus of the Post-Quantum Cryptography (PQC) 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."
"NIST researchers have held regular seminars throughout FY 2017. The presentation topics included the latest published results and security analyses, as well as status reports on quantum computation, hash-based signatures, coding-based cryptography, lattice-based cryptography, and multivariate cryptography. Through these presentations and discussions, the project team has made significant progress in understanding the strengths and weaknesses of the existing cryptographic schemes in each category."
"The NIST team also continues to be productive in post-quantum cryptography research. The results have been published at major conferences, such as Number Theory Methods in Cryptography (NuTMiC), Selected Areas in Cryptography (SAC), PQCrypto, and AsiaCrypt. NIST researchers have given many presentations at venues such as the ETSI Quantum-Safe Workshop, to increase awareness of the upcoming migration to post-quantum cryptography, and to engage with stakeholders in the US and other countries. NIST has also sponsored other research, education, and research events."
"In 2016, NIST published NISTIR 8105: Report on Post-Quantum Cryptography, which shared the team’s current understanding about the status of quantum computing and post-quantum cryptography. Shortly thereafter NIST began the Post-Quantum Standardization Process, a thorough multi-year effort with the objective of creating new quantum-resistant cryptographic standards for public-key encryption and digital signatures (see www.nist.gov/pqcrypto). These functionalities are much more complex than AES or SHA-3, and will require fundamentally new techniques to address several open research questions in this area (for example, how to measure security against quantum attacks when a quantum computer has not yet been built). Submitters from around the world are invited to propose quantum-resistant cryptosystems for consideration by NIST as part of the PQC standardization process. In December 2016, after resolving and assessing public comments, NIST issued the final submission requirements and evaluation criteria. NIST has received several proposals, and the final submission deadline is in November 2017."
"In FY 2018, NIST will continue to explore the security and feasibility of purported quantum-resistant technologies submitted to the Post-Quantum Standardization Process. NIST will hold a public workshop in April 2018, co-located with the PQCrypto conference, during which submitters will be invited to present their algorithms. The Post-Quantum Standardization Process will proceed with multiple rounds of public evaluation and analysis, with the goal of selecting algorithms for standardization by NIST after three to five years."
"Email project team: pqc@nist.gov"
20171030 19:02:00 UTC file 20240617/Annual reports for PQC and ECC_3.pdf-attachment-Elliptic Curve Cryptography_2017-Annual-Repor.docx:
Notes from djb, last edited 20240624 05:27:25 UTC:
"However, the provenance of the curves is not fully specified in the standard, leading to recent public concerns that there could be a hidden weakness in these curves. NIST is not aware of any vulnerability in these curves when they are implemented correctly and used as described in NIST standards and guidelines."
Comment on this text from Moody: "It’s been long enough now that we could possibly remove this text, or modify it to not make it seem as strong of a concern."
#nsa
20171031 01:05:47 file 20240617/Re_ Process diagram for the randomness beacon_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Ok, thanks, would be good to know your thoughts."
"Part of the question is whether there’s an aid to have a computer-verified proof of security for a particular process. If the proof of security is simple enough that an expert can just see it all at first glance, then we may not need to add anything. But in a more complex system, perhaps computer- verification could help."
20171031 02:04:42 file 20240716/SRP attack_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently from Daniel Smith-Tone regarding correcting an error in an attack paper.
20171031 13:24:17 file 20240716/Re_ SRP clone_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Lots of redactions. #needmorerecords
20171101 02:47:48 file 20240617/Annual reports for PQC and ECC_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Okay, I’ve incorporated feedback received from the group. Do I need to send these to Patrick? Or you will take care of that?"
"Note – for each one, I included a table/graphic that Patrick can use if he would like. If he doesn’t want to use them, that’s fine."
20171101 02:50:51 file 20240617/Re_ Annual reports for PQC and ECC_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I will send them along with the other sections that I receive to Patrick."
20171106 03:14:00 file 20240617/RE_ PQC - soon to kick into high gear_5.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks Jacob. You’ve been a huge help!"
20171106 11:08:00 file 20240716/Help with pqc-forum Google Group Mail List.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Logistics for moving pqc-forum to Google Groups. Warning that some messages seem to have been lost: "Also, I’ve been told that the last (most recent) message showing in the archive is dated September 6; however, there has been a lot of discussion on the list over the last two months. Do you know what would cause this? The list was activated October 5 if that helps."
20171106 16:06:00 UTC file 20240716/Help with pqc-forum Google Group Mail List.pdf-attachment-Email List Info 11062017.docx:
20171107 03:32:00 file 20240716/PQC-forum is becoming a google group.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Planning for replacing pqc-forum with a Google group.
20171107 09:26:43 file 20240617/Re_ PQC - soon to kick into high gear(2)_4.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"OK thanks."
20171107 10:00:00 file 20240716/FW_ PQC - soon to kick into high gear_3_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Down thread: "Starting up in January, we’ll probably need to start meeting weekly or biweekly to start our review of the submissions." #weveshownallourwork
"In the past, we’ve met on Tuesdays from 10am-noon, as well as from Fridays, from 10am-noon."
20171107 12:02:54 file 20240617/Re_ PQC - soon to kick into high gear(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Sounds ok to me. I will keep some space available in my schedule for early December. I don’t foresee any problem finishing by Dec. 18th if the number of submissions isn’t terribly large. (The hard part for me is always when the submitter “sort of” satisfies a requirement, and then we have to figure out how to deal with that. ☺ I think there are time-efficient ways to address this though.)"
"Either of the meeting times you mention is ok for me – I have a slight preference for 10am-12pm on Fridays, that worked well for me in the past."
"Thanks for the management work! This is an exciting project and I’m looking forward to being involved."
In quoted email: "Starting up in January, we’ll probably need to start meeting weekly or biweekly to start our review of the submissions. In the past, we’ve met on Tuesdays from 10am-noon, as well as from Fridays, from 10am-noon. Please let me know if either of those times works for you so I can schedule B-341 accordingly."
What happened at these meetings? #needmorerecords
20171108 01:36:27 file 20240617/Fw_ FY16 Annual Report Blockchain Writeup_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Attachment; no text other than quoting previous messages.
20171108 04:42:00 file 20240716/pacrypto_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Who was this sent to? #needmorerecords
Forwarding internal ISO communication. #ethics
20171108 07:29:17 file 20240617/Re_ PQC - soon to kick into high gear_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I personally prefer Fridays. Thinh works on FRidays and could help you to review post- quantum candidates/submissions after the completeness checks."
#weveshownallourwork
20171108 18:22:00 UTC file 20240617/Fw_ FY16 Annual Report Blockchain Writeup_1.pdf-attachment-CircuitsAnnualReport2017.docx:
20171109 06:36:02 file 20240617/Re_ Heard last night that Walt is going to OSTP..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"OK! That’s good to hear. Thanks Jim."
20171113 10:43:37 file 20240716/HFEv- paper_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently sent by Daniel Smith-Tone.
"I've written the sections on Q-rank, and using projection with MinRank. Please check them out and make sure they are okay. I am very tired and they may not make sense. Also, Ray, is this what you had in mind for MinRank then Proj and Proj then MinRank?"
20171113 13:26:04 file 20240716/1st cut as Asiacrypt slides_3_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
From "Moody, Dustin" to "Liu, Yi-Kai" and redacted address and "Perlner, Ray A." and "Alperin-Sheriff, Jacob" and redacted address and "daniel-c.smith@louisville.edu". Salutation says "Yi-Kai, Ray, Jacob, Lily, Daniel" so one redaction is Lily Chen. #needmorerecords
Draft slides for Asiacrypt.
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" #claimingtransparency
"We do not expect to “pick a winner” " #inconsistency
"~ 2012 – NIST begins PQC project"
"THE NIST PQC TEAM": "Consists of 12+ NIST researchers in crypto, quantum information, quantum algorithms"
"Hold bi-weekly seminars (internal and invited speakers)" #weveshownallourwork
"PRELIMINARY SUBMISSIONS": "37 submissions received"; "10 signature schemes"; "27 Encryption/KEM schemes"; "15 were lattice-based"; "7 were code-based"; "5 were multivariate"; "The rest were a mix (hash-based, isogenies, ….)"; "From 15 states, 18 countries, and 5 continents"
20171114 02:06:19 file 20240617/Re_ Abstract_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
Posting abstract for a talk on quantum information theory.
20171114 08:48:00 file 20240617/RE_ FY 2018 work_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"There is an ongoing revision of FIPS 186. It will also include a new SP 800-186, which will be on elliptic curves."
"And of course we are doing a major PQC project, but it isn’t tied to a FIPS or SP (yet)"
20171115 01:56:00 file 20240716/RE_ Memory_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently to Daniel Smith-Tone. Discussing MinRank attacks.
20171115 06:12:43 file 20240716/Re_ 1st cut as Asiacrypt slides(1)_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
A few comments on draft Asiacrypt slides.
20171116 01:18:05 file 20240716/Re_ 1st cut as Asiacrypt slides_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Regarding slide 27: "Looks good! If you like, you could also mention Tor and Signal as possible applications... they are not so commonly used, but they might be early adopters of PQC."
20171117 02:52:21 file 20240716/Re_ Our paper_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently from Albrecht Petzoldt.
"I think this would be better. I missed the term HFE."
20171117 10:54:55 file 20240716/Re_ confused_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Looks like this was from Daniel Smith-Tone. Discussing UOV security with Perlner.
20171120 09:09:34 file 20240716/Re_ the invariant attack_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
From Daniel Smith-Tone. Attack discussion.
20171120 10:10:00 file 20240617/RE_ [Pqc-forum] Reminder - Final Deadline for s..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I didn’t get a warning. I realized right after sending it I’d sent it to the wrong email address. But I didn’t want to send it again."
"I did think it odd that I didn’t get a warning email, since that’s what is apparently supposed to"
20171127 01:58:43 file 20240617/RE_ Any approved hash function to substitute SH..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Qunhy also notes no key gen algorithm. And to allow other pre-hashes."
20171128 02:32:06 file 20240617/Re_ Since Larry's Gonna Be Out I'll be Doing th..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Got it. No worries. It's great we have Jacob to help us here."
20171128 03:46:13 file 20240716/Review Request(1)_3_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Review request, apparently from Daniel Smith-Tone.
20171128 04:52:26 file 20240716/Re_ Review Request(1)_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Looks like this was from Daniel Smith-Tone. Looking for someone to review a paper.
20171129 01:00:09 file 20240617/GUI and Rainbow_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I uploaded 2 submissions: GUI and Rainbow, delivered to me in person by Albrecht."
20171130 02:01:00 file 20240716/RE_ Review Request_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently to Daniel Smith-Tone. Short review of a paper.
20171130 02:44:56 file 20240617/RE_ classifying submission_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Yeah, not expecting them to go far, but I think we have to call it 2 submissions, since 2 different functionalities."
20171130 09:26:00 file 20240617/RE_ PQC meeting_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I am on travel starting tomorrow and all of next week."
"Yes, my intention is to assign everything out tomorrow."
20171130 11:56:00 file 20240716/RE_ Google mailing lists.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"FYI – Dustin moved pqc-forum over and it’s been pretty seamless except for letting members know they have to add “list” to the email address now lwc-forum@list.nist.gov. Once it’s set up, let me know and I’ll update that web page."
20171201 04:54:43 file 20240617/Re_ Unless You Have Serious Objections(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Ok. Just wasn’t sure how serious of an issue(s) Jacob was addressing."
20171201 08:26:23 file 20240507/Re_1 .pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"I think I managed to upload the gemms stuff sent to me. They kept using every half hour or so. I just uploaded it all. Hopefully you can figure out the right one to use."
"Chrysallis didn't submit. Odd, I thought they would."
20171201 09:56:52 file 20240507/PQC Submissions Over_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"PQC submission call ended yesterday at 5PM local. We received 80 as of the count this morning. We are still sifting to be sure there are no duplicates, double counting and reviewing the paper submissions."
"Next milestone is Dec 15 to finish package reviews for completeness and correctness and notify submitters. That will then be our final number as we expect to reject some during these next two weeks."
"Thanks, and I will keep you updated, shaping up to be a fun winter-spring"
20171201 11:29:45 file 20240531/Re_ Game on!(3)_3.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Thanks!"
20171201 12:50:17 file 20240507/Pqc summary_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"82 submissions"
"23 signature schemes, 59 kem/encryption"
"Of the signatures: 7 multivariate, 5 codes, 4 lattice, 4 hash, 3 other"
"Of the kem/enc: 24 lattice, 19 code, 6 multivariate, 10 other"
20171201 13:27:55 +0900 file 20240716/Fw_ A few (minor) corrections.pdf-attachment-LOTUS_specifications_2017Nov30_final.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
LOTUS submission dated 30 November 2017.
20171201 22:34:37 +1100 file 20240716/Fw_ A few (minor) corrections.pdf-attachment-Titanium_NISTSub.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Titanium submission dated 1 December 2017.
20171202 08:07:40 file 20240617/Re_ Unless You Have Serious Objections_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"That should be fine. Please copy me on your emails. I do agree with Larry, that major changes shouldn't be permitted. So we need to keep that in mind before replying to anybody. If you have any doubt if it's a minor or major change, please consult with the team."
"Maybe send a copy of your planned email response to me, Ray, and Larry and wait a few hours to check with us."
20171202 14:59:42 UTC file 20240617/Slides_4.pdf-attachment-AsiaCrypt Moody PQC.pdf:
20171203 10:31:31 file 20240617/Slides_4.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
No text, just attachment.
20171204 04:03:29 file 20240617/RE_ Slides(2)_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks. That is where I had in mind also."
20171204 04:20:00 file 20240617/RE_ Slides(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"That is all right. We can stay on 82."
20171204 04:20:59 file 20240531/Re_ Game on!(2)_2.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Thanks"
20171204 09:30:20 file 20240617/Re_ Slides_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks for noticing. I updated it, and it's attached now. It's of course fine to wait till Lily approves it."
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
20171204 14:25:17 UTC file 20240617/Re_ Slides_1.pdf-attachment-AsiaCrypt Moody PQC.pptx:
20171204 14:25:42 UTC file 20240617/Re_ Slides_1.pdf-attachment-AsiaCrypt Moody PQC.pdf:
20171205 02:39:00 file 20240507/RE_ Attending Eurocrypt 2018_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
Travel planning.
20171205 03:15:00 file 20240516/Re_ Comments on _Quantum Entropy Chip_ paper_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Discussing a quantum RNG.
20171205 03:31:03 file 20240617/RE_ We've decided to disqualify Theory of Mathe..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Agreed. I will do the contacting the submitters, as before, for the final notifications."
20171205 04:24:52 file 20240617/The Kachko (Ntruprime IIT Ukraine) and Rustam I..._1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Hope my responses were okay; I assume we’ll eventually disqualify them but I figured we are giving at least an initial chance to fix to everyone but the truly special Theory of Mathematical Defense guy. I’m not going to spend any more time back-and-forthing with them though."
20171205 08:48:03 file 20240531/Re_ Game on!_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Ok, thanks."
20171205 09:50:42 file 20240507/PQC submission data_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"See pages 33, 34, 35."
20171205 14:49:00 UTC file 20240507/PQC submission data_1.pdf-attachment-AsiaCrypt Moody PQC copy.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"We see our role as managing a process of achieving community consensus in a transparent and timely manner" #claimingtransparency
"We do not expect to “pick a winner”": "Ideally, several algorithms will emerge as ‘good choices’" #inconsistency
"Hold bi-weekly seminars (internal and invited speakers)" #weveshownallourwork
"Much broader scope – three crypto primitives"
"These are understood to be preliminary estimates" #inconsistency
"Submitters need not provide parameters for all levels" #inconsistency
"Gaussian simulation"
20171205 21:33:47 UTC file 20230118/Thermodynamic_Analysis_of_Classical_and_Quantum_Search.pptx:
20171207 02:21:56 file 20240507/Re_ Before You Respond to Anyone That Their Sub..._1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"I added a new column to the master table on whether I’ve also checked the comments."
"(I also hid a column I created on Monday separating schemes into Key agreement/exchange or signatures [to minimize complexity of the problem-type table]. I don’t anticipate this will be a problem for you or anyone but I figured I’d mention it)."
20171208 01:33:56 file 20240426/RE_ How are the reviews going_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"I started on the reviews and it’s going fine so far. I should be able to finish by next Friday – although I do also have some other deadlines next week. I will update you asap if I run into trouble."
20171208 01:33:56 file 20240426/RE_ How are the reviews going_4.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"I started on the reviews and it’s going fine so far. I should be able to finish by next Friday – although I do also have some other deadlines next week. I will update you asap if I run into trouble."
20171208 05:37:11 file 20240426/Re_ How are the reviews going_(2)_3.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"The three that I’ve done so far have gone smoothly, and I don’t anticipate any problems. (I’ll be setting more time aside for this next week.) The Dec. 15th deadline works for me. Have a great weekend!"
20171210 12:01:16 file 20240426/Re_ How are the reviews going_(1)_2.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"I did a few this weekend, but I am flying out of the country again today. I will be back on the 24th. I can do some more then if necessary."
"I changed my name to red in the excel spread sheet on the ones I got done."
20171211 06:37:17 file 20240716/RE_ Review Request_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently from Daniel Smith-Tone. Saying thanks for a (short) paper review, and saying will finish reviews of competition submissions.
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."
20171211 10:27:02 file 20240516/Re_ Had to Create a New NIST Reference Platform_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"I should be fine. I have 12 more to do a first check on after I finish the one I’m doing, and I should get that done today."
20171211 10:46:32 file 20240516/RE_ Meeting on Dec. 12th_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Thanks. Feel free to use any of it for any presentations you give!"
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."
20171212 10:53:49 file 20240516/Re_ Kerman, Sara J. (Fed) wants to access 'PQC'_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"I got notified that it was moved while I was on travel. I wanted to wait until I got back to notify the group. I’ll do that today. Once you see the message please update the site."
Discussion shows internal URL: https://nistgov.sharepoint.com/sites/PQC
#needmorerecords
20171213 06:06:10 file 20240516/Re_ Re Submissions with Albrecht on Them_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"I agree."
20171213 06:07:55 file 20240507/Re_ A Submission Includes an Intrinsic using-ve..._1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"It should be fairly equivalent, but it would be great if you could direct them to use the OpenSSL version."
20171213 07:16:59 file 20240516/RE_ Sample Letter to PQC Workshop_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Conference planning.
20171214 03:01:00 file 20240426/Frodo_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Does it pass your optical media checklist? I see “Fix” in Implementations in ANSI-C, but in the detailed checklist, no problems noted."
20171214 03:09:00 file 20240516/RE_ SIKE_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Got 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."
20171214 09:42:04 file 20240617/Same question on DualModeMMS_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Same question as I asked on BIKE. Just double checking you cleared it, even though I don't see notes on the checklist."
20171214 10:07:15 file 20240617/same question for PQRSA_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
No text.
20171215 01:46:00 file 20240516/RE_ NTRU prime Ukraine_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Perfect. Thanks"
20171215 03:25:00 file 20240516/RE_ Giophantus_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Yes, I checked it. It seemed like things were in order – just as they were in the early submission – so there was no need to update the checklist."
20171215 08:39:28 file 20240507/Re submissions_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"BIKE, CFPKM, LUOV (I could’ve sworn I specifically double-checked and did that one after the spreadsheet issue) and PQRSA are all definitely fine. DualMMS was fine for the single KAT that took 12.5 minutes. I will run it now to check a grand total of 3."
20171215 09:16:29 file 20240426/Re_ PQC_2.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Hmmm. That wasn't supposed to happen. We gave permission for a few teams to send us new specifications, as they said they were only changing typos."
"We allowed them to revise their implementation in line with what Jacob was asking (so that he could verify the KATs). But they shouldn't have changed their spec pdf. Do you recall which ones?"
20171215 09:17:16 file 20240507/Re_ Lima updated submission_2.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"Yes - thanks for catching this. We will do this."
20171215 09:57:00 file 20240617/RE_ Reviews(1)_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"That's what I figured. Thanks!"
20171215 11:03:30 file 20240516/RE_ PQC Isogeny system_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
Intern supervision.
20171218 01:17:23 file 20240516/Re_ Regarding Round2_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"There are 25 directories, 20 for uround, 5 for nround. I’m okay with posting it though but it’ll be over our 25MB limit"
20171218 07:22:00 file 20240426/FW_ PQC_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Not sure how to check, but lets make sure we are using the most current versions, especially for what we post."
20171218 07:59:00 file 20240716/RE_ Reviews_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Apparently to Daniel Smith-Tone. Agreeing to allow a submission (Rainbow?) not meeting the software rules (not having portable code?).
Down thread: "NTRU Prime seems to be incomplete, unless I overlooked the data. I see no timing values for the NTRULPrime scheme. It seems fine for the SNTRUP scheme with everything complete." #error
Also down thread: "I'm not moved by the reply from the submitters of STRPI and TPSig that the decryption/signing function is linear "only" for the legitimate user. What nonsense is that? Is y=2x quadratic for me if I don't look at it? The submission is complete, but not proper." #weveshownallourwork
20171218 10:44:18 file 20240617/This week ITL item_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I am traveling this week and want to get this info for this week:"
"This week, NIST will post the accepted public submissions for Post Quantum Cryptography (PQC) standardization. These submissions from around the world must meet NIST criteria for strength, speed, size and capabilities. This is a major milestone achievement in PQC development for NIST and the nation as we now start a transparent and traceable review of all the submissions. https://csrc.nist.gov/projects/post-quantum-cryptography"
20171218 11:27:05 file 20240516/RE_ Post-Quantum Crypto Competition_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Thanks for the information. For some reason when I searched earlier I couldn’t find that page on the CSRC, so thank you for the link. I requested to join the mailing list. What you suggested is essentially what I’d like to do with these algorithms. As I understand there are a handful of structures that many are based on. I look forward to receiving the list of qualified candidates."
Mail thread mentions confidentiality. #weveshownallourwork #inconsistency
20171218 11:50:00 file 20240426/FW_ Reviews completed and compiled_1.pdf:
Notes from djb, last edited 20240506 18:31:57 UTC:
"Please consider the summary as an intermediate results. We need to discuss the group with 7 submissions tomorrow. I will send update later."
20171219 02:05:00 file 20240507/it was BIKE_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
No text.
20171219 02:35:00 file 20240507/lima has a bunch of pdf statements_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
No text.
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"
20171219 04:05:43 file 20240531/RE_ Zip Files - Starting to review_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Yes! :-0"
"We need that info to be there for accessibility. Plus it helps with information retrieval on the site."
20171219 11:41:41 file 20240507/pqNTRUsign is cleared_1.pdf:
Notes from djb, last edited 20240511 21:52:47 UTC:
"The subject says it all"
20171220 02:59:41 file 20240531/Re_ himq-3(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Checking their documentation, " A family of HiMQ-3 consists of HiMQ-3F and HiMQ-3P, the generalization of HiMQ-3 and HiMQ-3 using a small random seed as the secret key, respectively. HiMQ-3, HiMQ-3F and HiMQ-3P are optimized for signing performance, the public key size and the secret key size, respectively.” (HiMQ-3P doesn’t appear to have been included). I think they’re best viewed as different parameters based on this and glancing at the code, I will reorganize to fit this."
20171220 03:03:41 file 20240531/Re_ himq-3_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"OK, I modified it to put it in a more correct directory format."
20171220 09:15:20 file 20240617/Two decisions, one still pending_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Okay, so the OKCN one is a YES. The Asymmetric QCMDPC is a NO. We’re still deciding on GuessAgain."
20171220 09:49:40 file 20240516/RE_ Regarding the FAP_KC Submission_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"We have done an amazing job to look into 82 packages in such a short period of time. It is very wise to look into some “No” submissions one more time in case we have missed something. Not complete and/or not proper shall be a major reason to be categorized to “No”."
20171220 11:00:50 file 20240617/Re_ Regarding GuessAgain_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Nice!"
Quoted thread shows Alperin-Sheriff "desperate to salvage my goal number of submissions".
20171221 01:47:11 file 20240617/summary of PQC project for ACMD annual report_3.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"I wrote a short summary of the PQC project, for the ACMD annual report. What do you think? Let me know if you have any comments or suggestions, and I will try to incorporate them into the final version, and submit it on Friday."
20171221 02:14:47 file 20240531/Re_ Posting Our Attack Thoughts_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Hey why not?"
#weveshownallourwork
20171221 02:46:23 file 20240531/RE_ Posting Our Attack Thoughts_(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
Discussing whether to post NIST's initial analysis of submissions.
"We need to determine when will be “eventually”. In SHA-3 case, we have the first round report, which include public analysis and also NIST team’s analysis."
"Can you please clarify “I don’t think that we should put the comments on the site initially.” Which comments?"
"For minor issues, would we have included in the acceptance letter to the submitters?"
#weveshownallourwork
20171221 06:33:48 file 20240617/Re_ summary of PQC project for ACMD annual report(1)_2.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Looks great! Good work!"
20171221 06:43:00 UTC file 20240617/summary of PQC project for ACMD annual report_3.pdf-attachment-pqc-summary-2017-draft.docx:
20171221 12:39:10 file 20240531/Re_ Submitter Acceptance Letters_1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Yes, I did. So you can send it to her."
20171222 07:49:11 file 20240716/Fw_ A few (minor) corrections.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"I realize I probably wasn't totally clear about what I meant by "latest version". Do you think anybody on the mailing list will mis-understand? I don't want people to think we are allowing teams to update their submissions. Both teams sent more than one version on the last day, and we apparently posted the wrong one. So, we're just correcting our mistake."
"But I see that my email might make people think we are allowing teams to update their spec. Should I explain that more in another message to the forum? Or is it fine?"
20171224 02:41:49 file 20240617/Re_ summary of PQC project for ACMD annual report_1.pdf:
Notes from djb, last edited 20240624 05:27:25 UTC:
"Thanks, Lily! I removed the mention of "discrete log," as it is not the right term, as you noted."
"I think it's still ok to talk about the submission deadline, since the FY17 report can also describe activities that continue in FY18."
"I didn't want to mention how many proposals were deemed "complete and proper," because many people will not know what that means, and I didn't want to explain exactly how a proposal could be so bad that it should be rejected immediately."
"I will submit the final version now..."
20171226 10:09:22 file 20240531/Re_ Some People Didn't Get Migrated Into the Go..._1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"Not sure I understand."
"I believe some people weren't migrated. We noticed that. We have had lots signing up in the recent days."
"When you say only people accepted can view it, what do you mean? The archives? I think that is the case. The archives are publicly viewable for group members. That was not the case with the old system. Only NIST could view those archives. So it's not perfect, but it is better than what it was."
20171228 07:33:00 file 20240531/Re_ What Are We Doing About the Attacks That We..._1.pdf:
Notes from djb, last edited 20240624 05:27:28 UTC:
"With previous “ competitions” I think there were various outside groups - SHA Zoo as an example - that would create tables with breaks, etc. We already see people putting up tables now. I would let the community continue like that. All we need to do is eventually justify some decisions. It’s still very soon after we announced the candidates. I bet that by the time the people give their presentations at the Workshop there will be plenty of sites up with that sort of information."
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:
20180108 09:41:00 file 20240716/DAGS_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Nobody on the forum has posted about DAGS yet. You may wish to do so."
20180124 10:17:38 file 20240716/RE_ Copy of _HFERP -- A New Multivariate Encryp..._Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Looks like this is to Daniel Smith-Tone. Discussion of publication logistics.
20180126 11:22:00 file 20240621/about mailing list internal-pqc_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Can we check who is on the list?"
20180209 01:32:40 file 20240621/Categorizing the PQC submissions_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"We had 69 accepted submissions. 3 have been withdrawn, leaving 66."
"46 Key Establishment schemes 24 lattice 17 code-based 5 other (2 multi-variate, 1 RSA, 1 random walk, 1 isogeny-based)"
"20 Signature schemes 7 multi-variate 5 lattice 3 code-based 3 hash-based (or symmetric based) 2 other (1 RSA, 1 braids)"
"I think this is what you were after?"
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.
20180213 12:30:47 file 20240716/RE_ DAGS-5 Entropy(1)_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Discussion of NIST planning to make a public comment about DAGS-5. In short: "The issue is that the shared seed for generating the keys has only 192 significant bits."
What happened here? #needmorerecords
20180220 01:21:00 file 20240716/RE_ FW_ Conference Registration_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Discussing travel logistics for Daniel Smith-Tone.
20180220 04:11:46 file 20240621/Re_ Conference Registration_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"I just registered for PQCrypto. Thanks!"
20180222 file 20240621/Agenda-PQC2018-Mar23_1.doc:
Notes from djb, last edited 20240628 14:24:55 UTC:
Draft conference schedule.
Seems to have been edited in 2024. What was edited? #needmorerecords
20180223 10:02:00 file 20240621/BIKE slides_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
No text, just attachment.
20180223 10:14:17 file 20240716/Fw_ BIKE slides_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Who was this message sent to? #needmorerecords
Passing along internal BIKE slides from Perlner. #weveshownallourwork
20180223 15:00:04 UTC file 20240621/BIKE slides_2.pdf-attachment-BIKE.pptx:
Notes from djb, last edited 20240628 14:24:55 UTC:
Should compare to other versions.
20180225 10:30:59 file 20240621/CA paper review_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Text of a review by Peralta of a paper. No obvious post-quantum connection.
20180306 09:25:19 -0500 file 20240716/_no subject_.pdf-attachment-RLCE.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Slides on RLCE.
20180306 10:09:43 file 20240716/_no subject_.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
No text, just sending RLCE.pdf attachment.
20180307 01:22:43 file 20240621/RE_ 2nd NIST PQC workshop_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Conference planning.
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.
20180410 07:55:05 file 20240621/Re_ AFP panel, Chicago Nov. 4-7_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Travel planning.
20180412 11:49:17 file 20240621/Certified randomness in NIST news_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Links to public postings on quantum randomness.
20180416 10:35:21 file 20240716/Re_ CSRC announcement_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"No objection here either."
20180417 01:02:29 file 20240716/Decryption failure in original NTRU when p = 2 + X_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Someone forwarding an old NTRU-related paper.
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
20180419 10:13:09 file 20240716/An ideal generated by a polynomial._1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Some basic math pointers sent by someone anonymous and cc'ed to someone anonymous. #needmorerecords #scramble
20180425 04:30:45 file 20240716/Re_ Guidelines for merging submissions.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Planning merge procedures.
20180426 02:16:15 file 20240716/RE_ 2nd draft of Submission Merging Guidelines(7).pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"We aren’t expecting many to merge. And if two teams merge (neither of which is strong enough), well yes, it would be lots of work for no benefit. But we are asking them to tell us first. And also saying that the rest of the merged submission isn’t due until later. I suspect that’s what will occur. If they tell us they are merging – we can probably give them guidance before they do a lot of work that it might not be necessary"
20180426 02:37:00 file 20240716/RE_ a very large Galois group, so that the numb...(1)_2_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
For number theorists, the content of this thread between Moody and Dang is astounding. #scramble #error
Other records show that there was more internal discussion here resolving NIST's simple mistake regarding evaluation at 1. Was there more internal discussion of NIST's much more fundamental mistake regarding Galois groups? #needmorerecords
The glaring problem here is that all of this was out of sight of the public. NIST knew that it was having trouble understanding something a submission said, so why didn't it issue prompt public questions? This looks like a government agency hiding its lack of expertise behind a lack of transparency. #weveshownallourwork
20180426 02:47:00 file 20240716/RE_ a very large Galois group, so that the numb..._1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Clearly to Dang. Corrects previous misstatement by Moody that "This seems to be true for NTRUprime. I don’t see where they claim the attack doesn’t work." Still doesn't correct NIST's more basic confusion about Galois groups.
20180427 08:47:33 file 20240716/Re_ 2nd draft of Submission Merging Guidelines_5.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"This is why we should guarantee that merging won't reduce their chances of 2nd round selection. I don't think that restricts US at all because it still lets us rejected merged algorithms if we would've rejected both of them separately, and similarly i don't see binding us to accept a merged algorithm if we would have accepted at least one of the components as a restriction since we can insist that the merged algorithm reflect the best component if necessary."
20180427 08:47:45 file 20240716/Re_ 2nd draft of Submission Merging Guidelines(2)_4.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Interesting thread showing some awareness of unfairness of NIST's procedures, but missing the unfairness created by a lack of transparency (e.g., "we could handle this situation because the teams which would like to merge will talk to us and we could give them some advice about their candidates' statuses"), and not showing how NIST ended up deciding what to do.
#needmorerecords
20180430 01:16:41 file 20240716/RE_ 2nd draft of Submission Merging Guidelines(6)_3.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
More discussion of merging.
20180430 08:09:00 file 20240716/RE_ 2nd draft of Submission Merging Guidelines(5)_2.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"As to the line you quoted, we mean that by necessity a merging will require many changes. The teams can therefore update their parameters. However, our decision as to which submissions move into the 2nd round will also factor into account the original parameters from the original submission(s). Meaning, we don’t want anybody to merge just as a way to make some changes, because they were attacked and want to increase their parameters. In our CFP we said we weren’t allowing changes before the 2nd round, so this is just a hint that we are trying to keep a level playing field."
"Not sure if that makes sense. Yi-kai explained it better at our meeting last week."
20180430 09:31:00 file 20240716/RE_ 2nd draft of Submission Merging Guidelines_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Finalizing draft of announcement on merging submissions.
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:
20180507 03:27:00 file 20240621/Mail_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Public email regarding the "signed IP statements".
20180507 08:01:00 file 20240716/RE_ Very urgent please help!(1)_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Moody again explaining to Dang why fields block a particular attack.
20180517 07:55:20 file 20240716/RE_ or maybe stick with DAGS_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Sounds good!"
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.
20180717 12:48:16 file 20240621/Re_ authority for hash-based_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"I think that’s really a non-issue. SP’s were a lot less common when we started the modes of operation work. Now no one seems to question SP vs. FIPS unless we were specifically instructed by law/executive order to do a “standard.” "
"That being said, I don’t have a problem with including that sentence in the explanation section. It’s easy enough to do."
20180731 11:04:30 file 20240621/Any chance I could get you to present on NTRU a..._1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Let me know. Your NTRU prime one was great – and these would be very similar…."
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 01:57:03 file 20240621/RE_ Check slides(3)_3.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Looks good to me. I put some small suggestions for you using comments (attached)."
20180814 04:26:00 file 20240621/RE_ Check slides(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Changed slide 8 again after talked with Ray."
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.
20180814 17:53:31 UTC file 20240621/RE_ Check slides(3)_3.pdf-attachment-QsCI2018-Prepost-08132018-dm.pptx:
20180814 20:25:27 UTC file 20240621/RE_ Check slides(1)_2.pdf-attachment-QsCI2018-Prepost-08142018.pptx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Cryptography in “Pre-Post-Quantum” Time"
"Lily Chen"
20180815 08:43:18 file 20240621/RE_ Check slides_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
" “Essential” crypto primitives is fine with me. "
20180827 03:51:38 file 20240621/RE_ Crypto Reading Club - August 29_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Hmm.. interesting. I hope you receive the original email soon! : )"
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".
20181202 05:18:10 file 20240621/Re_ About hash-based blind signatures_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Discussing threshold signatures and blind signatures.
20181204 01:06:00 file 20240621/RE_ (Related note) Re_ Security concerns about LAC_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Yeah, sure – I should be in after lunch on Thursday"
Thread is discussing details of the security of LAC.
#weveshownallourwork
20181206 01:38:00 file 20240716/RE_ announcement_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Planning an announcement. Apparently a conversation with Daniel Smith-Tone.
20181210 01:38:29 file 20240716/1st Round Report(1)_8_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Draft of NIST IR 8240, the first-round report.
"This report describes the evaluation criteria and selection process, based on public feedback and internal review of the first-round candidates, and summarizes the 26 candidate algorithms announced on January 7, 2019 for moving forward to the second round of the competition." Meanwhile NIST often publicly claimed that this wasn't a competition. #inconsistency
"The 17 Second-Round Candidate public-key encryption and key-establishment algorithms are BIKE, Classic McEliece, CRYSTALS-KYBER, FrodoKEM, HQC, LAC, LEDAcrypt (merger of LEDAkem/LEDApkc), NewHope, NTRU (merger of NTRUEncrypt/NTRU-HRSS-KEM), NTRU Prime, NTS-KEM, ROLLO (merger of LAKE/LOCKER/Ouroboros-R), Round5 (merger of Hila5/Round2), RQC, SABER, SIKE, and Three Bears. The 9 Second Round Candidates for digital signatures are CRYSTALS-DILITHIUM, FALCON, GeMSS, LUOV, MQDSS, Picnic, qTESLA, Rainbow, and SPHINCS+."
"NIST feels that Three Bears is just right for moving forward." This disappeared from the final report. The final report added "However, the security assumption upon which Three Bears is based is new and requires more analysis." Why were these changes made? #needmorerecords
"NTS-KEM generates their keys in a different way, and their specification has decryption failures."
"information-set-decoding algorithms have only been incrementally improved since they were introduced over 50 years ago, and unlike lattice attacks there is good agreement between theory and experiment regarding their computational complexity." Why did NIST suppress this comparison? #needmorerecords
20181210 02:45:49 file 20240716/Re_ 1st Round Report(1)_7_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"See my proposed changes in the NTRU and NTRU Prime sections."
"One more thing: you skipped the sentence about security property of being a large Galois group. It seems to me that Mike Hamburg kinda implicitly agreed that being a large Galois group might have security benefit."
"If an attack is based on the Galois group (all of the automorphisms), a large Galois group would be computationally expensive to be computed. For the size of 4500!, it is around 10^14,5000."
Some comments under "MD" don't seem to have been in previous text; does this mean the comments were edited by Dang? Namely: "There are 2 options that they can consider. The first one is to drop one ring since 701 and 743 are close. The second is to use only 1 encryption scheme. The HRSS option is superior (in my opinion) because variables are taken from uniformly random distributions (no fixed-type restrictions for g and m), but that is a minor thing. NTRU Prime uses fixed-weights, not uniformly random variables either." Also: "The issue is that if we ask them to do that: they would feel agonized because the 2 teams will have to fight hard again. I don’t think it would hurt the analysis effort if you leave them as they are."
#weveshownallourwork
20181210 03:17:02 file 20240716/RE_ 1st Round Report(2)_6_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Thanks. I’ve made the changes"
20181210 04:29:44 file 20240716/Re_ Dear D.B.A._1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Thread shows internal rationales for preliminary decisions regarding LIMA. #weveshownallourwork #needmorerecords
Down thread, Apon:
"Tomorrow at 10am is our last PQC meeting to finalize decisions before the next round."
"I would like to advocate for LIMA to be moved through to the next round. (BLahblahblAh, it'll be eliminated eventually, etc.)"
"There are two factors to consider: 1) SUPERCOP benchmarking results, which we haven't fully looked through yet (which offsets the "2x overhead" of LIMA in the comparison talk..) and more importantly, 2) LIMA has working code for distributed decryption https://eprint.iacr.org/2018/1034.pdf"
"Jacob and I have discussed looking into real-world PQC threshold signatures recently, and LIMA is -- now, in my view -- the best jumping-off-point to approach that. I don't see why would eliminate them (given that we kept both of Classic McEliece and NTS- KEM, zzzz)"
Robinson asking: "Was LIMA only removed for inefficiency?":
Apon responding: "Ya, I originally advocated axing it because it was 2x worse bytes/cycles than similar lattice KEMs from Jacob's numbers (It is very, very similar to other such lattice schemes -- as are they all, amen) At the time, it was the "closest-to-margin cut" among the lattice KEMs -- I compared it with NTRU Prime in particular."
There were already public warnings that some submissions didn't have optimized code yet and that speedups would vary from one primitive to another. It was wrong for NIST to use a 2x cycle-count gap as a reason for cutting a submission. There was no reason to think that this gap would persist. #error
20181211 03:08:19 file 20240621/1st Round Report_4.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"I’ve incorporated comments in from our meeting this morning. Please review. Send back suggestions/edits by Friday."
20181211 08:20:05 file 20240716/Re_ 1st Round Report_5_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Yes, I suggest we have a pun on the scheme name in every write-up rather than just LAC and Three Bears"
20181211 20:05:00 UTC file 20240621/1st Round Report_4.pdf-attachment-PQC Report on Round 1_NISTIR.docx:
Notes from djb, last edited 20240628 14:24:55 UTC:
Editing NISTIR 8240 to add author names.
"The 17 Second-Round Candidate public-key encryption and key-establishment algorithms are BIKE, Classic McEliece, CRYSTALS-KYBER, FrodoKEM, HQC, LAC, LEDAcrypt (merger of LEDAkem/LEDApkc), NewHope, NTRU (merger of NTRUEncrypt/NTRU-HRSS-KEM), NTRU Prime, NTS-KEM, ROLLO (merger of LAKE/LOCKER/Ouroboros-R), Round5 (merger of Hila5/Round2), RQC, SABER, SIKE, and Three Bears. The 9 Second Round Candidates for digital signatures are CRYSTALS-DILITHIUM, FALCON, GeMSS, LUOV, MQDSS, Picnic, qTESLA, Rainbow, and SPHINCS+."
20181212 01:05:42 file 20240621/All I want for Winter Solstice is.._1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"..mergers of or selections among:"
"--Kyber --Saber"
"--LAC --Round5"
"--Classic Niederreiter --NTS-KEM"
"--NTRU --NTRU Prime"
"--BIKE --HQC"
"--ROLLO --RQC"
"--Every Multivariate Signature"
20181212 10:05:54 file 20240621/RE_ 1st Round Report(1)_3.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Good catch."
"The 5 were the ones withdrawn, but we should include them so that the numbers add up."
20181213 10:22:05 file 20240621/RE_ Call for Papers for 2nd NIST PQC Workshop(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Attached please see my comments. About the timeline, I think we can review the submissions in 4 weeks (or shorter). There is no problem to push the submission deadline to June. If we can send the acceptance note to the authors before July, would they have enough time for travel arrangement? Even for visa application, I think they have enough time."
20181213 11:03:57 file 20240621/Re_ 2nd round tweaks(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Let me post the microcontroller/programmable hardware thing first and get back to you tomorrow taking any responses into account."
20181213 11:46:57 file 20240621/Re_ 2nd round tweaks_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Yes, this is what I was saying."
20181213 11:51:31 file 20240621/RE_ Call for Papers for 2nd NIST PQC Workshop_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"I’ve made the change (and Lily’s other suggested changes). Thanks!"
20181213 15:16:00 UTC file 20240621/RE_ Call for Papers for 2nd NIST PQC Workshop(1)_2.pdf-attachment-LLC-Call for 2nd NIST PQC Workshop.docx:
Notes from djb, last edited 20240628 14:24:55 UTC:
Editing call for papers.
Comment from Lily Chen on "Cryptanalysis of candidates, including cryptanalysis of weakened or toy versions": "For PQC, the toy version may not tell much intuitive about the actual security strength. This is not like hash functions."
20181217 11:11:00 file 20240716/RE_ Final list_(1)_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"Anybody wanting more should have caught you last week. You seemed to not care then. Ha-ha!"
Down thread: "I know we’ve had some discussion on Lima and KINDI, but at the last meeting we left it with both of them still out."
20181218 07:42:28 file 20240716/Re_ Candidate list_1_Redacted.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
Clearly to Daniel Smith-Tone. "Thank you. I agree with your assessment and your advice for how we can do better in the future."
Comment from Smith-Tone that this is replying to has three paragraphs. Paragraph 1: "I would have been happy to keep KINDI, but I think that I would prefer to respect the opinions of those who have consistently wanted it out at this point. It is unlikely that their impressions will be swayed so much to make it or LIMA a strong candidate in the future."
Paragraph 2: "I think it would be best at this point to merely leave ourselves open to influence from new information, since we seem to have established a collective position on the given data. By this I mean that the group position has been consistent. Sort of three strikes and you're out."
Paragraph 3: "I think we need to discuss our decision process in more detail in advance for the next round. What I would like to change is to specify what our priorities are for drawing comparisons for various schemes ahead of time as well as to discuss our target for the next round(if needed). In this round, I think that we did not communicate very well our priorities for use cases and performance. This approach is fine probably for this round, in particular it allows us to keep our options open in a way, but I think we need to be specific in the next round. Also, we had a very ad hoc approach to prioritizing security or performance which I am not sure will be the right approach for subsequent rounds, though it may have been the right approach this time. In short, I think that we have done a decent job with the massive array of candidates given to us, but I think the approach is likely too loose on organization and direction to be appropriate in the future. I want to get this thought out there before it escapes me."
What happened with this? #needmorerecords
20181218 11:44:45 file 20240716/RE_ Final list_1.pdf:
Notes from djb, last edited 20240726 21:43:58 UTC:
"I prefer the current list that we have. I think the “adding members” message that’s in preparation covers any other cases"
20181220 04:19:07 file 20240621/PQC project summary for Math Division annual re..._3.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"I have to write up a short summary of the PQC project, for my division's annual report. Here is the draft -- let me know (by tomorrow afternoon, if possible -- sorry for the short notice) if you have any comments?"
20181220 12:42:00 file 20240621/CSD Weekly WERB Update_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Includes abstract of the following: "NISTIR 8240 Status Report on the First Round of the NIST Post-Quantum Cryptography Standardization Process (PUB #927303)"
20181220 21:10:00 UTC file 20240621/PQC project summary for Math Division annual re..._3.pdf-attachment-pqc-summary-2018-draft.docx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"NIST has solicited proposals for post-quantum cryptosystems, which were due in November 2017. NIST received a total of 82 proposals. Since then, NIST has been carrying out a first round of review, including both internal reviews by NIST staff, and public discussions with experts and stakeholders in academia, government and industry. In these reviews, NIST is evaluating the key properties of these cryptosystems regarding security, performance, and ease of deployment in the real world."
#weveshownallourwork
20181221 02:19:01 file 20240621/Re_ PQC project summary for Math Division annua...(1)_2.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"P.S. Here's a revised version. I have to submit it now, but can still make changes later if needed. Thanks, and happy holidays!"
20181221 02:36:22 file 20240621/Re_ Project Summaries for Division Yearly -- Yo..._1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Annual reporting.
20181221 08:25:07 file 20240621/Re_ 2019 Conferences_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Travel planning.
20181221 19:11:00 UTC file 20240621/Re_ PQC project summary for Math Division annua...(1)_2.pdf-attachment-pqc-summary-2018-final.docx:
20181221 19:28:00 UTC file 20240621/Re_ Project Summaries for Division Yearly -- Yo..._1.pdf-attachment-ykliu-summaries-2018.docx:
20181221 19:31:00 UTC file 20240621/Re_ Project Summaries for Division Yearly -- Yo..._1.pdf-attachment-pqc-summary-2018-final2.docx:
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:
20240503 10:02:38 UTC file 20240507/FW_ [Itl_supervisors] News Clips from Wednesday..._2.pdf-attachment-ATT00001.txt:
20240503 12:16:34 UTC file 20240507/PQC evaluation procedures and submission checkl..._2.pdf-attachment-PQC Submission Checklist.doc:
20240503 12:16:34 UTC file 20240507/PQC evaluation procedures and submission checkl..._2.pdf-attachment-PQC submission eval procedure.doc:
20240610 12:26:58 UTC file 20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO..._1.pdf-attachment-image001.png:
20240610 12:27:12 UTC file 20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO...(1)_2.pdf-attachment-image001.png:
20240618 08:44:38 UTC file 20240621/[Pqc] No PQC seminar this Friday_1.pdf-attachment-ATT00001.txt:
20240618 08:44:52 UTC file 20240621/[Pqc] PQC seminar_2.pdf-attachment-ATT00001.txt:
20240618 11:30:27 -0400 file 20240621/1NISTFeb2018_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
Slides reviewing the Gui submission.
#weveshownallourwork
20240618 11:46:13 -0400 file 20240621/AsiaCrypt Moody PQC copy_1.pdf:
Notes from djb, last edited 20240628 14:24:55 UTC:
"THE SHIP HAS SAILED"
"The NIST Post-Quantum Crypto “Competition” "
"Dustin Moody, NIST"
20240618 15:24:00 UTC file 20240621/commentsOnPQctalk_1.docx:
Notes from djb, last edited 20240628 14:24:55 UTC:
" Page 3-5, the figure need to be re-justify. Page 8 added note. Page 11, replied your comments. Page 23, what do you mean by "Note: Key sizes don’t depend on implementation"? Page 24-29, resource? Who provided the chart? Can we make the title larger? Maybe you need to generate a title to cover the original title. Page 31 instead of "37 submissions have official comments", maybe "37 submissions received official comments" Page 33, "ISO/IEC JTC 1 SC27 has already had three 4-6 month study periods for quantum-resistant cryptography" should be "ISO/IEC JTC 1 SC27 has already had a two-year study period for quantum-resistant cryptography and is developing a standing document (SD)." Page 34, It is not very clear from the two bullets: "Sometime before then, we will pick a smaller number of submissions that we feel are the most promising" and " Reminder – doesn’t necessarily mean you’re out if not selected". There are multiple possible understandings, assuming that the current candidate is {A, B, C, D, E} • (U1) Next year we will pick {C, D} as narrow down candidates. But {A, B, E} are not "out" • (U2) Next year, we will pick {C, D} as narrow down candidates. Among {C, D} we might pick {C} to standardize. But this does not mean {D} is "out". But {A, B, E} are certainly out. I somehow feel the correct understanding is (U1), then {A, B, E} can also make modifications. If it is (U2), then only D can make modifications. Page 36 Change " What should we with submissions which are very similar?" to " How should we handle submissions which are very similar?" or " What should we do with submissions which are very similar?" "
20240618 15:50:34 UTC file 20240621/BIKE_1.pptx:
Notes from djb, last edited 20240628 14:24:55 UTC:
Similar to 20221003/BIKE.pptx. Here are further notes.
"BIKE (Bit-Flipping Key Exchange)"
"Presented by Ray Perlner"
"Non-algebraic codes like MDPC codes look good for key reduction with quasi cyclic structure "
"BIKE-3: patented LWE-like “Ouroboros” key exchange." NIST was considering patents internally while discouraging public discussion of patents. #inconsistency #slowingdownpqcrypto
#weveshownallourwork
20240618 15:56:42 UTC file 20240621/CSIA-IWG03182018-arr_1.pptx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"NIST Cryptography Program"
"- Develop Essential Tools for Cybersecurity"
"Andy Regenscheid and Lily Chen"
20240618 15:57:00 UTC file 20240621/draft Announcement of stateful HBS-Nov 5_1.docx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Request for Public Comments on Stateful HBS"
"Draft"
"November 5, 2018"
20240618 15:58:03 UTC file 20240621/ESFNISTPQC_1.pptx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"NIST Update on Post-Quantum Cryptography Standardization "
20240618 15:58:36 UTC file 20240621/ETSI-2017-update-09052017_1.pptx:
20240618 15:59:00 UTC file 20240621/Guidelines for submitting tweaks for 2nd Roun_1.docx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"Guidelines for submitting tweaks for 2nd Round candidates"
Comment from Dustin Moody on "As part of the submission package, NIST requires a brief document which highlights which aspects of each of the merged scheme are used.": "Is this needed? It will probably be in the specification."
Comment from Dustin Moody on "include the reference and optimized implementation": "Remove requirement for ANSI C?"
20240618 15:59:00 UTC file 20240621/NCCoE-DOJ Visit_1.docx:
Notes from djb, last edited 20240628 14:24:55 UTC:
"National Cybersecurity Center of Excellence"
"Department of Justice Visit/Tour"
"8 September 2017"
20240715 08:37:34 UTC file 20240716/[Cmvpwg] CVP Industry WG - Accreditation Overview.pdf-attachment-ATT00001.txt:
20240715 08:39:40 UTC file 20240716/[Crypto-club] QCrypt public lecture - _Cryptogr....pdf-attachment-ATT00001.txt:
20240715 08:53:28 UTC file 20240716/FW_ [Crypto-club] Reminder - TODAY _ Crypto Rea....pdf-attachment-ATT00001.txt:
20240715 09:00:08 UTC file 20240716/[Itl_mgmt] Save the date_ QuICS Stakeholders Da....pdf-attachment-ATT00001.txt:
20240715 09:00:52 UTC file 20240716/FW_ [Itl_mgmt] FW_ News Clips from Tuesday, Jan....pdf-attachment-ATT00001.txt:
![20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO..._1.pdf-attachment-image001.png](20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO..._1.pdf-attachment-image001.png){kind=link}
![20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO...(1)_2.pdf-attachment-image001.png](20240617/Re_ [Itl_mgmt] FY18 Critical Milestones_ due CO...(1)_2.pdf-attachment-image001.png){kind=link}