LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 08-08-2007, 12:28 PM   #1
furryspider
Member
 
Registered: Feb 2004
Location: by the Bavarian Sea
Distribution: Slackware 14.1
Posts: 56

Rep: Reputation: 15
cryptsetup+LUKS: security concept feasible?


Hi,

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!
 
Old 08-08-2007, 01:48 PM   #2
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654
http://linuxgazette.net/140/pfeiffer.html

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

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.

Last edited by jschiwal; 08-08-2007 at 02:40 PM.
 
Old 08-09-2007, 02:18 PM   #3
furryspider
Member
 
Registered: Feb 2004
Location: by the Bavarian Sea
Distribution: Slackware 14.1
Posts: 56

Original Poster
Rep: Reputation: 15
Thanks for your reply, jschiwal.

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:

Code:
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.
 
Old 08-11-2007, 04:10 AM   #4
jschiwal
Guru
 
Registered: Aug 2001
Location: Fargo, ND
Distribution: SuSE AMD64
Posts: 15,733

Rep: Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654Reputation: 654
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LUKS automation script jippo Linux - Security 6 01-12-2008 12:56 AM
cryptsetup-luks question nomb Linux - Software 4 06-14-2007 10:22 AM
VPN Tunnel + Proxy Security Question (Concept not config problem) E-Oreo Linux - Networking 1 03-09-2007 11:08 AM
cryptsetup-luks error flying-tuxman Linux - Security 2 11-20-2006 11:08 AM
dmcrypt+luks - Benchmarks ddaas Linux - Security 0 05-24-2006 08:07 AM


All times are GMT -5. The time now is 12:45 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration