5 ms·
There's no need for one. How NIST chose algorithms in the past was done in quite diverse ways. Sometimes they merely said "this is a standard" and people could
by hannob 4y ago
There's no need for one.
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.
- mort96 4y agoI don't understand cryptography enough to vet algorithms. I need to trust an authority to tell me which algorithms to use. I do not trust NIST as an authority. That's why it would be nice to have an actually trustworthy authority which does similar work to NIST. 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.
- mabbo 4y agoWhat if those trustworthy organizations were to tell you: "We trust this NIST competition result, and so should you"?
- mort96 4y agoMaybe, if their reasoning for trusting the NIST competition result holds up to scrutiny. Do you have any links to trustworthy organizations which wholly endorse the results, with a detailed write-up as to why?
- jvanderbot 4y agoI think we can revisit OP: > 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. https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography_Standardization https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography...
- giomasce 4y agoWho do you trust as an authority?
- DennisP 4y agoNIST wouldn't get away with choosing an algorithm that has been shown to have vulnerabilities, which is the only thing it could do is come up with an algorithm with a subtle unnoticed flaw. And that algorithm has to have performance at least as good as the other algorithms in the contest. 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.
- capableweb 4y ago> The thing you should look at is the process, not the organization. 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.
- tptacek 4y agoThere isn't a problem, except that nobody will take the other organization's contest especially seriously, or write its name into contracts.
- astrange 4y agoNobody trusted Dual_EC_DRBG despite its NIST accreditation. It was always obviously weird to experts, and it wasn't simple and performant enough for non-experts. 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.