These are meant as a gentle introduction to the ideas and intuitions behind the schemes. The book is recent but some of that stuff (hash-based signatures) I started writing back in 2015 and is available on my blog: https://cryptologie.net/article/306/one-time-signatures/
At the time the schemes had not yet been chosen, fortunately I picked the right ones :) don't have to rewrite that chapter (yet).
That NIST worked together with NSA to allow/insert backdoors into cryptography kind of left a sour taste in my mouth, and it's hard to trust them again after that.
The problem this argument has is that NIST competitions are legitimated by their participants. People trust NIST's hash competition because of who entered, and because the winning team has an unimpeachable record. For the most part, people will trust this contest for similar reasons. If you could get this cast of cryptographers not to submit to NIST contests, and instead submit to some other contest, we'd have something productive to talk about. But you can't, and so, when we talk about contest-based cryptography standards, you're going to end up back at NIST.
I don't like NIST for another, better reason: I think the whole enterprise of picking cryptography standards in advance is bankrupt, and holds the industry back. So I'm not a NIST fan either. But I don't see what's to be gained by derailing conversations about new cryptography so we can relitigate the same points over and over again.
Meanwhile: pull up the authorship team on CRYSTALS-KYBER. Approximately 0% of credible cryptographers believe that NIST was somehow able to exert improper influence over this design.
Sorry if you think I'm trying to convince people of anything. I'm simply asking for alternatives to NIST itself, for my own personal and selfish reasons. I'm not arguing against other people trusting NIST, their competitions or anything like that. Just asking a question regarding alternatives.
I'm glad you and others answered. Someone even gave a proper alternative based in Germany, and for that I'm very happy. I'm sorry you feel like people are "relitigating the same points over and over again", I cannot steer the conversation any more than you can and I personally haven't seen any conversations on HN about alternatives to NIST, then obviously I wouldn't ask for it, if I already knew the answer.
The closest analog to NIST I can think of is ECRYPT and the eSTREAM contest. It produced interesting work and you could follow it in much the same way people followed these last two NIST competitions. But for PQ KEMs, it's likely that NIST's will be the "competition of record".
I understand that neither NIST nor NSA have designed these schemes, but isn't NIST the organization who picked these winning schemes after all? That's the impression I got, and my history of trusting what NIST picks, isn't the greatest, so I'd like to avoid that. I also understand that countless of people have reviewed the schemes as well, people from all around the world with different types of experience. It's still hard to shake off something that essentially boils down to a feeling: "trust".
Thank you for providing some alternatives in your final paragraph, for the uneducated plebs like myself.
Edit to add: if the authorship of the submitters is as above reproach as we are led to assume, why can that not be the case for the NIST decision panel itself?
Edit 2: answered already elsewhere: https://news.ycombinator.com/item?id=31993896
It’s think it’s also an example of why NIST is so important. The subversion of the standard is a problem, but the real exploit using that subversion was the laziness and lack of skill that downstream practitioners demonstrated. People clicked next and installed that RSA BSAFE package without any configuration or reading of the manual.
Without NIST, you’d have Crypto AG — much worse. With NIST, you may have trust concerns, but ultimately the US government is protecting much of its own data as well as politically/economically critical data with NIST algorithms (aka FIPS 140-2).
Ultimately, I think the model in place with these competitions is probably the “best worst” option.
It appears that BULLRUN was the name of the effort/program, not the faulty algorithm itself.
(I'm among an elite cadre† of cryptography-adjacents who felt it probably wasn't, but only because I thought it was too stupid to actually be used anywhere --- as soon as it was disclosed that (a) it was a default-yes algorithm in BSAFE and (b) big companies actually used BSAFE in important products, it was immediately clear what was going on).
The idea of Dual EC is essentially that your output is internal RNG state encrypted with a public key, leaving open the obvious question of "who has the private key?". I think we all know the answer to that now.
† i am being ironic
I appreciate the point about trust in the authorship of those presenting these algorithms, and I personally do accept it, but there's a lack of trust broadly (in the very community that these standards are intended for) in the process that your comments don't account for in this instance.
Nitpick: strictly speaking, it wasn't plainly a backdoor specifically, but plainly either a backdoor, or something deliberately designed to look backdoored, but with some unknown way for the NSA to 'reluctantly' declassify a proof that it wasn't backdoored in a attempt to discredit people who accused it of being backdoored (basically trying to recreate the DES S-box versus differential cryptanalysis thing). But smart money was on actually-a-backdoor.
In advance of what ? Not intended as a gotcha I'm genuinely interested.
I see past NIST competitions as a mixed bag in terms of whether what we got is important (e.g. AES) or not so much (e.g. SHA-3) but I don't see any cases where they made things worse. And the NIST competitions attract some attention whereas something more discrete like the CFRG PAKE selection process can be so quiet if you're not intimately involved you might not know the CFRG actually selected anything. If you build a new product with Serpent or Twofish inside it, that will attract questions about why not AES - does this happen if your product has SPAKE2?
How NIST chose algorithms in the past was done in quite diverse ways. Sometimes they merely said "this is a standard" and people could comment and the comments were ignored. This is basically what happened with Dual EC DRBG, whcih is the likely example you're referring to.
However the way this standardization worked - and several others before, like AES and SHA-3 - is that NIST made a public competition. They basically asked everyone to submit proposals and then asked everyone to find flaws in theses proposals.
These competitions have a very good reputation in the cryptographic community. An algorithm like Dual EC where the issues were quite obvious would've never survived such a process.
The thing you should look at is the process, not the organization.
EDIT: To more specifically address the process: If NIST wanted to get people to trust a shady algorithm, they could have some amazing cryptographers invent an algorithm which stands up to scrutiny, but which has some extremely hard to notice flaw which only they know about. They could then make those cryptographers submit the algorithm to NIST, and, in a seemingly fair way, pick the subtly broken algorithm as the winner. I can't know whether this happened of course, and it probably didn't, but we fundamentally have to trust that NIST wouldn't do something like that... and we do know that they would do, and indeed have done, something like that.
Maybe the process is such that this attack, and any other kind of attack, is impossible. If that's the case, please do cite something which goes into detail on that.
> However the way this standardization worked - and several others before, like AES and SHA-3 - is that NIST made a public competition. They basically asked everyone to submit proposals and then asked everyone to find flaws in theses proposals.
> These competitions have a very good reputation in the cryptographic community.
A very brief google search provided citations to the proposals and counter-attacks for your perusal.
But if it can come up with a competitive algorithm with a subtle unnoticed flaw, than that attack would work almost as well in a contest hosted by some other organization. They wouldn't be able to guarantee the win, but they would still have a good shot at it.
Then there shouldn't be a problem with another organization hosting the contest than NIST? Since I'm probably not alone in not being able to trust them anymore.
The reason it was enabled in some systems is 1. libraries (like openssl and ffmpeg) used to implement and ship every algorithm on Earth for pride reasons 2. NSA bribed RSA BSafe to make it the default.
You don't have a solution for #2.
And didn’t they subsequently ban the NSA from their input once the Snowden leaks were out?
So I don’t think it’s fair to disregard NIST completely. And the international counterparts can compare & perform their own due diligence
Not sure if that's better or worse than them collaborating directly.
Edit: from a paper linked in another comment:
> Researchers raised concerns to NIST about both possible bias in the bits and a possible backdoor in Dual_EC_DRBG. NIST examined the issue. NSA dismissed NIST's concerns, responding that implementers could choose their own parameters to handle concerns about possible backdoors. NSA pressed NIST to standardize the algorithm, claiming that it needed FIPS validation of agency devices running Dual_EC_DRBG, and thus NIST approved Dual_EC_DRBG as one of four possible standardized random-bit generators. Dual_EC_DRBG remained a FIPS until shortly after the 2013 revelation of an NSA backdoor in a cryptographic algorithm.
So seems NIST and others were aware of the shortcomings of Dual_EC_DRBG but was pressured by NSA to end up as a FIPS anyway.
Either way, hard to start trusting NIST again after a fiasco like that.
> And didn’t they subsequently ban the NSA from their input once the Snowden leaks were out?
AFAIK, NSA didn't submit anything for this competition, but bunch of mathematicians from NSA have worked on helping NIST with the overall process of the competition, including reviewing the entries.
It wouldn't surprise me that if NSA found something, they would withhold any findings if they could benefit from being the only ones knowing about any holes. Although we all know how that ends.
> And the international counterparts can compare & perform their own due diligence
Yes, this is exactly what I'm asking for, the purpose of my initial comment. Who are these international counterparts that I can look to instead of NIST?
I think you would be correct and do you know that ends?
Well, one is an issue of competency or at the very least experience. The other is an issue of ethics. I'll take a competency concerns over ethical ones any day.
The conclusion is no, there is no alternative right now.
But then again I may be completely ignorant as to the scope of NSA meddling.
You say this like NIST was an accomplice (and not also a victim).
Not sure what consequences NSA told NIST would happen if they said no, when they pressured them, but from the look of things (https://harvardnsj.org/wp-content/uploads/sites/13/2022/06/V...) it seems that NSA just asked NIST nicely to make Dual_EC_DRBG a FIPS even as it was weak, and NIST accepted that.
OpenSSH basically decided to ignore the NIST competition and implemented Streamlined NTRU Prime. https://www.openssh.com/txt/release-9.0
Not especially if you're in the US and want to work with government systems or be a sub-contractor to a company that does. Otherwise pick an algorithm and have at it:
> That NIST worked together with NSA […]
Did they? Or did the NSA lie to NIST?
Any trust you're going to put into an algorithm is going to have to come from downstream of NIST.
Russia didn't develop Kuznyechik for nothing
Good luck there.
I am not an expert so I will simply link the Wikipedia article on Computational Complexity Theory as my "source".