Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NSA and IETF, part 3: Dodging the issues at hand

blog.cr.yp.to

Post reply on HN
Print view View original

81–90 of 249 posts

Re: NSA and IETF, part 3: Dodging the issues at hand

#81

Post by glitchc »

dhx wrote: post #21

Amongst the numerous reasons why you _don't_ want to rush into implementing new algorithms is even the _reference implementation_ (and most other early implementations) for Kyber/ML-KEM included multiple timing side channel vulnerabilities that allowed for key recovery.[1][2] djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor im…

This logic does not follow. Your argument seems to be "the implementation has security bugs, so let's not ratify the standard." That's not how standards work though. Ensuring an implementation is secure is part of the certification process. As long as the scheme itself is shown to be provably secure, that is sufficient to ratify a standard.

If anything, standardization encourages more investment, which means more eyeballs to identify and plug those holes.

Re: NSA and IETF, part 3: Dodging the issues at hand

#82

Post by crote »

Foxboron wrote: post #32
dhx wrote: post #21

Amongst the numerous reasons why you _don't_ want to rush into implementing new algorithms is even the _reference implementation_ (and most other early implementations) for Kyber/ML-KEM included multiple timing side channel vulnerabilities that allowed for key recovery.[1][2] djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor im…

> See for example the many problems of NIST P-224/P-256/P-384 ECC curves What are those problems exactly? The whitepaper from djb only makes vague claims about NSA being a malicious actor, but after ~20 years no known backdoors nor intentional weaknesses has been reliably proven?

As I understand it, a big issue is that they are really hard to implement correctly. This means that backdoors and weaknesses might not exist in the theoretical algorithm, but still be common in real-world implementations.

On the other hand, Curve25519 is designed from the ground up to be hard to implement incorrectly: there are very few footguns, gotchas, and edge cases. This means that real-world implementations are likely to be correct implementations of the theoretical algorithm.

This means that, even if P-224/P-256/P-384 are on paper exactly as secure as Curve25519, they could still end up being significantly weaker in practice.

Re: NSA and IETF, part 3: Dodging the issues at hand

#83

Post by arccy »

glitchc wrote: post #81
dhx wrote: post #21

Amongst the numerous reasons why you _don't_ want to rush into implementing new algorithms is even the _reference implementation_ (and most other early implementations) for Kyber/ML-KEM included multiple timing side channel vulnerabilities that allowed for key recovery.[1][2] djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor im…

This logic does not follow. Your argument seems to be "the implementation has security bugs, so let's not ratify the standard." That's not how standards work though. Ensuring an implementation is secure is part of the certification process. As long as the scheme itself is shown to be provably secure, that is sufficient to ratify a standard. If anything, standardization encourages more investment, which means more eye…

this is like saying just use C and don't write any memory bugs. possible, but life could be a lot better if it weren't so easy to do so.

Re: NSA and IETF, part 3: Dodging the issues at hand

#85

Post by ImPostingOnHN »

pverheggen wrote: post #63

While it's true that six others unequivocally opposed adoption, we don't know how many of those oppose the chairs claiming they have consensus. This may be a normal ratio to move forward with adoption, you'd have to look at past IETF proceeding to get a sense for that. One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write…

> Accusing the chairs of corruption may have influenced how seriously his complaint was taken.

If you alter your official treatment of somebody because they suggested you might be corrupt (in other words, because of personal animus), then you have just confirmed their suggestion.

Re: NSA and IETF, part 3: Dodging the issues at hand

#86

Post by johncolanduoni »

glitchc wrote: post #81
dhx wrote: post #21

Amongst the numerous reasons why you _don't_ want to rush into implementing new algorithms is even the _reference implementation_ (and most other early implementations) for Kyber/ML-KEM included multiple timing side channel vulnerabilities that allowed for key recovery.[1][2] djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor im…

