Live data from Hacker News

Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]

media.defense.gov

221–230 of 235 posts

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

#221
post #220
post #209

Earlier quoted context omitted.

Try pasting your cert into https://lapo.it/asn1js/ You can see all the parts in the blob: OBJECT IDENTIFIER 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type) SEQUENCE (6 elem) INTEGER 1 SEQUENCE (2 elem) OBJECT IDENTIFIER 1.2.840.10045.1.1 prime-field (ANSI X9.62 field type) INTEGER (256 bit) 1157920892373161954235709850086879078532699846656405640394575840079088… SEQUENCE (2 elem) OCTET STRING (32 byte) 0000…

The parent comment is wondering about the structure of the signature and if different curve parameters can be specified for it. How can explicit curve parameters be specified in an ECDSA signature? ecdsaWithSHA256, at least, is simply two bigints. There's no spot for specifying explicit parameters.

This is answered upthread and in RFC 5480: the AlgorithmIdentifier has an ANY OPTIONAL field for parameters.

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

#222
post #220

Earlier quoted context omitted.

The parent comment is wondering about the structure of the signature and if different curve parameters can be specified for it. How can explicit curve parameters be specified in an ECDSA signature? ecdsaWithSHA256, at least, is simply two bigints. There's no spot for specifying explicit parameters.

This is answered upthread and in RFC 5480: the AlgorithmIdentifier has an ANY OPTIONAL field for parameters.

Missed that. Thank you!

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

#223
post #70
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…

The important part might be just how hard it is to come-up with G'.

Here is a sage script that implements the described attack. I have scripts that implement curve parameters separately (so I can load them into other scripts as needed) so this might look a little redundant in places:

    #!/usr/bin/env sage

    nistp256r1_order = 0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551
    nistp256r1_modulus = 2**224 * (2**32 - 1) + 2**192 + 2**96 - 1
    nistp256r1_a = 0xFFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC
    nistp256r1_b = 0x5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B

    nistp256r1_field = GF(nistp256r1_modulus)
    nistp256r1 = EllipticCurve(nistp256r1_field, [0,0,0,nistp256r1_a,nistp256r1_b])

    nistp256r1_base_x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
    nistp256r1_base_y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
    nistp256r1_gen = nistp256r1(nistp256r1_base_x, nistp256r1_base_y, 1)

    curve = nistp256r1
    curve_order = nistp256r1_order
    curve_gen = nistp256r1_gen

    CG = Zmod(curve_order)

    ### these are "inputs" to the system. Only pubkey is known to an attacker
    privkey = CG.random_element()
    Q = curve(ZZ(privkey) * curve_gen)

    ### The attacker generates the necessary malicious generator
    
    kprime = CG.random_element()
    kprimeinv = kprime.inverse_of_unit() 

    Gprime = ZZ(kprimeinv) * Q

    ### We can now verify that the attacker knows a private key corresponding
    ### to the public key under their generator

    Qprime = curve(ZZ(kprime) * Gprime)
    print("Q==Q'", Qprime == Q)
    print(Qprime.xy())
    print(Q.xy())

    ### So if the attacker believes Gprime is a correct generator,
    ### this is bad news.
    ### you can implement something relying on it, with Gprime as your generator, here.
This is using real secp256r1, i.e. NIST P256, parameters. You can try this in sagemath's online tools and see that it works very efficiently. inverse_of_unit is a nice function that computes the inverse of kprime in the multiplicative group modulo the prime order of the curve. You can do exactly the same thing with the XGCD algorithm from sage.arith.misc. ZZ is required simply for type conversion: sage doesn't understand how to multiply a point by a Zmod element. We help it out by converting to an integer. .xy() is not required, it simply prints affine, instead of projective, coordinates. I wrote this with sage 9, which is based on python 3. The 0,0,0 are not necessary for the elliptic curve constructor (two parameters = short weierstrass) but I'm in the habit...

As a corollary to Lagrange's theorem, any prime order group is cyclic, which means any randomly chosen point is a generator and since the group of curve points under elliptic curve point addition is of prime order, any randomly chosen point on the curve necessarily generates the whole group. However, we need to choose a random secret key to relate the old generator to the new, because solving G' = k'Q is a discrete logarithm problem and we can't solve those.

P256 is obviously quite difficult for humans to deal with in their minds, so if you want to play with a more human-sized curve, try:

    E=EllipticCurve(GF(17),[3,5])
