When will they learn that the only way to respond to a hostile government is to overthrow it?
Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
231–235 of 235 posts
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#232Earlier quoted context omitted.
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.
So... exactly what I said?
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#233Earlier quoted context omitted.
We don't need the ability to switch to new algorithms as much as we need the ability to ditch old ones. Agility in cryptography only needs to mean the ability to deprecate what's broken. We're still going to see newer and more robust algorithms implemented in new software and protocol versions anyway. What we need is 1 or 2 strong cipher suites and exactly zero weak ones, not 10 strong ones and 5 weak ones.
How is that not cryptographic agility? Which cipher suites to support is a question separate from whether the cryptography should be runtime configurable at all.
One should version whole protocols instead of adding option negotiation for things like cipher suite.
So say: TLS 1.4 = “NIST version” only supports ECDHE(P-256)+AES-256-GCM+SHA256 TLS 1.5 = “Bernstein Version” only supports ECDHE(X25519)+ChaCha20-Poly1305+Blake2b
Because of the X.509 legacy both these future TLS might have to support RSA-2048 and P-256 ECC certs, but supporting just one would be better.
In either case fewer options and branches is simpler and more secure. Both can be enabled, one turned off if a weakness is found.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#234Earlier quoted context omitted.
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?
It won't, unless only a fairly small elite ends up using Vulkan. And I believe that's what will happen indeed: Vulkan is low level enough that most likely, only engine devs and middleware devs will touch it.
You will of course have the occasional cowboy (which I personally am, though in a different domain), but that shouldn't matter that much in the grand scheme of things.
Now if you ask me, Vulkan is not enough. What we really want is a stable, usable hardware interface. Basically an ISA. The thing will have close to zero bug, because hardware folks know how to properly test their designs. Undefined behaviour is likely unavoidable, but I believe it can be reduced to a reasonable minimum.
If AMD and NVidia started something like RISC-V, except for graphics cards, it will likely have a greater impact than RISC-V itself.
Re: Patch Critical Cryptographic Vulnerability in Microsoft Windows [pdf]
#235Earlier quoted context omitted.
Yep : https://www.joelonsoftware.com/2000/04/06/things-you-should-...
> That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95. 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 c…
>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.
"Shaving" seems more close to refactoring & partial rewrite than starting from scratch. Which is what we are talking about.
Still, You make good points. Maybe, we should think of "restarting from scratch" the same way we do premature optimization - (1. don't do it. 2. Don't do it too early. 3. if you must do, measure first)
I think every developer dreams of rewriting from scratch because they hate how hacky and ugly their code is probably due to rushed deadlines and because it was just supposed to be an mvp. And they think about throwing it away and starting clean and doing it the 'proper way'. This imo is the wrong reason to start from scratch.
But if your technical debt is genuinely preventing your product from going where it needs to go or do its job. That is the right reason. Again you have to make the calculation whether the technical debt is greater than the cost of rewriting from scratch, re-opening old bugs and introducing new ones, breaking your customers workflow - they also invested a lot into your old program. How many times have you liked a program until 'the damn devs went and ruined a good thing' by 'fixing what wasn't broken'. Again, customers don't see or care about the code or technical debt. They just need to get their work done.