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

151–160 of 249 posts

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

#151

Post by tptacek »

supernetworks_ wrote: post #148
tptacek wrote: post #125

Earlier quoted context omitted.

It's "Dragonblood", not "Dragonbleed". I don't like Harkin's PAKE either, but I'm not sure what fundamental attribute of it enables the downgrade attack you're talking about. When you're talking about the P-curves, I'm curious how you get your "sanity check" argument past things like the Koblitz/Menezes "Riddle Wrapped In An Enigma" paper. What part of their arguments did you not find persuasive?

yes dragon blood. I’m not speaking of the downgrade but the timing sidechannels — which were called out very loudly and then ignored during standardization. and then the PAKE showed up in wpa3 of all places, that was the key issue and was extended further in a brain pool curve specific attack for the proposed initial mitigation. It’s a good example of error by committee I do not address that article and don’t know wh…

Aren't the timing attacks you're talking about specific to oddball parameters for the handshake? If you're doing Dragonfly with Brainpool curves you're specifically not doing what NSA wants you to do. Brainpool curves are literally a rejection of NIST's curves.

If you haven't read the Enigma paper, you should do so before confidently stating that nobody's done "sanity checks" on the P-curves. Its authors are approximately as authoritative on the subject as Aaronson is on his. I am specifically not talking about the question of NSA's recommendation on ECC vs. PQ; I'm talking about the integrity of the P-curve selection, in particular. You need to read the paper to see the argument I'm making; it's not in the abstract.

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

#152

Post by temoiu3 »

tptacek wrote: post #118
timschmidt wrote: post #117

Earlier quoted context omitted.

