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

101–110 of 249 posts

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

#101

Post by basilgohar »

seethishat wrote: post #10

For context, djb has been doing and saying these things since he was a college student: While a graduate student at the University of California at Berkeley, Bernstein completed the development of an encryption equation (an "algorithm") he calls "Snuffle." Bernstein wishes to publish a) the algorithm (b) a mathematical paper describing and explaining the algorithm and (c) the "source code" for a computer program that…

djb has earned my massive respect for how consistent he's been in this regard. I love his belligerence towards authoritarian overreach in this regard. Him, Phil Zimmermann, Richard Stallman, and all are owed great respect for their insistence on their principles which have paid massive dividends to all of us through the freedom and software that has been preserved and become possible through them. I appreciate them immensely and I think we all owe them a debt of gratitude for their sacrifices, because they all paid a heavy price for their advocacy over time.

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

#102

Post by tptacek »

vorpalhex wrote: post #44
jcranmer wrote: post #20

Earlier quoted context omitted.

The standard used in the C and C++ committees is essentially a 2-to-1 majority in favor. I'm not aware of any committee where a 3-to-1 majority is insufficient to get an item to pass. DJB's argument that this isn't good enough would, by itself, be enough for me to route his objections to /dev/null; it's so tedious and snipey that it sours the quality of his other arguments by mere association. And overall, it gives t…

We're talking about a landmine in a crypto spec and you're bikeshedding about consensus ratios. We should talk about the NSA designed landmine.

Have you implemented MLKEM? How well do you understand it?

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

#103

Post by tptacek »

basilgohar wrote: post #101
seethishat wrote: post #10

For context, djb has been doing and saying these things since he was a college student: While a graduate student at the University of California at Berkeley, Bernstein completed the development of an encryption equation (an "algorithm") he calls "Snuffle." Bernstein wishes to publish a) the algorithm (b) a mathematical paper describing and explaining the algorithm and (c) the "source code" for a computer program that…

djb has earned my massive respect for how consistent he's been in this regard. I love his belligerence towards authoritarian overreach in this regard. Him, Phil Zimmermann, Richard Stallman, and all are owed great respect for their insistence on their principles which have paid massive dividends to all of us through the freedom and software that has been preserved and become possible through them. I appreciate them i…

That's the right pantheon, I think. Bernstein, Zimmerman, Stallman.

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

#104

Post by basilgohar »

zahllos wrote: post #74
blintz wrote: post #70

Earlier quoted context omitted.

> Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible AES and RSA are also supported by the NSA, but that doesn’t mean they were backdoored.

SHA-2 was designed by the NSA. Nobody is saying there is a backdoor.

I think it's established that NSA backdoors things. It doesn't mean they backdoor everything. But scrutiny is merited for each new thing NSA endorses and we have to wonder and ask why, and it's enough that if we can't explain why something is a certain way and not another, it's not improbable that we should be cautious of that and call it out. This is how they've operated for decades.

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

#105

Post by ants_everywhere »

seethishat wrote: post #10

For context, djb has been doing and saying these things since he was a college student: While a graduate student at the University of California at Berkeley, Bernstein completed the development of an encryption equation (an "algorithm") he calls "Snuffle." Bernstein wishes to publish a) the algorithm (b) a mathematical paper describing and explaining the algorithm and (c) the "source code" for a computer program that…

That was when he had the legal expertise of the EFF to help him make his case. Later he decided to represent himself in court and failed

> This time, he chose to represent himself, although he had no formal legal training. On October 15, 2003, almost nine years after Bernstein first brought the case, the judge dismissed it....

https://en.wikipedia.org/wiki/Bernstein_v._United_States

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

#106

Post by glitchc »

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.

Yeah except there are certified versions of AES written in C. Which makes your point what exactly?

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

#107

Post by glitchc »

johncolanduoni wrote: post #86
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…

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 complic…

> 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 argument is without merit. ML-KEM/Kyber has already been ratified as the PQC KEM standard by NIST. What you are proposing is that the NIST process was fundamentally flawed. This is a claim that requires serious evidence as backup.

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

#109

Post by timschmidt »

tptacek wrote: post #98
timschmidt wrote: post #91

Earlier quoted context omitted.

> I'm confused The original paper which proposed the OpenSSL Heartbeat extension was written by two people, one worked for NSA and one was a student at the time who went on to work for BND, the "German NSA". The paper authors also wrote the extension. I know this because when it happened, I wanted to know who was responsible for making me patch all my servers, so I dug through the OpenSSL patch stream to find the aut…

What does that paper say about implementing the TLS Heartbeat extension with a trivial uninitialized buffer bug?

About as much as Jia Tan said about implementing the XZ backdoor via an inconspicuous typo in a CMake file. What's your point?

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

#110

Post by tptacek »

timschmidt wrote: post #109
tptacek wrote: post #98

Earlier quoted context omitted.

What does that paper say about implementing the TLS Heartbeat extension with a trivial uninitialized buffer bug?

About as much as Jia Tan said about implementing the XZ backdoor via an inconspicuous typo in a CMake file. What's your point?

I'm asking what the paper has to do with the vulnerability. Can you answer that? Right now your claim basically comes down to "writing about CMake is evidence you backdoored CMake".
Post reply on HN