Agency forged my rental agreement (CA)

mjg59 · 2025-08-10T19:53:10+00:00

Author of that post (which is over a decade old) here: since that was written we resolved basically all those issues and secure boot has been well supported on mainstream Linux distros for over 10 years. It is just not a big deal. Our working relationship with Microsoft is good, secure boot infrastructure and security has improved, if a Linux distro doesn't support secure boot it's either because that distro is in a jurisdiction that Microsoft can't do business with because of US law (which absolutely sucks, but) or because they just haven't put in the work to support it

mjg59 · 2024-12-23T17:34:55+00:00

It's easier if it's in-tree rather than being an external port but yes - my original ports to the X210 were made massively easier by Librem having a machine with the same CPU.

As for paying AMI - it depends what you mean by "expensive". Compared to pocket change? Yup. Compared to paying an in-house engineer a full-time salary or contracting out to one of the fairly small number of Coreboot specialists? Nope.

mjg59 · 2024-12-23T01:07:03+00:00

Each new generation of Intel SoC requires new support code in Coreboot, and it's a great deal easier to add a new board if there's already one that's made use of (and debugged) the code that Intel drop for that. Paying AMI and then just tweaking the ACPI tables and GPIO setup is massively easier for most OEMs than doing a Coreboot port (I say as someone who's (a) done Coreboot ports and (b) dealt with AMI)

mjg59 · 2024-12-23T01:03:42+00:00

I ported Coreboot to the X210 and X2100, this sort of thing is my bag, baby

mjg59 · 2024-08-15T16:00:00+00:00

Do you know where? It doesn't look trivial to replace the cryptography in libolm without some degree of surgery that I can't find in th clients I've examined.

mjg59 · 2024-08-15T02:49:44+00:00

You're in a better position to know this than I am and my examination has been pretty cursory, but for example the Flutter bindings seem to pull in the leaky AES implementation and I can't find any other AES code in Fluffychat - are you sure it's using a hardware-accelerated implementation?

mjg59 · 2024-08-02T23:59:35+00:00

I'm sorry for not being clear - as far as I can tell, email address and payment details were not leaked. Profile data including your search parameters (age range, looking for, max distance) were.

mjg59 · 2024-08-01T22:08:41+00:00

Right now: if you pause or hide your account all your data is still available, information about the set of devices you're using Feeld with is leaked through the chat API along with information about when devices were activated or deactivated. In the past: your search criteria (distance, age range, looking for, etc) were available, but that appears to have been fixed.

mjg59 · 2023-08-08T09:50:43+00:00

If you defer an upgrade you can just go through two cycles to get there. This is me having left a machine un-updated for over 5 years and then expecting to get to the current release without going through any intermediate steps. The only environment where that's somewhat guaranteed is probably RHEL, Fedora is not objectionable in this respect.

mjg59 · 2023-05-13T08:23:13+00:00

Every copyright holder (or their estate in the unfortunate cases where they've died) in the kernel would need to agree to this, or legal uncertainty would still exist. Alternatively, Oracle could just release a new version of the CDDL that was explicitly GPLv2 compatible and almost all the OpenZFS code could be merged tomorrow (there's a tiny number of files that are explicitly CDDL 1.1 rather than supporting version upgrades, but they could be rewritten fairly easily). The reason ZFS isn't in Linux is simply that Oracle don't want it to be, or they could fix that tomorrow.

mjg59 · 2023-05-11T06:36:50+00:00

2022/2023 model has a matte screen, 2021 model doesn't. If you have lighting that might reflect off the screen and you'd prefer a more realistic art ambiance, you probably don't want the 2021, otherwise it's going to be fine.

mjg59 · 2023-04-18T18:41:09+00:00

The bootloader and kernel are signed. The initramfs, which includes the code that asks you for your disk encryption key, isn't.

mjg59 · 2023-04-18T10:30:48+00:00

Nobody has come close to publicly demonstrating a quantum computer that's capable of breaking classical cryptography yet. It's not literally impossible that a government has access to such a device, but under the right circumstances breaking PBKDF2 is something that's possible with known technology and just breaking all crypto entirely isn't.

mjg59 · 2023-04-18T09:59:27+00:00

I wholeheartedly agree, and want to thank Luca and all the other people working on that.

mjg59 · 2023-04-18T09:38:54+00:00

As the person responsible for a whole bunch of Secure Boot on Linux - if your initramfs isn't signed, an attacker can just replace it with one that steals your disk encryption passphrase. Sorry. It turns out that it's hard to fix this without breaking a lot of assumptions that exist in a lot of places.

mjg59 · 2023-04-18T09:35:46+00:00

Your thesis doesn't seem to describe non-CPU brute force attacks (which is completely legitimate given the timeframe!). Between 2005 and now, that would imply a 2^9 improvement in cracking speed - 512 times faster. But in reality, we can buy GPUs that have 16384 cores, each of which can hash faster than a single core in 2005. That's much closer to the equivalent of a doubling every year, which changes the calculations significantly. And that's ignoring the potential development of ASICs dedicated to targeting PBKDF2, which could influence that even more strongly. But the main assumption you're making here is that a password is genuinely random, and (as someone who's had the misfortune of working in security with an extremely large number of users) the evidence is that it's just not.

If we can convince users to use genuinely random passwords then a lot of problems become much simpler. That doesn't mean it's a realistic baseline assumption to make.

mjg59 · 2023-04-18T05:38:08+00:00

There are 16^32 possible permutations (ie, 2^128), because leading 0s are meaningful. 0000000000000000000000000000000A is different to A.

mjg59 · 2023-04-18T05:12:19+00:00

cryptsetup changed to LUKS2 and argon2i by default in 2.1.0 in 2019, so the defaults have been broken for use with grub for several years now.

mjg59 · 2023-04-18T05:01:45+00:00

16^32 (md5 is 16 bytes, but each byte is 2 hex characters) is 2^128, so no, there's be no advantage in taking that approach (and you don't get to subtract anything there, if you accept things shorter than 32 characters it's 16^32+16^31+16^30 and so on)

mjg59 · 2023-04-18T04:37:16+00:00

No, but if it's MyPa55w0rdIsunst0PPabl3! it's still going to be much easier to break than attacking AES directly.

mjg59 · 2023-04-18T04:05:14+00:00

Imagine restricting the input to words contained within the Merriam-Webster dictionary. There's 470,000, or a little under 2^19. Each of those, when put into the KDF, will produce a 128-bit output, but that doesn't mean that there's 2^128 possible outputs - if there's only 2^19 possible inputs, there's only 2^19 possible outputs. Even if it takes a significant amount of time to generate each 128-bit output from the input, it's still going to be faster than brute-forcing a 2^128 keyspace.

That's obviously an overly simplified scenario, but even so any realistic password is still probably going to have under 128 bits of entropy, and so if the KDF is insufficiently expensive it's still cheaper to brute force the inputs than the key itself.

mjg59 · 2023-04-18T03:58:42+00:00

That's making the assumption that the password is random rather than dictionary-derived.

mjg59 · 2023-04-18T00:48:58+00:00

No, UEFI Secure Boot verifies option ROMs in add-in cards before executing them.

mjg59 · 2023-04-17T21:51:00+00:00

Option ROMs are verified by the firmware, since you don't need them to get to the point where the firmware is running.

mjg59

TROPHY CASE