# How to test security of LUKS encrypted volumes?

## o5gmmob8

Hi all,

I have encrypted my drives using LVM with LUKS and was wondering how secure the data actually is.

I was wondering if there is some automated tool I can use much like john the ripper for cracking passwords to determine that a drive is indeed encrypted, what algorithm, padding, and mode it is using, and finally brute force attack it to determine the password(s) used to encrypt the volume.

I've run john the ripper in the past against my passwords and manually stopped the brute force after about a month, whereas I believe I've run something else against Windows passwords and that cracked them in a matter of seconds.  I was just curious from a security standpoint, if my drive would get intercepted, what could be deciphered, when, etc.

Walter

----------

## Goverp

 *walterw wrote:*   

> ...
> 
> I have encrypted my drives using LVM with LUKS and was wondering how secure the data actually is.
> 
> I was wondering if there is some automated tool I can use much like john the ripper for cracking passwords to determine that a drive is indeed encrypted, what algorithm, padding, and mode it is using, and finally brute force attack it to determine the password(s) used to encrypt the volume.
> ...

 

You're not testing the security of your volumes, your testing the security of your password.

To test the security of your volumes, give a copy to an enemy  :Smile: 

More seriously, I don't think you can really test LUKS security; you can read up on what security researchers think about LUKS (which is, I believe, very, very good).  An encrypted disk should look like random noise, so no tool can determine which algorithm, padding or mode is being used unless the encryption algorithm is rubbish!  Sometimes security systems leave stuff about that can be used to crack passwords - perhaps your Windows experience was related to that - though I believe Windows security is mostly good.

You're right to worry about passwords and cracking packages - of course a weak password compromises any system, no matter how secure.  You can use the same password on different systems, and therefore use one where your choice of cracking tool will run - though you want to be sure you don't leave a copy of the password lying around as a result.

The thing about passwords - or rather, pass phrases - for fundamental protections like LUKS or password vaults is that, of course, they should be hard to guess.  That means lots of variations, because the crypto system will use the password to generate a pseudo-random bit string, and if the password is too short, there will be only a few bit strings to try.  Bit strings generated from English language passwords are reckoned to get about 1.5 bits per character - very few, because Engligh (and most written languages) follow patterns determined by spelling and pronunciation.

Pass-phrases use symmetric encryption, so you're looking at the length of the AES key you're trying to protect - typically 256 bits, rather than the a public-key encryption key (1024 or 2048 bits), which makes things a bit easier.  But if you believe you need to protect the security of a 256 bit AES key, an English pass phrase needs to be about 170 characters long!  The trouble with that is such phrases are nearly impossible to type without error, or remember without writing down.

Some ways to handle this:

Generate a random password using letters and numbers using a reliable package.  As they aren't English you typically get one of 36 random values per character, i.e. about 5 bits, so you "only" need remember a 50 character string (!).  More realistically, an 8 character string gives about 40 bits of security, and importantly the dictionary attacks used by most password crackers are useless.  I find I can memorize an 8 character random password by using it for about half an hour - any less and it will probably be gone the next day.

Use a pattern to combine strings you know from unrelated sources - such as lines from addresses, car registrations, telephone numbers.  They're good to defeat dictionary attacks, easy to remember, and hard to guess unless the attacker can find out about you personally (so maybe not good for hiding secrets from the IRS  :Smile: 

Use two-part security, where you need both a password and a password-protected security device such as a USB memory stick containing the real key.  Then the attacker needs the memory stick as well as the LUKS volume.  This is probably the best security provided you never leave the memory stick in the PC unattended, and of course you have a backup copy stored somewhere safe.

One rule beloved of security advisers is to change your password regularly.  This makes a lot of work remembering stuff.  However, at least one adviser, Bruce Schneier, says don't bother to change your password unless you have reason to believe it's been compromised.  I agree with that.  But avoiding compromise means you NEVER write it down or store it in a computer system, and you don't type it in on a system where someone might have installed a key-logger.

Don't forget that none of this protects against attacks from the Internet.  If your PC is attached to the net, an attacker can read it just like any application code, so the length of password is completely irrelevant.  So to take this seriously, you need a firewall, anti-virus, anti-fishing and intrusion-detection tools.  And to review the logs regularly.

----------

## o5gmmob8

Hi Greybeard,

Thanks for your insight, it was certainly lengthy.

I guess that is the message I am getting is that there is no automated, brute force way to do all of those things.  I guess if there were, it would probably be in the hands of the NSA or something.

That said, going forward for me, I already have a firewall (which I believe to be rather strict), and will probably consider using anti-virus software along with running an application to monitor log files.

Thanks,

Walter

----------

## Goverp

Walter,

Your question prompted me to lookup "two factor authentication" with LUKS.  Two factors is the third of the options in my list above, where you have a password and a USB memory stick.  IMHO it's the best approach to securing something like LUKS. The general approach is to store a long truly random LUKS key in the memory stick, and protect that with a password.

I found a long a detailed write-up for Ubuntu, but nothing specific to Gentoo.  IIUC, it's possible to migrate from simple pass-phrase to two factors by adding a new LUKS key and then deleting the pass-phrase when you're confident it all works.  I've not tried it, as it gives me nightmares of being so secure even I couldn't get into my own system   :Very Happy:   I'm going to look at it again though, as my PC is collecting too much information about me...

----------

## o5gmmob8

Hi Greybeard,

Cool, I read something about using a USB key to store your private key or something, but this "2 factor authentication" seems to be a little safer.  In the end though, it boils down to the security of your password.

I'll have to experiment with encryption and updating the password(s) to see what happens when you get locked out.

