So we either expose the key material for inspection (very obviously bad) or we try and brute force how many possible "weak" private keys from the public key to see if they check out?
Note that this is on the order of trillions of useless computations at least per year since almost everyone just uses a CSPRNG or HWRNG available in all modern computers to generate their keys sanely.
Now, for CAs, sure because that is a very small number of certificates. But that's a completely different discussion and also however eMudhra managed to lop off all of the entropy except for the final byte was wildly incompetent and not something a layman would even consider doing.
It's also not the job of the CA to detect you being an idiot. You can go post your private key online after getting your certificate if you so wish, the CA may revoke it if they find out but they're just in the business of helping you secure your communications with others. If you wish for them to actually be insecure... You are silly, but that was always allowed.
FWIW, at at least some of the ACME CAs still willing to sign RSA certificates will make a cursory attempt at brute forcing your private key to make sure you don’t have one very tiny prime and one big one. Tom7 encountered this when he tried to implement the least secure website he could without being flagged by the browser. He ended up using a public modulus with four prime factors instead of 2.
The “4” affair did make me wonder… as a non-expert, I’d always kind of assumed that—with all the ceremony around key ceremonies and all—there might be some way to provably assert the set of techniques used to arrive at the key in the first place. XYZ hardware-signed source of entropy was sampled at DEF time and input into ABC signed chunk of algorithm to arrive at the private key…
In fact I assumed that’s why somebody might explicitly choose “4” as their key: to make it as easily detected as “TK” in a copy edit, or a prefix-designated API key in a repo, or an “@example.com” that slides by into a serious environment.
We really go on a pinky swear across the public CA ecosystem?
You could certainly use zero knowledge proofs to prove some statements about the secret key, like requiring it to be roughly a 1:1 ratio of 0s and 1s and the longest run of the same bit is not significantly larger than log2(n). I think if I were trying to enforce a minimum level of security then I might take that route, requiring that the key passes zero-knowledge proofs of various statistical tests of randomness.
By pigeonhole principle, nearly all numbers have to have a Kolmogrov complexity within some constant of their own length, meaning they are algorithmically random and will by definition pass every statistical test of randomness, so you lose surprisingly few bits entropy per assertion this way.
I am not sure how trillions of computations will occur, simply attempting 0-255 would have found ... all? ... of the eMudhra fuckups. Maybe a few million instructions burnt on a CPU.
And again, you have to actively work to get a "private key" of 0000 ... 0-255. If you want to be stupid it's not really the CA's job to tell you not to be. It's their job to verify your identity. And, again, a CA itself is a totally separate beast where this thinking does not apply. If you want to be secure it's easy to be secure and if you don't want to be... Why should anyone else care? You are only hurting yourself.
This is just flatly false. You're comparing a worst case SSD with maybe 10% of its writes left to an extremely lucky floppy disk that hasn't died to binder hydrolysis, mold and fungal growth, warping or demagnetization. And you also completely made up that you couldn't generate a strong enough magnetic field at home to corrupt one - you absolutely could especially since rare earth magnets are not that uncommon and are more than enough to kill a floppy.
> Cloudflare is no better, maybe worse. They forward your complaint & PI on to the offending site's registered owner and to whichever (gray or black hat) host it's served from.
This is literally false. They are one of the few hosts I have dealt with that actually does NOT do this. Their abuse reporting form even has check boxes that are optional to forward it to the underlying host and the owner. If you leave them unchecked they don't forward anything.
I don't know where you got your information from but it's quite literally the opposite of reality.
Now, whether or not they actually act on it depends on whether they are proxying the site or merely providing authoritative DNS. If they are just providing DNS they will continue to provide it and deny your report and I think that's stupid and frustrating. If they are proxying it they will put up a block page in front of it which is meh.
I swear I have seen plenty of PCs attempt a PXE boot before failing and continuing on to the next boot option. It probably isn't the default for most "personal" machines but... That's not really a guarantee I would want to hang my hat on...
You need to compile a device tree for every single device you want to support individually, whereas x86 has ACPI to avoid that mess. ACPI is its own mess, yes. And UBoot is great. But it isn't a standalone replacement for a unified firmware interface/"BIOS"/whatever.
It's basically the same solution just in a different format. Device tree specifies device types while ACPI specifies the bytecode to interact with them, but the idea behind both is the same: the computer firmware tells the OS how to interact with it. It's been a slight success in both forms but not nearly as good as you'd hope it to be. The real problem is that nobody's testing all the firmwares and OSes for compliance so lots of devices ship incorrect data in firmware and then the OS has to patch it anyway.
Also uboot is firmware, there's no lower layer it runs on so of course it has to include the device tree. Or in practice, like most vendors, you just put the device tree in the kernel because you know your kernel runs on one specific device model anyway and then you can just edit it when you discover why it's wrong, instead of doing a weird dynamic patching thing.
Uboot contains a device tree which may or may not be in sync with your kernel device tree. Recent uboot supports efi which then muddies the water more.
When vendors ship a specific kernel, you are unlikely to get security updates in a timely fashion, if ever.
Well, for one, the dtbs don't belong with the shipped kernel. If a dtb exists, it should be shipped on the hardware (perhaps as part of firmware.) Right now, there is an intricate dance in some arm setups where:
The installed kernel has 200+ dtbs shipped with it and the boot loader has to be configured by some non-standard userspace glue to detect the correct dtb before rebooting. This glue doesn't exist everywhere and can be ad-hoc per-board or completely non-existent. IMHO, this leads to folks just not updating kernels.
One nice thing (in theory) about a dtb is that there is no code. Of course, there doesn't seem to be an established standard for finding that data so we are back to relying on specialized boot configuration and code anyway.
One place this all becomes glaringly bad is if you take an SD card and move it from one arm64 node to another; There is a good chance it won't boot. It's no wonder there are so many board-specific OS-images floating around instead of having arm64 installers that just work.
Also, a FDT is useless to most OS and remains primarily a Linux concept that has bled into other spheres (like U-Boot) so why would a manufacturer include it?
So ... what should we actually have? A standard on arm that doesn't depend on the triple of which (OS,board,bootloader) you are running. We should be able to just build an arm64 kernel (BSD/Linux/Windows/whatever...) and have a good chance that the thing just works. If that's done via UEFI, then so be it.
IMHO, given (waves hands) the current state of arm64 boards, arm64 support for Linux should look like:
1) Load a board-specific firmware to provide UEFI via EDK2/U-Boot/custom
* This is likely on the board-manufacturer to provide and should be pre-loaded.
On most devices that aren't PCs, there is no separate firmware - the firmware is part of the software. The boot ROM is just loading a sector and jumping to it. You may implement UEFI as your second or third boot stage if you want to, but it's your responsibility.
You wouldn't want the boot ROM to implement UEFI. It would have many unpatchable bugs and different ones on every device revision. Better to put the UEFI where you can patch it. For instance on a Pinephone booting from SD card, the firmware is on the SD card. Moving the SD card to a different device is putting the wrong firmware on that device, that's why it doesn't boot.
And then once you're shipping your own UEFI impl and shipping a kernel that runs inside UEFI, as part of the same SD card image, the next obvious step is to wonder why you can't short circuit those two layers and run the kernel directly on the hardware.
Yup. There is no reason it has to be a ROM though. It can easily be a small flash device sitting on spi or something. Firmware sitting on an SD card is annoying for all the reasons already stated.
For many of us, this would not be a better experience. The physical and mental components of doing it yourself is half the pleasure
Of someone’s carried my ass around all day I’d be a physically atrophied and mentally addled maniac, on obese to boot if I’m stuffing my face the whole ride
Part of the dilemma with modern culture is that most people seem to be striving for and hoping technology will provide pleasure funk laziness and glut. But these things in and of themselves produce bad outcomes. I get why people really stressed out might daydream about that, but this is probably more indicative of being overworked than of the virtues of laziness and glut
You're implying that they should???
reply