
Cracking LUKS/dm-crypt passphrases - dvaun
https://diverto.github.io/2019/11/18/Cracking-LUKS-passphrases
======
loeg
Maybe it goes without saying, but for this to work, your password must be bad
to begin with. Or at least, the article does not point to any significant
design weaknesses in LUKS; it instead documents a variety of ways to get
passphrase-encrypted secrets into existing tools for bruteforcing passwords.
The article suggests it is about backup or data recovery, but I think it is
probably more interesting to people in the business of digital forensics.

~~~
polack
I agree with you, but I actually used the brute force for data recovery.

I had a NAS with a 22 characters passphrase that I had up and running for
years and eventually forgot the password to. When I set it up I practiced the
password enough times that I was sure I would never forget it so I never
stored it anywhere. After years of never rebooting the NAS parts of the
passphrase eventually got blurry and when I was about to move I realized I
couldn't remember it anymore. I didn't really have anything of high value
stored on it, but it kind of became a pet project to try to "crack" into it
again. Together with Hashcat and the extracted header I eventually managed to
brute force it after a couple of weeks :)

~~~
DyslexicAtheist
one way to solve the problem of memorizing (long passwords) is to use
something like this:

to avoid forgetting it use a string of words that make sense to your brain[1]
but are unlikely to be encountered in the wild (in any texts).

Example passphrase: _" My hamster kicks soapy homework with smurf locks like a
tandem at 45 o clock!"_

Then use this to generate a hash which can never be remembered in itself, and
is unlikely to be brute-forced:

    
    
      $  echo -n "My hamster kicks soapy homework with smurf locks like a tandem at 45 o clock!" | sha512sum
      7364796a1ad957d7c524165aa2fec2501eaa59e6bd8380bad3252504cdb8592018e30ae2fff1b2c2295e6da7a7f47f52ef1c0e3010c054598d76fe0c6d64bac6  -
    
    

this way there is no need to remember the hash itself as long as you know how
to recreate the hash (+ have the tooling present like sha512sum).

In case you want to change the hash without having to remember a new
passphrase just twiddle with the input string (by changing one character only)
to get a totally new hash.

If you're on a multi-tenant machine this is probably dangerous since running
_`ps`_ might show other users on the system the input string when you run the
command. Not an issue with single user systems. In case you want to avoid the
command being recorded in your shell history file you can prefix the whole
command with a blank (space).

Benefit of this is you get a pretty long hash that is impossible to brute-
force and extremely hard to remember, which makes it really useful as a
master-password.

~~~
monort
You are susceptible to a length extension attack if you use sha-512 this way.
You should hash twice or use sha-3

[https://en.wikipedia.org/wiki/Length_extension_attack](https://en.wikipedia.org/wiki/Length_extension_attack)

~~~
bscphil
I think you misunderstood what they are using the hash for - neither the hash
nor the plaintext should ever be revealed to a third party anyway.

That said, I don't really see the point since it's no more secure than just
using the long passphrase directly.

~~~
DyslexicAtheist
_> don't really see the point since it's no more secure than just using the
long passphrase directly. _

a 5 word passphrase isn't automatically more secure than a 5 char password if
the words are predictable. interesing paper goes into this[1]. brains are
generally bad in coming up with good passphrases (not enough entropy :)).

while my example is certainly very hard to predict I want to rule out an
attacker predicting what makes the (nonsensical) passphrase.