On a side note, do you have any experience with pam mount with LUKS?  I just had a first stab at it and I used documentation that seemed a few years old.  I can login fine, but my encrypted volume is not mounted.  Also, the password prompt now says, pam_mount password.

Walter

----------

## malern

Brute-forcing a password does test an encryption schemes security to some degree. A password can be checked more quickly with some schemes than others, making them less secure in that regard. LUKS is designed to be more resistant to brute force attacks by making the key setup more CPU intensive, and therefore reducing how many passwords you can try in a given time period.

It would be interesting to do some real world tests against LUKS, and compare it to other encryption schemes. I'd like to see how many passwords-per-second can be checked on an average desktop machine. Unfortunately I don't know of any tools for brute forcing LUKS. You could create a script that repeatedly called luksOpen, but I imagine the overhead in doing that for each iteration would eclipse the actual time spent checking the password.

----------

## frostschutz

To verify that the encryption works in general, it's sufficient to run hexdump or strings on the raw device.

Some people get a bad suprise here already (didn't wipe their disk correctly and had old, unencrypted version of their data, still accessible in the "free space" of the encrypted partition).

Then if it looks random, you can verify that it actually is random, even when the data itself is not random (zeroes). As in pick a substring with a decent length and see how often it occurs. If a seemingly random 32 byte sequence is in there not just once or with a lot of luck maybe twice, but a hundred times, there's something wrong with your block cipher. Many hardware AES devices suffer from this problem, AES is not secure by itself...

Also make sure that your password is long enough so that a large number of tries is necessary to brute force it. Long time to verify each individual password is not enough as this can probably be sped up considerably using specific hardware... so it has to be strong against brute force even if password verification is fast (so you need a lot of tries).

For a more detailed analysis you need to know a lot more about cryptography... that's not easy at all so you just have to trust that other people did this work for you.

----------

## kernelOfTruth

*subscribes*

thanks for this informative thread !

found another interesting thread with informative links:

 thread 

links:

http://linuxgazette.net/140/pfeiffer.html

http://mareichelt.de/pub/texts.cryptoloop.php

----------

## o5gmmob8

I guess my other question regarding that matter as well is, what can you do in terms of data recovery?  In the event of a hard-disk failure, what can you do at that point to recover the data?  If your luks encrypted device is still intact, but the file system is not, then you can at least use file system tools at that point.  But what if the device no longer becomes recognizable?

Walter

----------

## frostschutz

 *walterw wrote:*   

> In the event of a hard-disk failure, what can you do at that point to recover the data?

 

Possibly nothing whatsoever. If you rely on recovery possibilities after a hard drive failure, you've lost either way. What you need is a backup solution.

----------

## jchau

Goverp, you offer some valid points, but I'll have to correct you on a few points to avoid misconceptions:

 *Goverp wrote:*   

> More seriously, I don't think you can really test LUKS security; you can read up on what security researchers think about LUKS (which is, I believe, very, very good).  An encrypted disk should look like random noise, so no tool can determine which algorithm, padding or mode is being used unless the encryption algorithm is rubbish!  

 

Hiding the "algorithm, padding or mode" is not necessary for good encryption.  On the contrary, LUKS, which you claim is "very, very good" explicitly provides this information to anyone who can read the disk (you don't even need to know the key or the password).  To see what I mean, try

```
cryptsetup luksDump /dev/sdb1
```

where /dev/sdb1 is the encrypted partition and it'll tell you something like

```
Cipher name:    aes

Cipher mode:    cbc-essiv:sha256

```

 *Goverp wrote:*   

> ...the crypto system will use the password to generate a pseudo-random bit string...
> 
> Pass-phrases use symmetric encryption, so you're looking at the length of the AES key you're trying to protect - typically 256 bits, rather than the a public-key encryption key (1024 or 2048 bits), which makes things a bit easier.  

 

Just to clarify, assuming that you picked AES to encrypt your drive, the password you choose is used to generate pseudo-random key.  This pseudo-random key is then used to encrypt a separate randomly-generated AES key, which is used to actually encrypt the content of your drive.  Also, although longer & more complicated passwords can improve security, and although encrypting more data with the same key can marginally reduce security, you don't really need to use a longer password to protect longer data (i.e., you don't need a longer password to protect a 2048-bit private key than you do to protect a 256-bit symmetric key).  

Also, a relevant warning:

If you store the real key on a USB drive, and if anyone untrustworthy ever gets a chance to make a copy of the USB drive, you better have a really good password protecting the key.  Changing your password in this case won't help since LUKS doesn't change the key actually used to encrypt your drive; LUKS will just re-encrypt the same key using the new password.  But since the attacker already has a copy of the key encrypted with the old password, she can still get the key by using the old password.  

The same applies if you didn't put the key on a separate drive, but someone was able to copy the encrypted drive.  

----------

## o5gmmob8

jchau,

Ok, I was just curious - perhaps in the future, there will be better tools for testing security.  I know you can read stuff, but theory goes hand and hand with reality.

I don't use USB keys for that reason, it is an extra thing to carry around.

Walter

----------

## frostschutz

 *walterw wrote:*   

> I don't use USB keys for that reason, it is an extra thing to carry around.

 

Not really... they're really small, no larger than a regular key, and you can carry them on the same keychain... Also dead useful... my USB stick not only unlocks my LUKS hard drives, but also serves as Linux Live and Rescue CD in several flavours. Visiting a friend who's got a Windows netbook? Put in your stick and it's a Linux netbook, at least while you're the one who's using it  :Laughing:  etc. Plus it's nice to know that no one can mess with my bootloader / initramfs while I'm away... otherwise it'd be easy for someone to just install a keylogger and your encryption goes *poof*...

----------

