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

141–150 of 249 posts

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

#141

Post by impossiblefork »

anonym29 wrote: post #34
kiray wrote: post #29

[flagged]

Name calling, bullying (forms of systematic harassment) and attempting to instill feelings of social isolation in a target are documented techniques employed by intelligence agencies in both online and offline discourse manipulation / information warfare. You can read up more here if you are curious: https://www.statewatch.org/media/documents/news/2015/jun/beh... Many of the attacks against djb line up quite nicely w…

Very nice document, I have to say. I was surprised that they care so much about hacktivists.

Are the strategies you mention actually in the document? It seems like one particularly focused on very soft tactics.

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

#142

Post by dwaite »

jancsika wrote: post #52

Dear some seasoned cryptographer, Please ELI5: what is the argument for including the option for the non-hybrid option in this standard? Is it a good argument in your expert opinion? My pea brain: implementers plus options equals bad, newfangled minus entrenched equals bad, alice only trust option 1 but bob only have option 2 = my pea brain hurt!

More of a person with IETF participation experience than as a cryptographer (I enjoy watching numbers dance but am not a choreographer):

This ( https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ ) is a document describing how to use the ML-KEM algorithm with TLS 1.3 in an interoperable manner.

It does not preclude other post-quantum algorithms from being described for use with TLS 1.3. It also does not preclude hybrid approaches from being used with TLS 1.3.

It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents.

There is no MTI (mandatory-to-implement) once these are documented from the IETF directly, but there could be market and regulatory pressures.

My suspicion is that this is bleed-out from a larger (and uglier) fight in the sister organization, the IRTF. There, the crypto forum research group (CFRG) has been having discussions on KEMs which have gotten significantly more heated.

A person with concern that there may be weaknesses in a post quantum technique may want a hybrid option to provide additional security. They may then be concerned that standardization of non-hybrid options would discourage hybrid usage, where hybrid is not yet standardized and would likely be standardized later (or not at all).

The pressure now with post quantum is to create key negotiation algorithms are not vulnerable to theoretical post quantum computer attack. This is because of the risk of potentially valuable encrypted traffic being logged now in the hopes that it could later be targeted by a post-quantum computer.

Non-negotiated encrypted (e.g. just using a static AES key) is already safe, and signature algorithms can be updated much closer to viable attacks to protect transactional data.

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

#143

Post by zahllos »

adgjlsfhk1 wrote: post #140
blintz wrote: post #131

Earlier quoted context omitted.

There was lots of public scrutiny of Kyber (ML-KEM); DJB made his own submission to the NIST PQC standardization process. A purposely introduced backdoor in Kyber makes absolutely no sense; it was submitted by 11 respected cryptographers, and analyzed by hundreds of people over the course of standardization. I disagree that ML-KEM is "obviously weaker". In some ways, lattice-based cryptography has stronger hardness f…

I don't think anyone is arguing that Kyber is purposefully backdoored. They are arguing that it (and basically every other lattice based method) has lost a minimum of ~50-100 bits of security in the past decade (and half of the stage 1 algorithms were broken entirely). The reason I can only give ~50-100 bits as the amount Kyber has lost is because attacks are progressing fast enough, and analysis of attacks is compli…

Source for this loss of security? I'm aware of the MATZOV work but you make it sound like there's a continuous and steady improvement in attacks and that is not my impression.

Lots of algorithms were broken, but so what? Things like Rainbow and SIKE are not at all based on the hardness of solving lattice problems.

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

#144

Post by dwattttt »

dataflow wrote: post #121
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…

> So there's a controversial feature added in C2y, named loops, that has spawned many a vociferous argument. (...it) is just a popularity contest Thankfully cryptography design isn't programming language design, what we have here neither is nor should be a debate or contest over popularity, and the costs of being wrong are enormously different between the two, so you can just sleep easy knowing that your experience d…

I marvel at your ability to consider cryptographers as inhuman machines, despite evidence to the contrary.

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

#145

Post by vitus »

stavros wrote: post #66
abhv wrote: post #14

20+2 (conditional support) versus 7. 22/29 = 76% in some form of "yea" That feels like "rough consensus"

> 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 general sense of agreement.) Consensus
   can be determined by a show of hands, humming, or any other means on
   which the WG agrees (by rough consensus, of course).  Note that 51%
   of the working group does not qualify as "rough consensus" and 99% is
   better than rough.  It is up to the Chair to determine if rough
   consensus has been reached.
The goal has never been 100%, but it is not enough to merely have a majority opinion.

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

#146

Post by ekr____ »

dwaite wrote: post #142
jancsika wrote: post #52

Dear some seasoned cryptographer, Please ELI5: what is the argument for including the option for the non-hybrid option in this standard? Is it a good argument in your expert opinion? My pea brain: implementers plus options equals bad, newfangled minus entrenched equals bad, alice only trust option 1 but bob only have option 2 = my pea brain hurt!

More of a person with IETF participation experience than as a cryptographer (I enjoy watching numbers dance but am not a choreographer): This ( https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ ) is a document describing how to use the ML-KEM algorithm with TLS 1.3 in an interoperable manner. It does not preclude other post-quantum algorithms from being described for use with TLS 1.3. It also does not preclude h…

> It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents.

FYI, the specification for hybrid MLKEM + ECC is ahead of this document in the publication process. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/

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

#147

Post by rvba »

johncolanduoni wrote: post #89
arccy wrote: post #83

Earlier quoted context omitted.

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.

If the standard had clear algorhitm -> source code, thrn couldnt everyone copy from there though?

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

#148

Post by supernetworks_ »

tptacek wrote: post #125
supernetworks_ wrote: post #39

Earlier quoted context omitted.

It would be wise for people to remember that it’s worth doing basic sanity checks before making claims like no backdoors from the NSA. strong encryption has been restricted historically so we had things like DES and 3DES and Crypto AG. In the modern internet age juniper has a bad time with this one https://www.wired.com/2013/09/nsa-backdoor/ . Usually it’s really hard to distinguish intent, and so it’s possible to de…

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 why the NSA advised migration that early.

The riddle paper I’ve not read in a long time if ever, though I don’t understand the question. As Scott Aaronson recently blogged it’s difficult to predict human progress with technology and it’s possible we’ll see shors algorithm running publicly sooner than consensus. It could be that in 2035 the NSA’s call 20 years prior looks like it was the right one in that ECC is insecure but that wouldn’t make the replacements secure by default ofc

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

#149

Post by f33d5173 »

yardstick wrote: post #129
f33d5173 wrote: post #50

Earlier quoted context omitted.

A consensus is 100%. A rough consensus should be near 100%. 2/3 is a super majority. That's a very different standard.

See https://news.ycombinator.com/item?id=46035639 A consensus isn’t always 100%

A consensus is by definition 100%. You can redefine the word in a specialist context, but that is what the word means.

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

#150

Post by thomasdeleeuw »

France and Germany propose hybrid schemes as well:

The german position:

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...

"The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism."

The french position, also quoting the German position:

https://cyber.gouv.fr/sites/default/files/document/follow_up...

"As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybridation1 wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"

Post reply on HN