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

121–130 of 235 posts

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

#121

Post by bepvte »

macinjosh wrote: post #63
age_bronze wrote: post #12

Nothing screams "we have microsoft keys!" harder than the fact that the only vulnerabilities reported by the NSA is a cryptographic validation bug. If I had to guess exactly what kind of vulnerabilities they do not need, this is exactly those kind. Who needs crypto validation bug when you already own microsoft's keys?!

I think you're spot on. Everything agencies at this level do is calculated and weighed carefully. They definitely would not seek to patch a useful vuln. It is a PR stunt.

Its patched because of the risk it poses to the government and from other state actors

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

#122

Post by CiPHPerCoder »

Herrera wrote: post #97
tptacek wrote: post #92

Earlier quoted context omitted.

There's a history of vulnerabilities like these, in some of the most important crypto libraries. For instance: until 2008, NSS, the TLS library used by Firefox, couldn't properly validate RSA signatures from e=3 RSA keys (it wasn't validating the full signature block, but rather parsing it and looking for the embedded hash). For e=3 roots, which were readily available at the time, you could simply build any signature…

Bleichenbacher'06 never dies.

Neither does BB'98

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

#123

Post by mleonhard »

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

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

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

#124

Post by monocasa »

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…

I mean, the 0 days in the shadowbroker dumps wouldn't count as "NOBUS" backdoors either, but the NSA was sitting on those like a dragon hording gold.

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

#125

Post by an_account_name »

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…

So the mitigation would be to add a check that the generator point in (for example) a CertificateVerify message is the one in the p256 spec (or otherwise the one on the cert, I’m not deep enough to know where it usually lives)?

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

#127

Post by baby »

loup-vaillant wrote: post #117
_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 Signature verification is one of the hardest things to get right. One reason is, they're harder to test: when you encrypt or hash something, you have a whole bunch of bits you can check against test vectors. With signature verifications, you only have one bit: it's a match, or it's a fail. Moreover, it's very easy to forget to check something (here, that we are using the…

That’s an interesting assessment. Rogaway just gave a talk at RWC about APIs for secret splitting schemes. IIRC he said that the API needed to be closer to what symmetric crypto was. But from the diagram it seemed like you were obtaining some associated data back to check that the secret was correct (not sure if this would work/is relevant with more recent DKG schemes).

A signature verification returning an actual AD would be interesting as well.

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

#128

Post by tptacek »

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.

By all means: make yourself some one-time pads. Maybe you can convince Google to accept one from you at a dead drop somewhere in Mountain View.

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

#129

Post by tptacek »

monocasa wrote: post #124
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…

I mean, the 0 days in the shadowbroker dumps wouldn't count as "NOBUS" backdoors either, but the NSA was sitting on those like a dragon hording gold.

Those aren't vulnerabilities NSA created, unlike Dual_EC, which is.

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

#130

Post by wahern »

an_account_name wrote: post #125
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…

So the mitigation would be to add a check that the generator point in (for example) a CertificateVerify message is the one in the p256 spec (or otherwise the one on the cert, I’m not deep enough to know where it usually lives)?

In practice this means rejecting the "specifiedCurve" choice in ASN.1 ECParameters. ASN.1-based protocols are the only ones I'm aware of that permit specifying an arbitrary curve. For the PKIX ASN.1 standard(s) old-style EC public keys are specified with an ECParameters field:

  ECParameters ::= CHOICE {
    namedCurve      OBJECT IDENTIFIER
    implicitCurve   NULL
    specifiedCurve  SpecifiedECDomain
  }
PKIX, which is what TLS and most other standards use for ASN.1 message grammars, already mandates that "implicitCurve and specifiedCurve MUST NOT be used". See https://tools.ietf.org/html/rfc5480#section-2.1.1 (There are many other related RFCs. It gets very confusing, especially once you take into account obsolete and draft RFCs.)

Newer curves, like EdDSA curves, are always each specified with unique OIDs and have a simpler public key grammar. See https://tools.ietf.org/html/rfc8410 Older public curves share an OID and a more generic ("flexible") syntax, thus the ECParameters field. (RSA public keys also have a parameters field, but it's unused. However, annoyingly, some implementations omit the field altogether, others set a NULL value.)

Post reply on HN