> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of opsec failures this implies that even relatively complex passwords can now be brute forced.
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.
Here's how it works:
When the gov wants to crack a password, they gather all of your digital life (phone, computers, thumb drives, etc.) and basically run "strings" on all of the hard drives / data they have of you.
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.
> They are happy to let it churn for months / years (because the case is working through the system).
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)
No. Resources are always limited. Forensic investigators will not be running things on server farms for years. People who think such things really do not understand how many cases are "in the system" at any one time. Even for something relatively serious like CP, drug smuggling or lower-end terrorism, there are literally thousands of cases in-the-system. The server farms infrastructure (ie hiring cloud capacity) would be reserved for national security, foreign intelligence and stopping Magneto. The contents of your laptop are not worthy of such treatment.
Not sure how it's done in the US but an effort to crack it like this would happen only on very high profile cases in France which is not the case of this one.
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
...on LUKS? Are you sure Apple and Google had this guy's local encryption password on hand? Unless of course he reused his password (highly likely), which is the actual flaw in his security
These days, most consumer and commercial machines are running multiple operating systems under Linux below ring 0. Same goes for hardware components with full access to memory and CPU time running their own OSes. Linux is mostly to completely unaware of their existence and can't do much if anything about them.
The presumption that 20 characters is any meaningful amount of entropy is based on the password actually being somewhat random, and there's no fundamental reason to believe that that's true. I tend towards brute forcing not being the most likely reason for this, but the indisputable reality is that any combination of weak passwords and PBKDF2 makes it plausible (if not necessarily likely) that an adversary with a sufficiently large hardware budget can break disk encryption.
You don’t need to merely tend towards. You just can’t brute force a random 20 characters password of the type that he mentioned. Brute force is almost never used, even with half of entropy of such password.
His password was intercepted, or was embarrassingly deterministic.
I didn't see anyone mention a random 20 characters password. I saw 20 character password with symbols and upper and lower case. That might be 4 words strung together "correct horse battery staple" style.
Or something like, notebook still had the keys in memory when it was recovered
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.
If the computer is suspended at the time it's seized, does it become easier to recover the FDE key from the computer's memory? Or is that encrypted with the user password, or something like that? (On stock ubuntu, say.)
If the DRAM is powered on at the time of seizure, recovering the key is eminently possible. If this is an issue for you, completely power off the laptop when transiting customs.
If you can dump the contents of memory then you have the key (after all, the CPU has to be able to encrypt and decrypt the material, so it has to be available).
Pedantically, if there's an HSM/similar hardware in play, the CPU only asks for material to be encrypted/decrypted and doesn't have the key in system RAM to be able to do so itself.
MacOS machines with a T2 chip keep the encryption key in the T2 chip so it isn't in system RAM.
Making this bit mor concrete: luks1 uses pbkdf2 with sha1 and minimum iteration count of 1000 as far as I can tell. Looking at random hashcat benchmark for rtx 4090, the closest thing is about 20MH/s. If we assume attacker spends a month with 1000 gpus, they will have bruteforced 20e6×86400×30×1000 combinations. Log2 of that rounds up to 56 bits.
You're underestimating the default PBKDF parameters used by LUKS1, `cryptsetup luksFormat` [1] benchmarks the `--pbkdf` function at runtime when configuring the keyslot, and the default iteration count is based on a target `--iter-time` [2], which is either 1s or 2s [3], unless overridden by the distro. I'm not entirely sure about the PRF (SHA1/256) used by LUKS1, it might be SHA-1 or SHA-256 [4].
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.
The author clearly meant "cracked" rather than "brute forced".
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.
They used chatGPT, trained on this user's emails, posts, data!
(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!)
A previous letter[1] supposedly from the same person stated that he was under surveillance before arrest, and thus "black-bag cryptanalysis"[2] is quite probable, particularly due to SDAT being a well resourced domestic spy agency.
"the SDAT explains that they began to tail me and the other comrade (quickly exonerated) starting last January"
English has ~1 bit of entropy per character. Replacing a character with a similar symbol adds ~1.5 bits to that character (there aren't leetspeak substitutions for every letter, so I am being a little generous). Random symbol insertions between words adds ~5 bits per ~5 characters (10 numbers, their shift-codes, and the punctuation, average word length is ~5). If every letter of the password is randomly leetspeak that yields 50 bits. If symbols are inserted between each word (average of ~4 in 20 characters) that yields 70 bits, which is barely greater than the 68 bits of entropy per second equivalent of 300M TH/s
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.
> 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
Grammatical English is an extremely restricted subset of all strings of characters. You can actually see for yourself that it's in the ballpark of a bit by going to a book, covering up a line, reading the context, and trying to guess the next letter one at a time. I get it 3/4 times, and would probably be down to 1/2 if I had to do it the right way.
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:
French dude gets in trouble with the law and has his encryption cracked. Hackernews goes into an extended (and extremely interesting) thread about the entropy content of grammatical English. Probably not that different in terms of entropy content per character, though.
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?
Oh yeah, my assumption is that it's 4 words chosen from a 100,000 word dictionary. I honestly have no idea if it's a reasonable estimate but it stuck in my head from XKCD's original correct-horse-battery-staple comic. Of course in real life an attacker won't know necessarily the distribution you've pulled your password from, but by using the exact distribution in your calculations you have an ironclad lower bound.
My God, where on Earth did I get 100,000? I mean that's a lot of words, plausibly more than I will ever hear. And how did it just cancel out anyway so I got roughly the right entropy? This will frustrate me until I understand how I fucked it so totally
Yep, I somehow internalized that there were 100,000 words (on reflection, I couldn't name a tenth of that in one sitting), but also halved the result, and the error canceled out a bit. Terrible.
(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)
Grammatical English has about a bit of entropy per character (Wikipedia has it between 0.6 and 1.3). Most passwords won't be fully grammatical, or even close, but it's a decent worst-case bound for passwords chosen by English speakers to be memorable. If you have a specific scheme it obviously goes out the window.
I don't follow your math. If we assume the cost of your password hash matches the cost of a bitcoin hash, I arrive at 2 * 10^6 years, not 4 * 10^39 years.
I... don't know what the hell happened. I was doing the calculation on mobile while on the move and I must've screwed up the parenthesis in the denominator. Embarrassing...
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.
Yeah, I'm not following that calculation either. Adding to that:
> 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"?
Disagree, long paragraphs are more annoying than breaking up thoughts like this. I think it's reasonable to expect a reader to continue to the next paragraph, and corrosive to start writing for poor readers (distracted, skimming, etc - let people who do this bear the risk and consequences of their actions rather than changing writing to make this behavior less risky)
> Even assuming just upper/lowercase and 20 characters you are looking at 114 bits of entropy.
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.
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.
The birthday paradox only applies when you're trying to find any pair of inputs with the same output, because then the probability of success scales with the number of pairs ≈ guesses^2. If you're trying to find an input with a particular output (in this case one that results in the same key as their password), then on average you'll have to try half the search space (divided by the number of correct answers in the search space, but that should be one in this case)
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
a) The part you quoted stipulated "...in the absence of any sort of opsec failures this implies...". You might be surprised to learn that some folks _can_ run really, really tight opsec.
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.
I don't want to overstate this - it's absolutely possible that the password was obtained through some other mechanism. But a weak password (even if it's 20 characters long!) as the input to PBKDF2 is something that can plausibly be broken in a reasonable timeframe using realistic hardware, and there's a really easy way to fix that, and people who care about this should protect themselves.
> ...it's absolutely possible that the password was obtained through some other mechanism.
+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?".
The creator of LUKS has a few words around this on Reddit. This appears to be a non-story unless you're not practicing best proper password management
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.
I think the creator's comment is talking past the original post: in my reading, it wasn't suggested that a random 20-character password was successfully brute-forced due to a weak KDF. My reading was that the target likely had a strong non-random password, one that was derivable via OSINT or post-seizure forensics (i.e., playing password keyword soup). The KDF's weakness made a search for that password feasible where a strong KDF (like Argon2id) would have prevented it.
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).
And 128 characters chosen by quantum decay in an airgapped facility would be unassailable. But among the many passwords between the two, there is a band of passwords which were reasonably secure under a threat model that excluded massive GPU attacks, and are not reasonably secure when one includes them.
Something I have wondered about as a nerdy person is just typing in your favourite bit of maths (as LaTeX) or similarly pseudocode. Utterly memorable to you, highly unlikely to be memorable to other people, high use of special characters and non-English words, and a reasonable number of characters are generated without brain power. A bad example of this perhaps would be "i\hbar\frac{∂}{∂t}|\psi\rangle=H|\psi\rangle". Burned into my brain, typable quickly on a keyboard with known special character locations (replace ∂ with \partial if that is a concern) and almost _certainly_ not in a wordlist. Shannon entropy of ~4.3, equivalent to ~240 bits of key, and a specific metric entropy of ~0.1.
Honestly that's a pretty good idea, since there are still enough latex commands that you're sitting pretty even with a latex-augmented dictionary attack. Still though, I've never had trouble memorizing 5 word passwords even with weird capitalization patterns, and they're really easy to type compared to anything with a special symbol. Then again I only have 3 passwords on hand and not in a manager, so who knows?
Cleverness can't compete with real entropy. There's a reason that ping-pong balls, and not mathematicians, generate the weekly lottery numbers.
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.
I mean 40 bits is better than a correct-horse-battery-staple format password by a little bit. The space of all interesting equations is presumably tiny, but I do think I could memorize a random twenty-expression password almost as well as I could remember 6 or 7 words (since many random arrangements will be somewhat meaningful). I'll stick with my 5 random words because they're easy to type, but so long as you draw at random it really doesn't matter what you're sampling from.
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.
Once this idea becomes popular, it will get into brute-force probing templates.
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.
Only if you're sure you'll never have to type it when the keyboard layout is set to something different from what you're used to. Good luck remembering where these special chars are...
That’s a third thing: most people don’t use either random passwords or XKCD-style passwords; they use a combination of words, letters, and punctuation that contain some memorable context. That generally produces very mediocre (but not completely terrible) passwords, which a strong KDF then transforms into an infeasible amount of work.
I always find this thinking fascinating. If you are using a suitably strong password, you don't need a KDF. And you _should_ be using a strong password, so we can hand wave any KDF related issues away.
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.
Even when using a very strong password, you should still use a KDF, since many ciphers expect uniformly random keys. But it could be a cheap unsalted one instead of an expensive salted hash.
I really don't get that. I see it happening even in companies that use password managers. Some silly easy passwords and they don't even have to type them, they should copy and paste them from the password manager. I use it to generate random passwords and I can't understand why not everyone is doing it.
Not sure here, but hasn't argon2 some advantages beyond simple brute-force-resistance? (e.g. that it can be made to scale with hardware or better resistance to timing attacks)?
Its main benefit is it's memory-hard in addition to time-hard. You're not just repeating a hash function across a few dozen bytes a few thousand times, you're doing it over tens or hundreds of MB, thus making it much harder to scale up an attack.
I'm french, and the source in french linked is not clear. The article is biased, the comments are saying it's from 2020, and I am pretty sure the french cyber teams would not throw a bunch of GPU to solve a password for a small case like his.
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 ?
Agree, apart from a full-on keylogger, given the password was not super trivial to guess, is some other bad practice like unencrypted swap, though I hope there never was a distro that suggested that setup if you choose full disk encryption in the installer. If he was under surveillance a tampered with initramfs would be my guess.
A naive question: Are KDFs meant to improve the security of systems or merely preserve it? I was under the impression that the purpose of KDFs is twofold:
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.
If the password is, say, 'abcd', then it could be converted into an AES-128 key in the following ways:
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.
On paper, PBKDF2 is a better option because an attacker would need to perform the PBKDF2 computation before each decryption attempt, which would be time-consuming. Therefore, as long as the KDF is implemented correctly, it should offer better protection than the first option.
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).
So there are different types of kdf's. For passwords, the goal of the kdf is to "stretch" the entropy by making the kdf function hard to compute.
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
>they can precompute KDF outputs for each of those passwords and reuse them
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.
Could one seperate the kdf from the disk? Actually, not have any kdf?
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.
To be specific, LUKS supports up to 8 slots. Slots can be used by different decryption mechanisms such as passwords (either typed in, or read from a keyfile), or something like clevis+tang to decrypt the disk on the correct network.
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.
You could enter a password using the Yubikey instead, provided there's a way to input a password. That might make brute-forcing a little challenging especially if you added tamper evidence and heat-sensitive fuses that blow if someone tries to open the case and modify the device. At that point you might be stuck brute forcing with a pen plotter.
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
Possibly an excellent trade-off for a desktop you rarely reboot.
Adding four randomly generated characters a-z to your password adds a factor of 456976x to the bruteforce time required.
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.
That's quite a funny idea. LUKS2 really should do this by default when creating the empty slots when the disk is initialized first time. The used slots will be overwritten by passphrases, but these other slots would be indistingishable and would waste the attacker's time.
Doesn't that just give the attacker more targets to hit?
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 you've got a TPM to leverage, this is essentially actually what systemd-cryptenroll --tpm2* does. Generate a large, cryptographically-secure key and pair it with PBKDF2 with 1000 iterations. Seal that random value in the TPM with optional PIN.
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
> His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation [...]
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.
For a brute force attacker, how does a high entropy 20 character password vs a low entry 20 character password change discovery time? Even throwing in a random character in the middle would probably defeat any shortcuts, no?
I think where this reasoning gets people in trouble is when their 20 char password was leaked by LinkedIn or some such and they've since mutated it by inserting the random character and think it's now secure.
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.
There are 20 places to put the random character, and there are roughly 100 possible values, for a total of 2000 possibilities. Thus, assuming someone has knowledge of you using this trick, it corresponds to adding 11 bits of entropy. There are other similar tricks you could have been using instead, so there may be a few additional bits of security if they know you use some trick but not which one.
> Unfortunately it's not really practical to ask a user to type in 128 bits of binary every time they want to unlock their drive, so another approach has to be taken.
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.
That's not legal in the US though, at least the "destroy if shit hits the fan" part. The only legal solution is a secure password that's never written down or told to anyone else, ever. I really do mean ever, if the police have given up on you but they later find out that there was no incriminating evidence against you on the drive, they could charge you years later for obstructing the investigation. You and your lawyer need to come up with a glomar response strategy (i.e. "neither confirm nor deny") that there is anything on the drive that could incriminate you. You are not protected from providing the data/password if the contents incriminate people other than you and not you, so never say under oath that there's nothing incriminating on your drive, because they will make you prove it.
I found that running tang[1] at home and needing to decrypt that box (can be a Pi or whatever) requiring a complex passphrase is very sufficient. You can even just unplug it at night if it makes you sleep better.
I don't think deniable encryption is needed, you just need to not say under oath "there is nothing on the drive that could incriminate me". If you say that you lose your protection and they can force you to provide the contents. Destroying keys, including wiping a LUKS header, wiping a TPM, destroying a USB hardware security key, etc. is destroying evidence and a crime. Not providing your really long password is not a crime, as long as there is some doubt (doubt you and your lawyer can carefully cultivate) regarding the fact that nothing on the drive incriminates you.
> Not providing your really long password is not a crime
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?
Intentionally entering wrong pins to lock out is probably destruction of evidence, and pins are so short I would not trust them. Just have an at least 15-length base32 password that's randomly generated with `echo "$(openssl rand -base64 20 | base64 --decode | base32 | head -c 15)"` or whatever. You might want it to be lowercase instead, or base64 for more entropy. That command should be secure on OpenSSL 1.1.1 or later, and combined with argon2id over 4GiB of memory and 12+ rounds, should be pretty much uncrackable.
You don't need to trust PINs, they aren't passwords in technical sense. And you don't need to enter wrong PINs either, if someone else tries they would reach a limit very soon.
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.
In theory you could store it both offsite (using a hidden Micro SD card) and on your phone simultaneously, with a special key combination, e.g. pressing Vol Up + Vol Down + Power causing the phone to be rebooted, and the key erased from RAM... So in that case you would need to get the offsite copy, from GPS coordinates you have memorized, using a GPS receiver that is known not to leave any location information in it's EEPROM / Flash.
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.
Sure, knock yourself out if that's your thing. But what I meant was basically "power user" level devices, like what systemd-cryptenroll lists. So fido2, pkcs11 (smartcards and tokens) and tpm2. If you want to bury any of them in the woods, I guess you can.
> ... again and look for the PBKDF: line in each keyslot (pay attention only to the keyslots, ignore any references to pbkdf2 that come after the Digests: line). If the PBKDF is either "pbkdf2" or "argon2i" you should convert to argon2id
All good here then (Debian Bookworm default LUKS install):
I 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.
IIUC the main benifit of Windows and macOS full disk encryption over Linux is that they will use a TPM to protect the key by default. This effectively prevents brute forcing of even very weak passwords at the expense of being unable to recover your data on a different computer.
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.
The TPM is a blessing and a curse. On the one hand, it protects you from having to remember any passwords and makes encryption available to almost anyone.
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.
That assumes the TPM is willing to unseal the drive, so you can use a probe to capture the key as it sends it. Microsoft recommend using TPM+PIN which prevents this as the TPM won't release the key unless you provide the PIN. The PIN can be fairly weak as the TPM prevents brute force.
I'm sure there are still vulnerabilities, but this is the method that governments themselves use for their devices, at least in UK.
Yes, TPM without a password is a step up from no encryption but TPM with even a weak password is a huge benefit.
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.
Use the TPM as an additional layer of protection. In combination with other things as well, heck even the encryption built into an SSD. So if any one fails, it's still better than nothing. All with separate, uncorrelated passphrases.
> What if I want to move my own drive somewhere else?
That's the fun part: you don't. Move the contents somewhere else, format the drive, and move them back. Also another cool feature: if the TPM stops working for some reason you lose all your data! (unless you have offsite backups, which you should anyways). I'm saying this kinda jokingly but this really is a feature of keeping the keys in your TPM, in a lot of situations this is a desired behavior.
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]
>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.
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.
You generally can't backup the TPM key as most TPMs are designed to prevent key material extraction.
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.
They're fine for most use cases. Probably wouldn't trust windows or MacOS against state actors.
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.
They are not sanke oil but "compliance tricks" ;=)
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.
It all depends on your threat model, of course. If you trust Apple and Microsoft and just don't want thieves to read your data, then you can probably rely on OS encryption tools: as far as I know, not even governments have managed to unlock any of these methods without access to a (backup) key. If you're an activist in a totalitarian country, you should take different precautions.
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.
Would help if the comment expanded on what a Shufflecake is. For anyone else reading this, apparently it's "plausible deniability for multiple hidden filesystems on Linux."
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.
The problem with disk encryption on Linux isn't that it doesn't work.
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)
What's missing from cryptsetup? What would you like the state of the tooling to be?
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.
AFAIK some bootloader versions do not support LUKS2 format; this could make for a bad day for some people. Don't blindly follow blogs on a critical topic without more research
I tried encrypting /boot once, but grub2 is painfully slow to do the key derivation that Linux does in a couple of seconds. I understood vectorization makes the difference. The better approach seems to use dm-verity to make sure it's not been manipulated and store any secrets it might need in the TPM. Just for the design. I am not an anarchist or similar target, so I still live with just an encrypted rootfs which should be good enough against a random laptop thief.
Does that support verification of the initramfs? I have the feeling no it doesn't, but I am not sure. (Yes you can build the initramfs into the kernel. But I don't think that's commonly done. And UEFI implementations have undocumented size limits of what they can boot. So even if you are willing to spend the effort to configure that the image might not boot in the end.
>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.
The ESP too small? It's just a partition and filesystem. Of course an ancient filesystem, but I don't think there are any relevant limits. I routinely use ESPs of 1 GB on my R&D systems so it can hold enough images for testing purposes.
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".
>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.
True. I don't use Windows either normally. I have one R&D system which has Windows installed, and of course installed first because I would never trust the Windows installer to leave a Linux installation untouched. It has a disturbingly small ESP. I could just fit 2 kernels + initramfs there. I did not even try to repartition it because I would not be surprised Windows either breaking or reverting some changes at next boot. For me that system is not important and I did not want to spend a single extra minute on it. But obviously someone had to spend a lot of time to cope with that unfriendly system.
Bootloader not really, main problem for me has been server providers with outdated rescue/live images. Everything is fine until you need to use rescue mode and can’t decrypt your root fs
I'm not aware of any bootloaders that support encrypted /boot with LUKS2 aside from GRUB. GRUB itself didn't support LUKS2 until 2021, I believe; I imagine there are many people using versions older than that.
Even with newer versions, some (many?) distro installers still default to using LUKS 1 for the root partition anyway. As the article also says, while grub2 does support LUKS 2 now it still only supports pbkdf2, so having root be LUKS 1 makes it harder to accidentally switch away from pbkdf2.
The issue as I understand it, is that if you want to limit the amount of time that the user has to wait to a second or less (a reasonable assumption) then you can't use all that much memory with Argon2. So you don't get a lot of memory hardness.
Totally random question that I was recently thinking about: can reuse of LUKS passphrases undermine security?
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?
The amount it could potentially "weaken" protection is likely negligible compared to how much it reduces the burden on the user (unless you consider the risk of having a single exposed password in plain text now means N machines are compromised instead of 1).
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.
Seemingly you cannot convert live to LUKS2; you'll need to unmount first. So that's a bit sad, and would probably make distro conversion a more complex.
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.
> Also, if you're using an encrypted /boot, stop now - very recent versions of grub2 support LUKS2, but they don't support argon2id, and this will render your system unbootable.
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.
It's a pain to set up, but you can use the EFISTUB[1] capabilities of the Linux kernel to make it boot itself. Initramfs is then capable of decrypting argon2id LUKS2 partitions.
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.
No need to pull any systemd utilities into this; the kernel can embed its initramfs within the kernel image when you build it -- just point it to either a directory containing the files that should be inside it, or a .cpio archive containing them. You can then sign that kernel image as normal and boot it directly as an EFI application.
Well, the downside to this is that you have to compile your own kernel. Totally speculative, but I think most people (who update their kernel frequently) don't do that.
You, struanr and struanr's [3] link are mixing up two different methods used to boot a kernel as an EFI application. It's a common mistake, you'll find it made a lot on the internet.
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.
I can't find any documentation about how to do that with CONFIG_EFI_STUB. Arch wiki, Gentoo wiki and the kernel docs all talk about specifying the initramfs as an ESP file path. Are you sure you didn't make a UKI (the second method) ?
Yes, they're sure. The kernel config option CONFIG_INITRAMFS_SOURCE lets you specify the path to either a directory or a .cpio archive. The contents of that will then be embedded into the kernel image itself during build. You end up with one binary containing the kernel code and the initramfs, and if you also enabled CONFIG_EFI_STUB, that one binary happens to also be an EFI application and you can digitally sign it for UEFI Secure Boot (or hash it and enroll the hash into the firmware instead, if you want to avoid the hassle of public/private keys -- but if you're rebuilding regularly, it works out to be the opposite; signing with a trusted key is a lot less hassle than constantly enrolling new kernel image hashes).
I think an unencrypted boot should also work fine with GRUB, as that too will let initramfs do the volume unlocking. I was hoping to get encrypted /boot to work.
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.
Maybe using two layers of encryption, so if one fails, then we at least have another one to be bruteforced as a backup? Also two implementations, from different operating systems (!), e.g. why not store the data encrypted on a server running OpenBSD, which is then encrypted again using Linux LUKS. So then both the OpenBSD and Linux implementations would have to fail, in order for the government to be able to decrypt it. Of course, using different, long passphrases for each.
Yes, if used as a root filesystem. My computer is setup to have immutable read-only root filesystem, any changes go to RAM. Except for the home directory. There is no swap either.
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.
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.