Comment by josh2600 | Hacker News Reader

Comment by josh2600 | Hacker News Reader

I just want to say, the problem here is worldwide standards bodies for encryption need to be trustworthy. It is incredibly hard to know what encryption is actually real without a deep mathematics background and even then, a choir of peers must be able to present algorithms, and audits of those algorithms with a straight face.

Presenting broken-by-design encryption undermines public confidence in what should be one of our most sacrosanct institutions: the National Institute of Standards and Technology (NIST). Many enterprises do not possess the capability to audit these standards and will simply use whatever NIST recommends. The danger is that we could be engineering embedded systems which will be in use for decades which are not only viewable by the NSA (which you might be ok with depending on your political allegiance) but also likely viewable by any capable organization on earth (which you are probably not ok with irrespective of your political allegiance).

In short, we must have trustworthy cryptography standards. If we do not, bedlam will follow.

Please recall, the last lawsuit that DJB filed was the one that resulted in essentially "Code is speech" in our world (https://en.wikipedia.org/wiki/Bernstein_v._United_States).

There's an easier problem here, which is that our reliance on formal standards bodies for the selection of cryptography constructions is bad, and, not hardly just at NIST, has been over the last 20 years mostly a force for evil. One of the most important "standards" in cryptography, the Noise Protocol Framework, will probably never be a formal standard. But on the flip side, no formal standards body is going to crud it up with nonsense.

So, no, I'd say that bedlam will not follow from a lack of trustworthy cryptography standards. We've trusted standards too much as it is.

Believing both "Don't roll your own crypto" and "Don't trust the standards" would seem to leave the average developer in something of a quandry, no?

No. I don't think we should rely on formal standards, like FIPS, NIST, and the IETF. Like Bernstein himself, I do think we should rely on peer-reviewed expert cryptography. I use Chapoly, not a stream cipher I concocted myself, or some bizarro cipher cascade posted to HN. This is what I'm talking about when I mentioned the Noise Protocol Framework.

If IETF standards happen to end up with good cryptography because they too adopt things like Noise or Ed25519, that's great. I don't distrust the IETF's ability to standardize something like HTTP/3. I do deeply distrust the process they use to arrive at cryptographic architectures. It's gotten markedly better, but there's every reason to believe it'll backslide a generation from now.

(There are very excellent people who contribute to things like CFRG and I wouldn't want to be read as disparaging any of them. It's the process I have an issue with, not anything happening there currently.)

> No. I don't think we should rely on formal standards, like FIPS, NIST, and the IETF.

I assume your concerns are with the process of standardization, and not the idea of standards themselves. After all, there are plenty of expert peer-reviews going on in NIST and in the IRTF.

Noise is useful for building your own bespoke kit, but there does need to be an agreement to use it in the same manner if you hope for interoperability. Things like public key crypto are precisely useful because the other side can read the information back out at the end of the process, even if they aren't running e.g. the same email client version.

NIST is procedurally the least objectionable of all of these standards bodies. Contests are better than collaborations. But NIST itself is a force for evil, not for the lurid message board reason of a shadowy cabal of lizard people trying to weaken PQC, but because "NIST standardization" keeps a lot of 1990s-era crypto in use and prevents a lot of modern crypto from being deployed in the industry.

Standards are for people who are not experts in the field or don't have the time and energy to research the existing crypto and actually sift through them to try and decide what to trust and what not to trust.

Lack of standardization might just make it harder for Joe to filter through the google searches and figure out what algorithm to use. He may just pick the first result on Google, which is an ad for the highest bidder on some keywords which may or may not be good.

Standards are also essential for the interoperability of systems.

Formal standards aren't essential for interoperability.

Maybe not "essential" but I'm willing to guess that a huge percentage of the modern web communicates over HTTP or HTTPS.

"Essential" is interesting because you could definitely argue that HTTP isn't essential, but I don't think there is any feasible way of denying that the formalization and acceptance of early internet protocols (UDP, TCP, HTTP, FTP, etc) have played a significant role in shaping our modern technology world.

In a similar way, having reasonable standards makes it easier for everyone that isn't an expert in a particular field to just use something that is likely to work reasonably well while they worry about some other special part of their idea.

I guess this is my point: If you have strong mathematicians and cryptographers, you don't end up using NIST.

There are lots of companies who have need for cryptography who don't know who to trust. What should they do in a world where the standards bodies are adversarial?

Maybe this is just the future, if you don't know crypto you're doomed to either do the research or accept that you're probably backdoored? Seems like a rough place to be...

So use whatever crypto Signal uses, or that WireGuard uses. You're not working in a vacuum. You don't even trust NIST to begin with, and yet we still encrypt things, so I'm a little confuddled by the argument that NIST's role as a trusted arbiter of cryptography is vital to our industry. NIST is mostly a force for evil!

Signal’s crypto doesn’t solve all problems (neither does wireguard).

For example, we built private information recovery using the first production grade open source implementation of oblivious RAM (https://mobilecoin.com/overview/explain-like-i'm-five/fog you’ll want to skip to the software engineer section) so that organizations could obliviously store and recover customer transactions without being able to observe them. The signal protocol’s techniques might be part of a cryptographic solution but it is not a silver-bullet.

I guess, notably, we never looked at NIST when designing it so maybe that’s the end of the discussion there.

I didn't say Signal and WireGuard "solved all problems", and neither does any given NIST standard! The track record of cryptosystems built to, say, FIPS standards is extremely bad.

how could NIST possibly be "one of our most sacrosanct institutions" after the NSA already fucked them with Dual_EC_DRBG?

whoever wants to recommend standards at any point since 2015 needs to be someone else

https://en.wikipedia.org/wiki/NIST_SP_800-90A for this who have forgotten.

Look, my point is that there are lots of companies around the world who can’t afford highly skilled mathematicians and cryptographers on staff. These institutions rely on NIST to help them determine what encryption systems may make sense. If NIST is truly adversarial, the public has a right to know and determine how to engage going forward.

They don't have to (and shouldn't) retain highly skilled mathematicians. Nobody is suggesting that everyone design their own ciphers, authenticated key exchanges, signature schemes, and secure transports. Peer review is good; vital; an absolute requirement. Committee-based selection processes are what's problematic.

Where does the non-cryptographer public find out about the current consensus of the literature? Genuine question.

I guess if I saw what FAANG companies were using to secure their own data that could be an indicator. Though they could be compromised.

I'm just saying, you're speaking as an expert in the field. Let's say you don't want to do design any of that stuff but you need some parts of those systems for the thing you're building. How do you decide what you can or can't trust without having deep knowledge of the subject matter?

Maybe that's it, maybe you can't?

How do you know that Noise is a good design and that a cipher cascade isn't? Whatever (correctly) told you that, apply it to other cryptographic problems.

I see. So maybe what you’re really saying is “why are you writing a system that has cryptographic primitives if you’re not a cryptographer/mathematician?”

No, that is not at all what I am saying.

Let me ask this another way. I know how we determined noise was a good standard and that was talking to a lot of people who had built sophisticated crypto systems and then doing the research ourselves, but that’s only because we had the people on staff who had the capacity to evaluate such systems.

If we didn’t have those people, how would you suggest figuring out which system to implement?

Peer review is a good start. Noise, and systems derived from it like WireGuard, are peer reviewed (check scholar.google.com for starters), and NIST had nothing at all to do with it.

It is incredibly hard to get a good grasp of the consensus in a literature as a non-expert just by searching Google Scholar. People spend years in graduate school to learn to do that.

Are there reputable journals or conference proceedings that you specifically recommend reading for high-quality literature reviews?

I got a lot of mileage out of attending IACR in person. Lots of amazing content there every time. A lot of it is addressable even if you aren't going to do the math.

There's nothing you're going to read, with or without trustworthy standards, that is going to enable you to design safe novel applications of cryptography. Encrypting a file, setting up a secure transport, and (if you're extraordinarily careful and do a lot of reading) exchanging secure messages are all within reach without anything resembling postgraduate education.

Reply on news.ycombinator.com