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

Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

media.defense.gov

Post reply on HN
Print view View original

141–150 of 235 posts

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#141

Post by bscphil »

mleonhard wrote: post #123
_hl_ wrote: post #88

Earlier quoted context omitted.

I hope that the actual vulnerability is far more complicated. If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are), then there's not much hope of security for the rest of the industry. I'm normally not much of a pessimist but things like this really make me wish we could just burn all the things and start over.

We need one time pads. They're the only really trustworthy crypto.

Hmm. Maybe I'll generate some high quality OTPs for myself with a good CSPRNG. I could use any decent block cipher in counter mode, just need to guard against counter re-use, and then ship my OTPs off to anyone I need to communicate with.

Hang on, if I could come up with a way of securely sharing the key I used with my recipient, I wouldn't need to actually mail the OTP to them, since they could generate it themselves. Should probably include a nonce too.

Now, if only there were a secure method to share the key...

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#142

Post by derefr »

_hl_ wrote: post #88
tptacek wrote: post #48

From a conversation with Thomas Pornin, a plausible explanation given the details provided in the DoD advisory: Given an ECDSA signature and control over the curve domain parameters, it's straightforward to create a second private key that matches the original public key, without knowledge of the original signing private key. Here's how: To start with, you need to understand a little bit about how curve cryptography…

I hope that the actual vulnerability is far more complicated. If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are), then there's not much hope of security for the rest of the industry. I'm normally not much of a pessimist but things like this really make me wish we could just burn all the things and start over.

> If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are)

Personally, I'd hope most of the formal verification folks are working in firmware for industrial/medical embedded systems, and/or the microcontroller designs that go into those same systems. A lack of encryption (outside of military contexts) doesn't usually directly cause people to die.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#143

Post by saagarjha »

tptacek wrote: post #120
Havoc wrote: post #111

Earlier quoted context omitted.

I like NSA being more active, but the concept of trusting NSA on crypto is just never gonna happen. Their core mandate is being able to break it so the whole concept is a non-starter

This kind of logic is attractive on message boards but makes little sense in the real world. What NSA needs are NOBUS ("nobody but us") backdoors. Dual_EC is a NOBUS backdoor because it relies on public key encryption, using a key that presumably only NSA possesses. Any of NSA's adversaries, in Russia or Israel or China or France, would have to fundamentally break ECDLP crypto to exploit the Dual_EC backdoor themselv…

Right, but in the absence of everyone using their NOBUS-backdoored software presumably the next best thing would be to hoard zero days and hope they can work as pseudo-NOBUSes.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#144

Post by cliqueiq »

I think the scariest thing about this is if this was a PR stunt, the release of an unknown vuln could be completely controlled by whoever knew about it. Best case scenario is a relationships between Microsoft and the five eyes. It could have just as easily been China, a independent group or whatever. It's even possible that the top of Microsoft and/or NSA might not even know. But if it wasn't planned, no one would admit it anyway.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#145

Post by tptacek »

saagarjha wrote: post #143
tptacek wrote: post #120

Earlier quoted context omitted.

This kind of logic is attractive on message boards but makes little sense in the real world. What NSA needs are NOBUS ("nobody but us") backdoors. Dual_EC is a NOBUS backdoor because it relies on public key encryption, using a key that presumably only NSA possesses. Any of NSA's adversaries, in Russia or Israel or China or France, would have to fundamentally break ECDLP crypto to exploit the Dual_EC backdoor themselv…

Right, but in the absence of everyone using their NOBUS-backdoored software presumably the next best thing would be to hoard zero days and hope they can work as pseudo-NOBUSes.

That's certainly true; NSA is chartered to exploit vulnerabilities and certainly hoards them. But that doesn't address the question of whether you should trust NSA "on crypto". Here, they're the ones disclosing the crypto flaw; there's no need to "trust" them, because they're clearly right (Saleem Rashid worked out a POC for this on Slack in something like 45 minutes today).

Should you trust them about Dual_EC? Obviously not: the sketchiness of Dual_EC has been clear since its publication (the only reason people doubted it was a backdoor was that it was too obviously a backdoor; I gave them way too much credit here).

