Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm on the brink of encrypting some partitions and containers (cryptoloop migration), and I'm trying to decide which way to go. Currently I'm in favor of 'regular' dm_crypt/cryptsetup, but I've read a lot about the LUKS hype, and how it's the 'new and coming standard' and suchlike.
About one particular characteristic of LUKS, however, I'm not able to find a good explanation or even discussion so far. I'm sure there must be. So, if anyone here doesn't find the time to answer but has a good link or resource, please share. :-)
The thing is this: LUKS is storing a lot of information in a header preceding the 'payload' of the encrypted partition (or container file). For example, the (encrypted) keys. However, it also stores, plainly, for everyone to see (cryptsetup luksDump /dev/hdx), the used cipher, its mode, its length, used hash types, the information necessary to determine the end of the header, and if I remember right, even some data about the passphrase salting.
I may be naive and/or paranoid, but doesn't this considerably weaken security? Wouldn't those be some top items on a potential attacker's list of things to have?
I'd appreciate some insights of people who have more experience in encryption matters than me (which, admittedly, isn't a tough requirement =). Thanks!
Here are a couple links that might interest you. The first one is a LUKS howto from the July, 2007 Linux Gazette. The second describes a problem with truecrypt and the kernel crypto api due to a watermark attack.
However, what your question is describing concerns about being able to determine the type of crypto system being used. Your security should need to depend on such security by obscurity. The kernel will need to know this information anyway, and it may not be hard to guess what you use to A) hash the keys and B) implement the encryption. The latter will need to be fast to operate as a filesystem so that will narrow your an attackers guesses. Your concern about the salt information might be valid. What information is revealed about that? The second link I posted deals with a weakness enabling cracking the keys in some implementations because only one key is used and it isn't salted.
I suspect that there may be a reason you will want the data you want encrypted in its own partition and encrypt only that and not a partition that might contain known content. Knowing that the partition contains a certain program or file might make an attack against the keys easier. I'm not a crypto expert however. If it means trying every possibility and checking the result, then no. But if guessing the correct result; that is guessing which file is contained in a region on the disk; will reveal the keys, that could provide a shortcut to revealing the keys. This is somewhat similar to how the enigma would be broken. The operator would in practice repeat the message preamble code. Also, much of the contents of some types of messages such as weather reports would contain known words in known locations. Once it was known how each wheel translated a character, it was easier to attack by finding which combinations would encrypt a repeating character the way it did.
About the salting, the data given by luksDump may be of no relevance at all; I just don't know enough about these things to be sure. Here's the relevant output for a test container I created:
MK salt: b6 bd 35 0d f1 ef eb 6b 9d 77 2f 07 67 7a 9c 70
d4 85 53 46 93 5e c8 9f 33 d3 34 53 b6 f1 7c 0b
The second link is an interesting read, although it hasn't been updated since May 2006, so it's hard to tell whether the issues mentioned therein are still valid.
I'm a little confused though, because, if I created a LUKS partition through a tool that, according to the article, is vulnerable (e. g. cryptsetup), wouldn't the resulting LUKS partition be susceptible to the same vulnerabilities? In addition to announcing my cipher?
In another section of the article, the author is comparing data security with the travel arrangements of a celebrity. I may be getting this wrong, but I think this actually goes in favour of my point. If the press (=attacker) hadn't gotten the information about his method of travelling (=cipher, mode, hashes), they would have had a harder time finding him.
You say in your comment that security shouldn't need to rely on obscurity. I may be thinking in the wrong direction, but it seems to me that obscurity is the most integral part of security. For example, I would be ill advised to write my passphrase on a sticky note and pin it to my monitor. Instead, I will obscure it in the windings of my brain, or in some random data file on a USB stick or something. Is it so different for any other data required to break the encryption?
And lastly, I have read some comments about the deniability of encryption. Truecrypt claims to provide this (as their header is only accessible when hit with the correct passphrase), and I believe Bruce Schneier also recommended this sometime. With LUKS however, just about any person with access to the partition/container can comfortably find out what they're dealing with.
I don't feel my concerns have lifted so far. :-)
If there are any other comments or resources, I'd much appreciate it.
The security is dependent on the strength of the crypto, the key lengths, and the relative strength of the crypto.
I wonder myself how strong the encryption of a mounted partition would be. The salt is used to make it harder to use a dictionary attack against keys. However, if the salt is given, that only effects dictionary attacks, and not brute force attacks. So the key length needs to be long enough to make brute force attacks impracticable. But there is a performance issue. You can't wait a couple minutes for the system to decrypt a block of data. If keys were around 350 decimal digits in length, that would make dictionary attacks very unlikely. There aren't enough atoms in the Universe to construct a hard drive large enough to contain a database of 10^350 entries.
However, when you supply a passphrase to generate the keys (via a hash function), it will be probably be shorter in length and make an easier brute force target.
If you look at the /etc/shadow file, for example, you will see a regular pattern at the beginning that contains salt information. "$2a$10$". If you encrypt a file using one of the openssl programs, the file will start with "SALTED__" but when I encoded a test file, after that everything looked random. ( That isn't saying it was )
I think that the moral is that salt is used to make dictionary attacks more difficult. If you want stronger crypto, use a larger key as well.
Some HOWTOs that I have read have indicated that you want to fill the partition with random bytes before using it.
Also chose a system that uses a number of keys and not a single key as the article suggested.
If you look at "man crypto" for example, you will see how the internal functions of the openssl library are broken down. There are hash functions, symetric functions, certificate functions, etc. Some wouldn't be used for your purpose. You wouldn't use a one way hash function for encryption for example. Someone trying to break your encryption could probably be able to guess correctly the one or two best choices that you had. A crypto expert may be able to do so accurately with no guessing. I'm no expert but I would guess that you would use aes256 to hash the key. Am I right? I remember one time I was on a computer forum about about wireless. The mod of the board was suggesting that people rely on hiding their ssid. He just wouldn't listen that that didn't provide any protection at all.