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

181–190 of 235 posts

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

#181

Post by loup-vaillant »

0xff00ffee wrote: post #150
_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.

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

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

As long as you are talking about knowledge, not artefacts. There is indeed no choice but accrete, organise, and correct knowledge over time, because anything you forget is something you might get wrong all over again.

Artefacts are different. It often makes sense to rebuild some of them from scratch, using more recent knowledge. We rarely do that, because short terms considerations usually win out (case in point: Qwerty).

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

Only if we give up any hope of improving performance, energy consumption, or die area. Right now the biggest gains can be found by removing cruft. See Vulkan for instance.

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

#183

Post by eru »

Darkphibre wrote: post #162
0xff00ffee wrote: post #150

Earlier quoted context omitted.

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

It really pisses me off when devs start ripping out asserts and tests that fail "But have been doing so for a while, so clearly they aren't needed." How about... no. Review the code and determine our undefined behavior is understood well enough that we can accept the bad inputs. Those asserts & tests were created for a reason, and need to be maintained. Not just removed because no one can spot the subtle failure mode…

Yes, though fragile tests can be a sign that simplification might benefit your system.

Sometimes it's useful to just turn flaky failures into solid failures.

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

#184

Post by janekm »

tptacek wrote: post #164
tialaramex wrote: post #161

Earlier quoted context omitted.

My guess is somebody at Microsoft responded to a customer need or claimed customer need to support specifiedCurve arguing that it was OK so long as said curve was a standard curve. I just don't see why you wouldn't stop at "PKIX forbids this, let's just not implement it" otherwise. There probably aren't any such certificates out in the Web PKI because Mozilla's rules prohibit them (and almost as important Firefox won…

Who on earth has a corporate internal CA that issues certificates signed on non-standard curves? Who would ever do that? It's not like you're just a couple parameters away from Curve25519; a serious alternative curve will always come with alternative curve code .

Curve25519 was only introduced in 2005, so it's entirely plausible that MS had a customer prior to that with the attitude "we don't trust those NSA curves, we'd rather use our own" (though whether those customers would choose to use the MS crypto library is another question...)

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

#185

Post by swarnie_ »

chance_state wrote: post #116
cafxx wrote: post #103

Earlier quoted context omitted.

> Sources say this disclosure from NSA is planned to be the first of many as part of a new initiative at NSA dubbed "Turn a New Leaf," aimed at making more of the agency's vulnerability research available to major software vendors and ultimately to the public. Sounds like "we find so many critical bugs... we don't need all of them to achieve our goals, so let's blow some of them for PR"

I think it's more like, "We find so many critical bugs, let's blow some of them for PR once we discover that adversaries are using them too."

Bull.... A more likely scenario is they've been sat on this for years and finally saw another actor using it in the wild.

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

#186

Post by LightMachine »

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 wonder if I should take those opportunities to talk about Formality (https://github.com/moonad/formality).

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

#187

Post by mirekrusin »

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…

This attack is similar in nature to some JWT implementations' bug where you could pass "no-encryption" as encryption scheme to use, effectively rendering the whole scheme open to any arbitrary payload which will pass validation; in this case you can pass arbitrary G, which effectivley allows you to generate (private key, G) pair for any public key so you can inpersonate as any identity with it, right?

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

#188

Post by pjmlp »

loup-vaillant wrote: post #181
0xff00ffee wrote: post #150

Earlier quoted context omitted.

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

> You make progress by building on top and fixing your mistakes because there literally IS NO OTHER WAY. As long as you are talking about knowledge, not artefacts. There is indeed no choice but accrete, organise, and correct knowledge over time, because anything you forget is something you might get wrong all over again. Artefacts are different. It often makes sense to rebuild some of them from scratch, using more re…

Vulkan is a good example indeed.

Most studios end up putting middleware on top of it to reduce Vulkan boilerplate to some more manageable code level, which ironically makes some Vulkan code bases run slower than OpenGL AZDO, due to misunderstandings how to do the low level work in a proper way.

Post reply on HN