This logic does not follow. Your argument seems to be "the implementation has security bugs, so let's not ratify the standard." That's not how standards work though. Ensuring an implementation is secure is part of the certification process. As long as the scheme itself is shown to be provably secure, that is sufficient to ratify a standard. If anything, standardization encourages more investment, which means more eye…

No, the argument is that the algorithm (as specified in the standard) is difficult to implement correctly, so we should tweak it/find another one. This is a property of the algorithm being specified, not just an individual implementation, and we’ve seen it play out over and over again in cryptography.

I’d actually like to see more (non-cryptographic) standards take this into account. Many web standards are so complicated and/or ill-specified that trillion dollar market cap companies have trouble implementing them correctly/consistently. Standards shouldn’t just be thrown over the wall and have any problems blamed on the implementations.

Re: NSA and IETF, part 3: Dodging the issues at hand

#87

Post by ImPostingOnHN »

blintz wrote: post #64

Standardizing a codepoint for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous. You can see him do this on the mailing list: https://mailarchive.ietf.org/arch/browse/tls/?q=djb

Sunlight is the best disinfectant. I see one group of people shining it and another shading the first group.

Someone who wants to be seen as acting in good faith (and cryptography standards folks should want this), should be addressing the substance of what he said.

Consensus doesn't mean "majority rule", it requires good-faith resolutions (read: not merely responses like 'nuh-uh') to the voiced concerns.

Re: NSA and IETF, part 3: Dodging the issues at hand

#88

Post by aw1621107 »

timschmidt wrote: post #60
UltraSane wrote: post #56

Earlier quoted context omitted.

The NSA changed the S-boxes in DES and this made people suspicious they had planted a back door but then when differential cryptanalysis was discovered people realized that the NSA changes to S-boxes made them more secure against it.

That was 50 years ago. And since then we have an NSA employee co-authoring the paper which led to Heartbleed, the backdoor in Dual EC DRBG which has been successfully exploited by adversaries, and documentation from Snowden which confirms NSA compromise of standards setting committees.

> And since then we have an NSA employee co-authoring the paper which led to Heartbleed

I'm confused as to what "the paper which led to Heartbleed" means. A paper proposing/describing the heartbeat extension? A paper proposing its implementation in OpenSSL? A paper describing the bug/exploit? Something else?

And in addition to that, is there any connection between that author and the people who actually wrote the relevant (buggy) OpenSSL code? If the people who wrote the bug were entirely unrelated to the people authoring the paper then it's not clear to me why any blame should be placed on the paper authors.

Re: NSA and IETF, part 3: Dodging the issues at hand

#89

Post by johncolanduoni »

arccy wrote: post #83
glitchc wrote: post #81

Earlier quoted context omitted.

This logic does not follow. Your argument seems to be "the implementation has security bugs, so let's not ratify the standard." That's not how standards work though. Ensuring an implementation is secure is part of the certification process. As long as the scheme itself is shown to be provably secure, that is sufficient to ratify a standard. If anything, standardization encourages more investment, which means more eye…

this is like saying just use C and don't write any memory bugs. possible, but life could be a lot better if it weren't so easy to do so.

Great, you’ve just convinced every C programmer to use a hand rolled AES implementation on their next embedded device. Only slightly joking.

Re: NSA and IETF, part 3: Dodging the issues at hand

#90

Post by gnfargbl »

dataflow wrote: post #75
blintz wrote: post #64

Standardizing a codepoint for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous. You can see him do this on the mailing list: https://mailarchive.ietf.org/arch/browse/tls/?q=djb

> standardizing a code point (literally a number) for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. I think the whole point is that some people would be forced to use it due to other standards picking previously-standardized ciphers. He explains and cites examples of this in the past. > He has essentially accused anyone who sha…

Let's invert that thinking. Imagine you're the "security area director" referenced. You know that DJB's starting point is assumed bad faith on your part, and that because of that starting point DJB appears bound in all cases to assume that you're a malicious liar.

Given that starting point, you believe that anything other than complete capitulation to DJB is going to be rejected. How are you supposed to negotiate with DJB? Should you try?

Post reply on HN