> What part of the paper you're describing instructed implementers of the TLS Heartbeat extension to copy data into an uninitialized buffer and then transmit it on the wire? That's a very easy question to answer: the implementation the authors provided alongside it. If you expect authors of exploits to clearly explain them to you, you are not just ignorant of the details of backdoors like the one in XZ (CMake was nev…

Which "paper" are you referring to?

Think the above poster is full of bologna? It's less painful for everyone involved, and the readers, to just say that and get that out of the way rather than trying to surgically draw it out over half a dozen comments. I see you do this often enough that I think you must get some pleasure out of making people squirm. We know you're smart already!

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

#153

Post by [deleted] »

tptacek wrote: post #151
supernetworks_ wrote: post #148

Earlier quoted context omitted.

yes dragon blood. I’m not speaking of the downgrade but the timing sidechannels — which were called out very loudly and then ignored during standardization. and then the PAKE showed up in wpa3 of all places, that was the key issue and was extended further in a brain pool curve specific attack for the proposed initial mitigation. It’s a good example of error by committee I do not address that article and don’t know wh…

Aren't the timing attacks you're talking about specific to oddball parameters for the handshake? If you're doing Dragonfly with Brainpool curves you're specifically not doing what NSA wants you to do. Brainpool curves are literally a rejection of NIST's curves. If you haven't read the Enigma paper, you should do so before confidently stating that nobody's done "sanity checks" on the P-curves. Its authors are approxim…

[deleted]

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

#154

Post by pjz »

qi_reaper wrote: post #108

I understand you are smart and are talking about things above my paygrade, but dang can you format the text on your site so it is easier to read please

uhhh... that's mostly on your browser. The css is at the top and pretty skimpy. If it really bothers you, find a styler extension that will override the CSS to render it more pleasingly.

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

#156

Post by smaudet »

tptacek wrote: post #123
johncolanduoni wrote: post #111

Earlier quoted context omitted.

DJB has specific (technical and non-conspiratorial) bones to pick with the algorithm. He’s as much an expert in cryptographic implementation flaws and misuse resistance as anybody at NIST. Doesn’t mean he’s right all the time, but blowing him off as if he’s just some crackpot isn’t even correctly appealing to authority. I hate that his more tinfoil hat stuff (which is not totally unjustified, mind you) overshadows hi…

There are like 3 cryptographers in all of NIST. NIST was a referee in the process. The bones he's picking are with the entire field of cryptography, not just NIST people.

> The bones he's picking are with the entire field of cryptography

Isn't that how you advance a field, though?

It has been a couple hundred years, but we used to think that disease was primarily caused by "bad humors".

Fields can and do advance. I'm not versed enough to say whether his criticisms are legitimate, but this doesn't sound like a problem, but part of the process, to me (and his article is documenting how some bureaucrats/illegitimate interests are blocking that advancement).

The "area adminstrator" being unable or unwilling to do basic math is both worrying, and undermines the idea that the standards that are being produced are worth anything, which is bad for the entire field.

If the standards are chock full of nonsense, then how does that reflect upon the field?

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

#157

Post by mpyne »

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…

Given the emphasis on reliability of implementations of an algorith, it's ironic that the Curve 25519-based Ed25519 digital signature standard was itself specified and originally implemented in such a way as to lead to implementation divergence on what a valid and invalid signature actually was. See https://hdevalence.ca/blog/2020-10-04-its-25519am/

Not a criticism, if anything it reinforces DJB's point. But it makes clear that ease of (proper) implementation also needs to cover things like proper canonicalization of relevant security variables and that supporting multiple modes of operation doesn't actually lead to different answers of security questions meant to give the same answer.

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

#158

Post by ImPostingOnHN »

dwaite wrote: post #136
ImPostingOnHN wrote: post #84

Earlier quoted context omitted.

consensus is not a synonym for majority , supermajority , or for any fraction of the whole, unless the fraction is 100%

You may misunderstand how the IETF works. Participation is open. This means that it is possible that people who want the work to fail for their own reasons rather than technical merit can join and attempt to sabotage work. So consensus by your definition is rarely possible given the structure of the organization itself. This is why there are rough consensus rules, and why there are processes to proceed with dissent.…

> the work in question is a document describing how to apply ML-KEM to TLS in an interoperable way. It is not a discussion of whether ML-KEM is a potentially risky algorithm.

In my experience, the average person treats a standard as an acceptable way of doing things. If ML-KEM is a bad thing to do in general, then there should not be a standard for it (because of the aforementioned treatment by the average person).

> It is clear here that they _are_ attempting to prevent a description of how to use ML-KEM with TLS 1.3 from being published.

It's unclear why trying to prevent a bad practice from being standardized is a bad thing. But wait, how do we know whether it's a good or bad practice? Well, we can examine the response to the concerns DJB raised: Whether the responses satisfactorily addressed the concerns, and whether the responses followed the rules and procedures for resolving each of those concerns.

> They regularly resort to personal attacks when they don't get their way

This is certainly unfortunate, but 6 other parties upheld the concerns. DJB is allowed to be a jerk, even allowed to be banned for abusive behavior IMO, however the concerns he initially raised must nonetheless be satisfactorily addressed, even with him banned. Banning somebody is sometimes necessary, but is not an acceptable means of suppressing valid concerns, especially when those concerns are also held by others who are not banned.

> DJB's behavior is why there are rules for how to address dissent.

The issue here seems to be that the bureaucracy might not be following those rules.

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

#159

Post by mpyne »

vitus wrote: post #145
stavros wrote: post #66

Earlier quoted context omitted.

> That OMB rule, in turn, defines "consensus" as follows: "general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after…

To add to this: rough consensus is defined in BCP 25 / RFC 2418 ( https://datatracker.ietf.org/doc/html/rfc2418#section-3.3 ): IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more ge…

And to add to that, the blurb you link notes explicitly that for IETF purposes, "rough consensus" is reached when the Chair determines is has been reached.

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

#160

Post by mpyne »

johnisgood wrote: post #46
jonstewart wrote: post #22

Earlier quoted context omitted.

Sure! First, while I’m in no position to judge cryptographic algorithms, the success of cha-cha and 25519 speak for themselves. More prosaically, patriecia/critbit trees and his other tools are the right thing, and foresighted. He’s not just smart, but also prolific. However, he’s left a wake of combative controversy his entire career, of the “crackpot” type the parent comment notes, and at some point it’d be worth h…

I do not understand your last paragraph. :/

https://medium.com/@hdevalence/when-hell-kept-on-payroll-som...
Post reply on HN