okay, I’m way too late to post xkcd “4” comic and still be funny, so instead I will have to write a serious post
Could this disturbingly severe mistake be because someone asked The Cat for a certificate? Hypothetically, yes. But there’s absolutely no reason to jump to that conclusion with self-righteous confidence when all serious infosec experts have been screaming for THIRTY YEARS that our programming languages are designed to maximize the probability of catastrophic mistakes in cryptographic code even when handled with care by experienced professionals.
Here’s what we know: several signing certificates from the same issuer with private keys that are, in their entirety, just a number below 256, all the way down to the comical “4, just 4, that’s not a typo, the private key is 4.” This strongly suggests a bug where the first byte of the intended key, treated as an array, was used rather than the whole key. A bug that’s absolutely, positively trivial to write in C and its descendants. I’ve seen proposals for how to gotcha yourself like this in Go as well.
I’m not saying The Cat isn’t involved, it could be. But you absolutely, positively do not have to ask a mischievous clawed agent for a random number for it to go this horribly wrong. We’ve always had the human strength within us to fuck up this bad all along
(And I do assume it’s a fuckup and not a backdoor, because there’s no reason to design a backdoor such that the next random enthusiast to run a sanity check script on public certificates will instantly spot it and start screaming)
@0xabad1dea Kind of wonder what sort of language would actually protect against this sort of human error, I don't think even type systems actually would.
Instead of like,
assert(priv_key > (2<<15));(Or more likely a much higher value, say how many privkeys can be generated in 10 years of compute on a really nice machine, the one I picked being Debian OpenSSL fiasco number of possible keys)