0

I want to increase the time it would take to brute force my full disc encryption. I’m on Ubuntu and encrypted with Luks on installation. I have read that I would use the following command to make it so that only one password could be entered every 10 seconds,

$ sudo cryptsetup luksChangeKey --iter-time 10000 <device>

Would I replace “device” with “/boot”? Not sure if I need to do this with the boot partition, my main partition or both.

2
  • I wonder: Did you read the manual (man cryptsetup)? Your --iter-time 10000 would mean that a successful authentication would need more than three hours to succeed. That will definitely slow down any brute force attack, but maybe your laptop battery will be empty before having even authgenticated (unlocked) your LUKS device once.
    – U. Windl
    Commented Apr 28, 2021 at 8:14
  • 1
    @U. Windl - 10000 milliseconds (10 seconds), not 10000 seconds (3 hours). Commented Apr 28, 2021 at 15:42

4 Answers 4

2

Anyone trying to brute force your encrypted disk would be running the attack on their computer(s) against your disk headers. System parameters on your OS would be meaningless.

Edit

Per U. Windl's comment I looked more carefully. My original statement above is still correct, however iter-time is not a system parameter as I incorrectly assumed from the name.

iter-time is not exactly time at all, it appears to be iterations defined in what I would consider to be a strange way using time. Instead of a fixed iteration count, it is the number of iterations possible on that specific machine in the defined msec stated by iter-time. So yes the iter-time parameter is time, but it results in differing iteration counts as a function of the speed of that specific machine.

I found Linux-Blog – Dr. Mönchmeyer to be very informative.

A few quotes from the article I found interesting:

...It is the calculation of the Master Key which leads to huge delay times. The aes-decryption itself is not a major source of the boot delay time ...

This suggests that brute force pass phrase guessing is slowed, but raw key guessing would not be affected. Realistically raw key guessing would be hopeless anyway.

...One should also take into account that an attacker which got the encrypted disk under his physical control would try to break LUKS passwords on much faster machines than yours. So several 10 millions PBKDF2-iterations per second are certainly possible - meaning multiple password trials per second. ...

Thanks again to U. Windl for the kick to look further.

1
  • It seems you don't understand how the LUKS encryption (specifically "iterations") work: It will definitely slow down brute force attacks, even offline ones.
    – U. Windl
    Commented Apr 28, 2021 at 8:16
0

You would run this command on your encrypted partition(s). This does not normally include /boot because the system needs to load code to find and decrypt your LUKS partition.

To find all LUKS-encrypted partitions on your system:

sudo fdisk -l |grep ^/dev/ |grep -Eo '^\S+' |xargs --max-args=1 -d '\n' -I DEV bash -c 'sudo cryptsetup isLuks DEV && echo DEV'

Note that the cryptsetup man page says that using --iter-time "does slow down all later luksOpen operations accordingly." In other words, you'll have to wait 10 seconds to unlock your partition, even if you type the correct passphrase. Also, I believe the 10 seconds is computed for your system, so using faster and/or multiple computers would be able to crack your passphrase faster.

Make sure to use a strong passphrase!

1
  • I'm surprised what people tell here: You can definitely encrypt /boot for example when using GRUB2 bootloader. Probably you'll have to supply the password inside an early GRUB stage even before you can access the GRUB menu.
    – U. Windl
    Commented Apr 28, 2021 at 8:18
0

To find out the LUKS device /boot corresponds to, try mount | grep /boot, then verify using cat /etc/crypttab and blkid <your_device>. Output should be something like:

/dev/sys/boot: UUID="f3aabb69-d3ca-41cf-87cf-b19585f2c123" TYPE="crypto_LUKS"

Also see my comment on the question.

0

It seems that I misunderstood what I was attempting to do. If this only increases the amount of time on my own machine, then there really isn’t much of a point. Thanks everyone for the great information. It would be great if a feature like this were built into the encryption module so that a time out could be said that would carry across any machine in which the encrypted drive were put on. Example: A 10 or 15 second timeout no matter what device the drive is put into. If someone has a long passphrase, as they should, then I couldn’t see this as any sort of an inconvenience and would only result in further hardening of the drive.

1
  • No no! It will increase time on any machine, just not necessarily by the same amount of time, it will be by iteration cycles. Commented Apr 29, 2021 at 2:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .