Earlier quoted context omitted.
Windows 7 reached EOL today so they may leave it as is if it is affected.
According to https://portal.msrc.microsoft.com/en-US/security-guidance/ad... , it doesn't look like windows 8.1 received a patch either, and that's still in support. Maybe only windows 10 has ECC support, and therefore any previous versions are not affected? Also, according to https://support.microsoft.com/help/4534310 , it looks like Windows 7 got security patches for this month.
Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
191–200 of 235 posts
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#192Nothing 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?!
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#193Earlier quoted context omitted.
This stuff often looks simpler and less subtle in hindsight. Modern cryptography has gotten better at taking human (developer) error into account for designing secure API’s, but the fact of the matter is that the math is subtle, and cryptography in general is subtle due to the places where it collides with reality, so burning everything down and starting over is likely to just cause us to rediscover issues we already…
> cryptographic agility seems to cause more issues than the problems it solves, Is that so? The ability to shift to new hash functions and ciphers within the bounds of a single protocol seems to have accelerated the adoption of better primitives.
What we need is 1 or 2 strong cipher suites and exactly zero weak ones, not 10 strong ones and 5 weak ones.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#194I'm assuming there will never be an official proof of concept release, so how long do you all think it will be before we see widely available exploit code and fake certificates out in the wild?
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#195Earlier 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…
Yep : https://www.joelonsoftware.com/2000/04/06/things-you-should-...
with the proper code comments for the hair (in the code or in the source repo) and regression tests it becomes possible to clean up and even rewrite.
floppy disks are no longer a thing and neither is windows 95. RAM & swap space are abundant, so that OOM may never happen any more IRL.
the app's whole architecture may have been carefully chosen for the hardware and simplistic compilers of another age.
is it okay never to rewrite a webpage where 50% of the codebase is IE6 hacks?
if it is code that must be maintained, then at some point the hair may need to be shaved; it simply cannot grow forever as the world moves on around it. the doma of "never rewrite" is silly without further context.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#196Earlier quoted context omitted.
> 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.
Vulkan tries to remove the "bloat" of the driver by moving it into the engine (or the middleware the engine uses), which, yes, reimplements a pretty sizable chunk of what the driver used to do.
But it exposes the API in a way that requires domain-specific knowledge of how modern GPUs work, which requires, frankly, smarter engine developers. They need to stop only thinking in the ways OGL/D3D taught them to think, and need to also think like a driver developer, or possibly even a compiler developer.
OpenGL was written wrong because no one knew what modern GPUs would eventually look like, and tried to solve the problem at the wrong layer; and fixed function hardware worked pretty much the way OpenGL worked in the beginning, not realizing stuff would eventually become, basically, absolutely massive highly parallel DSP-esque math coprocessors that are more complex than the system that hosts it. OpenGL became a mess because they kept bolting newer styles of hardware onto it (VBOs/IBOs/VAOs, the eventual move to unified buffers, compute shaders, fixed function geometry then non-fixed function geometry shaders, ubershaders and the move from direct to deferred back to direct, etc)
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#197It's obvious they're only now making it public and taking credit for it because the Chinese likely learned about it, too.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#198Earlier quoted context omitted.
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.
Vulkan is both a good and bad example. Vulkan tries to remove the "bloat" of the driver by moving it into the engine (or the middleware the engine uses), which, yes, reimplements a pretty sizable chunk of what the driver used to do. But it exposes the API in a way that requires domain-specific knowledge of how modern GPUs work, which requires, frankly, smarter engine developers. They need to stop only thinking in the…
Which is exactly the opposite than anyone that wants to draw something wants to think about.
Also Vulkan is on its merry path to have endless list of extensions, so it will eventually match OpenGL's complexity about what code paths to take, with the required cleverness of having to be a graphics programmer, driver developer and compiler developer at the same time.
No wonder anyone that wants to stay sane rather picks up a middleware engine instead.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#199Earlier 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 .
As a crypto/ security person your instinct is to say "No" because if something is more complicated but adds no apparent benefit that's a problem. That's why PKIX says "No" here, and it's why Mozilla policy says "No" here. But for a Microsoft sales person trying to land a large deal before the quarter ends the instinctive answer is "Yes" unless one of the technical people can explain why it's inherently unsafe.
This is how Microsoft ends up supporting six different bad ways to do something in Windows - not because they're lousy engineers but because they are willing to do what it takes to make the sale. Of course specifically in security arguably that does make them lousy engineers.
The worst part about such requirements is that they can often turn out to be bogus. One technical person pastes in a description of NIST's P-256 with all the curve details and a game of telephone results in the idea that they want to use specifiedCurve when actually they'll use a named curve because duh, of course they will. But if nobody says "No" the specifiedCurve feature gets backed into a requirements document and actioned.
I have had non-security "requirements" that I pushed back on and six transatlantic conference calls later I'm talking to the person who supposedly "had" the requirement and they go "I have no idea how this got made into a requirement, we don't need this at all" and a bunch of work vanishes instantly. But I do that sort of thing because I'm stubborn, it might well be easier and faster (and more profitable) to just fulfil the unnecessary requirement.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#200Earlier quoted context omitted.
Vulkan is both a good and bad example. Vulkan tries to remove the "bloat" of the driver by moving it into the engine (or the middleware the engine uses), which, yes, reimplements a pretty sizable chunk of what the driver used to do. But it exposes the API in a way that requires domain-specific knowledge of how modern GPUs work, which requires, frankly, smarter engine developers. They need to stop only thinking in the…
> They need to stop only thinking in the ways OGL/D3D taught them to think, and need to also think like a driver developer, or possibly even a compiler developer. Which is exactly the opposite than anyone that wants to draw something wants to think about. Also Vulkan is on its merry path to have endless list of extensions, so it will eventually match OpenGL's complexity about what code paths to take, with the require…
This is a case of working as designed. The people trying to directly use Vulkan in their games without any middleware layer are just generally wrong here.
Regarding extensions, this is just what happens when you specify something that keeps evolving - there’s no getting around this. What you can do to minimise the complexity is decide to require certain extensions once they’ve been around for long enough. That’s what everyone does.