[HN Gopher] PSA: Upgrade your LUKS key derivation function
___________________________________________________________________
PSA: Upgrade your LUKS key derivation function
Author : YakBizzarro
Score : 243 points
Date : 2023-04-18 08:33 UTC (14 hours ago)
(HTM) web link (mjg59.dreamwidth.org)
(TXT) w3m dump (mjg59.dreamwidth.org)
| ryan-c wrote:
| I would highly recommend setting the key derivation parameters to
| take as long as you can tolerate.
|
| For example: --pbkdf argon2id --pbkdf-
| memory 4194304 --pbkdf-parallel 4 --iter-time
| 60000
|
| (4GiB memory cost - it's specified in KiB, 4 threads (maximum),
| 60 seconds target time)
|
| 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.
| ryan-c wrote:
| Also, if you want to be a troll, add some additional passwords
| (LUKS2 supports multiple) with weak KDF parameters that are
| generated like this: head -c48 /dev/urandom |
| base64
|
| It won't add much to your unlock time, but anyone trying to
| crack your disk will probably try the "easier" ones first.
| rwmj wrote:
| 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.
| Arnavion wrote:
| It would make typoing the password annoying for legitimate
| users too, so it wouldn't be good to enable it by default.
| __MatrixMan__ wrote:
| 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.
| sowbug wrote:
| Each of those red-herring passphrases is 384 bits. Enough
| said.
| orlp wrote:
| 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.
| ryan-c wrote:
| Adding extra random characters to the end of the passphrase
| requires effort from the user, key derivation only requires
| them to wait.
|
| 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.
| [deleted]
| pshirshov wrote:
| There is the same (and ignored) problem in OpenZFS:
| https://github.com/openzfs/zfs/issues/14762
|
| Please vote there.
| Sesse__ wrote:
| 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.
| Arnavion wrote:
| >So that's a bit sad, and would probably make distro conversion
| a more complex.
|
| It shouldn't be. It can be done on next boot by the initramfs,
| before the real root etc are mounted.
| Sesse__ wrote:
| Yes, it means you need a reboot at the very least, and
| initramfs integration.
| thway15269037 wrote:
| 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?
| KingMachiavelli wrote:
| 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.
| snowstormsun wrote:
| Yeah there's a salt used
| orlp wrote:
| > 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.
| zokier wrote:
| 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 20e6x86400x30x1000
| combinations. Log2 of that rounds up to 56 bits.
|
| https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
| [deleted]
| CodesInChaos wrote:
| 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.
|
| 2^114/350e18/3600/24/365 = 1.9e6
|
| Even 2^114 itself is only 2 * 10^34
| codethief wrote:
| 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"?
| orlp wrote:
| 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 numbers were completely off.
| 8organicbits wrote:
| > 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.
| [deleted]
| corndoge wrote:
| NSA agent spotted /s
| mox1 wrote:
| 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.
| comboy wrote:
| > 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)
| realusername wrote:
| 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
| [deleted]
| survirtual wrote:
| [flagged]
| Arnavion wrote:
| >Prove me wrong. Show me in their source code of the OS
| you're running that they don't do this.
|
| https://github.com/torvalds/linux
|
| https://gitlab.gnome.org/World/Phosh/phosh/
| heavyset_go wrote:
| 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.
| flangola7 wrote:
| Do you have any legal cases where this occurred?
|
| While it is technologically possible, I have never heard of
| a case of this actually happening.
| mox1 wrote:
| Ahh yes the classic "prove a negative".
| ravi-delia wrote:
| ...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
| ryan-c wrote:
| 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.
|
| For example, A11 y0ur b4s3 4r3 b3l0ng 70 u5!
|
| would be trivial to guess.
| dhx wrote:
| 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"
|
| [1] https://anarchistnews.org/content/update-letter-ivan-alocco
|
| [2] https://en.wikipedia.org/wiki/Black-bag_cryptanalysis
| mjg59 wrote:
| 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.
| AlexCoventry wrote:
| 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.)
| [deleted]
| aborsy wrote:
| 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.
| mort96 wrote:
| 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.
| raverbashing wrote:
| 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).
| mjg59 wrote:
| A stronger KDF would plausibly have protected him even if
| his password was embarrassingly deterministic.
| stouset wrote:
| Maybe. But probably not.
|
| 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.
| segfaultbuserr wrote:
| > _so in the absence of any sort of opsec failures [...]_
|
| The original sentence already came with this disclaimer.
| wallmountedtv wrote:
| Agreed. Annoyingly the author does split up a very core idea
| to the next paragraph:
|
| > 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.
| eduction wrote:
| 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)
| comboy wrote:
| > absence of any sort of opsec failures
|
| There is no such thing.
| BeefWellington wrote:
| While I agree in the specifics the overall message still stands
| IMO: Update your KDF going forward if you care about this kind
| of security.
| simoncion wrote:
| 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.
| mjg59 wrote:
| 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.
| simoncion wrote:
| > ...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?".
| acchow wrote:
| > it would still take you 4 x 10^37 centuries.
|
| 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.
| benlivengood wrote:
| 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
| dangerlibrary wrote:
| > English has ~1 bit of entropy per character.
|
| 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.
| michaelmrose wrote:
| You are confusing the fact that you can store in some
| encodings one character per byte, 8 bits, with a bit of
| entropy.
| ravi-delia wrote:
| 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.
| nickelpro wrote:
| Please explain the math behind a 26 letter alphabet having 1
| bit per character
| dangerlibrary wrote:
| I was also skeptical of this claim. It seems to come from
| Schneier's "Applied Cryptography" and assumes you are using
| whole words in the password.
|
| 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
| [deleted]
| AlexCoventry wrote:
| > As an example of a numerical value, GPT-2 achieves 1 bit
| per character (=token) on a Wikipedia data set
|
| 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)
| ravi-delia wrote:
| 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 4 _lg(100000) = 33
|
| And this one of the same length where each character was
| chosen from a bank of 68:
|
| VIW&jubiHZUgBrFA8PI9Vy1_E(%G 28*lg(68) = 170
| seanhunter wrote:
| 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?
| ravi-delia wrote:
| 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.
| Brian_K_White wrote:
| 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.
| TacticalCoder wrote:
| > Could one seperate the kdf from the disk? Actually, not have
| any kdf?
|
| 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 : )
| waste_monk wrote:
| LUKS already supports keyfiles:
| https://wiki.archlinux.org/title/dm-crypt/Device_encryption#...
|
| 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.
| riceart wrote:
| Yes it is just another mechanism for header decryption. You
| can replace these keys just like a pass phrase.
| tetha wrote:
| 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.
| snowstormsun wrote:
| The limit of 8 slots is only true for the older LUKS1
| version
| deafpolygon wrote:
| Interesting article;
|
| 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.
|
| Any advice or tips for me?
| kevincox wrote:
| 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.
| 0cf8612b2e1e wrote:
| By design, does the TPM prevent me from making a backup of
| own keys? What if I want to move my own drive somewhere else?
| doodlesdev wrote:
| > 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]
|
| [0]: https://www.tomshardware.com/news/crucial-samsung-ssd-
| encryp...
|
| [1]: https://twitter.com/matthew_d_green/status/10594413723
| 175813...
| kevincox wrote:
| 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.
| jeroenhd wrote:
| 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.
|
| 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.
| jsmith99 wrote:
| 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.
| kevincox wrote:
| 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.
| 1827162 wrote:
| 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.
| gruez wrote:
| >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/
|
| That only works for dTPMs. fTPMs (ie. ones built into the
| cpu) is safe from that attack, although they might have
| other weaknesses.
| nh2 wrote:
| It's not quite clear to me whether fTPMs really protect
| against hardware attacks.
|
| 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.
| onlypositive wrote:
| 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.
| veeti wrote:
| I will never trust the FDE implementation shipped on an SSD.
|
| [1] https://www.tomshardware.com/news/crucial-samsung-ssd-
| encryp...
| sampa wrote:
| SSD password in BIOS is mostly a snake oil. Nobody verifies
| that the encryption scheme is sound.
|
| PS And when somebody takes a look at it, most of the time it
| is broken. Google the research.
| dathinab wrote:
| 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.
| petepete wrote:
| If anyone is looking into self encrypting drives, the main
| specification is called Opal.
|
| https://en.wikipedia.org/wiki/Opal_Storage_Specification
| jeroenhd wrote:
| 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(tm) for most
| people.
| runeks wrote:
| > 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.
| vlovich123 wrote:
| 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?
| im3w1l wrote:
| 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.
| vlovich123 wrote:
| Right. But it requires some starting point for the password
| in the first place.
| __MatrixMan__ wrote:
| 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.
| xaduha wrote:
| > 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.
| Vecr wrote:
| 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.
| asmor wrote:
| 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.
|
| https://github.com/latchset/tang
| xaduha wrote:
| That's usually where people bring up plausible deniability,
| off-topic and was discussed to death elsewhere anyway.
|
| https://en.wikipedia.org/wiki/Deniable_encryption
| Vecr wrote:
| 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.
| 1827162 wrote:
| 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.
| xaduha wrote:
| 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.
|
| https://www.freedesktop.org/software/systemd/man/systemd-
| cry...
| IAmLiterallyAB wrote:
| According to one of the experts on the panel of the Password
| Hashing Competition, Argon2 is actually weaker than bcrypt
| https://twitter.com/TerahashCorp/status/1155129705034653698
|
| 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.
| JeremyBanks wrote:
| [dead]
| stevelacy wrote:
| Farther comments in that thread indicate they are referring to
| PHF (password hashing function) not KDF (key derivation
| function). LUKS uses a KDF.
| upofadown wrote:
| 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.
| olabyne wrote:
| 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 ?
| iforgotpassword wrote:
| 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.
| dylan808hewitt wrote:
| [dead]
| jagrsw wrote:
| 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).
|
| PS: Not a cryptographer, please don't shoot!
| bawolff wrote:
| 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
| gruez wrote:
| >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.
| jagrsw wrote:
| Ah.. that makes sense. I was sort-a stuck in the WiFi/WPA
| mode, where there are no explicit salts (I guess ssid names
| can be considered as such).
| 1827162 wrote:
| 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.
| snowstormsun wrote:
| That would impact r/w performance heavily.
| the-anarchist wrote:
| On a side note, regardless of whether and how big of an issue
| this is, from what I understand OpenZFS uses the same KDF:
| https://github.com/openzfs/zfs/issues/10764
|
| Gladly correct me in case I'm wrong.
| brnt wrote:
| Am I the only one that chiefly uses FDE just so I only have to
| overwrite the LUKS header when I pass the drive on?
| throwawaaarrgh wrote:
| 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
| tgflynn wrote:
| The article warns against doing this if your /boot filesystem
| is encrypted.
| forbiddenlake wrote:
| Can you expand on "some"? The article mentions grub2.
| ijlx wrote:
| 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.
| josephcsible wrote:
| Your bootloader doesn't need to support it unless you insist on
| encrypting /boot.
| [deleted]
| usr1106 wrote:
| 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.
| Arnavion wrote:
| Or use UEFI + Secure Boot instead if your motherboard lets
| you.
| usr1106 wrote:
| 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.
| ttyprintk wrote:
| Shufflecake has been posted recently:
|
| https://news.ycombinator.com/item?id=33586503
|
| https://shufflecake.net/#news
| jzb wrote:
| 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.
| j0e1 wrote:
| Obligatory xkcd: https://xkcd.com/538/
| [deleted]
| jeroenhd wrote:
| > 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.
| struanr wrote:
| 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.
|
| [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...
| jeroenhd wrote:
| 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.
| aaronmdjones wrote:
| 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.
| xx_ns wrote:
| 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.
| Arnavion wrote:
| 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.
| mjg59 wrote:
| argon2i is a strict improvement over PBKDF2, but sadly grub2
| doesn't support any argon2 KDFs right now.
| jeroenhd wrote:
| I see, I must've misread. Thank you!
| TacticalCoder wrote:
| > ... 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):
| cryptsetup luksDump /dev/... | grep PBKDF PBKDF: argon2id
| dathinab wrote:
| 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)
| asmor wrote:
| 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.
| 12345hn6789 wrote:
| 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.
|
| [0]https://www.reddit.com/r/linux/comments/12q51ce/psa_upgrade_..
| .
| blueflow wrote:
| How do you even get a "Social Justice Warrior" badge on reddit?
| steelbrain wrote:
| In most subreddits, you can choose your own flair through
| reddit preferences.
|
| 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.
| atoav wrote:
| 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)?
| 8organicbits wrote:
| 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.
| CodesInChaos wrote:
| 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.
| pmontra wrote:
| 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.
| [deleted]
| woodruffw wrote:
| 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).
| GoblinSlayer wrote:
| Something like correct horse battery staple can be guessed on
| first try, no KDF will save you then.
| ravi-delia wrote:
| 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.
| azalemeth wrote:
| 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.
| sowbug wrote:
| 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.
| ravi-delia wrote:
| 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.
| ravi-delia wrote:
| 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?
| nine_k wrote:
| 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.
| Crontab wrote:
| I think the mention that upgrading your distro doesn't
| automatically enable a better KDF for LUKS is a good point.
___________________________________________________________________
(page generated 2023-04-18 23:01 UTC)