[https://eprint.iacr.org/2016/246.pdf](https://eprint.iacr.org/2016/246.pdf)

Edit: there is also a video to the above paper:
[https://www.youtube.com/watch?v=6-vrumB0UUw](https://www.youtube.com/watch?v=6-vrumB0UUw)

~~~
bscphil
Right, but usually designs for password systems assume that the whole system
is transparent to the attacker, in which case hashing it before use doesn't
buy you anything. If your input phrase is low entropy then a hacker can
compute sha512sum(low entropy phrase) just as easily as you can.

So to get anything out of doing this is basically just assuming that your
attacker won't know (or guess) that you're doing this. Maybe it doesn't hurt,
but I wouldn't trust it with a low entropy passphrase. I suppose one use for
it would be getting more entropy on sites with low password length
requirements, like 10-15 characters max.

Another possible problem is if your computer gets stolen and the `echo xxx |
sha512sum` command is in your .bash_history file. To me this seems to add a
lot of additional risk.

------
Aardwolf
I admit I didn't read the entire article, I've been reading only the text
around instances of argon and PBKDF, but:

can someone ELI5 how they do 882 hashes per second if PBKDF2 is set up to take
2 seconds, for example? What's so broken about PBKDF2 that they get a > 1000x
speedup?

~~~
simcop2387
It's trivially parrallelizable so I suspect that they're doing it on a gpu or
something like that.

~~~
wongarsu
Which is a known "vulnerability" of PBKDF2. In any modern setup you are better
served by Argon2 (or if that's not available at least scrypt). CPU time is
cheap to parallelize, memory bandwidth is much harder to scale.

~~~
Aardwolf
There must, in addition to memory, be other things that are hard to
parallelize on GPU's, right? How would 64-bit integer division do on a GPU?
The GPU does not have 1000x more transistors than a CPU, it can't be 1000x
faster for everything, right?

The annoying thing is LUKS1 only supports PBKDF2, but LUKS2 comes with a JSON
parser, and no full support everywhere yet

~~~
wongarsu
GPUs are essentially wide SIMD processors. If cores take different branches
that can slow them down dramatically, in the worst case all cores have to
execute all branches.

The other thing that slows them down is memory access. Caches are small
because everything adds up quickly once you multiply it by a few thousand.
They are optimized for access patterns typical in graphics, which is mostly
sequential or every-x-bytes. The main memory might be GDDR5 or GDDR6, but even
the 600GB/s memory bandwidth of the RTX 2080TI is quickly used up once you
have 8000 threads requesting random bytes from memory.

Apart from branching and memory I don't think GPUs have many weaknesses. They
can save a lot of transistors because they don't care about single-core
performance. For example instead of doing sophisticated instruction reordering
to hide memory latency they just switch to a different set of threads whenever
they would otherwise wait for memory. There are some tasks that Intel CPUs
have transistors dedicated to like AES or 64bit integers and they do loose
some speed on those, but at the same time these things are easy to do in
silicon so your CPU loses to ASICs. And even a GPU eventually has enough cores
that the software implementation run 4000 times in parallel will beat the CPU
by a wide margin again.

------
quotemstr
Sure. That's why I wish I could do LUKS authentication via TPM, which can do
hardware rate-limiting. Is this kind of setup possible these days?

~~~
anon9001
You can use a yubikey to do it. It can work in challenge/response mode, so the
yubikey is required to unlock the device. That's good for laptops.

You can also use a private gpg key and an gpg-encrypted keyfile. Yubikey can
store gpg keys (with attestation if you want), and you can enable both yubikey
access and gpg in initramfs. That's good for servers if you pair it with
initramfs sshd.

TPM is kind of broken, as I understand it, so I didn't even bother looking
into it. There's really no reason I can't carry my keys on my physical
keychain, so I don't see a need for TPM. I can also put a USB stick on my
keychain and use that to boot.

That way even if an attacker has physical access to the hardware, it would be
require some really advanced firmware/microcode hackery to compromise the
machine.

~~~
quotemstr
How is TPM broken? I'm curious.

~~~
anon9001
Some TPM chips are vulnerable to key dumping:
[https://www.schneier.com/blog/archives/2019/11/tpm-
fail_atta...](https://www.schneier.com/blog/archives/2019/11/tpm-
fail_attack.html)

TPM dies if your motherboard dies, so you'd need a backup key anyway.

There's also no way for you to independently audit the TPM device, so you
don't know how secure it really is. Personally, I don't trust Intel to keep
the TPM secure, as they've shown they can't (see the above link).

The keys are in the chip if you use them for FDE, so you're expanding your
trust that someone with access to the TPM can never dump the keys. This could
be a problem if your machine is stolen.

By going the yubikey route, you can move the trust to a device that's
physically on your person. That way, if the machine is stolen, there's
absolutely no way to recover the keys, and there never will be even if more
intel vulnerabilities are found.

You could use a yubikey for the FDE keys, and only use TPM for trusting the
boot device. But if you're already carrying a yubikey to decrypt your device,
you might as well boot off USB too.

------
luksflux
Good luck with people like me. As ypu know, luks per default allows over 8
megabytes of key, so, i just make a dev/urandom file that is up to the byte
filling the top default keysize, which means a password of over 8 million
characters, of which none or very few at best are found via the keyboard. I
use at the minimum 8 million chars on all my luks devices. And I've set the
key stretching to take above 15 mins to unlock, even with the right password,
so good luck with John the ripper.

~~~
loeg
I have to assume this is a joke. If it isn't, well. There's not a lot of
reason to use more than 32 bytes from /dev/urandom. The extra 7.97 MB of key
aren't doing you any favors, nor is 15 minutes of unlock time helping — zero
seconds would be fine for this use.

------
AdmiralAsshat
I peaked at some of the stats regarding his brute force attempt, but I
couldn't figure out how much progress he was making and whether a bf was
actually feasible with LUKS. Is it something to be concerned about at this
stage?

~~~
loeg
LUKS1 (2004 design) uses PBKDF2 with 2 seconds worth of iterations. It's not
especially susceptible to brute force. The only reasons to be concerned are
(1) your password is very weak, or (2) you initialized the LUKS volume on an
extremely low power or heavily oversubscribed CPU such that 2 seconds of
PBKDF2 iterations is below the 2016 NIST recommendation for 10,000 iterations.
(The LUKS implementation may/should have an iteration floor that would make
this (2) concern invalid, but I'm unfamiliar with the codebase and unable to
speak to that.)

LUKS2 uses argon2.

See, e.g., _Cryptographic Right Answers_ [1]:

> Password handling

> Percival, 2009: scrypt or PBKDF2.

> Ptacek, 2015: In order of preference, use scrypt, bcrypt, and then if
> nothing else is available PBKDF2.

> Latacora, 2018: In order of preference, use scrypt, argon2, bcrypt, and then
> if nothing else is available PBKDF2.

[1]: [https://latacora.micro.blog/2018/04/03/cryptographic-
right-a...](https://latacora.micro.blog/2018/04/03/cryptographic-right-
answers.html)

