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.
A followup FOIA request "Newer records regarding NSA, NIST, and post-quantum cryptography" was filed in January 2023. A lawsuit on that was filed in October 2023. The U.S. government began delivering some records in July 2024.
This page is an index of the records delivered by 20241213 in both lawsuits, plus notes last edited 20241220 01:17:00 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: 15 #ethics. 17 #slowingdownpqcrypto. 23 #claimingtransparency. 29 #missingclarity. 41 #ftqcic. 51 #scramble. 53 #nsa. 115 #error. 118 #needmorerecords. 126 #inconsistency. 166 #weveshownallourwork.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"
20140707 08:57:37 -0400 file 20240726/Edwards isogeny paper.pdf-attachment-edwardsisogenies-final revision.pdf:
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.
20151022 14:43:02 +0100 file 20240726/Re_ question about Quantum Communications appli..._1.pdf-attachment-InnovateUK_QuantumTech_CO004_final.pdf:
20151118 file 20241213/CFP v1.docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
Looks like early draft of CFP, with comments from 2015-11-18. However, all metadata is from 2024. What happened to this file? #needmorerecords
20151124 file 20241213/Topics for CFA-edited YKL.docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
Another version of outline of desiderata for submissions.
The following comment is dated 11/24/2015: "FWIW I would rate quantum collision resistance for SHA256 at 80 bits and for SHA384 at 128 bits of security. (This is actually based on the classical algorithms, since they parallelize better than would be expected for a quantum algorithm. See http://cr.yp.to/hash/collisioncost-20090517.pdf )" (Original had a paragraph break.)
This comment is striking for multiple reasons.
As background, standard algorithms to find b-bit collisions involve 2b/2 operations. Some papers claim that quantum algorithms to find b-bit collisions involve only 2b/3 operations. The point of the collisioncost paper is that 2b/3 is using a cheating notion of operations (somewhat like allowing a "find a collision" operation); with proper accounting, all known algorithms involve at least 2b/2 operations.
The above comment indicates that NIST viewed the collisioncost paper as endorsing an operation count of 2b/3. But that's not what the paper says. #error How did NIST make this mistake? #scramble #needmorerecords
What the public saw in mid-2016 was NIST claiming without explanation that the hardness of "collision attacks against SHA-256/ SHA3-256" was "128 bits classical security / 80 bits quantum security". This sounds like it's regressing to the claims that quantum algorithms improve 2b/2 to 2b/3. Did NIST forget about the collisioncost paper? #needmorerecords
After objections, NIST publicly cited the collisioncost paper and withdrew its "80 bits" claim. The fact that NIST had already seen the paper was not disclosed to the public until this FOIA result in 2024, and the public still cannot figure out what happened. #weveshownallourwork
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
20151222 13:37:00 UTC file 20241213/Latest version of NISTIR and other documents fo....pdf-attachment-CFP v1.docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
Early draft of CFP.
20151222 13:38:00 UTC file 20241213/Latest version of NISTIR and other documents fo....pdf-attachment-Topics for CFA-edited YKL.docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
Outline of desiderata for submissions. e.g.: "Quantity of prior cryptanalysis (discourage submitters from revising their proposals while under evaluation)" #inconsistency
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
20160111 10:15:00 file 20241213/RE_ Your visit to NIST_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing logistics for somebody's visit.
20160112 file 20241213/PQC NISTIR v2.docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
Draft of NIST report on post-quantum cryptography.
NSA pushing NIST to endorse algorithms: "NSA comment: > In the final paragraph of the section, you discuss the possibility of a new quantum algorithm breaking any of the previously discussed systems. You then rightly point out that all of today's public-key systems come with security proofs that rely on unproven assumptions, so that the lack of known attacks is used to justify the security of today's systems. That all makes sense, but then you say that more analysis needs to be done before any of the PQ algorithms are recommended. That may be true, but I feel like you just argued against it. More to the point, it might be worth discussing when "the lack of known attacks" would become sufficient for us to recommend a PQ algorithm."
#nsa
20160112 09:02:10 file 20241213/Latest version of NISTIR and other documents fo....pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"The latest version of the PQC NISTIR (with comments from NSA and Donna) is attached. Also the current Call For Proposals, as well as a list of topics to be addressed in the Call for Proposals."
#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.
20160112 13:58:00 UTC file 20241213/Latest version of NISTIR and other documents fo....pdf-attachment-PQC NISTIR v2.docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
Draft of NIST report on post-quantum cryptography.
"Novice reading this sees no drawbacks to lattice-based." #error #scramble
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 09:05:50 file 20240726/Re_ Will the Posting on USAJobs be up relativel..._1_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Apparently from Jacob Alperin-Sheriff. Thread is discussing new position for Alperin-Sheriff at NIST.
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
20160303 09:37:00 file 20240726/RE_ Travel in March(1)_2_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Thread discusses travel planning, including visits by Jintai Ding and Tsuyoshi Takagi.
20160303 11:53:00 file 20240726/RE_ Travel in March_1_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Apparently to Daniel Smith-Tone. Travel planning.
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 09:12:00 file 20240827/RE_ PQC call for papers v4(1)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for papers.
Down thread, from Perlner: "I don’t think we should be overly concerned with submitters doing incorrect or biased security analysis. The worst thing that would come of that is that they set their parameters incorrectly – something which I think is likely to be less fatal for the submissions in this process than it was in the SHA3 competition. If we like a submission but think the submitters set the parameters wrong, we should simply tell the submitters that we’d like them to tweak their parameters for the next round, and publicly state the same in the report."
NIST later announced a policy along these lines but then didn't follow it. #inconsistency
"Hopefully I am getting across the message that we would prefer an imprecise measurement of security in a realistic attack model to a precise measurement of security in an unrealistic attack model (which, by the way, is the opposite of the typical incentives when the primary goal is getting academic papers published, so I do think we need to be somewhat explicit to push the analysis in this direction.)"
From Jordan, earlier: "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. I'd be in favor of saying something totally simpleminded and mathematically well-defined like: ..."
Did NIST ever ask for public feedback on these arguments for and against well-defined attack metrics? Did NIST ever even disclose that it was internally having this argument? #weveshownallourwork
20160407 09:35:43 file 20240827/RE_ PQC call for papers v4_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for papers.
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 12:34:35 file 20240827/Post-Quantum Crypto - Call For Submissions - co..._Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Asking more people to review call for proposals.
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.
20160420 19:25:00 UTC file 20240827/NISTIR 8105 -- Coordinating release with Public....pdf-attachment-NIST.IR.8105.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Some version of NISTIR 8105.
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
20160426 03:20:18 file 20240827/NISTIR 8105 -- Coordinating release with Public....pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing publication and press for NISTIR 8105.
20160426 15:18:44 -0400 file 20240827/NISTIR 8105 -- Coordinating release with Public....pdf-attachment-NIST.IR.8105.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Looks like final version of NISTIR 8105.
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 03:17:26 file 20240827/Re_ Current KMAC document in Word_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing KMAC.
20160427 08:31:42 -0400 file 20221014/NIST.IR.8105.pdf:
20160428 09:02:00 file 20240827/RE_ Post-Quantum Crypto - Call For Submissions ...(1)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Thank you so much for taking the time to go through it. We really appreciate it."
20160429 01:38:57 file 20240827/Re_ Post-Quantum Crypto - Call For Submissions ..._Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing early draft of call for proposals.
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".
20160503 08:51:00 file 20240827/SC27 study period on quantum computing resistan..._Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding ISO documents.
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 01:06:45 file 20240726/RE_ Oscar Garcia Morchon.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"When is he available ? Is he in the DC area?"
Down thread: "Oscar is the HIMMO guy. He is wanting to come and give a presentation at NIST, and we thought it might be nice if we could fit it in while I'm here. Is there some time in the next couple of weeks that would work to invite him? His HIMMO thing is being advertised as lightweight and post-quantum."
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 09:32:00 file 20240726/latest version of PQC Call.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"I don’t know if the lawyers need the latest version of the Call or not. I’ve attached it. There are no major changes, but we did make several of the suggestions sent to us by the rest of our group."
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 13:28:00 UTC file 20240726/latest version of PQC Call.pdf-attachment-CFP v9.1.docx:
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 02:04:56 file 20241213/Re_ invitation to Oscar Garcia Morchon_(1)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Visitor logistics.
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.
20160513 15:47:58 +0200 file 20240726/Re_ question about Quantum Communications appli..._1.pdf-attachment-93056_Quantum Manifesto_WEB.pdf:
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".
20160516 12:03:04 file 20240827/Talk.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding talk announcement. Looks like the abstract was Daniel Smith-Tone copying from a paper on HIMMO: "This is entirely made up. It could be the case that he talks about Mickey Mouse. I actually have no clue."
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 02:35:08 file 20240726/Re_ Hybrid Modes.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Thanks for the invitation; I’ll plan to come in for the meeting."
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."
20160518 08:05:00 file 20240726/RE_ Hybrid mode.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Planning meeting to discuss NSA comments on CFP, and to discuss hybrids. #nsa
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 11:05:03 file 20240726/Latest version of the CFP.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Hope everyone had a nice long weekend. I’ve attached the latest version of the CFP, which incorporates some changes to clarify some of the things the NSA comments discussed. Most of them are minor. The biggest addition is to the quantum security section in 4.A.4, which Ray and Yi-Kai wrote. We also removed any mention of FIPS or validation when talking about hybrid modes. We can address that in a FAQ on our website. Let me know if there are any comments on anything. Thanks!"
#nsa
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.
20160531 14:57:00 UTC file 20240726/Latest version of the CFP.pdf-attachment-CFP v9.4.docx:
20160601 05:10:34 file 20240827/Re_ Summer Visit to NIST_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing guest researchership with Nicky Mouha. Several lines of redactions, presumably not about NIST post-quantum discussions.
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!"
20160602 11:06:23 file 20240827/Re_ Latest version of the CFP(5)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing call for proposals.
20160602 11:29:03 file 20240827/Re_ Latest version of the CFP(4)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"I don't have strong feelings about this. My inclination is to tell the submitters that it is incumbent upon them to convince us and the community at large of their security claims (and leave it at that)."
"Ray told me he expects people to argue security by saying something like - the best algorithm we can think of is XXX - an analysis of XXX shows that these parameters are good enough."
"I don't like that too much. I would rather see an argument like - the security seems closely related to well-studied problem XXX (e.g. subset-sum) - a (very conservative) estimate is that breaking the proposed algorithm with this parameter set is at least as hard as solving XXX of a given size. Ergo my security claim."
"I guess I would rather not steer the submitters to a particular security argument. But I am willing to go with whatever the rest of the team wants."
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".
20160606 01:11:17 file 20240827/Re_ Latest version of the CFP_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"With no explanation we run the risk of everyone choosing their own arbitrary definition after which we need to spend much more time deriving results that should be the responsibility of the submitters. Even with reasonable effort and honesty from submitters, there could be a lot of discrepancy if we don't provide some guidance on this."
20160606 12:29:44 file 20240827/Re_ Latest version of the CFP(3)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for proposals.
20160606 12:51:58 file 20240827/Re_ Latest version of the CFP(2)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for proposals.
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 03:03:15 file 20240726/interesting recent paper.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Forwarding a link to a paper on extractors.
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.
20160610 08:24:00 file 20240827/RE_ FYI_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing talk. Redactions seem to be of Timothy Grance's email address.
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 04:05:27 file 20240827/Re_ Question_Redacted_001.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing how to get cost estimates from people working on building quantum computers.
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 02:27:34 file 20240827/RE_ Reminder - PQC FAQ.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
FAQ editing.
20160616 03:35:40 file 20240827/Re_ Fw_ Reminder - PQC FAQ_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing planned FAQ entries.
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
20160623 10:17:43 file 20240827/Zhang Tan Paper_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing MQ security.
20160625 01:37:17 file 20240726/Fw_ Update to protocol integration._Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Forwarding extractor discussion to somebody.
20160628 02:54:36 file 20240827/RE_ NIST-NSA TWG meeting.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"There is a hybrid mode update. An IETF draft specifies a hybrid cipher suite https://tools.ietf.org/html/draft-whyte-qsh-tls12-01. The final premaster secret is the concatenation of all the secret values, established by classical method and by quantum-safe method. To Validate the Hybrid mode, the key derivation test will need to be modified to allow form the final premaster secret. William Whyte from Security Innovation also suggested another method to input the secret values established through quantum-safe algorithm in the SuppPrivInfo portion of key derivation function. Claim that it will not require any change of the current testing. NIST decision on whether to approve such hybrid mode will be rely on the acceptance of IETF community. The discussion at the meeting indicated that the impact on the performance, in particular, the data size, may prevent from a general acceptance of the hybrid mode."
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."
20160630 06:01:54 file 20241213/Re_ QRC Stall_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Lots of redactions. #needmorerecords
20160630 12:42:38 file 20240827/Re_ Hold for NIST_PCI-SSC Teleconference.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Logistics for call with the PCI Security Standards Council regarding many topics, including post-quantum crypto.
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 04:57:46 file 20240726/Re_ Tentative changes to address _standardizati..._1_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Sounds good to me. Thanks Ray!"
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 11:36:21 file 20240726/Resolution to handle comments on _standardization_3_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Attached please see some proposed text to address Ajit comments on “standardization”. These text shall be checked and polished before we include them in the call for submissions."
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
20160722 13:56:22 -0400 file 20240726/Re_ question about Quantum Communications appli..._1.pdf-attachment-Quantum_Info_Sci_Report_2016_07_22 final.pdf:
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:50:44 file 20240827/Re_ News Clips for Friday, August 5, 2016.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Pointers to recent NIST advertising.
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 02:28:45 file 20240726/Re_ Include Carl and Jacob to the discussions(2)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Scheduling.
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.
20160809 09:58:49 file 20240726/Re_ Carl Miller(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Planning internal meetings.
20160810 08:34:49 file 20240726/Re_ Include Carl and Jacob to the discussions(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Down thread indicates frequent meetings with NSA: "Is anyone opposed to Tuesdays afternoon? We could do it right after lunch, which would probably work for the NSA people."
#nsa
20160810 11:46:06 file 20240726/Re_ Include Carl and Jacob to the discussions_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Scheduling.
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 07:38:51 file 20240726/Fw_ FW_ SAC 2016 notification for paper 104_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Forwarding to someone a report of paper acceptance.
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.
20160818 12:33:57 file 20240726/Edwards isogeny paper.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
No text, just attachment.
20160822 09:50:15 file 20240726/Re_ ITL Science Day, October 13, 2016.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Poster planning.
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."
20160823 02:18:39 file 20240827/Re_ Multi-Talk_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Looks like email from Daniel Smith-Tone scheduling meetings. Mentions "Brad"; maybe NSA's Brad Lackey? #nsa #needmorerecords
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
20160826 12:47:04 file 20240827/Re_ ITL Science Day, October 13, 2016(1)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Poster logistics.
20160829 01:54:51 file 20240726/Poster for ITL Science Day - October 13.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Planning a poster on lightweight crypto.
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 08:41:25 file 20240726/ITL Science Day posters.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Proposing a poster presentation.
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 08:00:21 file 20240827/Re_ PQC workshop numbers_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Maybe from Daniel Smith-Tone?
"I think it will be larger because there are more relevant disciplines for this project than for SHA-3. I think that in the range of 250 is a reasonable guess. This wild guess is based on an estimate that only about half of those who wanted to attend pqcrypto this year were able."
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 12:00:29 -0400 file 20240827/revising our PQC paper.pdf-attachment-KRACABCSMMES-v2.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Key Recovery Attack on the Cubic ABC Simple Matrix Multivariate Encryption Scheme"
20161005 12:20:06 file 20240827/Proposed edits to security strengths section.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Since I will be gone for the next PQC meeting, Dustin asked me to try rewriting the security strengths section (which I have now divided into 4.A.4 and 4.A.5) See attached"
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.
20161005 16:19:00 UTC file 20240827/Proposed edits to security strengths section.pdf-attachment-final CFP Ray.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Draft call for proposals.
20161006 04:50:41 file 20240827/Re_ .pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
No evident post-quantum content.
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 05:24:00 file 20240827/RE_ Proposed edits to security strengths section_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Four-line redaction in the middle of a discussion of security. #needmorerecords
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 01:26:42 file 20240827/Status update on PQC CFP_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for proposals.
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 09:20:00 file 20240827/FW_ pqc article that quotes me_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding link to Wired article.
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."
20161013 04:47:03 file 20240726/FW_ News article_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Forwarding a magazine link to someone.
20161014 07:56:38 file 20240827/Re_ Status update on PQC CFP_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"I think of the whole thing as a standardization process. The writing of the standard is only the final stage at the end. We are plagued a bit by not having a good word like "competition"."
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 04:27:17 file 20240827/RE_ Status update on PQC CFP(5)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for proposals.
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.
20161017 20:22:00 UTC file 20240827/RE_ Status update on PQC CFP(5)_Redacted.pdf-attachment-final CFP 20161017Ray.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Draft call for proposals.
20161018 01:15:00 file 20240827/RE_ PQC FAQ update_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Logistics.
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.
20161018 09:59:23 file 20240827/RE_ Status update on PQC CFP(4)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for proposals.
20161018 10:01:21 file 20240827/RE_ Status update on PQC CFP(3)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding draft call for proposals.
20161018 10:45:00 file 20240827/RE_ Status update on PQC CFP(2)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for proposals.
20161018 12:28:11 file 20240827/Re_ FW_ Proposed edits to security strengths se...(1)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Thread shows secret controversy within NIST regarding some of NIST's most important mistakes in setting up the competition rules, specifically NIST's emphasis on pre-quantum security and NIST's failure to define cost metrics. #weveshownallourwork #needmorerecords
20161018 13:56:00 UTC file 20240827/RE_ Status update on PQC CFP(3)_Redacted.pdf-attachment-final CFP v2.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Draft call for proposals.
20161018 14:41:00 UTC file 20240827/RE_ Status update on PQC CFP(2)_Redacted.pdf-attachment-final CFP v2 Ray.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Draft call for proposals.
20161019 01:51:26 file 20240827/RE_ Status update on PQC CFP(1)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing call for proposals.
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.
20161020 08:39:14 file 20240827/Fw_ Status update on PQC CFP_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing edits to call for proposals.
Down thread: "We had a meeting with the NIST lawyers. They said we need to keep our IPR statements as they currently are (meaning we can’t have only royalty free algorithms). There will probably be a few lines added into the CFP strengthening our language that we have a strong preference for royalty-free, and that it will be used as an evaluation criteria. Andy would also like to add a line that we will commit to having at least one algorithm of each type be royalty-free." #slowingdownpqcrypto
20161021 02:26:22 file 20240726/RE_ FAQ update(3)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
FAQ editing.
20161021 03:59:09 file 20240726/RE_ FAQ update(2)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Not sure what happened. Try now."
20161021 19:58:00 UTC file 20240726/RE_ FAQ update(2)_Redacted.pdf-attachment-new FAQ-1 Ray.docx:
20161023 05:01:27 UTC file 20240726/Fw_ First cut at a summary of our thinking on s..._2.pdf-attachment-DW4_gr_qsc001v010101p.pdf:
20161023 08:45:46 file 20240726/Re_ FAQ update(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Apparently from Daniel Smith-Tone.
"That's actually a good idea. Do we indicate that the submitters should specify compiler/options/flags? I feel like we did. Instead of specifying and exact compiler and option set, perhaps it is better for us to require that simply some common compiler and options are used without demanding a single option. Then the submitters can be responsible for these issues, but free to do anything that we can easily deal with. I'm curious what Larry thinks."
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 10:37:58 file 20240726/RE_ FAQ update_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
FAQ editing.
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:26:07 file 20240726/Fw_ First cut at a summary of our thinking on s..._2.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Some discussion of setting security targets.
Down thread: "A number of commenters suggested making a change in the opposite direction. Some even suggested going so far as to treat an algorithm with 128 bits of classical security and no quantum speedup, as being equivalently strong to a 256-bit block cipher, since both have “128 bits of quantum security.” We don’t think this is reasonable. We can come up with plausible computation models where something with 192 bits of classical security and no quantum speedup might be as hard to break as AES 256 (and we can come up with plausible models where nothing with less than 256 bits of classical security is as hard to break as AES256) but we can’t come up with a reasonable justification for treating something with much less than 192 bits of classical security as being as strong as AES 256."
This shows how NIST's focus on depth limits, in combination with NIST targeting various pre-quantum security levels, ended up creating pressure to go beyond 128 bits post-quantum. This doesn't show why NIST thought it was a good idea to target pre-quantum security levels in the first place. #needmorerecords
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:03:56 file 20240726/Fw_ PQC docs_5_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Discussing call for proposals and FAQ.
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:29 file 20240827/Re_ Performance_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Planning a meeting.
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 11:30:32 file 20240726/Fw_ Key Establishment for PQC algorithms_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Forwarding a mailing-list message to someone.
20161028 11:30:58 file 20240726/Fw_ API for PQC algorithms_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Forwarding API email.
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 09:37:43 file 20240726/Re_ WERB_3.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Paper editing.
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.
20161101 21:27:06 -0400 file 20240726/Re_ WERB_3.pdf-attachment-cryptanalysis2.pdf:
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:22:25 UTC file 20240726/Re_ question about Quantum Communications appli..._1.pdf-attachment-gs-16-18-quantum-technologies-report.pdf:
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:28:56 file 20240827/Re_ CFP__Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"We think it will be out early next week. The people who had to approve/sign off were a bit slow. When it is posted, it will be on www.nist.gov/pqcrypto"
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:38:46 file 20240827/PQC CFP_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding copy of draft call for proposals.
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 04:57:31 file 20240827/Re_ Slides for RWC talk(1)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing slides.
20170103 09:42:47 file 20240827/Re_ Slides for RWC talk(2)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Thread making ambiguous claims about lattice-based "key agreement". #scramble #missingclarity
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 02:50:37 file 20240726/Re_ Hash-based signatures(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"A look through the CFP indicates that we didn’t address stateful vs. stateless, so looks like you’re not a liar!"
"But I had thought the problems with stateful signatures go well beyond the size of the private keys …"
20170104 07:20:14 file 20240726/Re_ Hash-based signatures_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Thanks to all for the clarifications. There is no contradiction with what I stated. NIST is interested in hash-based signatures. Stateful hash-based signatures are out of scope for the PQC CFP but in scope for the PQC project."
"I also stated that the names of the people in the project is not a secret (most are named as authors of the PQC report), and that we would make the list of names public somehow."
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 03:58:48 file 20240726/Re_ International Cryptographic Module Conferen....pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Planning a conference submission.
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."
20170109 09:36:14 file 20240827/FW_ Slides for RWC talk_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding slides for RWC 2017 talk.
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."
20170110 11:08:03 file 20240726/RE_ I think I figured out how to extend our cub...(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
The timestamp on this message is missing a colon (not marked as a redaction). What happened here? #needmorerecords
Discussing attack software.
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:39:21 file 20240827/MUST attend! 10 to 11_ Room A318!_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding talk announcement.
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!"
20170127 07:50:53 file 20240726/Fwd_ Explaining the upside and downside of D-Wa..._Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Is this anything significant?"
20170127 08:18:00 file 20240827/RE_ Update_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Intern supervision.
20170131 01:26:46 file 20240726/Re_ I think I figured out how to extend our cub...(2)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Discussing attack software.
20170131 01:55:32 file 20240726/Re_ I think I figured out how to extend our cub...(1)_1_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Discussing attack software.
20170131 02:10:55 file 20240726/Re_ I think I figured out how to extend our cub..._Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Discussing attack software.
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.
20170207 08:40:00 file 20240827/Re_ japanese visit_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing a "meeting with the Japanese" on 20170221. #needmorerecords
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."
20170214 12:27:53 file 20240726/RE_ Current Draft for our PQC paper improving o..._Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Paper planning.
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!"
20170217 03:25:08 file 20240827/Re_ question_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Paper editing.
20170217 11:56:25 file 20240827/Re_ question(1)_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Paper editing.
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.
20170222 07:35:48 file 20240726/Re_ ieee_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Apparently to Stephen Jordan. Paper editing.
20170222 07:57:24 file 20240726/ABC_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Discussing costs of "an ABC minrank attack".
20170222 121501 file 20240726/Re_ ieee(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Many redactions. #needmorerecords
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"
20170228 01:09:00 file 20240827/RE_ When are you coming_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Planning talk by Daniel Smith-Tone. Down thread: "I want to talk about my new attack on HFE minus. It breaks most parameters practically, so it's fairly impactful for considering parameters for Gui or some other iteration of these things."
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 01:16:22 file 20240726/Re_ question about Quantum Communications appli..._1.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Advertising quantum technologies.
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 01:22:11 file 20240726/Re_ API_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Something redacted; in context, probably just logistics.
Down thread: "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)."
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 02:02:41 file 20240726/FW_ API.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Discussing random-number generation: e.g., people "must define the properties that randomness needs in their algorithm"; "some algorithms indicated that there may be drastically different requirements on the “randomness” ".
#weveshownallourwork
Also, down thread: "doing what Dan says will mask the true cost of calling a DRBG" #error
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
20170412 15:33:21 file 20240827/RE_ flu_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Email from Moody to Perlner and, apparently, Smith-Tone. Excessive redactions of message down-thread; don't need to hear about Smith-Tone's flu, but there also seems to have been technical content to the message. #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 03:16:00 file 20240827/revising our PQC paper.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Paper editing.
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 03:40:00 file 20240827/RE_ revising our PQC paper_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Paper editing.
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 07:35:49 file 20240827/Re_ Postquantum crypto project_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing advertising.
20170418 07:35:49 file 20241213/Re_ Postquantum crypto project__1_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing advertising.
20170418 10:17:45 file 20241213/Postquantum crypto project_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing advertising.
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."
20170418 12:23:28 file 20240827/Re_ annual report welcome letter_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing reporting.
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 09:12:16 file 20241213/Re_ Conference Registration.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Travel planning.
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.
20170606 02:22:50 file 20240827/Post Quantum blockchain.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Here are my notes on quantum resistant cryptocurrency tech."
20170606 18:21:00 UTC file 20240827/Post Quantum blockchain.pdf-attachment-Quantum Resistant Blockchain.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Quantum Resistant Blockchain"
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.
20170609 04:14:00 file 20240726/I found a case where, minrank is cheaper than d..._Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Forwarding a few numbers to somebody.
20170612 08:40:50 file 20240516/Re_ pqc surveys_1.pdf:
Notes from djb, last edited 20240520 20:11:25 UTC:
"Thank you!"
#scramble
20170612 09:48:00 file 20240726/RE_ I found a case where, minrank is cheaper th..._Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Actually, I’m a moron. The example I gave doesn’t work, since I grossly overestimated the complexity of direct attack in the case I gave. I forgot you could guess values for the variables until the system for direct solving is fully determined. I think I can now write up a justification of why direct attack is pretty much always cheaper than minrank for overdetermined, but not superdetermined systems."
20170614 02:32:00 file 20240827/RE_ NRC Postdoc Program Instructions..pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"I think it doesn’t matter whether your research is on ECC or PQC, you can write research opportunities on either or both of them. You can have more than one research opportunities."
Down-thread from Moody: "I can apply to be an advisor – though in reading through all the requirements it seems to me that I should be advising somebody in ECC, not PQC. They mention having published for 5 years in your field in peer reviewed journals, which I have done for ECC, but I don’t quite feel I have done that in PQC. I feel confident that I would be able to help mentor somebody in PQC, just that I don’t know that I have the qualifications they discuss. Anyway, I thought I’d mention that to you."
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:
20170614 12:44:14 file 20240827/Re_ Idea for speeding up direct attack and HFEv..._Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing MQ attacks.
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 05:00:36 file 20240827/Re_ NRC postdoc_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing jobs available at NIST.
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.
20170620 09:55:35 file 20240827/Re_ NRC postdoc e-mail_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing jobs available at NIST.
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:16:00 file 20240827/FW_ PQC seminar this Friday.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding apology for missing 20170623 NISTPQC seminar by Scott Simon regarding eprint 2017/397. #nsa #weveshownallourwork
20170623 11:16:00 file 20240827/RE_ PQC seminar this Friday.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"I'll let Scott know. Sorry you had a bad morning!"
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
20170703 02:02:09 file 20240726/info_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Sentence redacted. #needmorerecords
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."
20170712 10:26:36 file 20240827/Re_ Attachments to Submission emails_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing possibility of malware attached to submissions.
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 02:38:07 file 20240726/Fw_ primality paper_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Internal paper review.
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.
20170721 11:50:16 file 20240827/MinRank_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Smith-Tone and Perlner working on a paper.
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."
20170726 01:21:00 file 20240827/RE_ [Pqc-forum] Feedback on Libraries Likely to..._Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"There were a few requests to include GMP. I talked with Ray, Larry, and John, and they seemed to think that wasn’t unreasonable. The conversation extended to the idea that perhaps a few other libraries might be made available. Larry wanted to know what other libraries people would want. He is thinking about setting up a virtual machine where people could check their builds to see if everything will compile correctly when we have to do it here. He wants the headaches to be on the submitters’ end, not on his end."
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 04:16:22 file 20240726/Here's what I have so far.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Draft paper on a model of computation.
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."
20170802 16:02:28 -0400 file 20240726/Here's what I have so far.pdf-attachment-Brownian.pdf:
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 04:36:12 file 20240726/Re_ Here's what I have so far.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Thanks, I'll take a look! (I probably won't get to it until late next week, though... sorry for the delay...)"
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 01:02:57 file 20240726/Re_ berb review for the probability estimation ...(4)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Quantum information theory.
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.
20170814 11:01:18 file 20240726/Re_ berb review for the probability estimation ...(3).pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Quantum information theory.
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:04:01 file 20240726/Re_ berb review for the probability estimation ...(2)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Quantum information theory.
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:34:00 file 20240827/RE_ Travel Question_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Travel planning.
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:36:00 file 20240827/RE_ PQC API_randomness meeting_1_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Meeting logistics.
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."
20170818 03:53:37 file 20240726/Re_ berb review for the probability estimation ...(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Quantum information theory.
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
20170821 05:46:28 file 20240726/Re_ berb review for the probability estimation ..._Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Quantum information theory.
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 10:11:00 file 20240827/RE_ SAC_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
MQ security discussion, and discussing what happened at SAC.
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?"
20170829 12:55:16 file 20240726/RE_ ERB Reminder(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Paper planning.
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:09:00 file 20240726/RE_ FW_ ERB Reminder_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Apparently to Daniel Smith-Tone. Paper editing.
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 05:20:00 file 20240726/RE_ ERB Reminder.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Paper editing.
20170830 06:24:35 file 20240827/Openssl random stuff_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Someone forwarding https://wiki.openssl.org/index.php/Random_Numbers link.
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 15:50:13 -0400 file 20240726/FW_ ERB Reminder.pdf-attachment-CryptSRP_final.pdf:
20170830 15:50:13 -0400 file 20240726/RE_ ERB Reminder.pdf-attachment-CryptSRP_final.pdf:
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 08:08:34 file 20240726/RE_ ERB Reminder(2).pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Paper editing.
20170831 08:09:37 file 20240726/FW_ ERB Reminder.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Internal review of paper breaking SRP.
20170831 10:03:57 file 20240827/RE_ PQC stuff_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Down thread: "I will get some work done, but I won't have everything done tomorrow. The API doc will be done. I don't want to promise more than that. I will work on things this weekend and have stuff to post on Tuesday. I plan to implement ctr_drbg in randombytes() and the seed expander. I'll also have the KAT generation files ready."
Redactions are presumably something like "I have a cold" and "Get well soon".
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".
20171003 11:23:00 file 20240726/PQC reviews(5)_10_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"I have you down for the following: STRPI and TPSig (these two are in the same submission, but do 2 checklists, one for the Enc scheme, and one for the signature) Post Quantum RSA (again do two checklists, one for signature and one for Enc/KEM) Chrysalis (Enjoy) LedAkem DAGS"
"Once they’re done, go into the excel spreadsheet on the main Documents page of the Sharepoint site, and put your name in red, so I will know."
20171003 11:31:00 file 20240726/PQC reviews(4)_9.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Here’s your reviews: NEO (done and it’s already been withdrawn) PostQuantum RSA (both KEM/Enc and signature – already done) Hila5 GuessAgain QC-MDPC KEM NTRUprime Ding’s LWE key exchange Three Bears"
"Once they’re done, go into the excel spreadsheet on the main Documents page of the Sharepoint site, and put your name in red, so I will know."
20171003 11:33:32 file 20240726/PQC reviews(3)_8.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Here are your reviews: Lima (done) STRPI and TPSig (done) PRUNE-HORST Compact-LWE LEDAKem Picnic Lotus CAKE Three Bears"
"Once they’re done, go into the excel spreadsheet on the main Documents page of the Sharepoint site, and put your name in red, so I will know."
20171003 11:35:08 file 20240726/PQC reviews(2)_7.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Here are your reviews: RLCE Lima Ramstake GeMMS Picnic Saber Titanium Cake HQC"
"Once they’re done, go into the excel spreadsheet on the main Documents page of the Sharepoint site, and put your name in red, so I will know."
20171003 11:39:00 file 20240726/PQC reviews(1)_6.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Mine: RVB (done) RLCE (done) Hila5 HiMQ-3 Lizard NTRU (both KEM/enc + signatures) SIKE IEC"
20171003 11:41:22 file 20240726/PQC reviews_5.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Here’s the ones I’d like you to do the optical media checklist for (Jacob will do the rest): Lima PostQuantum RSA (both KEM/Enc and Signature schemes) Prune-HORST GuessAgain GeMMS Picnic Saber Titanium Dilithium Three Bears"
"Once they’re done, go into the excel spreadsheet on the main Documents page of the Sharepoint site, and put your name in red, so I will know."
20171003 12:32:24 file 20240726/Re_ PQC reviews(1)_4.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Ok, sounds good. I will aim to have these done by Oct. 17."
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 08:07:00 file 20240726/RE_ PQC reviews_3.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"You don’t need to worry about the signatures. They have to mail in physical copies, so it doesn’t matter what is on the electronic version."
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?"
20171016 16:47:00 file 20240827/pqrsa.pdf-attachment-PQC Submission Checklist_FINAL_PQRSA_SPJ-and-D.doc:
Notes from djb, last edited 20241002 20:43:30 UTC:
Completeness checklist for pqRSA submission. There must be many more of these checklists for other submissions. #needmorerecords
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 01:41:40 file 20240726/RE_ PQC Reviews.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"No, it all looks good."
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 09:53:40 file 20240726/RE_ PQC Reviews(1).pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Great – thanks."
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"
20171123 02:09:08 -0600 file 20240827/pqrsa.pdf-attachment-doc.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Looks like copy of pqRSA submission.
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 05:24:52 file 20240726/Re_ Expanding Our Role, Expanding Our Impact.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Discussing high-level advertising.
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."
20171130 22:22:00 UTC file 20240726/Re_ Expanding Our Role, Expanding Our Impact.pdf-attachment-Expanding Our Role, Expanding Our Impact v2_E.docx:
Notes from djb, last edited 20240801 23:15:11 UTC:
Editing high-level advertising.
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 01:08:06 file 20241213/FW_ Kevin K called regarding a WH data call.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing bullet items to report to management.
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 10:38:50 file 20241213/Re_ Kevin K called regarding a WH data call.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Bullet items to report to management.
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 04:10:56 file 20240827/Re_ Found Another Submission Hidden Inside GeMS....pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing slowness of DualModeMS.
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!"
20171211 12:47:00 file 20240827/RE_ Posting submissions(2).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Planning submission database.
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:28:00 file 20240827/pqrsa.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding documents, no text.
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.
20171213 09:13:50 file 20240827/RE_ Posting submissions(1).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Planning submission database.
20171214 01:45:00 file 20240827/RE_ Kerus_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Ray has some attacks on a couple. If you have an attack, write something down that we can send to the submitter and give them the option to comment/withdraw or whatever."
20171214 01:46:47 file 20240827/FW_ Kerus_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding message from Daniel Smith-Tone saying he can break Kerus "by hand" and saying he can "break the 256-bit parameters of DAGS and DME". Redaction appears to be just for Smith-Tone's email address.
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 03:15:00 file 20240827/RE_ Security Notes_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"DAGS: In reference to sharing keys of length at least 256 bits: I guess this is interpretation, but the suggested parameters only provide 160 or 192 bits of entropy. Technically, one can share a key of length 256 bits, but trivially with any algorithm I can share a key of arbitrary length by computing H(m),H2(m),… This certainly doesn’t provide the amount of entropy I would want for claiming to establish “shared keys of length at least 256 bits.” On that note, I can break the 256-bit classical security level scheme right now."
"DME: In reference to the presence of security arguments: I am skeptical on the algebraic attack security claims. They don’t seem to consider field equations. I’m not too sure about this. The public key appears to consist of a system of 6 equations in 6 variables with 64 monomials of high degree. The authors mention algebraic attacks over F2, but they don’t mention that there necessarily is a solution over F2, so that one can add field equations x_i2+x_i. This reduces the degree of all monomials to at most 4 (which they did mention). I checked the arithmetic and this indicates that the degree of regularity (and likely the solving degree) are around 18, way less than q=224 as they claim. So their claims are wrong. This still does not break the 128-bit scheme, but it does break the 256-bit parameters. The complexity is about 2205. Also, they mention that since anyone can recover the exponential maps that they can be made public to improve EFFICIENCY. This can’t be true unless the entire private key is made public. The contributors clearly haven’t thought through the science…"
"KERUS: In reference to providing copies of references: Vacuously they do provide references... by which I mean, I seriously doubt that there exist references to provide so they have provided all of them. I’ll provide an additional cryptanalysis on behalf of the submitters, since they couldn’t do their own job. In pass one, the matrices T1=YA, and T2=BY-1X are sent openly. In pass two, the matrices T3=DYAC-1 and T4=CBY-1XH are sent openly. In pass three, the matrix T5=DXH is sent openly. Since A and B are centro-symmetric, the product P=A-1B-1 is as well. Notice that P satisfies the linear equation T3PT4=T5 by the commutativity property of centro-symmetric matrices. So we can solve for P. Then T1PT2=X, the shared “secret.” The scheme is totally bogus."
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.
20171217 10:35:43 file 20241213/Fw_ review a paper for PQCrypto_(1)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Lots of redactions. #needmorerecords
20171217 10:36:08 file 20241213/Fw_ review a paper for PQCrypto_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Many redactions. #needmorerecords
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 09:05:13 file 20240827/RE_ Posting submissions.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"We officially reported 82 submissions sent to us, but some have already been withdrawn. So that’s why I guess there are only 78 in the Master List of Submitters."
"We will be updating the Uploads folder today and tomorrow. We’re having a meeting tomorrow morning to officially decided what’s in and out."
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."
20171218 12:24:00 file 20240827/RE_ notes for the meeting tomorrow_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Down-thread are the following notes from Daniel Smith-Tone on various submissions.
"CRYSTALS-Kyber: Cool name. No specific comment. Seems complete."
"DAGS: The suggested 256-bit secure parameters are either broken or not functional depending on your perspective. The 256-bit parameters for the KEM only provide 160 or 192 bits of entropy for shared keys, so it is not capable of establishing shared keys of length at least 256-bits. Please recheck all other KEMs to make sure that they are not making the same error. (The submitters have acknowledged it.) It is an easy fix in this case, so I recommend acceptance. There is another issue in that in the statement on advantages and disadvantages it is claimed that there are no decoding errors, however, the decapsulation algorithms explicitly uses "bottom" to indicate decoding errors. Something is not clear here. I also see no other place indicating the error rate nor any justification for the no decoding errors comment. This is a serious mistake which should be clarified. I still recommend erring on the side of acceptance."
"DME: This is another one that I can break the 256-bit secure parameters. The submitters are not familiar with standard references in multivariate crypto. By using the field equations I can upper bound the complexity of running F4 on the 256-bit parameters using generic methods to achieve an attack of complexity about 2205. We notified the submitters of this and they said that this is plausible but they don't know the science (obviously paraphrasing). They also have other false claims in their security analysis, such as the solving degree being around q. Simply not close to true. In fact, their most secure parameters with q=224 has a solving degree somewhere around 18. Still, I don't think that the algebraic attack is what will ultimately break this one. I don't have a full attack, though, so I recommend acceptance as complete and we can see how it is broken in a few months."
"Emblem: My notes say that I only noticed category one parameters."
"Gui: They haven't quite followed the rules on the software submission. We really must accept this one, though. This is the oldest efficient unbroken post-quantum signature I know of. We should keep pushing them relentlessly for adherence to the rules, but the search would certainly be incomplete without this. Besides, the science is actually correct in this one."
"Kerus: I can break this one by hand for all parameters... literally. I'll attach the comment I put in the checklist. In pass one, the matrices T1=YA, and T2=BY-1X are sent openly. In pass two, the matrices T3=DYAC-1 and T4=CBY-1XH are sent openly. In pass three, the matrix T5=DXH is sent openly. Since A and B are centro-symmetric, the product P=A-1B-1 is as well. Notice that P satisfies the linear equation T3PT4=T5 by the commutativity property of centro-symmetric matrices. So we can solve for P. Then T1PT2=X, the shared “secret.” The scheme is totally bogus. It should be a definite reject."
"LAC: Seems okay to me."
"LEDAkem: The submitters backtracked from a IND-CCA claim to an IND-CPA claim, essentially admitting that they were wrong on that one. I'm not sure about this one, but I would err on the side of acceptance. It is likely to be eliminated early in it's current state anyway. If they can make it better and we accept changes later in the process... great. I doubt it will survive, though."
"NTRUKEM: Seems fine."
"NTRUPRIME: The proposal advertises two schemes SNTRUP and NTRULP. It has no timing data that I see for the second. I think then that it is complete for SNTRUP and incomplete for NTRULP (as two submissions)."
(#error What the call for proposals actually said was "The submitter must also include a statement regarding the algorithm’s estimated computational efficiency and memory requirements". The submission provided estimates for both schemes, including all of the required details. The estimates were justified, and subsequent analysis showed that both schemes could run even faster than estimated.)
"PQRSA: Doesn't mention amount of volatile memory used, which is likely large, unlike other submissions. Probably need some data on that, and I don't remember it being provided."
"RaCoSS: No specific comment. Seems alright."
"Rainbow: Again, it seems that there is an issue with Intel specific implementation issues. I'm not sure if these guys are trying to pull something or they though it that across platforms referred to across Intel platforms. Again, we should hold them accountable, but definitely accept. There is no multivariate scheme I know of with more theoretical support than rainbow. It is on a very solid footing."
"SPHINCS+: No specific comment. Seems okay."
"STRPI and TPSig: The submitters responded to our query about the linearity of decryption/signing by stating that these functions ARE linear, but “only for the secret key holder.” That is just nonsense. It is linear or it is not. y=3x is still linear even if I don’t look at it. One could interpolate the affine function by generating a large number of plaintext/ciphertext pairs and solving for unknown coefficients. The resulting map is a more efficient decryption technique than provided and the inverse is a more efficient encryption algorithm, though we might as well use the identity function. The scheme is not secure. On the other hand, the size of the scheme is such that I cannot accurately say that the scheme does “not incorporate major components believed to be insecure against quantum computers.” Mostly since large enough quantum computers have yet to be built…mostly. This is a definite reject. The idea that a function is linear for some people and not others is laughable."
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:19:03 file 20240827/RE_ Today's Meeting Notes.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"We just cleared HK17. We said we’d check something in their spec, and we checked it."
"So we still have 2 pending."
Down thread: "I only had FAPKC as one algorithm row previously (didn’t realize they were two)!"
Also list of algorithms "that we said no to": "1. Edon-S 2. FAPKC 3. GuessAgain 4. Kayawood KAP 5. KAZ 6. KERUS 7. NTRU Prime IIT Ukraine 8. Theory of Mathematical Defense to … 9. TPSIG" And: "We’re also going to say NO to LEDAsig."
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:46:00 file 20240827/RE_ PQC first round candidates.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Mentions internal-pqc mailing list.
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:02:32 file 20240827/OID and Vinegar Signature schemes_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Forwarding original UOV paper.
20171221 02:11:57 file 20240827/Re_ PQC Round 1 Submissions are posted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing metadata for submissions.
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:31:46 file 20240827/PQC first round candidates posted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Round 1 is up and posted. Great work by Lily and the team."
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 03:22:36 file 20240726/Fw_ Stuff_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"I might add - we can keep one document with all the official comments easily enough."
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 10:41:39 file 20240827/Re_ [Itl_supervisors] Researcher who is an acti....pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing NIST advertising.
20171221 10:42:11 file 20240827/RE_ Isogeny Paper Review.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing a submitted paper.
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 03:46:28 file 20240827/Re_ more isogeny paper drama_Redacted.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing a submitted paper.
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?"
20171222 09:48:56 file 20240726/Re_ [pqc-forum] A few (minor) corrections(1)_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
Astonishingly anti-scientific attitude: "I don't know that we want to provide a comment on every paper/posting/etc that breaks something/does something else. That gets to be a lot of acknowledging, and then we have to judge whether the paper is correct or not, which others might not agree with us." #weveshownallourwork
"We do want to generally thank people for all the work and analysis that they have done/will do."
Down thread, from Jacob Alperin-Sheriff: "Are we acknowledging and thanking people for doing the brute work in actually breaking things (especially things that we felt were broken but posted anyway because submitters disputed?) We probably should."
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?"
20180202 17:29:00 UTC file 20241213/FW_ NSA comments_1.pdf-attachment-NSA-PQC comments (1-16-2018).docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
#nsa
NSA secretly telling NIST that many submissions are "based on well-studied cryptographic primitives" (e.g., "lattices") that have "a long history of analysis for a significant number of schemes and the security profile of the underlying cryptographic primitive for many of these designs is well understood".
#error In fact, the security level of almost all submissions against public attacks dropped during the NIST competition, often dramatically; i.e., better attacks were published against almost all submissions.
20180205 08:29:30 file 20241213/FW_ NSA comments_1.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Forwarding comments from NSA. Down thread: "These are received together with TWG meeting notes. Please forward to internal PQC."
#nsa
20180206 file 20241213/NSA-PQC comments (1-16-2018).docx:
Notes from djb, last edited 20241220 01:17:00 UTC:
#nsa #needmorerecords
20180206 02:04:23 file 20241213/Re_ Notes_2_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Apparently Daniel Smith-Tone: "okay. thanks." Responding to Dustin Moody writing: "Do you want me to forward this to internal-pqc?"
20180206 03:42:27 file 20241213/NSA PQC comments_1_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing an NSA comment about non-uniform distributions.
#nsa
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:18:12 file 20240726/Re_ As a now-pseudo-biased observer of hash-bas..._1_Redacted.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Tuesday is definitely too quick, I think.. //our 'final' Round 1 PQC meeting is at 10am"
Something redacted regarding two Friday meetings. #needmorerecords
"Actually, I haven't gone through the details of Picnic in depth myself.."
Down thread comment from Kelsey: "I think stateful hash based signatures are pretty practical in a lot of places (though they might eventually be edged out everywhere by better alternatives), but the stateless ones have the dancing bear property (the surprising thing is that the bear dances at all)." #ftqcic
"I don’t feel like I really understand Picnic all that well yet. Hopefully I can remedy that when I get a few spare hours…."
Down thread comment from Apon: "As I've worked.. somewhat closely.. with Jonathan Katz and Xiao Wang, I should state that I'm no longer a totally-objective observer of Picnic. That said, my understanding is that the Picnic Team's intent is to replace Sphincs in terms of state-of-the-art hash-based signatures." #ethics
"The brand-new Picnic spec deserves some serious consideration, imo. Whereas I do not personally, truly see Sphincs surviving the extent of the PQC- Sig gauntlet against competing lattice and multivariate signatures, just as I do not need McEliece surviving its similar PQC-KEM gauntlet against competing lattice and code-based key transport schemes.. ..it may be the case that the new Picnic is a "not-1960s, not-1970s, not-1980s, etc." type of scheme that is actually competitive against e.g. lattice signatures." #ftqcic
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."
20181212 11:11:18 file 20240726/RE_ 1st Round Report_2.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Got it. Thanks Carl."
Down thread: tweak to qTESLA text.
20181212 11:12:00 file 20240726/RE_ 1st Round Report_ Picnic, minor_1.pdf:
Notes from djb, last edited 20240801 23:15:11 UTC:
"Got it. Thanks."
Down thread: tweak to Picnic text.
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 file 20241115/PQC Seminar 2-11-20 (Fiat-Shamir).pptx:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Not for public distribution."
#weveshownallourwork
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
20200601 06:34:31 file 20241213/Re_ FYI_ KEM-only TLS_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Thread is discussing https://eprint.iacr.org/2020/534. No apparent awareness of earlier literature on the same topic. #scramble
"How to make sure that the static KEM public keys are authentic is an issue in real world. Currently, PKIs using digital signatures are used for that. It would be not practical that the browser vendor takes all servers' static KEM public keys (in an authenticated way), then load them into the clients (in an authenticated way). This solution won't work. So, digital signatures are absolutely required for the internet to function." (with paragraph breaks in original)
#error Instead of checking a CA signature, one can encapsulate a session key to the CA KEM key and check an authenticator on the response. So it is not true that predistribution of server keys is required.
#ftqcic To argue that signatures are "absolutely required", one has to quantify of costs in context to see that alternatives are unaffordable. A full analysis of KEM costs and signature costs for the CAs would require accounting for (1) data volumes, (2) the effectiveness of server-side caching, and (3) the effectiveness of client-side caching.
20200601 08:44:04 file 20241115/Re_ Meeting tomorrow _ .pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Meeting logistics.
Down thread: "We will meet and have some topics to discuss I'm sure. For example, Dan's comment, Kris Gaj sent us a new report, writing our report, etc..."
20200602 03:49:32 file 20241115/RE_ pqc meeting summary .pdf:
20200602 12:51:40 file 20241115/Re_ What do you think about sending the Kyber t....pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Let's wait a day and see if they respond on the forum. They may present some arguments."
"If they don't, then we can ask them to respond."
"Either way, we can write them and mention your idea of a possible tradeoff and ask them what they think and any other questions we have."
Thread started with Apon saying "What do you think about sending the Kyber team a short email" followed by "Mentioning the CoreSVP vs DFR trade-off (RE: their noise rate at level 1 / 3)?".
20200603 03:13:09 file 20241115/Hessian isogeny question.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing costs of isogenies.
20200603 09:09:45 file 20241115/Re_ PQC next step.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
#nsa
"Having them as external werb should satisfy their desire to see an early copy as well but, if we can share before then that would put them at ease as well"
Down thread shows that NSA already knew the decisions: "From our last call with them, they said they are happy with our current plan."
What else was happening in calls with NSA? #needmorerecords
20200603 09:14:59 file 20241115/Re_ PQC Round 2 report assignments(11).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Report logistics.
20200604 01:32:16 file 20241115/Re_ PQC Round 2 report assignments(2).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Down thread: "For IPR, I don't want much about this in the report, certainly not specific details. Just a sentence mentioning that this topic is a factor in our decision making process."
#weveshownallourwork
Farther down thread: "I am happy to write a sentence about IPR issue. But, I think Ray understands the details of the current IPRs that we are aware of than I do."
20200604 01:44:12 file 20241213/Re_ Kyber's response discussion tomorrow _(7)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"if some other people think that it would be good to talk as I do. I don't want to show my voice in a desert"
20200604 02:21:21 file 20241213/Re_ Kyber's response discussion tomorrow _(6)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Logistics.
20200604 02:50:36 file 20241213/Re_ Kyber's response discussion tomorrow _(5)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Logistics.
20200604 03:09:33 file 20241213/FW_ Draft summary for PQC team(1)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing comments on stateful hash-based signatures.
20200604 03:18:31 file 20241213/Re_ Kyber's response discussion tomorrow _(4)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Planning Daniel Smith-Tone's edits to the report.
20200604 07:18:58 file 20241213/Re_ more hmmms_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
More discussion of security levels.
20200604 08:59:56 file 20241115/Re_ PQC Round 2 report assignments(10).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing report timeline.
20200604 09:47:21 file 20241115/Re_ Rethinking ROLLO.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"My preference would not be to add back in schemes. We need to make cuts - we can't keep everything. We can emphasize the positives about ROLLO and strongly encourage work in this direction. But they will need more time to achieve stability."
"Maybe a good way to handle this would be to describe the on-ramp more generally, which could allow for either signatures or KEMs. We then emphasize that in particular we would be interested in a signature scheme which isn't structured lattice."
20200604 09:52:26 file 20241115/Re_ PQC Round 2 report assignments(8).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Since the content of that section has been put somewhere else. I don't see a lot of need for that section. We don't have to have the same sections as in the the first round report."
20200604 10:02:01 file 20241115/Re_ PQC Round 2 report assignments(6).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Yes - exactly. We don't need to put in exact numbers if we don't want, but we can write just as you said. Check the speed. My memory says that it won't be faster (in part because it's using larger parameter sets)."
20200604 10:03:16 file 20241115/Re_ PQC Round 2 report assignments(5).pdf:
20200604 12:07:25 file 20241115/lattices.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Hi guys. It would be great to get your thoughts on my bullet summaries for Kyber, Frodo, and NTRU. In particular: did I miss any major notable events during Round 2? (I didn't really see any for NTRU, for example.) Thanks!"
20200604 12:19:49 file 20241115/Re_ PQC Round 2 report assignments(3).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Would it make sense to specifically call out the large key, small ciphertext/signature thing as a separate performance profile? Classic McEliece, Rainbow, and GeMSS all fit this profile. There’s a little test in the document now, but I wonder if it makes sense to call this out as its own thing"
Down thread: "When discussing the structured lattice candidates and their CoreSVP strength, we discussed how difficult it would be to tweak the parameters of the different schemes in order to bump up their level of security."
This is a major advantage of NTRU over Kyber, but NIST's public reports hide the advantage. #inconsistency #weveshownallourwork
20200604 12:41:59 file 20241115/LWC webpage - Comments on the R2 Candidates.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
LWC, not PQC.
20200605 01:37:12 file 20241115/Re_ Very unfair to 3 Bears. (1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"3 Bears are even more conservative in security than NTRUprime: combination of Kyber (get some flexibility and security advantage of the module over the ring) and a conservative ring (a field) as NTRUprime."
This is partially correct but partially incorrect: Three Bears uses a field with a small Galois group. #error
Down thread: "If the first reason was clear, we have no way to prove that level 2 is less important than level 3."
Down thread: "ThreeBears is basically halfway between Kyber512 and Kyber768 in terms of both security and bandwidth (consistent with its claim of category 2.) I don’t know about speed, but I doubt it’s very different and bandwidth seems more likely to be the main cost in the case of lattice crypto in most applications anyway."
"My understanding is that it’s hard for 3 bears to target the same security/performance tradeoff as Kyber512 given its choice of ring, and it’s hard for Kyber to target the same tradeoff as ThreeBears."
Down thread: "It is a promising scheme, but I think a very key factor is that Mike is pretty much the only person to do anything with 3 Bears. It is a little bit different from the other lattice based schemes, which are built directly upon lots of research from many people. The I-MLWE problem hasn't attracted as much attention. Daniel A thinks there is a reduction to MLWE, but that hasn't been discussed much and I haven't seen Mike claim that."
"Also, in David's KEM performance talk, he showed Kyber and SABER both are ahead of three bears in performance. True, yes, they are pretty much about equal, but still they are ahead. This is most evident where three bears has a much higher decaps cost. In looking at key sizes, both kyber and saber are smaller than three bears. Both kyber and saber have had some side- channel analysis and papers on hardware implementations done on them. I haven't seen that for three bears."
"The one big plus for three bears is that it has higher security margins. And that is important, since security is our top criteria, and if three bears were to do a tradeoff to improve performance at the cost of a little security that would be interesting. However, I'm not totally sure three bears is super flexible in how it can choose its parameters."
Down thread: "The only third party analysis on Kyber is the Dan's emails recently. We should not judge submissions based on counting the numbers of authors. We kicked out 3 Bears completely but treating Kyber as the/a "winning" candidate. I think many people will see what I said here and will feel not happy about our decision here."
20200605 02:05:15 file 20241115/Re_ Very unfair to 3 Bears. .pdf:
20200605 03:02:48 file 20241115/Re_ PQC Round 2 report assignments(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussion of speed of lattice signatures, more detailed than what was in NIST's public statements.
#weveshownallourwork
Down thread shows initial assignments of report sections for people to write:
20200605 09:14:47 file 20241213/Re_ Kyber's response discussion tomorrow _(3)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"We should respond to Kyber's request to share NIST's position. Let's continue to discuss via email, and try to come up with a draft response. We can talk about this on Tuesday."
20200605 10:52:50 file 20241213/Re_ Kyber's response discussion tomorrow _(2)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Apparently from Daniel Smith-Tone: "As I mentioned before, the lattice schemes aren't in a vacuum. Again, this discussion makes me think of GeMSS and how conservative, careful and respectful of our CFP they are."
"But still, it is very clear to me that this scheme is affected adversely by the choice to respect the CFP while (at least in principal if not in practice) the schemes that choose to consider their views and interpret their own requirements on cost are bending the rules."
"So I think that we should actually have a fairly hard stance on this issue. It may not be the case, but it gives the appearance that schemes like Dilithium are getting an unfair advantage by ignoring requirements against schemes like GeMSS that are going beyond what we asked."
Down thread: "Dan and other people could complain that we changed our security model in a significant way in the final round from the call for proposal." Yes, exactly. NIST ended up retroactively changing the rules to rescue Kyber. Why did NIST decide to do this? #inconsistency #needmorerecords #weveshownallourwork
20200605 11:46:07 file 20241213/Re_ Kyber's response discussion tomorrow _(1)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Thread is debating security levels.
"The Kyber team thinks it is impressive/ infeasible to build micro-SD cards to cover New York City; this is nowhere near the level of security that we are asking."
NIST's public reports instead kept changing how security was measured so that Kyber continued to qualify for its claimed security levels. #inconsistency #needmorerecords
"It's because there's a lot of uncertainty in our estimates of the actual concrete complexity of these algorithms, and because we have to account for decades of future progress in theory, algorithms, hardware, etc. And these things are really hard to understand and estimate, so we give ourselves a large margin."
"Now, can we be at least somewhat scientific about how large this margin should be, both in cases of time complexity and space complexity? Probably. Should we be open about how we're doing these assessments and how we're selecting these margins? I think so."
"Also: I agree with DanielS that we need to be even-handed in applying our assessments to all schemes, to whatever extent that is possible."
This was in response to Daniel Apon repeating what he called "the key point" from the Kyber team: "The additional memory requirement of this attack strongly suggests that Kyber-512 is more secure than AES-128 in any realistic cost model. … A planar sheet of terabyte micro-SD cards the size of New York City (all five boroughs, 800 km2 ~ 249.5 mm2) would hold 289 bits."
Earlier Daniel Smith-Tone had written: "I have a bit of a problem with saying, "We are secure because of other stuff that we can't measure really well." For other areas we have been requiring them to ignore memory costs even when that makes a difference for them."
"A problem occurs when we lack justification and when we lack consistency in how we apply restrictions in these analyses."
"If we chose to allow memory access cost as part of the complexity analysis, there will be consequences. We may have to communicate with each team explicitly, but I think we should make it clear (if we go that route) that they should analyze the memory concerns with strong justification for minimal cost models that they can then incorporate. We also need to assess the feasibility of these models and the appropriateness of the bounds they suggest."
20200605 12:07:29 file 20241213/Re_ Kyber's response discussion tomorrow _Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Apparently from Daniel Smith-Tone: "I think that I agree with everything there. To me I think that we need to raise the issue a bit more directly with Dilithium and Falcon. It is definitely too generous to simply not have the same requirements for lattice signatures that we have for literally every other scheme, whether KEM or sig."
Down thread, Perlner: "There’s also the fairness issue of treating things that have 20+ bits more security margin as exactly the same, and the issue of what to do about the higher security levels."
NIST's subsequent reports presented Kyber-512 and various non-Kyber proposals as "category 1", even when the non-Kyber proposals had much higher security margins (according to various public security estimates) than Kyber-512. This is exactly the "fairness issue" that NIST had secretly discussed. #inconsistency #weveshownallourwork
"NTRUprime’s claimed category 5 parameters are below Kyber’s claimed category 3 parameters." #error #inconsistency
20200606 08:34:26 file 20241115/Re_ Draft response to Kyber.pdf:
20200607 09:12:38 file 20241213/Re_ Rainbow_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing TLS size limits.
20200608 02:58:35 file 20241115/RE_ 2nd Draft response to Kyber (A few minor ed..._3.pdf:
20200608 03:09:01 file 20241115/RE_ 2nd Draft response to Kyber (A few minor ed...(1)_2.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Thread discusses drafts of a public message regarding NIST's retroactive modifications of the competition criteria to rescue Kyber-512.
Thread includes some internal recognition of the impropriety of what was going on: "I guess many algorithms could have been designed differently to improve their performances if their authors knew that up front."
#inconsistency
#weveshownallourwork
20200608 10:51:22 file 20241115/RE_ Call for Assistance.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Thread is discussing possibility of an improvement in GeMSS.
"I’d like GeMSS to not suck as much as it does right now"
20200608 10:59:14 file 20241115/Re_ 2nd Draft response to Kyber (A few minor ed..._4.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I also thought this was a nice response."
20200608 12:36:00 file 20241213/RE_ hash-and-sign_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing cutoffs in security levels.
20200609 01:04:35 file 20241115/Re_ 3rd Draft response to Kyber (A few minor ed..._1.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
More discussion of NIST retroactively modifying the competition rules to rescue Kyber-512.
20200609 06:00:38 file 20241213/Re_ internal PQC meeting_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"Ok, I did a short write-up for LAC. I'll go back and add the references tomorrow, and look at other sections of the report. Sorry again for being slow... and thanks for pushing this along..."
20200609 09:16:26 file 20241115/128-bit version for stateful hash-based sigs.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I support not approving 128-bit version of LMS and XMSS as I mentioned before."
"However, again, the current response text has a clear flaw in its technical justification."
"In addition, there would be serious consequences from that response."
"That response would imply that AES-128 shall not be used in situations where upgrading to AES-192/256 is not practical. There are a lot of deployments where this is the case I think." #ftqcic
... "After having sufficient amount of discussions, we'll make our decision at that time. This way, we practically avoid the 128-bit version for now (not making Stateful HBS so attractive as one of our goals)."
... "If we need to make a decision close to choosing a sig algorithm (Falcon for example), we could have a good reason to not specifying the 128-bit version because Falcon is a better choice."
20200609 10:11:00 file 20241213/Re_ Draft summary for PQC team(1)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing stateful hash-based signatures.
20200609 11:39:19 file 20241115/Re_ PQC Round 2 report assignments.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Ok, I’ll take a look at the Falcon and Dilithium discussions some time soon."
Down thread, list of missing writeups:
20200610 04:02:00 file 20241115/Another HQC section draft.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I want to offer another way of framing the HQC section (and to address the comments on the sharepoint file). I’ve attached a word file with your current HQC section and another draft. I’d like to know what you think of it and how we can blend them together into a single message. Please let me know when you can."
20200610 09:44:10 file 20241115/RE_ SPHINCS+ write-up.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"This discussion makes me nervous in the same way that standardizing stateful HBS and stating that we can validate hybrid signatures made me nervous: I just don’t think that it is a good idea. Anyway, on stateful HBS and hybrid signatures, that check’s been cashed. For the number of signatures requirement, the check has not been written and I hope we don’t."
Thread is generally discussing smaller maximum number of signatures for SPHINCS+.
Down thread: "They would likely prefer rainbow over SPING+ because rainbow does not have a small max. number of sigs problem."
#weveshownallourwork
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).
20200610 19:59:00 UTC file 20241115/Another HQC section draft.pdf-attachment-HQC_Round_2(draft).docx:
Notes from djb, last edited 20241125 00:54:00 UTC:
"HQC"
"HQC is a structured code-based KEM which achieves an upper bound on the decryption failure rate by introducing a new analysis of its error vector distribution. The new analysis shows the decryption failure rate is lower than previously believed, allowing reductions in key sizes. HQC also presents a new decoder using concatenated Reed-Muller and Reed-Solomon codes which further reduces the size of the public keys. However, these reductions in key size still result in public keys that are 1.6-2 times BIKE’s public keys and ciphertexts 4-5 times larger than BIKE’s ciphertext size. Although HQC’s bandwidth exceeds BIKE’s, HQC’s key generation and decapsulation functionalities are much faster than BIKE’s. "
"The new HQC implementation requires review from the community on side-channel protections. The new parameter sets will also require close analysis and vetting. The effect, if any, of the quasi-cyclic code structure on security should also be investigated. "
"HQC is a code-based KEM based on the hardness of the decisional quasi-cyclic syndrome decoding with parity problem. The scheme claims IND-CCA2 security based on a strong analysis of its decryption failure rate."
"In the second round, a new analysis of the error vector distribution shows that the decryption failure rate is lower than previously believed, allowing reductions in key sizes. The HQC team also presented a new decoder using concatenated Reed-Muller and Reed-Solomon codes, further reducing the size of the public keys. Even with these key size reductions, the resulting public keys and ciphertexts are 1.6-2 and 4-5 times the size of those of BIKE, respectively. Although the bandwidth of HQC exceeds that of BIKE, HQC’s key generation and decapsulation functionalities are much faster than BIKE’s."
"While HQC offers strong security assurances and a mature analysis, its performance characteristics are overshadowed by the lattice KEM candidates and it compares unfavorably with BIKE in the bandwidth metric. As a result of these facts, NIST does not deem HQC to be an appropriate addition to the first round of NIST standards. HQC is advancing as an alternate candidate in the third round due to the thoroughness of its security analysis in comparison to BIKE, the other strong code-based KEM candidate."
"During the third round, NIST encourages further research into the relationship between the decisional and search versions of the QCSD with parity problems as well as a close analysis of the new parameter sets. The community should also continue to investigate the effect on security produced by the quasi-cyclic code structure. (If we want to emphasize side-channel research at this point for the track 2 candidates, then we can place another sentence like your side-channel sentence here.)"
20200611 02:16:44 file 20241115/Re_ LAC.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I'll try to say more about LAC, but it is a little tricky, because the worst attacks on LAC happened in round 1, and were arguably fixed in round 2. The attacks in round 2 seemed relatively minor. I think the attacks in round 1 just left a bad taste in everyone's mouths, and since we had lots of lattice KEMs, we didn't feel any need to keep LAC in the competition. I'll try to find a nicer way to say this."
#inconsistency
#weveshownallourwork
20200611 09:20:43 file 20241115/RE_ Another HQC section draft.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing text about HQC and BIKE.
#weveshownallourwork
20200611 09:36:10 file 20241213/Re_ internal PQC discussion(2)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Scheduling discussion of report.
20200611 10:37:27 file 20241115/Re_ Report.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"It's in the report, section 4."
20200612 01:42:32 file 20241115/Re_ The path to standardization(3).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"We are not telling them they have to do this. We are just saying this is something they may wish to consider. It's up to the submitters to decide."
20200612 01:49:26 file 20241115/RE_ The path to standardization.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Oh also, the Daniel with whom I’ve been discussing 3 round Fiestel Patarin is Daniel ST. I realize I didn’t clarify."
20200612 02:01:56 file 20241213/Re_ internal PQC discussion_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Meta-discussion of report.
20200612 02:07:00 file 20241115/Re_ The path to standardization(2).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"How long after a major change in an algorithm would we feel like we needed to wait before moving forward with standardization? I mean, if GeMSS has that major of a tweak, I’d want to consider it as a round 4 alternate, not a fallback for round 3."
20200612 02:32:23 file 20241115/Re_ The path to standardization(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Down thread: "I still believe it’s worth hearing out the science first before reaching this conclusion" In response to: "Kyber512 is an example that something we did not see; we had complete confidence on it. But, it turned out there is something we should examine more."
Down thread: "I second Daniel A’s point that NTRU’s main path to standardization involves IPR concerns for the newer lattice schemes."
Down thread: "I don't think SIKE needs big tweaks. The actual algorithm is very stable. We'd like more confidence in the security, but mostly we want improved performance."
Down thread: "Thinking about the algorithms this way makes me think we should be more clear about the distinction between round 3 finalists, round 3 fallbacks, and round 4 alternates, because these are quite different. We want minimal tweaks for finalists and fallbacks, but we encourage tweaks for our alternates—they won’t be standardized until after somethink like a fourth round."
Chart of standardization paths for different candidates. #inconsistency #weveshownallourwork
20200612 05:31:30 file 20241115/Re_ PQC meeting summary + updated assignments.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I think we need to at least more-or-less talk about the path to standardization, but I agree we shouldn’t bind ourselves to standardizing anything."
Down thread: "Is there value in having this on the document, as opposed to it being our internal consensus as of today? Anything we say in the document is really hard to retract later."
#weveshownallourwork
Down thread, assignments of who edited which writeups:
Also a specific request to hide details of NIST's decision-making processes regarding lattices: "In particular, NTRU Prime, NewHope, and Three Bears need to be more high level. Please try and do some revising before Tuesday, where we can meet again to discuss the report."
#weveshownallourwork
20200612 06:33:02 file 20241213/Not asking for a level 5 option for NTRU Primes_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"I don't think we should say this " Finally, while NTRU Prime has considerable strength in its proposed level 1 parameters, NIST encourages the NTRU Prime team to provide a level 5 parameter set going into the 3rd round. "."
"A possible reason you might have for the statement is that you want to have a better performance comparison with the other structured lattice KEMs which have level 5 options."
"If that is the case, you should also ask Kyber and Saber's teams to include level 2 and level 4 options because NTRU Primes have these options."
"If you say that levels 1 and 3 are more important, but levels 2 and 4 are not, then the question is why is that ? Why did we not say that in our call for proposals ?"
"If you say level 5 is more important than level 4, then the question is why is that ? Why did we not say that in our call for proposals ?"
In public, NIST simply went ahead and asked for category 5, without even admitting that it was changing the rules. Public questions of why NIST was changing the rules were never answered. What happened here? #needmorerecords #weveshownallourwork
20200612 08:37:44 file 20241213/Re_ Not asking for a level 5 option for NTRU Pr...(2)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing security levels.
20200612 10:07:30 file 20241213/Re_ Not asking for a level 5 option for NTRU Pr...(1)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Unlike NIST's public announcements, admits that "We basically said category 4 was good enough in the CFP".
Interesting list of arguments for asking for category 5, very different from what NIST later said publicly: (1) generic argument that a higher security margin is better; (2) "Kyber and Saber did give category 5 parameters"; (3) "NSA asked for category 5 parameters".
#nsa
"I think at present, I’m leaning against explicitly asking for category 5 parameters where we’re comfortable saying schemes have at least category 4 parameters, since that’s what we asked for in the CFP. I do think we need to note somewhere that by the standard metrics, the highest security level offered by Kyber, Saber, and Falcon is higher than that of NTRU, NTRUprime, and Dilithium. Likewise, the lowest security parameters proposed by NTRU and Dilithium are on the low end compared to NTRUprime and Saber (with Kyber and Falcon somewhere in between. – Looking at the Falcon spec, I think 114 is the core SVP figure, not 103, which is labeled “quantum security.”)"
NTRU and NTRU Prime both added parameters with higher security margins than Kyber or Saber (which both have structural difficulties going beyond 1024). Where's the NIST praise for this extra security margin? #inconsistency
20200612 10:26:22 file 20241213/Re_ Not asking for a level 5 option for NTRU Pr..._Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Apparently Daniel Smith-Tone: "I agree, Daniel. Don't see why we can't ask for all schemes. (Even outside of their sections we can make a blanket statement that now we want level 5.)"
Notice the word "now" admitting that this was a change. The way NIST worded its subsequent request for level 5 (inside NIST's report on the previous competition round) was inherently deceptive, leading readers to believe that this is what the rules had always been.
Smith-Tone was responding to Daniel Apon writing: "I’m not sure I understand at all the problem with asking for a high security parameter set (that’s totally independent from the other parameter sets)."
The problem, obviously, is that this is punishing some submissions and not others by retroactively applying an ex-post-facto evaluation criterion different from the evaluation criteria that NIST had previously announced.
Back in 2016, NIST had issued a Federal Register notice calling for comments on the draft criteria, and had issued a Federal Register notice saying it would follow the final criteria. To change the criteria, NIST had to issue a Federal Register notice calling for comments on the modified criteria, had to wait at least a month for comments, and had to consider those comments, before applying the modified criteria.
#inconsistency #ethics
20200613 07:12:32 file 20241213/Re_ The path to standardization_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Thread discusses how specific candidates could end up being standardized.
e.g.: "That is, if Rainbow still looks solid at the end of round three and its IP situation doesn’t look too toxic, we will go with Rainbow. If either the security picture or the IP picture looks bad for Rainbow, then we will consider GeMSS, perhaps with some tweaks for improved efficiency."
e.g.: "I second Daniel A’s point that NTRU’s main path to standardization involves IPR concerns for the newer lattice schemes."
e.g.: "I don't think SIKE needs big tweaks. The actual algorithm is very stable. We'd like more confidence in the security, but mostly we want improved performance."
20200615 01:52:27 file 20241115/Re_ Style conventions.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing English style.
20200615 05:24:00 file 20241213/RE_ GeMSS figures in Asiacrypt paper(1)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing costs of attacks against multivariates.
20200615 05:42:00 file 20241213/RE_ GeMSS figures in Asiacrypt paper_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing costs of attacks against multivariates.
20200615 06:32:58 file 20241115/Re_ Algorithms vs. implementations.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
NIST was secretly punishing the LAC algorithm because of problems with the LAC software. This message (1) observes that this was not consistent with how NIST had said the competition would work, and (2) proposes pretending that the punishment was actually because of concerns that the software issues reflected algorithm issues. This fiction then appeared in NIST's report.
#inconsistency
#weveshownallourwork
20200615 11:04:30 file 20241115/Re_ Report convention.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I'd say we can call out the competitors if it seems appropriate to do so. We don't need to go out of our way and insert it in just because."
"I agree with the list of who's competing with who."
#weveshownallourwork
20200616 04:17:25 file 20241115/RE_ NTRU Prime.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I appreciate your edits"
"I’ve edited it again to condense the length"
Down thread: "For what it's worth, I appreciate what you wrote and I found the snarky style and the digs at Dan pretty funny. But we probably don't want those in a final report."
#weveshownallourwork
20200616 19:18:00 UTC file 20241115/pqc round 2 report.pdf-attachment-PQC Report on Round 2 June 16.docx:
Notes from djb, last edited 20241125 00:54:00 UTC:
#nsa
Includes a comment attributed to "Morgan" (presumably meaning NSA's Morgan Stern) praising Kyber: "I might comment on the fact that they themselves went into considerable analysis on what the precise strength was (as in, it was what they aimed for)."
#error
One wonders how many more comments NSA secretly made to NIST to influence NIST's perceptions of the candidates. #needmorerecords
Another erroneous NSA comment, this one regarding what had been proven regarding New Hope vs. Kyber, made it into the final document: "Start the paragraph with something like: In a technical sense, the security is never better than Kyber."
#error
An NSA comment regarding NTRU: "I think you need to come out and tell them to make a level 5 parameter set under their non-local model."
NIST was already asking NTRU to add parameters reaching "category 5" without counting memory-access costs (the "non-local model"). Meanwhile NIST allowed Kyber to count memory-access costs. #inconsistency
20200617 04:07:27 file 20241115/Re_ PQC meeting recap(2).pdf:
20200617 09:42:54 file 20241115/pqc round 2 report.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"We are advancing algorithms in 2 tracks. The first are the finalists, which are the most promising ones. We'll likely select 1 (or 2) of both the KEMs and signatures. We then are keeping several alternate candidates into the third round, which have a variety of different reasons for keeping them, but for not being a finalist. Our main explanation of this is in section 2.3."
"I was wondering if our rationale makes sense to somebody who is aware of our process, but not into all the details. Let me know what you think. Thanks!"
20200617 11:48:34 file 20241115/Re_ PQC Round 2 report(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Thank you for help. The world is waiting for 3rd round announcement . But the report is critical to tell people why we make those decisions. Therefore, we determined to release the report together with the announcement."
20200617 11:56:49 file 20241115/Report on Round 2 of the PQC process.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Moody, Dustin (Fed) has shared a OneDrive for Business file with you. To view it, click the link below."
"I'm not sure how much you're aware, but we've reached the end of round 2 of our post- quantum crypto standardization process. We've selected algorithms which will be moving on to the third round, and we're writing a report to document the process and explain our rationale."
20200617 12:15:15 file 20241115/Re_ pqc round 2 report.pdf:
20200618 01:38:16 file 20241115/Re_ Selection of Third-Round Candidates(3).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"That sounds right."
20200618 03:38:41 file 20241115/Re_ Selection of Third-Round Candidates(2).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"There are about 15 comments or so still in the report. Some don't need changes made, but the vast majority do. Please take a look, and make any changes you think good. Let's try to get them resolved."
Down thread: "I guess Round 5's plain LWE vs. FrodoKEM was another example of something eliminated for performance reasons."
"It seems that LAC and Round 5 had minor security issues that undermined our confidence in the schemes. Three Bears doesn't quite fit, but we had a security concern resulting from the lack of analysis."
Further down thread: "I'd say performance was more of a factor in terms of schemes being alternate candidates, rather than finalists. SIKE is a good case of this. If SIKE was efficient, it very well might be a finalist. FrodoKEM is an alternate, in part because it is slower/bigger than the finalists. Same for BIKE, HQC, GeMSS, SPHINCS+, and PICNIC to some degree. There might be other issues, but performance being slow/bigger was certainly a factor in them being alternates as opposed to finalists."
20200618 07:26:16 file 20241213/Re_ References_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing bibliography format.
20200618 08:35:05 file 20241115/references.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing what to cite regarding BIKE.
20200618 10:37:29 file 20241115/Re_ PQC meeting recap(1).pdf:
20200619 02:09:59 file 20241115/Re_ PQC meeting recap.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I finished going through our descriptions of each of the 26 submissions. Overall, it looks like we’ve followed the desired format (summary, round 2 happenings, etc.) pretty well. I pointed out a couple places where I thought one component of a description was missing or unusually short."
A serious consistency check would have seen, e.g., that the report made a new rule (NIST "strongly encourages the submitters to provide at least one parameter set that meets category 5") very different from what the call for proposals had said (NIST "recommends that submitters provide at least one parameter set that provides a substantially higher level of security, above category 3"). This was asking for category 5 instead of just above category 3 (e.g., category 4), and was saying "strongly encourages" instead of just "recommends".
A serious consistency check would also have seen that the report used strikingly different wording in applying this rule to different submissions:
NIST "encourages" Dilithium to add a category 5 parameter set.
BIKE "did not provide category 5 parameters", and NIST "strongly encourages" them to do so.
Anything named after NTRU was assigned failure wording, as if category 5 had been requested in the first place: for example, one of these submissions "lacks" category 5 parameters.
In response to a public question about this, NIST wrote the following: "The wording in the comments for Dilithium, BIKE, NTRU, and NTRU Prime may differ, but that should be interpreted as the result of the report having been written by 13 different authors, rather than a deliberate attempt to send subtly different messages to different teams." It's surprising for someone reading that to subsequently learn that NIST actually did carry out internal consistency checks.
20200619 09:16:11 file 20241115/Re_ Selection of Third-Round Candidates.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Sorry if I made the change prematurely. I didn't know you were still going to edit."
20200619 10:07:36 file 20241115/Re_ References 16 and 17 are just one reference. .pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing bibliographies.
20200622 03:01:21 file 20241115/Re_ this week - PQC report(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Thread is generally downplaying the impact of https://eprint.iacr.org/2020/743, which carried out a successful timing attack against the FrodoKEM software because the software used memcmp inside its FO transform.
For comparison, NIST punished LAC for timing variations. #inconsistency
Thread also features various false claims that specific replacements for memcmp are constant-time. #error #scramble #weveshownallourwork
20200622 09:37:36 file 20241115/RE_ Review of draft SP 800-208 and responses to....pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Thank you for sending these. I will review the documents and get comments back to you."
20200622 10:30:28 file 20241115/Re_ this week - PQC report(2).pdf:
20200622 10:47:00 file 20241115/Re_ About ATARC.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Thread is questioning proposals for QKD funding.
20200622 16:50:56 -0400 file 20221003/Cryptanalysis_of_LEDAcrypt622.pdf:
20200622 19:03:38 -0400 file 20221003/Cryptanalysis_of_LEDAcrypt622New.pdf:
20200623 02:19:35 file 20241115/PQC meeting summary today.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"We will ask teams advancing to the 3rd round to give us an idea of their proposed tweaks by August 1st. They then have til October 1st to send us their updated submission package. (If they need more time they can talk to us) The report is looking pretty stable. I've tried to incorporate/resolve all the comments. If you have more revisions you'd like to make, please do them within the next day or two. I'll start the process later this week of submitting it to WERB, etc. so that it can get published. Ray wrote a short response to Dan's recent forum post. We will study this issue in more depth still."
20200623 04:34:14 file 20241115/Re_ Constant time memcmp.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Are there cases where one needs a constant time memcmp where the caller needs to know more than just whether the two inputs are the same?"
20200623 09:33:59 file 20241115/Re_ this week - PQC report.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Actually, I hadn't read Dan's latest message when I wrote my last email. It would be good to discuss it. For those who can, please join."
20200624 02:17:15 file 20241115/RE_ Including memory access costs in gate count....pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
More discussion of NIST retroactively changing the competition criteria to rescue Kyber-512.
#inconsistency
#weveshownallourwork
20200624 03:33:56 file 20241115/RE_ Report on Round 2 of the PQC process.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Report-approval logistics.
20200624 18:52:00 UTC file 20241115/FW_ draft Status Report on the 2nd Round of the...(1).pdf-attachment-PQC Report on Round 2 draft.docx:
20200625 02:15:47 file 20241115/follow up.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Just wanted to check if you were going to write Kyber about increasing the noise a little bit? Maybe we should do that more when we announce our decision and release our report. What do you think?"
20200625 02:42:44 file 20241115/Re_ meeting tomorrow at 10 am _.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Kyber responded to Dan, and explained why they feel they meet category 1."
#error #weveshownallourwork
The actual events were as follows.
30 May 2020, Bernstein, along with extensive technical details: "The Kyber documentation gives five brief arguments that its security level is much higher than claimed by Core-SVP, and says 'it seems clear that in any actual implementation of an attack algorithm the product of the cost of those items will exceed 230'. However, one of the arguments (ciphertexts) is simply wrong for these Kyber attacks, another argument (memory) ignores the announced rules regarding cost metrics, a third argument (the o(1)) still lacks justification and could easily end up reducing Kyber's security, and the remaining two arguments aren't enough to rescue Kyber-512 without help. ... Does the Kyber team continue to claim that Kyber-512 meets NIST's minimum security requirements? If so, why?""
4 June 2020, Kyber team: "We agree with most of your analysis ... the current understanding of attacks against lattice schemes is not at the point, yet, where it allows to give extremely precise gate counts that would support or disprove our claim of at least 2143 for Kyber-512. Also, we agree that the rounding noise in the ciphertext does not add security against the key-recovery attack we consider ... We agree that 136 and 141 are smaller than 143, but at the moment we do not consider this to be a sufficient reason to modify the Kyber-512 parameter set. The additional memory requirement of this attack strongly suggests that Kyber-512 is more secure than AES-128 in any realistic cost model."
This was not disputing the flaws identified in the Kyber security analysis. This was also not arguing that Kyber-512 met category 1 according to NIST's announced rules. It was instead advocating different, more generous, criteria to allow Kyber-512.
Later in 2020, Kyber introduced a modified round-3 Kyber-512 that claimed several more bits of security. Because of improvements in lattice attacks over the next few years, it now appears that the more generous criteria are flunked by round-2 Kyber-512, and even by round-3 Kyber-512. But the issue pointed out in mid-2020 is that Kyber-512 was making unjustified security claims, in part through content errors (the ciphertexts issue), in part through procedural errors (the misuse of o(1) asymptotics, and in general the lack of concrete quantification), and in part through simply ignoring the rules that NIST had announced (the memory issue).
"It wasn't immediately obvious to us that they were wrong."
This is because NIST allowed Kyber to ignore NIST's announced rules regarding cost metrics. Meanwhile NIST used those rules to punish other submissions such as NTRU. #inconsistency
"We don't want to play Dan's game. This issue has been known for months. He only brings it up right during decision time. If there is some problem with Kyber, then we won't have to standardize it."
#error
These flaws in Kyber's security analysis, just like many other flaws in security analyses of many other candidates, were announced as soon as the description of the flaws had gone through sufficient checking. This was years before NIST standardization. The problems with NIST's handling of Kyber have nothing to do with the exact timing.
Down thread: "people looking at the forum discussion and the report would see that we were not sure whether or not Kyber-512 met the level 1 security, but still advanced it as a top finalist without publicly asking the Kyber's team to fix the issue. ... That would imply recklessness from us."
Further down thread: "We've stated our position, as has Kyber. We're encouraging them to look at this, as are we. Daniel A is going to communicate to them the suggestion that they might want to increase their noise."
So NIST was (1) asking Kyber to make changes, and at the same time (2) denying that there was any problem with Kyber.
Later NIST praised Kyber for its radically revised round-3 security analysis. Meanwhile NIST never gave credit to the person who pointed out the large gaps and outright errors in Kyber's round-2 security analysis. #ethics
20200625 02:45:31 file 20241115/Re_ Terminology(4).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"If the track 2 algorithms for round 3 are candidates, what do we call all the algorithms in round 2? They are currently also called candidates, I think."
20200625 02:49:58 file 20241115/Re_ Terminology(3).pdf:
20200625 02:52:08 file 20241115/Re_ Terminology(2).pdf:
20200625 03:24:07 file 20241115/Re_ Terminology(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing terminology for finalists vs. alternates.
20200625 03:26:41 file 20241115/Re_ Terminology.pdf:
20200625 04:12:27 file 20241115/Re_ draft Status Report on the 2nd Round of the...(6).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Down thread: "I would like to discuss the potential to move Sphincs+ up into the finalist from alternative. I have been read in but,…….. . I would be the manager making a call if needed, on the grounds of IP concerns but want to hear and discuss."
#weveshownallourwork
20200626 04:03:59 file 20241115/FW_ draft Status Report on the 2nd Round of the....pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Some relevant language in our draft report." Quoted language is about SPHINCS+ and the possibility of standardizing alternates after the 3rd round.
20200626 07:37:42 file 20241115/Re_ fourier sampling attacks.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I don't see how "known M" could be interesting against, say, Classic McEliece. There it seems to me that S and P are just the operators resulting from applying the systematic form algorithm to M. So for them, M is just the private key and the systematic form of M is the public key."
#error
Down thread: "Looking up “support splitting” I found this: https://hal.inria.fr/inria-00073037/document ."
#scramble
"Iirc, any permutation of a Goppa code is also a Goppa code, so finding the permutation is completely unnecessary (and in fact shouldn’t be possible, since every choice of the permutation is possible with an equivalent key.)"
#error
In fact, the secrets for, e.g., mceliece8192128 are a permutation of the field of 8192 elements and a degree-128 polynomial over that field. Support splitting quickly finds the permutation if the polynomial is known, giving an attack that has one support-splitting step per possible polynomial. The reason this attack is useless is that there are too many polynomials to search through.
20200626 12:34:37 file 20241115/FW_ draft Status Report on the 2nd Round of the...(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I hope to be able to catch you for about 30 mins this afternoon to do a quick run down on round 3 and some 'stakeholder' discussions that have potential to get escalated sometime soon. Let me know if you might have a window and if not perhaps on Monday?"
20200629 01:38:44 file 20241213/Re_ PQC(16)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Thread is discussing standardization possibilities for finalists and alternates.
e.g.: "Our current text isn't so clear. By merely saying that we are "unlikely" to standardize an alternate at the end of round three, that creates confusion. If my goal is to implement all algorithms that might be standardized before the standardization decision is made, can I implement just the seven finalists during the third round or do I need to implement all 15 remaining candidates since any of the alternates "could" be standardized at the end of the third round."
e.g.: "I don't think we want there to be any surprise if we get to the end of round 3 and we decide we're going to standardize SPHINCS+, Frodo, or one of the other four examples John cited. I think we'd want to signal that clearly, and somewhat formally, in advance."
20200629 01:38:56 file 20241115/Re_ PQC(15).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"That is, we could just decide, at the end of the third round, that we’re standardizing, say, Saber, Classic McEliece, and Frodo + Falcon, Rainbow, and SPHINCS+, with Frodo and SPHINCS+ explicitly chosen as paranoid options for people who want postquantum security but also are concerned that these structured lattice algorithms aren’t as well-understood as they should be. There would be nothing shocking about that, and it wouldn’t require a shocking new sequence of cryptanalysis results."
20200629 01:55:59 file 20241115/Re_ PQC(14).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"We have the finalists, and we say to focus on them. We have the alternates, for a variety of reasons. The current report draft says we're not likely to standardize an alternate at the end of the third round, but we don't rule it out. Several of the group wanted to rule it out, but we ended it leaving our options open."
20200629 02:44:46 file 20241115/Re_ You were right.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I'd say the reason was more like your first paragraph. We're confident in its security, but it is bad in performance. If we have Dilithium/Falcon then we don't need sphincs. If we decide we do need it, it can wait a little bit longer (4th round). We're just keeping it on ice."
"I'm not sure what John thinks is more unclear about the new text. Is it because we say we'd only bump up an alternate to a finalist if there is a break, but he thinks there is a chance we might standardize an alternate at the end of the 3rd round for a different reason? I think once I understand his concern, we should be able to figure out a way to word things."
Down thread: "If we're keeping SPHINCS+ around in case lattices and/or Rainbow fail, then it makes sense for SPHINCS+ to be an alternate. And if we start getting sufficiently worried about lattices or Rainbox, then we should come out and say SPHINCS+ is actively under consideration for standardization at the end of round 3."
Farther down thread: "I don't want to write this for fear it could blow up the delicate compromise that's been crafted here, but..."
"As John's last email said, there's a small number of alternates that are probably best described as backups. There's things we could standardize if we really wanted to, but something moderately drastic, or at least unexpected, would have to happen with the finalists."
"If that's not the case for the things in John's list A, then they should probably be finalists, not alternates. "
"If that is the case, then I'm just saying we should say when that unexpected thing happens that causes us to strongly consider standardizing something from A."
20200629 03:24:54 file 20241115/Re_ draft Status Report on the 2nd Round of the....pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"The responses to Dustin’s e-mail from the team show that a general statement about a possibility can trigger a lot of different understandings. Signature candidates are differently from KEM. For KEM, we have NTRU as a IPR fall back and Classic McEliece as a backup for lattice. For signatures, we do not have real backups."
20200629 03:50:00 file 20241115/Re_ PQC(13).pdf:
20200629 03:51:49 file 20241115/Re_ PQC(12).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"For KEM finalists, we have NTRU as IPR fallback and Classic McEliece as a backup in case of lattice based broken."
20200629 03:55:07 file 20241115/Re_ PQC(11).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I agree that the reasoning behind why a scheme is an alternate depends a lot on the scheme."
Down thread: "I agree that standardizing both Saber and Frodo (the latter for the paranoid) would not be shocking, or even very surprising."
20200629 04:25:28 file 20241115/Re_ PQC(10).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"If those of us who have been involved in the discussions can't understand the difference between a finalist and an alternate, then we have to assume that the audience for our report will be even more confused."
"If there is a chance that we would standardize SPHINCS+ and/or Frodo at the end of the third round without any prior announcement that they are now under consideration for standardization at the end of the third round, then why are we calling them alternates rather than finalists? Where does the report explain to readers that there are some alternates that we might standardize at the end of the third round without advance warning and some that we would only standardize at the end of the third round if something unexpected happened (e.g., all structured lattice KEMs are broken)?"
Much more discussion down thread. #weveshownallourwork
20200629 04:43:38 file 20241115/Re_ PQC(9).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"Like David said, if our group isn't clear on this, then it is likely other people will be confused. We need to agree on what our position is, and then make sure we clearly communicate that position."
"Andy suggested we be a little more up front with the possible changes that we could conceivably do during the third round. These are unlikely events, but it will go over better with the crypto community if we have explained what we're thinking in the report. I think this idea makes sense."
"In the write-up for SPHINCS+, we have text saying if one of the signature finalists were to be attacked, then it could be ready. Not quite as strongly, we say something similar for Frodo in regards to KEMs."
The partitioning here is interesting: apparently NIST saw a hypothetical (and later actual) break of a signature finalist as a content issue, a reason to promote SPHINCS+, but not as a procedural issue, a reason for skepticism regarding NIST's selection processes. Was this an explicit decision with a rationale somewhere? #needmorerecords
20200629 05:03:09 file 20241115/Re_ PQC(8).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"We get confused every time somebody proposes a short description of what is an alternate, or a single plan for alternates. I don't see that we need to do that. The text that we do have about each alternate does explain why that proposal is not a finalist and why we would like to keep that proposal around."
20200629 07:00:48 file 20241115/Re_ PQC(7).pdf:
20200629 07:08:11 file 20241115/RE_ PQC.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I second the thought that anything not listed as a finalist should only be standardized prior to a 4th round in the case of emergency (i.e. if a lot of the finalists are getting broken, or at least severely undermined.) If we think we might want to standardize Frodo or SPHINCS after round 3 in a non- emergency situation, I’d rather just list them as finalists."
20200629 08:38:55 file 20241115/Re_ draft Status Report on the 2nd Round of the...(4).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Discussing logistics.
20200629 09:44:14 file 20241115/Re_ draft Status Report on the 2nd Round of the...(3).pdf:
20200629 10:46:42 file 20241115/Re_ draft Status Report on the 2nd Round of the...(2).pdf:
20200629 11:41:43 file 20241115/Re_ draft Status Report on the 2nd Round of the...(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Thread indicates internal controversy.
"To be fair, I've been concerned about that text around SPHINCS+ (and more generally, standardizing "second-track" candidates) for a while now. I brought it up earlier- I just held my tongue after there was a group consensus that made SPHINCS+ an alternate."
"When we've talked about this sort of situation in our meetings, we've said that if something breaks a finalist we would probably regroup and figure out what to do at that point."
"Personally, I don't think that goes far enough to avoid another SHA3-like situation. And I'm also not sure what your new sentence is a good idea to include. The problem we face isn't that someone would try to mount a legal challenge that we broke the rules- it's that if we did something unexpected it might impact public confidence in the process."
#weveshownallourwork
20200629 12:03:44 file 20241115/Re_ PQC(22).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"That’s a plausible outcome, as far as I can tell, for five or six alternates: SPHINCS+, GeMSS, HQC, SIKE, Frodo, and maybe BIKE. For example, imagine that over the next 18 months, we get a bunch of results that make us uneasy about the parameter selection for structured lattice schemes, and at the same time, there’s a very clear upper bound on error rate for BIKE that lets them get CCA security. It seems very plausible to me that we standardize Frodo and BIKE as KEMs in that world. Then maybe we standardize a structured lattice KEM in another couple years when we feel like we know how the parameters should be selected."
20200629 12:12:38 file 20241115/Re_ PQC(21).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"One of the main things you want in these processes is predictability. It's not enough to say we might do something- people have to expect it. We learned that one in SHA-3."
20200629 12:27:30 file 20241115/Re_ PQC(20).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I don't think SPHINCS+ or Frodo probably need that much close attention to feel comfortable with them, but there might be some smaller things you'd want to make sure you understand before standardizing. Maybe discussions of parameters. Or maybe implementation pitfalls. Those are things people might not bother to spend much time on now because they: 1) don't think we're going to standardize on them right away, and 2) might not be big enough results to write a paper on."
20200629 12:50:33 file 20241115/Re_ PQC(18).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"One comment about Frodo: if we end up standardizing Frodo as a replacement for structured lattices, this will not be just a surprise, but a huge shock. Depending on the details of how this happened, we might want to sit down and completely rethink the entire process. In any case, I view this as an extremely low probability event, so there is probably not a need to spend a lot of time thinking in detail about how to handle it now."
20200629 12:51:35 file 20241115/Re_ PQC(17).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I agree that with this new text, we can probably just simply say we won't standardize an alternate at the end of the third round (because we would make it a finalist first). The alternates we want to keep at the end of the third round would then get a 4th round."
20200629 13:36:00 UTC file 20241115/Re_ draft Status Report on the 2nd Round of the...(3).pdf-attachment-PQC Report on Round 2 draft-arr.docx:
20200629 14:37:00 UTC file 20241115/Re_ draft Status Report on the 2nd Round of the...(2).pdf-attachment-PQC Report on Round 2 draft-arr-dm.docx:
20200630 02:23:04 file 20241213/Re_ PQC_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"Several of us discussed this topic just now. We agreed to change Andy's sentence to read:"
" "If new results emerge during the third round which undermine NIST’s confidence in some of the finalists, NIST may extend the timeline or make changes to the process." "
What happened in that discussion? #needmorerecords
Further down thread: "I completely agree with the sentiment that we should have no surprises, but a situation which undermines our confidence in the best schemes would be a big surprise to everyone"
"In fact, I think that it would be an unacceptable level of surprise for us to elevate a scheme to the status of finalist (with the implied same timeline) in case of such a circumstance that clearly calls for a great deal of caution instead of reducing the time spent on focused research into our first round of standards. If such an event happens we would need a round 3.1 and not the elevation of some scheme to the status of finalist."
"The elevation of an alternate to finalist is simply inappropriate in my view. We might even face suspicion if we did not restart the third round."
20200630 08:08:28 file 20241213/Re_ PQC(6)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Discussing paths to standardization for Frodo and for SPHINCS+.
Down thread: "I second the thought that anything not listed as a finalist should only be standardized prior to a 4th round in the case of emergency (i.e. if a lot of the finalists are getting broken, or at least severely undermined.) If we think we might want to standardize Frodo or SPHINCS after round 3 in a non- emergency situation, I’d rather just list them as finalists."
NIST did end up standardizing SPHINCS+.
20200630 08:50:05 file 20241115/Re_ PQC(5).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I would have no problem if we standardized Frodo at the end of the third round if Saber and Kyber are broken. If that were to happen, the community would know well before we started making our final decisions that there were security concerns with structured lattices, and I would hope that we would explicitly tell the community that as a result of these concerns we are now considering Frodo for standardization at the end of the third round."
20200630 08:57:36 file 20241115/Re_ PQC(4).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I was under the impression that, while it is true that each alternate is in that pile for a different reason, one thing they all share is that it is very unlikely that they will be standardized in the third round unless the facts as we understand them now change significantly (e.g., a finalist gets seriously attacked, or we realize we asap need things with a very different security/performance profile than we thought.)"
NIST did end up standardizing SPHINCS+ at the end of round 3, after serious attacks against a finalist signature scheme and an alternate signature scheme. One of NIST's four round-4 candidates, SIKE, was then broken.
20200630 08:58:30 file 20241213/Re_ PQC(3)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"I don't think we are as confused as we think we are." Well, that's confidence-inspiring. #weveshownallourwork
20200630 08:59:33 file 20241213/Re_ PQC(2)_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"I don't think that we need any language in the report stating that we may elevate an alternate to the status of finalist. I think that any circumstance that would make us go that route will likely be a big enough event that it would be no surprise to anyone that we may need to pause and regroup--- re-organize the project. I don't think that we should get hung up on low probability events that muddy the description of the project."
The words "low probability" here illustrate how NIST didn't do a proper risk analysis. Later NIST was so shocked by attacks against finalist Rainbow and alternate GeMSS that it called for new signature submissions. For encryption, NIST announced SIKE as one of just four round-4 candidates, and SIKE was publicly broken weeks later. #error #scramble
Most of NIST's conclusions about risk also weren't published. The "muddy" language illustrates that this secrecy was intentional. #weveshownallourwork
20200630 09:41:37 file 20241115/Re_ PQC(1).pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
"I'm not particularly concerned with whether we explicitly say something in our report about what we would do in the unlikely event that all structured lattice KEMs are broken (or some similar event). We can deal with that when/if it happens. I also agree with Daniel that we may need to strongly consider extending the third round if that were to happen."
20200630 11:21:09 file 20241115/Re_ Any new comments on PQC report.pdf:
Notes from djb, last edited 20241125 00:54:00 UTC:
Thread indicates internal controversy regarding "finalists and alternates".
#weveshownallourwork
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.
20220302 04:59:45 file 20240924/A quick (or medium length) talk about current PQC status.pdf-attachment-Re_ A quick (or medium length) talk about curre....pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Planning meeting between Matthew Scholl, Charles (Chuck) Romine, Kevin Stine. Down-thread agenda: "Current “asks” from other USG crypto agencies and how that might play out"; "IP issues and where we are"; "Anticipated time lines."
What happened at this meeting? #needmorerecords #nsa #slowingdownpqcrypto
20220302 10:03:04 file 20240924/ERB readers for PQC report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Requesting external reviewers for draft round-3 report.
20220302 10:19:10 file 20240924/Re_ ERB readers for PQC report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Report-reviewing logistics.
Down thread: "This is a high profile project, and we are hoping to announce the outcomes by the end of this month (along with having the report published)."
20220302 14:48:58 UTC file 20240924/ERB readers for PQC report.pdf-attachment-draft PQC_3rd_Round_Report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Draft NISTIR 8413.
20220302 14:50:03 UTC file 20240924/ERB readers for PQC report.pdf-attachment-draft PQC_3rd_Round_Report.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Draft of NISTIR 8413.
20220303 10:48:29 file 20240924/a few comments on NTRUprime.pdf-attachment-Re_ a few comments on NTRUprime.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Will do! Sorry for the delay, our kids caught a cold and had to stay at home yesterday. I will try to do it this afternoon or tonight..."
20220303 12:25:07 file 20240924/Chad's report.pdf-attachment-Re_ Chad's report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Chad has shared it with me as well, and we've done some editing back and forth. I think your comment is a good one to ask. Maybe we could re-state to still give an idea why we chose sphincs+, or it's fine with me to drop it. (Of course, we have the 4th round KEMs that will be a backup to the lattice KEMs. )"
20220304 08:38:25 file 20240924/engagement once PQC report is out.pdf-attachment-Re_ engagement once PQC report is out.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Sound good to me."
Replying to: "The PQC report will be a big deal. Beyond the PAO article and Gov Delivery blasts, have you thought about proactive engagement for once the PQC report is out? Thinking Hill briefings as one example. Mind if I put 30 minutes on our calendar with Cheri and Heyman to discuss?"
20220307 02:44:22 file 20240924/7RE_ Commenting on 3rd round report(4).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Comments on draft report.
20220307 02:44:22 file 20240924/RE_ Commenting on 3rd round report(4).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Comments on report.
20220307 05:49:57 file 20240924/6Re_ Commenting on 3rd round report(1).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing NP-hardness, with at least some people clearly not being aware of how solid the separations are between NP-hardness and PKEs. #scramble
Did false advertising regarding NP-hardness play a role in NIST's decisions? #needmorerecords
20220307 09:24:23 file 20240924/ERB reader comments for PQC report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Many small comments on draft NISTIR 8413, mostly about punctuation.
20220307 09:25:53 file 20240924/Re_ ERB reader comments for PQC report(1).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Acknowledging comments.
20220307 13:58:00 UTC file 20240924/7RE_ Commenting on 3rd round report(4).pdf-attachment-comments on p1-20-NISTIR8413.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Looks like earlier draft of this set of comments.
20220307 13:58:00 UTC file 20240924/RE_ Commenting on 3rd round report(4).pdf-attachment-comments on p1-20-NISTIR8413.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Looks like earlier version of these comments.
20220307 14:22:00 UTC file 20240924/ERB reader comments for PQC report.pdf-attachment-ERB Reader Comments on NISTIR 8413.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Comments covered in separate notes.
20220308 09:57:10 file 20240924/Re_ ERB reader comments for PQC report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Report-reviewing logistics.
20220309 12:54:19 file 20240924/5RE_ Commenting on 3rd round report(3).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing edits.
20220309 12:54:19 file 20240924/RE_ Commenting on 3rd round report(3).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing report.
20220309 12:57:00 file 20240924/4Re_ Commenting on 3rd round report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing edits.
20220309 12:59:25 file 20240924/3RE_ Commenting on 3rd round report(2).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing edits.
20220309 12:59:25 file 20240924/RE_ Commenting on 3rd round report(2).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing report.
20220309 17:51:00 UTC file 20240924/5RE_ Commenting on 3rd round report(3).pdf-attachment-comments up to p30-NISTIR8413.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Page 27: The 3rd paragraph, “In the 3rd Round, the KYBER team also provided an extensive and novel analysis of the system’s security “beyond core SVP.” ([14, Sections 5.2 and 5.3]) While many of the details in this section [? sections 5.2 and 5.3] remain somewhat speculative, NIST is not aware of any arguments which disagreed with the general bounds on security gain or loss presented.” It may sound passive and not convincing. Actually, it may be more objective if we say “the general bounds on security gain or loss presented reflected the current understanding of the community.” Or we can simply say something like “In the 3rd Round, the KYBER team also provided an extensive and novel analysis of the system’s security “beyond core SVP.” ([14, Sections 5.2 and 5.3])” The rest is unnecessary and not very objective. (See comments below for the rest of the paragraph.)"
"Page 27: The 3rd paragraph, “To wit – in the very worst case, if every open question is resolved in the worst case for KYBER, the scheme would drop slightly below NIST’s targeted security level in the gate-count model (but not in any model that takes into account memory costs).” This is to share a researcher’s view. But if we cannot tell why “the gate-count model” is less important than “any model that takes into account memory costs”, then this sentence will not convey the message we want the readers to hear. (I like to understand it.)"
"Page 27: The 3rd paragraph, “NIST finds that to be an unlikely outcome; rather, if security is reduced below an intended level, it would much more likely result from new algorithmic progress, not from a lack of concentrated analysis of the KYBER cryptosystem.” Not too sure what message this will convey. We may indeed have such a belief. But it will not convince the readers to share our belief. For our standards users, regardless for whatever reason, if the security can be reduced, then it is a serious issue. We did not tell people how unlikely it is."
#weveshownallourwork
20220309 17:51:00 UTC file 20240924/RE_ Commenting on 3rd round report(3).pdf-attachment-comments up to p30-NISTIR8413.docx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Looks same as other version of these comments.
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
20220311 10:11:44 file 20240924/2RE_ Commenting on 3rd round report(1).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Thread generally discussing edits. The recent messages are regarding hardness terminology.
20220311 10:11:44 file 20240924/RE_ Commenting on 3rd round report(1).pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing NP-hardness.
20220311 10:22:43 file 20240924/1RE_ Commenting on 3rd round report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing editing logistics. Apparently edits were mainly on Overleaf. #needmorerecords #weveshownallourwork
20220311 10:22:43 file 20240924/RE_ Commenting on 3rd round report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing report.
20220314 01:26:17 file 20240924/revising the report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Editing report.
20220315 10:03:04 file 20240924/April NICE Webinar on Quantum Computing.pdf-attachment-Re_ April NICE Webinar on Quantum Computing.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Talk planning.
20220315 10:48:21 file 20240924/FIPS vs SP question.pdf-attachment-Re_ FIPS vs SP question.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing whether a post-quantum standard should be a Federal Information Processing Standard (FIPS) or a Special Publication (SP).
20220322 03:43:25 file 20240924/Fw_ NTRU Prime write-up.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Thread indicating that NIST deselected NTRU Prime because "the claimed attack avenue on cyclotomic Ring/Module LWE didn't pan out". #error
In fact, unit attacks and more general S-unit attacks have successfully broken many lattice problems. For example, these attacks broke the cyclotomic case of Gentry's STOC 2009 FHE system, while the best attacks known against the generic case are much slower. These attacks then broke through the principal-ideal barrier claimed in 2016, broke through approximation-factor barrier claimed in 2018, broke through the precomputation barrier claimed in 2019, and broke through the probability barrier claimed in 2021. All of this was laid out with clear references in a document from the NTRU Prime Risk-Management Team filed before NIST's deadline for competition input.
Does this guarantee that the attacks will break the Module-LWE problems inside Kyber? No. But saying that this attack avenue is merely "claimed" and "didn't pan out" is wrong.
It is possible that "claimed attack avenue" was meant as "claimed attack", but then what is this referring to? Designers should be able to say that they're staying as far away as possible from what has been broken, without having this proactive safety mechanism misrepresented as saying that everything in between has already been broken too. #needmorerecords
The thread does refer to the above document, but doesn't actually engage with the contents. Also incorrectly refers to the document as "DJB's "lattice risks" document". #ethics
20220329 08:23:10 file 20240924/Re_ ERB for PQC report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Thank you!"
Replying to internal approval of report.
20220329 08:46:26 file 20240924/Re_ ERB .pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Yes, we are waiting for lawyers approval before we take the action of publishing the report (even if ERB is completed). It all needs to be done at the same time."
Down thread: "Yes, the lawyer stuff is just for the IP issue. It's not the joint statement, but rather the actual license deal text. I imagine their lawyers will want to review it and make changes, but the hope is that this sort of finalization can proceed after our announcement. But we want them to at least see our version we're sending to them and agree one last time before we announce."
"Yes, we need this step to happen before we publish. We need to have the IP situation confirmed, and have either them issue a statement to that effect, or we issue a joint statement to that effect. Ideally, the report, the announcement, and public IP statements all happen at about the same time. Without a public IP re-assurance the PQC community will be concerned about one of our selections."
Further down thread: "As to timing, yes - still waiting on the lawyers. Our lawyers took awhile, and then sent it to the State department for their lawyers to review (since it involved a deal with France). Hopefully they okay it with no changes. Could happen at any time. Then we send it to France and Jintai and verify one last time they are good with everything."
#slowingdownpqcrypto
20220331 10:52:28 file 20240924/Re_ IDF text.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Discussing how to handle Matzov paper. #weveshownallourwork
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:
20221003 15:05:56 UTC file 20240730/PQC_-_slides.pptx:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Our role: managing a process of achieving community consensus in a transparent and timely manner" #claimingtransparency
"Ideally, several algorithms will emerge as ‘good choices’" #inconsistency
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:
20230317 15:50:08 UTC file 20240730/PQC_RW.pptx:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Our role: managing a process of achieving community consensus in an open, transparent, and timely manner" #claimingtransparency
"Ideally, several algorithms will emerge as ‘good choices’" #inconsistency
"The security margin for Kyber-512 is close in the gate metric" #inconsistency
"NIST is currently leaning in the direction of including kyber-512 in the standard"
20230323 18:28:00 UTC file 20230915/Quantum talking points.docx:
20230517 15:58:03 UTC file 20240730/PQC_in_standards.pptx:
Notes from djb, last edited 20241002 20:43:30 UTC:
Slides on what some other organizations are doing in post-quantum cryptography. For example, regarding ISO: "New project: Develop Amendment 2 of ISO/IEC 18033 Part 2 (PQC key encapsulation mechanisms, Kyber, Classic McEliece, and Frodo)"
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:
20230815 15:14:53 UTC file 20240924/RE_ Final Agenda - NPL Visit.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Sending slides for "NPL visit".
20230815 15:36:43 UTC file 20240730/Re__Cyberstat_webinar_on_PQC_migration.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Talk planning.
20230822 14:12:33 UTC file 20240730/NIST-NSM10.pptx:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Is this just DH and RSA or should we also transition AES Key size?"
20230822 14:14:30 UTC file 20240730/PQC-us.pptx:
Notes from djb, last edited 20241002 20:43:30 UTC:
"Our role: managing a process of achieving community consensus in a transparent and timely manner" #claimingtransparency
"Ideally, several algorithms will emerge as ‘good choices’" #inconsistency
"We are planning to standardize Kyber-512, Kyber-768, and Kyber-1024"
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:
20240208 13:27:58 UTC file 20240726/Re_ WERB_3.pdf-attachment-cryptanalysis2.bib:
20240208 13:27:58 UTC file 20240726/Re_ WERB_3.pdf-attachment-cryptanalysis2.tex:
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:
20240501 12:29:59 -0400 file 20240924/a few comments on NTRUprime.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
PDF "portfolio" created by NIST later.
20240501 12:31:03 -0400 file 20240924/A quick (or medium length) talk about current PQC status.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
PDF "portfolio" created by NIST later.
20240501 12:35:29 -0400 file 20240924/April NICE Webinar on Quantum Computing.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
PDF "portfolio" created by NIST later.
20240501 12:40:41 -0400 file 20240924/Chad's report.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
PDF "portfolio" created later by NIST.
20240501 13:00:09 -0400 file 20240924/engagement once PQC report is out.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
PDF "portfolio" created later by NIST.
20240501 13:04:43 -0400 file 20240924/FIPS vs SP question.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
PDF "portfolio" added later by NIST.
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:
20240611 09:29:40 UTC file 20240726/Re_ question about Quantum Communications appli..._1.pdf-attachment-gs-16-18-quantum-technologies-report.pdf-attachment-15061_GOScience_Full_Book_Accessibility.pdf.accreport.html:
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:
20240722 10:45:08 UTC file 20240726/Here's what I have so far.pdf-attachment-Brownian.tex:
20240917 13:19:01 -0400 file 20240924/Quantum Slides.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
Advertisement for a "Quantum Working Group".
20240920 11:08:22 -0400 file 20240924/FOIA Coversheet 001133 Release in Entirety 2.pdf:
Notes from djb, last edited 20241002 20:43:30 UTC:
FOIA cover sheet, maybe was meant to be just internal to NIST?
20241104 10:54:53 -0500 file 20241115/stateful-HBS-public-comments-June2018-rfi.pdf:
20241113 18:54:48 UTC file 20241115/PQC Overview Aug 2020 - Friday 10am version.pptx:
Notes from djb, last edited 20241125 00:54:00 UTC:
Another version of slide set that was posted in response to an earlier FOIA request.
20241114 08:59:36 UTC file 20241115/RE_ SPHINCS+ write-up.pdf-attachment-image001.png:
20241114 08:59:36 UTC file 20241115/RE_ SPHINCS+ write-up.pdf-attachment-image002.png:
20241114 09:17:06 UTC file 20241115/Re_ Terminology(1).pdf-attachment-43A58A1DE3204A1DBF896820C21C63AA.png:
20241114 09:17:06 UTC file 20241115/Re_ Terminology(1).pdf-attachment-A34B0016AA2E4684BE3E4D2C74F4F4C1.png:
20241114 09:17:06 UTC file 20241115/Re_ Terminology(1).pdf-attachment-F399A78DE3D54B758DB97CF4C38C11F5.png:
20241204 09:06:34 UTC file 20241213/First drafts of selection memo for RIT (2) and ..._2_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Lots of redactions. #needmorerecords #weveshownallourwork
20241205 08:44:28 UTC file 20241213/meeting today at 10_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
"For anybody who would like to, let's meet at 10am to discuss the report. The link is below."
#needmorerecords
20241206 09:40:20 UTC file 20241213/RE_ Post-Quantum Crypto Group meeting today_Redacted.pdf:
Notes from djb, last edited 20241220 01:17:00 UTC:
Some redactions. #needmorerecords
![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}
.pdf-attachment-43A58A1DE3204A1DBF896820C21C63AA.png){kind=link}
.pdf-attachment-A34B0016AA2E4684BE3E4D2C74F4F4C1.png){kind=link}
.pdf-attachment-F399A78DE3D54B758DB97CF4C38C11F5.png){kind=link}