Should you trust them about the NIST P-curves? That depends on who you ask, but the NOBUS analysis is very helpful here: you have to come up with a hypothetical attack that NSA can exploit but that nobody else can discover, otherwise NSA is making China and Russia's job easier for them. Whatever else you think about NSA, the idea that they're sanguine about China is an extraordinary claim.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#147

Post by monocasa »

tptacek wrote: post #136
monocasa wrote: post #134

Earlier quoted context omitted.

My point is that the structural "NOBUS" framework the parent was trying to construct has glaring, recent counter examples, and can't really be used to holistically describe their behavior over the past couple decades. Of course I applaud responsible disclosure, and if they continue down that direction they have the possibility of rebuilding some of the trust they've broken in modern times.

You've lost me. What are the glaring counterexamples to NOBUS? The NOBUS framework says that NSA introduces vulnerabilities and backdoors only when it has some assurance that only NSA will be able to exploit them. It doesn't follow that NSA would immediately disclose any vulnerabilities they discover.

...the parent is literally talking about it in the context of today's crypt vulnerability and using that as example of their cohesive NOBUS framework.

> Clearly, no implementation flaw in Windows could qualify as a NOBUS backdoor; many thousands of people can read the underlying code in Ghidra or IDA and find the bug, once they're motivated to look for it.

The counter examples are the hordes of critical 0 days they've been sitting on, some of which have led to to a body count of five eyes citizens.

Like I said, disclosing is a step in the right direction, but they don't get a cookie for the first major disclosure in decades.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#148

Post by jpgoldberg »

derefr wrote: post #142
_hl_ wrote: post #88

Earlier quoted context omitted.

I hope that the actual vulnerability is far more complicated. If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are), then there's not much hope of security for the rest of the industry. I'm normally not much of a pessimist but things like this really make me wish we could just burn all the things and start over.

> If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are) Personally, I'd hope most of the formal verification folks are working in firmware for industrial/medical embedded systems, and/or the microcontroller designs that go into those same systems. A lack of encryption (outside of military contexts) doesn't usually directly cause people to die.

Interestingly Microsoft presented EverParse designed to produce verified parsers for these sorts of data formats at USENIX Security 2019. https://www.usenix.org/conference/usenixsecurity19/presentat...

But it's only for parsing the data. What gets down with it after parsing can still be buggy.

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#149

Post by SlowRobotAhead »

mzs wrote: post #59
SlowRobotAhead wrote: post #42

Earlier quoted context omitted.

So... Wait, they weren't calculating the signature based on ALL the contents of the cert? There was an "unprotected" section in the cert that allowed for curve details? This seems... too obviously bad.

Basically there are standard curves and software assumed parameters matched, bad design. edit: more detail https://news.ycombinator.com/item?id=22048619

Ah I see. It wasn’t that they didn’t secure parts of the cert, it’s that they assumed they didn’t need to add some data. The generator was assumed standard... and surely no one would ever abuse that intention!

Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

#150

Post by 0xff00ffee »

_hl_ wrote: post #88
tptacek wrote: post #48

From a conversation with Thomas Pornin, a plausible explanation given the details provided in the DoD advisory: Given an ECDSA signature and control over the curve domain parameters, it's straightforward to create a second private key that matches the original public key, without knowledge of the original signing private key. Here's how: To start with, you need to understand a little bit about how curve cryptography…

I hope that the actual vulnerability is far more complicated. If we can't even get crypto libraries right (where you'd hope most of the formal verification folks are), then there's not much hope of security for the rest of the industry. I'm normally not much of a pessimist but things like this really make me wish we could just burn all the things and start over.

> just burn all the things and start over

Wrap all of this with an "IN MY OPINION"...

That would make things worse because we'd make the same mistakes again. I've been on many start over projects (Xeon Phi, for example, threw out the P4 pipeline and went back to the Pentium U/V). It doesn't work. You know what the most robust project I've worked on? The instruction decoder on Intel CPUs. The validation tests go back to the late 1980's!

You make progress by building on top and fixing your mistakes because there literally IS NO OTHER WAY.

Go read about hemoglobin, its the one of the oldest genes in the genome, used by everything that uses blood to transport oxygen, and it is a GIGANTIC gene, full of redundancies. Essentially a billion years of evolution accreted one of the most robust and useful genes in our body, and there's nothing elegant about it.

I think that's where we are headed. Large systems that bulge with heft but contain so many redundant checking code that they become statistically more robust.

Post reply on HN