which is of prime order and has 23 points (and so cofactor 1 like P256).

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

#224
post #66

Earlier quoted context omitted.

> connections to the npm package server Doesn't npm use node.js for this, which uses openssl? > https://nodejs.org/api/tls.html#tls_tls_ssl Third party tools connecting to the npm server that use Window's TLS library would absolutely be affected though.

I suspect the answer is "it's complicated". For example, you can specify a package version string as `git://...` and it will grab the package from a git repository. It's possible that this uses a JS-native Git implementation, but it's also possible that it uses a locally-installed Git binary, which could in turn use MSCAPI, especially if it's configured to use an external SSH provider.

That's a good point. I'm not too familiar with npm code but it seems that they are indeed using git from the CLI instead using it via a library: https://github.com/npm/cli/blob/ba7f1466436cc22e27f8a14dede3...

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

#225
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.

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

> Go read about hemoglobin, its the one of the oldest genes in the genome, [..]

What do you mean with hemoglobin as a gene?

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

#226
post #213

Earlier quoted context omitted.

So 10 years from now those that don't want to be a mix of graphical developer, driver author and compiler designers, have to keep using a frozen API from 2018, without any access to whatever has changed on their computers during the next decade. All because providing something like MetalKit or DirectXTK is too much to ask for to Khronos and LunarG.

But should it change? There are issues where updating OpenGL support in drivers broke earlier apps due to accidental changes in how existing features were implemented. Vulkan and DX12 are far less likely to break existing apps i the future due to far fewer core features. It makes no sense to have what is essentially an entire legacy middleware in the driver when it no longer represents modern hardware. Unlike GLES, O…

> Vulkan and DX12 are far less likely to break existing apps i the future due to far fewer core features.

This is questionable. Vulkan by definition has basically no error checking in the driver, and while developers are supposed to use the validation layer, they may not do so, and even if they do, there are certain plenty of incorrect things an application can do that won't be caught by validation.

Incorrect programs may still happen to run correctly on existing drivers, but then fail with a driver update that happens to change the undefined behavior.

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

#228

Earlier quoted context omitted.

But should it change? There are issues where updating OpenGL support in drivers broke earlier apps due to accidental changes in how existing features were implemented. Vulkan and DX12 are far less likely to break existing apps i the future due to far fewer core features. It makes no sense to have what is essentially an entire legacy middleware in the driver when it no longer represents modern hardware. Unlike GLES, O…

> Vulkan and DX12 are far less likely to break existing apps i the future due to far fewer core features. This is questionable. Vulkan by definition has basically no error checking in the driver, and while developers are supposed to use the validation layer, they may not do so, and even if they do, there are certain plenty of incorrect things an application can do that won't be caught by validation. Incorrect program…

C compiler writers have answered that conundrum a long time ago: "if you (even accidentally) rely on undefined behaviour, the warranty is void".

I don't necessarily agree, but if we have a way to avoid undefined behaviour (and at least in C there are ways to make pretty thorough checks), then it works in practice.

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

#229

Earlier quoted context omitted.

> Vulkan and DX12 are far less likely to break existing apps i the future due to far fewer core features. This is questionable. Vulkan by definition has basically no error checking in the driver, and while developers are supposed to use the validation layer, they may not do so, and even if they do, there are certain plenty of incorrect things an application can do that won't be caught by validation. Incorrect program…

C compiler writers have answered that conundrum a long time ago: "if you (even accidentally) rely on undefined behaviour, the warranty is void". I don't necessarily agree, but if we have a way to avoid undefined behaviour (and at least in C there are ways to make pretty thorough checks), then it works in practice.

The checks that according to most surveys and security reports are used by a tiny part of the C community?

If it doesn't work for C regarding mainstream adoption, how come it will work for Vulkan?

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

#230
post #175
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 this explains the math and crypto part, but how does that tie into X.509 and certificates? From what I understand we can put custom parameters into a certificate, but the parameters come with the key, not the signature. So we have CA cert + key A + parameters A signs My cert + key B + parameters B + forged signature from A Now we can only mount this attack if we can somehow control a part of the parameters (the ba…

AIUI it's a root cert trust issue. You supply your own self-signed root cert, which obviously lets you specify your own parameters and build a fully valid chain of trust. Then the bug is that the library considers the root cert trusted if its public key hash and serial match that of a cert in the root trust store, even if the curve parameters don't.
Post reply on HN