8 ms·

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 actua

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 https://en.wikipedia.org/wiki/Bernstein_v._United_States).

bananapub 4y ago
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 https://en.wikipedia.org/wiki/NIST_SP_800-90A for this who have forgotten.
- josh2600 4y ago
  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.
  - tptacek 4y ago
    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.
    - nequo 4y ago
      Where does the non-cryptographer public find out about the current consensus of the literature? Genuine question.
      - TaylorAlexander 4y ago
        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.
    - josh2600 4y ago
      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?
      - tptacek 4y ago
        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.
        josh2600 4y ago
        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?”
tptacek 4y ago
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.
- javajosh 4y ago
  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?
  - tptacek 4y ago
    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.)
    - dwaite 4y ago
      > 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.
deleted 4y ago
[deleted]

bananapub 4y ago

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 https://en.wikipedia.org/wiki/NIST_SP_800-90A for this who have forgotten.

josh2600 4y ago
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.
- tptacek 4y ago
  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.
  - nequo 4y ago
    Where does the non-cryptographer public find out about the current consensus of the literature? Genuine question.
    - TaylorAlexander 4y ago
      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.
  - josh2600 4y ago
    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?
    - tptacek 4y ago
      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.
      - josh2600 4y ago
        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?”

tptacek 4y ago

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.

javajosh 4y ago
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?
- tptacek 4y ago
  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.)
  - dwaite 4y ago
    > 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.

deleted 4y ago

[deleted]