Ivan, an anarchist who has been in pre-trial detention in France for some time, reported in a letter that French police were able to gain access to the contents of his laptop.¹ The laptop in question had an encrypted Ubuntu Linux installed. Another device with Windows installed and encrypted with Bitlocker could not be accessed. Ivan explained in his letter that he had used a 20-digit password consisting of letters, numbers and special characters for the system.

Since then, there have been discussions on the web and in our environment about how this was possible, whether an outdated crypto algorithm in Ivan’s Ubuntu installation was to blame, and what this means for the security of other Linux systems. We even received claims that the encryption of the Tails operating system – which is also a Linux system – was not secure due to outdated algorithms. The topic of device encryption is not easily accessible to many, so we’d like to frame the discussion a bit with this post.

All Linux operating systems use the Linux Unified Key Setup, or LUKS for short, for encrypting the hard disk. The background to the assumption that an outdated algorithm might be to blame in Ivan’s case is that Ubuntu version 18.04 (released in April 2018, as the abbreviation suggests) still uses the relatively outdated “LUKS1” standard for hard disk encryption, while newer Linux installations use the “LUKS2” standard for this purpose.² To understand why this is relevant, it is necessary to get an overview of LUKS encryption and to understand what role the so-called key derivation function plays in it. Unfortunately, this is going to be a bit technical, although we will try to break it down as best we can.

Linux Unified Key Setup (LUKS) in a nutshell

A hard disk encrypted with LUKS is initially a two-part block with an unencrypted header and an encrypted body. The body contains the actual encrypted data, while the header is to be understood as an instruction manual: which encryption algorithm is used for the body, what size should the body have, where on the hard disk is the body located, what is the device ID of the partition, etc. – It looks something like this:

LUKS header information
Version:        2
UUID:           d077227a-eb02-4349-ab5b-fd9494ade3a6

Data segments:
  0: crypt
        offset: 16764544 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]
        ...

Important for us: The header also contains the information which key derivation function is to be used during the encryption or decryption process. The key derivation is a cryptographic conversion of the password into the key with which the body was encrypted and with which the body can be decrypted again. Contrary to what one might think, the password itself is not the key with which the body was encrypted, but only the actual key is derived from it. We will explain why this intermediate step is necessary in a moment. First, it is only important that there are many different algorithms for the derivation and that the information stored in the header is needed for the key derivation.

To give an example, a visualization with the password “dPhdWnv1.3k4d4,szv!”:

Now the question arises why the intermediate step is needed at all instead of simply encrypting/decrypting the body of the hard disk directly with the password. First of all, you have to consider the attack scenario that the encryption is supposed to protect against: Nobody would try to crack the actual algorithm – in this case: AES-XTS-PLAIN64: This is considered secure in research. Usually, people try to guess the password instead by simply trying all conceivable character combinations. This method is called brute force. Every single attempt costs computing power, memory and time, so one would usually use an exceptionally powerful computer or a cluster of many computers. There is also dedicated software that works with lists of known passwords or even personal data about the owner (languages, interests, passwords used for other services) to obtain more probable combinations.

This is where the key derivation function comes into play: The idea is to stretch decryption with the correct password by the intermediate step of password derivation just so many milliseconds that it is not noticeable in the everyday use of a laptop, but massively increases the effort of guessing passwords en masse. The key derivation function mainly protects short passwords and those that are composed of a smaller pool of possible characters: For a password that consists of only 6 digits, for example, the plethora of all possible combinations is calculated much faster than for a 20-character alpha-numeric password.

There are high demands on the key derivation function: On the one hand, they should be able to withstand huge computer clusters that have enormous computing power at their disposal, and at the same time, encryption and decryption on ordinary laptops and PCs should not take so long that encryption is no longer practical. The solution to this problem is – to break it down very roughly – the development of mathematical algorithms that are designed in such a way that even when the computing power is multiplied, the time required for key derivation remains relatively the same.

The vulnerability in Ubuntu 18.04, Tails and others

Now that the meaning of the key derivation function is explained, we come back to Ivan’s laptop: According to his letter, Ubuntu version 18.04 was installed on it. This version of Ubuntu still uses the outdated LUKS1 standard, which in turn uses an outdated key derivation function (PBKDF2). This is known to be of little use against specialized hardware, and is therefore no longer considered secure. Hence the assumption that the outdated key derivation function enabled access to Ivan’s laptop. Other versions are also affected by this possible vulnerability if their first installation was a long time ago: Indeed, the algorithm is usually not improved on an existing installation when a full version upgrade is performed (e.g. from Ubuntu 18.04 to Ubuntu 22.04).³ It has also been discussed that while the developer community behind the Tails operating system has had the switch to the more secure LUKS2 encryption in its todo list for several years, it has not yet implemented it. This again seems to have led others to claim that Tails stick encryption is insecure.⁴

What is to be made of this? Basically, it is a concern that many old Linux installations use an outdated algorithm for hard disk encryption. Users with older installations now have to decide whether they are tech-savy enough to upgrade their encryption themselves – there is a guide for this in our wiki -, reinstall their system or accept using an outdated algorithm. However, whether this vulnerability played any role at all in Ivan’s case is only an assumption and not a fact. The possibility that he was observed or filmed while entering his password, that he reused his password in different places, that the password may simply have been insecure, even that the traces of use on the keyboard could have been a clue to the password, are all conceivable explanations for the access to his data. In view of the vague information, statements like “The Tails encryption has been cracked” seem alarmist and dubious.

It is difficult to estimate how serious the outdated algorithm actually is: A better key derivation function that makes brute forcing more difficult undoubtedly contributes greatly to the security of device encryption. Conversely, however, this does not mean that all devices that use an outdated key derivation algorithm are therefore fundamentally insecure. First and foremost, the security of LUKS encryption depends on the security of the password, and while this is improved by a good password, it is not worsened by an outdated key derivation algorithm. A good password, i.e., a truly randomly generated password that is of sufficient length and generated from a large enough pool of letters, digits, and special characters, requires an extraordinary amount of time even with an outdated key derivation function and even with an extraordinary amount of resources. However, we cannot and do not estimate what resources are available to a potential attacker. However, we consider it at least unlikely that such passwords – even with poor key derivation – can be brute-forced without further ado.

Secure passwords

A short addendum about the security of passwords: When talking about a random password, it means: generated by a machine. A password that has been made up by yourself will never be as secure as a truly random password: Even the password dPhdWnv1;3k4d4;szv! looks secure at first glance with its lower and upper case letters, numbers and special characters. However, it is just the short form of the not-so-secret German sentence “Die Philosophen haben die Welt nur verschieden interpretiert; es kommt aber darauf an, sie zu verändern.” with some vowels replaced by numbers and a few special characters added. Such and similar tricks are very common, but can be easily guessed after some research and intuition and do not form the basis of a secure password.

The Tails community recommends in their documentation to use diceware passwords