PSA: Upgrade your LUKS key derivation function
mjg59.dreamwidth.org
mjg59.dreamwidth.org
Sorry but there's no world in which this password was bruteforced in 2023, even if they were using just SHA1 as their PBKDF. Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy. To put this in perspective, if you could use the entire global bitcoin mining equipment (estimated at 350 million terahashes / second) right now without modification to bruteforce this one password it would still take you 4 x 10^37 centuries. The author of the article failed to do this basic math.
The dude reused passwords, got keylogged, powned some other way, was coerced, had something unencrypted, or something else happened. But his password did not get bruteforced.
His password was intercepted, or was embarrassingly deterministic.
Though from this description it looks like they read the disk (trivial) but it's not sure if they actually pulled anything from it (at least it seems they didn't pull anything incriminating if I read it correctly).
If they were using a crib sheet to the point of only trying 1m attempts, this can be done in “days” with one CPU even if PBKDF2 is set to take one second each attempt on that CPU.
A “better” KDF isn’t fundamentally going to change this. It’s just going to enforce stricter limits on any time-memory trade offs and require more memory. Neither of these are going to be meaningful differences when you’re cracking a single password for a single user with a crib sheet, unless you’re in the realm of billions or more guesses.
MacOS machines with a T2 chip keep the encryption key in the T2 chip so it isn't in system RAM.
The original sentence already came with this disclaimer.
> and we should be transitioning to even more secure passphrases. [newline] Or does it? Let's go into what LUKS is doing in the first place.
That sentence really should have been put into the introductory paragraph, instead of being the start of the 2nd.
There is no such thing.
b) The first two sentences of the next paragraph read:
> Or does it? Let's go into what LUKS is doing in the first place
Someone who doesn't know in detail the math of how this stuff works but _does_ know how to run tight opsec could very reasonably assume that now fairly long passwords can be brute-forced. That's like, the entire point of the article, innit? Describing how this almost certainly _wasn't_ an attack on the password, but almost certainly an attack on the mechanisms that use that password as an input to crypto.
+1
To be clear, the person I was replying to was all like "You _idiot_. Obviously the plaintext of the guy's password was in the possession of the attacker!", when the primary (if not the entire) _point_ of the article was to set up and answer the question "Well, what if it _wasn't_? Is it possible using default settings to brute-force a password?".
Password/passphrase cracking is done with sophisticated (and in cases like this one, likely tailored to the target) strategies that try more likely possibilities first. In such a scenario, "supposedly greater than 20 characters and [including] a mixture of cases, numbers, and punctuation" tells us little about how difficult it was to crack.
For example,
A11 y0ur b4s3 4r3 b3l0ng 70 u5!
(not many know this, but gpt secretly is french for Government Person Trained!
The eventual goal, is that the gubberment will have mental maps of us all, and even use that to test meme class mental manipulation techniques on this simulated populous, to best determine those sweet words to control us.
Rebels will become loyalists, anarchists state advocates, our very natures used to control us!)
https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U ( Q3'18) CPU, that appears to result in an iteration count on the order of 1-2M. Assuming those hashcat benchmark numbers scale linearly on the iteration count, you're down to about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256.
Assuming 10kH/s, that drops you down to roughly 45 bits of entropy for 1k gpu-months, or 250k gpu-years to net 56 bits of entropy. Those would be on the order of [a-z0-9]{8} (41 bits), [a-zA-Z0-9]{8} (47 bits) or [a-z]{12} (56 bits).
OTOH it's easy to generate a 20-character password with far less entropy.
[1] https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyA...
They then use that strings output as input into the password cracking rig. They are happy to let it churn for months / years (because the case is working through the system).
So its far more likely this individual hibernated his PC with the password in memory or reused the password elsewhere than it was cracked.
Is that the case? I would be surprised. I would assume success ratio does not change much by checking say 10^4 more combinations (it's either a simple combination of these strings and common prefxies/suffixes or if it's complex then the amount of combinations grows so fast that you are unlikely to get a hit)
I'm betting on the second option, he reused the same password somewhere else or they just got lucky and seized the computer already unlocked
https://en.wikipedia.org/wiki/Entropy_(information_theory)#c...
> English text, treated as a string of characters, has fairly low entropy, i.e., is fairly predictable. We can be fairly certain that, for example, 'e' will be far more common than 'z', that the combination 'qu' will be much more common than any other combination with a 'q' in it, and that the combination 'th' will be more common than 'z', 'q', or 'qu'. After the first few letters one can often guess the rest of the word. English text has between 0.6 and 1.3 bits of entropy per character of the message.[6]: 234
Consider the difference in entropy between this totally randomly generated password, consisting of 4 words each from a pool of 100,000:
Correct Horse Battery Staple 4lg(100000) = 33
And this one of the same length where each character was chosen from a bank of 68:
VIW&jubiHZUgBrFA8PI9Vy1E(%G 28*lg(68) = 170
That being said I don't understand your calculation of 4lg(100000). That seems like it can't possibly be correct. For starters it is entirely independent of the entropy content of the words in the dictionary. I could have 100000 strong random passwords of 1000 characters each in my dictionary. Could you explain this a bit, please because there's obviously something I'm missing?
Edit: Aah I think I get it - the assumption is both me and the attacker know the dictionary so the entropy content of the words doesn't matter, the only thing that matters is the joint probability distribution of the combinations I'm choosing. Is that correct?
I think you mean 66. More realistically, 52 for Diceware's 7776-word dictionaries, or 44 for XKCD's 2000 common words.
https://towardsdatascience.com/perplexity-of-language-models...
(I have not checked this claim, it's just what I found from googling "best large-language model character-perplexity 2023".)
A token in a LLM is generally more than one character, so I would guess that the entropy is a bit lower than that. Shannon estimated it at 0.6-1.3 bits/character in 1950 (https://mattmahoney.net/dc/entropy1.html)
I think the discrepancy here is coming from the fact that you are assuming the password is using English words, where others are assuming completely randomly selected characters from the set /[a-zA-Z0-9]/, plus some special characters, which yields substantially more than 1 bit per character.
"the SDAT explains that they began to tail me and the other comrade (quickly exonerated) starting last January"
[1] https://anarchistnews.org/content/update-letter-ivan-alocco
Careful, that math assumes each character was chosen randomly, which isn't how people usually pick passwords. If the password contains words and patterns, then it was much weaker. "Passwordpasswordpass" matches those requirements, and is decidedly weak.
But I agree, password reuse or other similar mistake seems likely.
2^114/350e18/3600/24/365 = 1.9e6
Even 2^114 itself is only 2 * 10^34
> Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy.
Upper/lowercase are already 52 characters. If we add digits (0-9) we are already looking at log_2(62^20) = 119 bits of entropy.
On that note: Let's assume the password were indeed purely random and had 119 genuine bits of entropy. If you're the attacker and your goal is to do 1000 (≃ 2^10) rounds of SHA1 for each of those 2^119 potential passwords, couldn't you then just try to brute-force the 128-bit key directly, since 119 + 10 >= 128?
Put differently, wouldn't the statement "A fully random 20-character alphanumeric password has been brute-forced" amount to saying "AES-128 can be brute-forced"?
Your calculation is correct. My point still stands (2 million years is plenty of time), but my number given was completely off. I can't edit it anymore though.
This calculation is for exhausting the entire search space, right? Not guessing at random (which would invoke the birthday paradox?). For block solving on Bitcoin, clients don't search the whole space. They try random values and check if it's right.
I'd assume the random guesses for bitcoin miners is because with a deterministic chunk of the search space you risk the possibility that someone else chose the same chunk and so already tried all the values you're trying
Clemens Fruhwirth here. I am the inventor of LUKS.
A random keyboard typable character gives you around 6 bits of entropy. 20 of those give you 120 bits of entropy. Even without a KDF, brute-forcing this key space is infeasible with today's hardware. Even with PBKDF2, a 13-character password should be enough to keep your data secure for your lifetime.[1]
It is much more likely that there was some security failure in the linked case other than PBKDF2. That said, I support the upgrade to Argon2.
[1] In my thesis on LUKS, Chapter 5.3 Passwords from entropy weak sources anticipates the creation of specialized hardware for breaking PBKDF2. The "13 characters should be enough" advice is found on Page 86, Table 5.4, top left cell. It gives a 78-bit recommendation (=13 characters) in the worst-case scenario, which is Moore's law continues to double the attacker speed every 2 years.
[0]https://www.reddit.com/r/linux/comments/12q51ce/psa_upgrade_...
Once logged in, on `old.reddit.com`, search for "Show my flair on this subreddit. It looks like:" on the right side of the screen.
But people don't use strong passwords. We should know this by now. End users pick weak, predictable, non-random, short passwords. I've seen IT departments (who should know better) set weak passwords for users like "Company2023". A KDF can't save you if your password is extremely weak, but it can improve a mediocre password such that an attacker will give up before they succeed.
In other words: nothing about the scenario requires the target to have failed to engage in proper password management or even password selection (beyond the minor but extremely normal decision to use a memorable password rather than a random one).
My approach now is phrases in a few words in different languages, ideally transliterated from non-Latin scripts; it makes the search space much larger while preserving memorability.
Say there are a million cool math phrases, and for each one, a million different l33tspeak ways of expressing it. That's 10^12 possibilities, or around 2^40, which was coincidentally the US export limit for encryption tools in the 1990s (i.e., weak then and much weaker 30 years later). Maybe that doesn't sound horrible to you, but what are the chances that your scheme is so weird that a dictionary builder wouldn't generate it?
Better to stick with the xkcd/diceware/BIP-39 family of methods. Those algorithms intentionally lack cleverness.
That's right. My million-x-million estimate was rhetorically generous. (xkcd's specific example was about 44 bits.)
OP -- not to put too fine a point on it, but it's a terrible idea. So much money has been lost to brain wallets in the digital-currency space by people who picked obscure song lyrics, wrote it backward in pig latin, capitalized every third letter etc. etc. etc. and then wondered why their balances were zeroed out. You want the competition to be about the limits of physics, not about the limits of your creativity vs. an army of computers.
Read Moonwalking with Einstein by Joshua Foer to see how easy it is to memorize things using the memory-palace technique (https://en.wikipedia.org/wiki/Method_of_loci). Anyone can remember a 10-word phrase, especially if you build it up by adding a word or two every few weeks. The key is to start with something unguessable, as ravi-delia says, like https://iancoleman.io/bip39/. If you start with something guessable like a transliterated math expression, then you brought a knife to a gun fight.
Who knows if he used a non encrypted swap partition ? A leaked online account ? The guy complaining here doesn't make it very clear if its encryption was broken either, he's just over-interpreting the police reports by mentionnning some emails ?
a) Preserve entropy of the password material (up to a limit - size of the input to the next stage)
b) Derive a fixed-length output suitable for use as an input for the next cryptographic stage.
1). Use 'a', 'b', 'c', 'd' as the first four bytes of the AES-128 key (32 bits) in ASCII form, and then pad the rest with zeros or ones or use some other well-known pattern (based on convention). This method preserves entropy but is not computationally expensive.
2). Use a KDF like PBKDF2.
However, if we're talking about an attacker has the resources to brute-force a large number of generated passwords (based on real-world use or derived from hand-crafted or ML-derived criteria), they can precompute KDF outputs for each of those passwords and reuse them. This would make the second scenario (using PBKDF2) as easy or hard as the first one (using simple padding).
PS: Not a cryptographer, please don't shoot!
I'm not sure what is exactly meant by "precompute", but any sane implementation would use salts to prevent an attacker from precomputing common passwords so they can be used across multiple targets.
PBKDF2 basically works by hashing the password over and over again. Using pbkdf2 with 100,000 rounds, means bruteforcing is 100,000 times slower, because you have to hash each guess 100,000 times.
Argon2 takes the idea further by being memory hard and resistent to parallelism. People briteforcing will use gpus to try lots of guesses in parallel (or asic if money is no object). These can handle pbkdf2 really fast but not argon2
Where the disk only has a fully secure huge random key, not generated by a kdf but supplied whole by usb or something.
Protecting that external component is a problem, but it's a seperate problem, and having a copy of the drive, and everything else in your posession, and all the ram and gpus in aws doesn't get you into that drive.
The external part doesn't have to be a thumb drive right on your person. It could be stored anywhere on-line and/or on paper, and you just know where it is and how to get it.
You might have to re-create some kind of thumb drive for conveient use, but you could also intentionally lose/destroy it any time and not have it on your person during travel or sitting in a drawer at home. You would only recreate it when & where you decided it was safe to.
I guess that's what tpm aims to do. It's physically on-board but not accessible, as long as you trust the chip maker.
Obviously I've spent about 5 entire minutes thinking about this. Please excuse.
However I don't recall if the keyfile is then used to decrypt a header stored on disk to get the key that's actually used to en/decrypt the drive contents in the same way that passwords are.
Each of these slots can then decrypt the main key to decrypt the drive data. This is done for a few reasons. This allows you to change "your disk encryption password" - or rather, passwords used for password based slots - without re-encrypting the (arbitrarily large) disk (for an arbitrarily long time). You just change an encrypted master key for a different ciphertext of the same master key.
Don't know about that but you can now use any U2F device (like an old or new Yubikey) to unlock your LUKS partition.
I don't think anybody is bruteforcing that.
EDIT: of course it doesn't help much if law enforcement gets your Yubikey : )
For example:
--pbkdf argon2id
--pbkdf-memory 4194304
--pbkdf-parallel 4
--iter-time 60000
If you have an especially powerful machine, it seems to be able to use a significant fraction of total memory, so you can do something like this:
$ time cryptsetup benchmark --pbkdf argon2id --pbkdf-memory 100663296 --pbkdf-parallel 4 --iter-time 150000
# Tests are approximate using memory only (no storage IO).
argon2id 7 iterations, 100663296 memory, 4 parallel threads (CPUs) for 256-bit key (requested 150000 ms time)
real 2m36.822s
user 9m50.221s
sys 0m18.921s
head -c48 /dev/urandom | base64
I know that under normal circumstances you can just write off the wildly improbable case of a hash collision, but when you're up against an army of GPU's I'm not sure I'd want to risk the possibility that `aaa` (or some other brute force candidate) collides with whatever urandom spit out that day.
If used, the PIN itself can just be your prior disk encryption passphrase, and now you have the same PW entropy as before with additional protection against PCR modifications and brute-forcing via the TPM
A password that is derived in 1 millisecond with these characters appended takes longer to crack than a password that is derived in 7 minutes without those characters appended.
"setting the key derivation parameters to take as long as you can tolerate" gives a false sense of security. Because it's taking a minute to log in it must be secure, right? In reality just making your password slightly stronger is far more effective security-wise.
Ideally, one should use a strong passphrase with strong key derivation parameters.
You're free to make whatever security trade-offs you like, but don't presume they make sense for everyone.
It doesn't really matter what kinds of characters your passphrase of 20 characters contains. What matters is how much entropy it contains, ie. whether it was generated randomly.
A random 20-character password containing just lower case English letters would still take more time to break than the age of the universe assuming one billion guesses per second.
If the attacker uses a wordlist with the old password and a ruleslist with "throw in a random character", they're going to try the correct password long before they try a random 21 character string.
Yes, it's not practical to type that. So don't, stop using passwords for this as a main way to unlock it. You can add a password as a backup key, but the main one shouldn't include a keyboard. There are plenty of hardware options other than TPM that you can destroy if shit hits the fan.
Of course all this info has to be double checked to see if it actually works, and forensic tools run against the phone to be really really sure the key's not being written to Flash in any way, or remains in RAM after a reboot.
https://www.freedesktop.org/software/systemd/man/systemd-cry...
What about not providing a PIN? How is that different from password? Proper PIN protected smartcards will lock you out after several wrong attempts and would require a PUK. And you might not remember that, genuinely. What then?
It's all seems pretty arbitrary to me as to whether something is considered destruction of evidence and it's very US-centric anyway. So I'd say yes, deniable encryption is needed. If they decide you're not playing ball, then you'll be punished. The difference is whether they will use a legal system for that in a First World country or something else if you're not so lucky.
All good here then (Debian Bookworm default LUKS install):
cryptsetup luksDump /dev/... | grep PBKDF
PBKDF: argon2idI kind of want to ask a question here since I'm likely to run into my betters on this topic. How does macOS / Windows 11 / Linux stack up to each other in terms of full-disk encryption?
What's the simplest approach to ensuring that my data isn't as easily decrypted, and to protect myself? (I'm aware of other vectors like via Internet/browsing, etc, but I'm concerned also about the physical security of my data).
Is macOS disk encryption pretty good all things considering? I see Windows 11 requires a compatible configuration to enable it for Home edition, or a Pro license. (Why?)
I've setup LUKS, created my keyphrases and all of that before on Fedora. But I'll be honest, I don't know how effective the defaults are and whether I'm doing the correct thing. I also worried about losing access to my data if the disk or LUKS volume became corrupted.
Any advice or tips for me?
You can set up Linux to use the TPM which will be a good improvement. Other than that I believe that LUKS has good defaults.
On the other hand, someone who can steal your laptop may be able to dump the TPM keys by simply attaching probes and turning on your machine: https://astralvx.com/stealing-the-bitlocker-key-from-a-tpm/
I'm not sure about the situation on macOS, I think Apple's TPM is a bit more advanced than most PC alternatives. I don't think modern macs are vulnerable to the attack I linked above. Microsoft's Pluton chip may also be different, I can't find much about its physical security properties.
I'm sure there are still vulnerabilities, but this is the method that governments themselves use for their devices, at least in UK.
Of course I am assuming that the TPM works correctly. Vulnerabilities in that may be more likely than with software crypto. But that is a difficult tradeoff to evaluate.
That only works for dTPMs. fTPMs (ie. ones built into the cpu) is safe from that attack, although they might have other weaknesses.
According to
https://security.stackexchange.com/questions/189950/how-does...
most CPUs can be controlled via JTAG, and apparently that includes many of their deep internals.
However, with LUKS there are two keys. The key slot key that is stored in the TPM is not able to be retrieved (by design) however the disk encryption key is not stored in the TPM, it is stored encrypted in each key slot. As long as you have access to the disk encryption key via an existing key slot you can create additional key slots without TPM protection. Once you have a non-TPM key slot you can transfer the drive anywhere and unlock it using that slot instead of the TPM. Of course this slot will not be protected from brute-forcing by the TPM but if using a sufficiently long passphrase for backup or transfer it should be fine.
TL;DR if you have access to the TPM you can migrate away from it. But if the TPM is your only form of access and you lose access (stolen, wiped, forget password...) then your data is irretrievable.
> What if I want to move my own drive somewhere else?
Be aware that in the case of Bitlocker specifically Microsoft "conveniently" saves your encryption key on their "cloud", so you don't really need the TPM to decrypt stuff, which of course goes completely against the purpose of storing the key there in the first place. Oh yeah, also: DON'T trust Bitlocker, it's absolutely compromised if you are using an SSD which provides firmware "encryption". [0][1]
[0]: https://www.tomshardware.com/news/crucial-samsung-ssd-encryp...
[1]: https://twitter.com/matthew_d_green/status/10594413723175813...
What MS stores in the cloud is not the encryption key but a recovery key. Obviously a recovery key can also be used to perform the decryption, but it has the benefit that it's generated by the system to be of high entropy, as opposed to a human-chosen password.
If you're against FDE recovery keys I assume you're also against 2FA recovery codes.
On Windows 11, Bitlocker should just work. Windows 10 still requires a Pro license for encryption, but 11 should've fixed that, making it available (in most part) to all versions.
If you use Bitlocker, pay attention to where the recovery codes are stored. By default, Windows will offer to add the recovery key to your Microsoft account, theoretically giving Microsoft and various governments access to a method of decrypting your drive. You can opt out of that and store the recovery key somewhere safe instead. You should keep this key available, because you may need it even if you know your password (for example when the secure boot state gets toggled, or the boot configuration changes).
Also consider using a password in addition to the TPM key storage if you're okay with your drive not being decryptable without the recovery key outside of your computer (https://www.howtogeek.com/262720/how-to-enable-a-pre-boot-bi...). Windows likes to store the key inside your TPM (which is then exchanged without encryption in a way that someone with physical access can probably intercept), which makes it possible for Windows to boot without prompting for a key, meaning an exploit against the Windows login prompt can bypass the security Bitlocker PROVIDES. An additional password means you need to type in a password on boot,
If you distrust closed source encryption methods, Veracrypt is available for PC as an open source full disk encryption system. My understanding is that the code is reasonably safe, though you may want to Google around to make sure it's as secure as you'd like it to be.
With LUKS, your data is gone when the LUKS headers are gone; your password only serves to decrypt the real key that protects your data. You can back up the headers somewhere safe (this article shows you the commands to do so) and restore them later in case something goes terribly wrong. You'll still lose data if the data written to disk is corrupted of course, but with the headers backed up you should be reasonably safe against specifically encryption related disk corruption.
Once you have loaded the encryption keys, LUKS presents itself as just another drive, completely transparent to the underlying file system, so fixing partition corruption is similar to fixing an unencrypted drive. As far as I know, the same is true for most other operating systems as well. Many traditional file recovery tools work after simply unlocking an encrypted volume.
If you're paranoid, you can also use the fact that LUKS headers are all you need to your advantage. It's possible to configure LUKS to store the headers on a separate device (i.e. one you always carry with you and another in a secure location) so a drive can be completely unreadable without a second physical storage device, even if your adversaries know your password.
I think the simplest method of securing yourself would be to just enable drive encryption built into your OS with a sufficiently long and random password. It's probably best to use a password generator to create one. In theory attacks on bad key derivation functions are feasible, but most people's data isn't worth all the time and compute it takes to crack such a password. If you use modern tools and modern configurations (backwards compatibility can be an issue), the tools built into your OS are probably Good Enough™ for most people.
Fedora defaults are adequate but depend on the strength of your password.
Simplest setup is actually to just enable SSD password in bios. All SSDs these days are encrypted by default - they just store the password in bios and don't tell you they're doing it. If you set a password there is zero perf overhead.
A basic linux setup is unencrypted boot and encrypted root partitions.
You can encrypt boot using a small grub partition to chain load boot/root but all it's preventing is someone swapping your kernel/bootloader configs out without your knowledge. If that's not a concern you can skip it.
While using bios level encryption is simple it limits my options as far as controlling decryption with keyfiles on USB or yubikey which I like in some situations.
The bigger problem I have with encryption these days is ensuring my automated backups are encrypted despite being always on.
PS And when somebody takes a look at it, most of the time it is broken. Google the research.
Basically:
- full disk encryption is required for whatever reason
- BIOS SSD passwords fulfill that requirement
and it is good enough to prevent accidentally leaking data when losing the laptop and it goes in the hand of someone slightly technical versatile but not a specialist/hacker nor a targeted attack interested in handing the laptop to a specialist.
Hence why compliance rules in cases involving actual sensitive data often require full disk encryption using more strict requirements not fulfilled with BIOS encryption.
> Nobody verifies that the encryption scheme is sound.
for some Latop brands/variants you most likely have a sound encryption schema, but there is still the problem that it's unlocked by the TPM and the en-/de-cryption is likely run on the CPU or similar instead of an specialized IO description chip tightly coupled with the TPM (modern Apple devices, at least phones, are a notable exception here AFIK). So even if the encryption schema is sound it's normally not too hard to extract the key in one of many ways for a specialist. And even if that doesn't work there is still the attack to inject your OS which then sees the unencrypted SSD... so normally not secure.
[1] https://www.tomshardware.com/news/crucial-samsung-ssd-encryp...
More: Shufflecake is made of two components: dm-sflc, which is a kernel module implementing the Shufflecake scheme as a device-mapper target for the Linux kernel, and shufflecake-userland, which is a command-line tool allowing the user to create and manage hidden volumes. The kernel module must be loaded before using the userland tool.
It's that while there is well working reliable core tooling, all the tooling around it, especially more higher level tooling is, well, not so grate and often incomplete.
This makes it a "expert" topic even through there is no fundamental need for it being such a topic.
At least for full disk encryption (encrypted `/`), `systemd-homed` is it's own, different, can of worms ;=) (and given that it add no benefit for a single user non-server laptop system with properly done full disk encryption I didn't use it yet, so I can't give feedback)
One big issue I see is that generating an initramfs is a very distro-dependent process and the glue to unlock your disk is not the most consistent. On the other hand, systemd now handles crypttab.
Like automatically on-the-fly re-doing the key encryption/KDF when the default algorithm changes and is now more secure then the one used currently.
or tooling for setting it up including TPM unlock, secure boot, hibernation etc. without needing to know all the config files and initramfs options you need to edit.
(and lockdown mode + hibernation is currently also not at all supported and some distros default enabled lockdown mode when secure boot is used leading to a lot of headaches or "hibernation doesn't work claims" from users)
Also standard schemas for desktop setups of the core system, including full disk encryption, raid(if needed), etc.
But there is no tool and too many divergend approaches leading to no standard schema.
And I mean sure, I can use a patched LTS kernel supporting both lock down and hybernation (at the cost of lockdown being slightly less secure) or disable lockdown mode. And then setup full disk encryption knowing how to evaluate the difference of FS (e.g. ZFS) encryption vs. LUKS and choose weather to do RAID=>LUKS=>LVM=>FS or LUKS=>LVM(with RAID)=>FS or LUKS=>FS(with subvolums and RAID) and maybe script some custom initrd mods to make that work well. Setup hibernation and how to setup secure boot with an efistub, systemd-boot or grub and why to do (or not do) either with custom platform keys.... and setup TPM encryption unlock and evaluate weather I want it or not etc.
But man it's sooo annoying to do that and 100% not something I can expect anyone new to Linux to be able to get that anywhere close to right for their use-case.
https://news.ycombinator.com/item?id=35615911
>And UEFI implementations have undocumented size limits of what they can boot.
If the problem is that the ESP is too small, you can put systemd-boot or similar in there and make a XBOOTLDR partition to store the actual UKI ("UKI" == the output of "the second method" in the comment I linked).
If the problem is literally that the firmware can't execute a .efi bigger than a certain size, and if that extends to the UKI even if there's a bootloader in between, then I guess you're out of luck.
I had the problem on NUC10 that it doesn't want to boot images around 100 MB. No problem with around 70 MB. Figures from memory, could be slightly lower. We routinely use systemd-boot, I'd guess it was also in that experiment. Or maybe not? Good point, I would need to try again. Either way we did not end up buying NUC10 for production, so I just made a note to myself that UEFI implementations might have size limits. On another implementation we boot the same size without issues.
Yes, I read the UKI postings when they came. And Lennart spoke about it at FOSDEM again this year, IIRC. Certainly something to look into "when I have time".
I was just relaying what I've read about the reason that the concept of the XBOOTLDR partition was invented in the first place. Eg:
https://wiki.archlinux.org/title/systemd-boot#Installation_u...
>A separate /boot partition of type "Linux extended boot" (XBOOTLDR) can be created to keep the kernel and initramfs separate from the ESP. This is particularly helpful to dual boot with Windows with an existing ESP that is too small.
I have no idea why it's not possible to just resize the ESP and move the partitions around. Maybe the Windows install doesn't like being moved? I don't use Windows so I don't know. On all my machines I have full freedom to make the ESP as big as I want and move partitions around as I want.
I'm not an expert, but I'm really curious to hear more. It's especially weird given I've heard nothing but good things about Argon2 otherwise.
Yeah, yeah, I know, reusing passwords/passphrases is bad and all, but consider only this use case: you have PC and have a laptop. Or you have a PC where you accidentally written your passphrase twice in two different slots (if that's possible). Does that weaken protection? Or it would not help attacker in any way provided you kept passphrase safe?
Anyway, I'd assume that each LUKS key slot has a unique plaintext salt to prevent a single rainbow table being useful to attack every key slot - the attacker would still have to build a unique rainbow table for each. As long as this is the case then the time to bruteforce a password should be the same no matter how many keyslots or machines use the same password.
But I think maybe you can increase the number of PBKDF2 iterations? I heard at some point that the default in very old versions of cryptsetup, you'd always get 1000 iterations (which is very low), but nowadays, I think it's based on timing the CPU you're creating the volume on.
It shouldn't be. It can be done on next boot by the initramfs, before the real root etc are mounted.
Gladly correct me in case I'm wrong.
That's rather unfortunate. My knowledge of key derivation algorithms is a bit out of date, so can someone confirm that if an old volume is still using PKBDF2 headers you can still get some benefits upgrading to argon2i? Or are both of them equally useless at this point in time?
I've always wondered why the key algorithm depends on the speed of the CPU, this makes cheaper devices or handheld devices less secure for a second or two of extra boot time.
Since it requires keeping the kernel and other boot files on an unencrypted /boot partition, secure boot is a must to ensure the kernel hasn't been tampered with. Unfortunately, UEFI secure boot only supports signing one file, and so systemd-stub[2] can be used (doesn't require SystemD) to combine boot resources in a single PE binary, allowing them to be signed.
I haven't followed it personally, but this[3] tutorial seems to go over the points I covered.
[1]https://wiki.archlinux.org/title/EFISTUB [2]https://www.freedesktop.org/software/systemd/man/systemd-stu... [3]https://nwildner.com/posts/2020-07-04-secure-your-boot-proce...
I still need to get secure boot to work but dealing with it seems like such a pain, especially since I use various DKMS modules.
One method is EFISTUB, which is to use the kernel config CONFIG_EFI_STUB to compile the kernel as a UEFI application. That's what struanr's [1] is about. This method does not bundle the initramfs so the initramfs must be present separately on the ESP so that the kernel EFI process can find it. If you plan to use Secure Boot you can sign the kernel but not the initramfs, and AFAIK there's no way to make the kernel verify the integrity of the initramfs in any other way. So using this method defeats the purpose of Secure Boot.
The other method is to use an external UEFI stub like the one provided by systemd-boot, etc. In this case you use a tool like dracut / ukify (new in systemd v253) to create a UEFI application using an externally provided stub (systemd-boot in dracut and ukify's case, I also remember seeing a tool that used gummiboot's stub) plus a regular kernel plus the initramfs. The initramfs becomes a PE section and the stub sets up the kernel cmdline to use it. The UEFI application is thus self-contained, and signing it lets Secure Boot guarantee correctness of both the kernel and the initramfs. This is what struanr's comment and their [2] and [3] links are about, even though their comment and [3] link claim to be about EFISTUB.
Note that a lot of distributions enable CONFIG_EFI_STUB by default anyway, so even for the first method you may not have to compile your own kernel.
Please vote there.
It shouldn't be a problem if you use it to store infrequently accessed material, e.g. the entire copy of Library Genesis (2.5 million ebooks). The double encryption will make sure absolutely that you cannot be prosecuted for possessing forbidden books (in countries where there is no mandatory key disclosure law). That way your reading habits are none of the government's business, period. As it should be.
FWIW, my fresh install of Fedora 38 uses argon2id as the KDF.