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

91–100 of 249 posts

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

#91

Post by timschmidt »

aw1621107 wrote: post #88
timschmidt wrote: post #60

Earlier quoted context omitted.

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

> 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 authors.

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

#92

Post by jcranmer »

crote wrote: post #73
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…

Standards - especially security-critical ones - shouldn't be a simple popularity contest. DJB provided lengthy, well-reasoned, and well-sourced arguments against adoption with his "nay" vote. The "aye" votes didn't make a meaningful counter-argument - in most cases they didn't even bother to make any argument at all and merely expressed support. This means there are clearly unresolved technical issues left - and not…

So there's a controversial feature added in C2y, named loops, that has spawned many a vociferous argument. Now, I'm a passionate supporter of this feature, for various reasons, that I can (and have, in the committee) brought up. And I know some people who are against this feature, for various reasons that have been brought up. And at the end of the day, it kind of is a popularity contest because weighing an argument of "based on my experience, this is going to be confusing for users" versus "based on my experience, this is not going to be confusing for users" is just a popularity contest among the voters on the committee, admittedly weighted by how much you trust the various people.

And then there's a third category of person (really, just one person I think, though). This is responsible for the vast majority of the email traffic on the topic. They're always ready with a detailed point-by-point reply of any replies to their posts. And their argument is... um... they don't like the feature. And they so don't like the feature that they're hanging on to any scintilla of a process argument to make their displeasure derail the entire feature, without really being able to convince anybody else of their dislike (or being able to be convinced to change their mind to any argument).

Now I don't have the cryptographic chops to evaluate DJB's arguments myself. But I also haven't seen any support for his arguments from people I'd trust to be able to evaluate them. And the way he's responding at this point reminds me very much of that third category of people, which is adversely affecting his credibility at this point.

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

#93

Post by johncolanduoni »

zahllos wrote: post #62
MYEUHD wrote: post #54

Earlier quoted context omitted.

> the more recent funny elliptic curve Can you elaborate please?

The commentor means Dual_EC, a random number generator. The backdoor was patented under the form of "escrow" here: https://patents.google.com/patent/US8396213B2/en?oq=USOO83.9... - replace "escrow" with "backdoor" everywhere in the text and what was done will fall out. ML-KEM/ML-DSA were adapted into standards by NIST, but I don't think a single American was involved in the actual initial design. There might be some…

Not that I think this is the case for this algorithm, but backdoors like the one in Dual_EC cannot be used by a third party without what is effectively reversing an asymmetric key pair. Their public parameters are the product of private parameters that the NSA potentially has, but if China or whoever can calculate the private parameters from the public ones it’s broken regardless.

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

#94

Post by aw1621107 »

timschmidt wrote: post #91
aw1621107 wrote: post #88

Earlier quoted context omitted.

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

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

Ah, that clears up the confusion. Thank you for taking the time to explain!

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

#95

Post by ImPostingOnHN »

gnfargbl wrote: post #90
dataflow wrote: post #75

Earlier quoted context omitted.

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

Your response focuses entirely on the people involved, rather than the substance of the concerns raised by one party and upheld by 6 others. I don't care if 1 of the 7 parties regularly drives busloads of orphans off a cliff, if the concerns have merit, they must be addressed. The job of the director is to capitulate to truth, no matter who voices it.

Any personal insults one of the parties lobs at others can be addressed separately from the concerns. An official must perform their duties without bias, even concerning somebody who thinks them the worst person in the world, and makes it known.

tl;dr: sometimes the rude, loud, angry constituent at the town hall meeting is right

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

#96

Post by adgjlsfhk1 »

jcranmer wrote: post #92
crote wrote: post #73

Earlier quoted context omitted.

Standards - especially security-critical ones - shouldn't be a simple popularity contest. DJB provided lengthy, well-reasoned, and well-sourced arguments against adoption with his "nay" vote. The "aye" votes didn't make a meaningful counter-argument - in most cases they didn't even bother to make any argument at all and merely expressed support. This means there are clearly unresolved technical issues left - and not…

So there's a controversial feature added in C2y, named loops, that has spawned many a vociferous argument. Now, I'm a passionate supporter of this feature, for various reasons, that I can (and have, in the committee) brought up. And I know some people who are against this feature, for various reasons that have been brought up. And at the end of the day, it kind of is a popularity contest because weighing an argument…

The really big difference between named loops and cryptography is that if one gets approved and is bad, a couple new programmers get confused, while with the other, a significant chunk of the internet becomes vulnerable to hacking.

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

#97

Post by adgjlsfhk1 »

gnfargbl wrote: post #90
dataflow wrote: post #75

Earlier quoted context omitted.

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

To start with, you could not lie about what the results were.

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

#98

Post by tptacek »

timschmidt wrote: post #91
aw1621107 wrote: post #88

Earlier quoted context omitted.

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

> 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?

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

#99

Post by jcranmer »

adgjlsfhk1 wrote: post #96
jcranmer wrote: post #92

Earlier quoted context omitted.

So there's a controversial feature added in C2y, named loops, that has spawned many a vociferous argument. Now, I'm a passionate supporter of this feature, for various reasons, that I can (and have, in the committee) brought up. And I know some people who are against this feature, for various reasons that have been brought up. And at the end of the day, it kind of is a popularity contest because weighing an argument…

The really big difference between named loops and cryptography is that if one gets approved and is bad, a couple new programmers get confused, while with the other, a significant chunk of the internet becomes vulnerable to hacking.

Just because a feature is standardized does not mean it gets implemented. This is actually even more true for cryptography than it is for programming language specifications.

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

#100

Post by zahllos »

johncolanduoni wrote: post #93
zahllos wrote: post #62

Earlier quoted context omitted.

The commentor means Dual_EC, a random number generator. The backdoor was patented under the form of "escrow" here: https://patents.google.com/patent/US8396213B2/en?oq=USOO83.9... - replace "escrow" with "backdoor" everywhere in the text and what was done will fall out. ML-KEM/ML-DSA were adapted into standards by NIST, but I don't think a single American was involved in the actual initial design. There might be some…

Not that I think this is the case for this algorithm, but backdoors like the one in Dual_EC cannot be used by a third party without what is effectively reversing an asymmetric key pair. Their public parameters are the product of private parameters that the NSA potentially has, but if China or whoever can calculate the private parameters from the public ones it’s broken regardless.

Indeed. Dual_EC was a NOBUS backdoor relying on the ECDLP. That's fair.

My point was more that it looked suspicious at the time (why use a trapdoor in a CSPRNG) and at least the possibility of "escrow" was known, as evidenced by the fact that Vanstone (one of the inventors of elliptic curve cryptography) patented said backdoor around 2006.

This suspiciousness simply doesn't apply to ML-KEM, if one ignores one very specific cryptographer.

Post reply on HN