Can you explain how using a poor/weak password that is hashed (with any algorithm) would increase the security level against a brute force attack? My point being that a poor/weak password is still a poor/weak password regardless if it has been hashed or not (easily recoverable via brute force iteration).

Running dictionary attacks could be implemented quite fast if you just concatenate known words with perhaps some digits, pad it to 32 chars and test decryption with the first block of the volume to see if there is a valid partition table (or something similar).
Running SHA256 on each passphrase would take longer time. Unfortunately I don't know the factor of slowdown. But I would estimate about three times. Ok, this is not soo much.

If you are saying the security level is low because another super-user could read the plain-text key, then I disagree as well. First, you shouldn't be giving super-user access to those you don't trust, and secondly, even with a hashed password, I would still be able to read the key using dmsetup when the volume is created.

Yes, you are right. The passphrase should be known by more than one person or all data would be lost if the person quits company. But it is somehow unexpexted and unusual to reveal the passphrase. If the Admin would awake on this, he/she would perhaps take more care not to use this passphrase elsewhere. It is just about knowing something to have the chance of making the right decision. I like to know which information is shared. (Our installation is just for my wife an me, but anyway)

LUKS would allow multiple passphrases and is "secure against low entropy attacks". But writing a ClearOS app for managing LURKs could be quite complex...

Perhaps I am a little bit strict because I use ClearOS for so long and owe the developement team many years of uncomplaining infrastructure. So my expectations are grown higher than elsewhere...

Joachim Korittky wrote:

after I couldn't find a way to mount my encrypted volumes und ClearOS 6.2 I did a little bit reverse engineering to help myself.

The dm-crypt app from 5.x has yet to be ported to ClearOS 6.x. As it is an old app, it requires a complete re-write and dusting off as you discovered.

The entered passphrase can be found in the file /tmp/dmcryptvtVz3E, padded with ASCII “0x0x...” at the beginning and the end.
This means that the user doesn’t see the “really” used passphrase and it is therefore impossible to “cryptsetup” the volume without ClearOS 5.2 Interface or this knowledge.

I agree that this should have been documented. Up until now, I don't recall anyone asking about how to manually mount an encrypted volume from the command-line. Perhaps that is why this "padding" information was not added to the user guide documentation. For 6.x, the padding will be changed to a SHA256 hash and will be documented to keep interested parties from having to read through source code.

For me the command for setting up the mapper looks very odd.
-c names the parameter for the cypher and leads to “aes-cbc-plain”. (which should no longer be used)
-h names the used hash algorithm for the key, but “aes-cbc-essiv:sha256” isn’t a valid hash algorithm.
Obviously the values for –c and –h are swapped!

Yes, and good catch! The correct parameters to cryptsetup should be:

# cryptsetup -c aes-cbc-essiv:sha256 -d /tmp/keyfileXYZ create <name> <loop_dev>

The AES key-size will default to 256. The key in /tmp/keyfileXYZ is to be SHA256 hashed.

Hmm, but why does it work anyway and what hapens with the hash algorithm?
I think the passphrase isn’t hashed at all!

No, it isn't and today I asked myself the same question: How can this work, why doesn't cryptsetup fail when supplied with an invalid hash algorithm? The answer I have discovered: the hash algorithm is ignored! It's not very apparent in the manual page for cryptsetup, but if you supply your own "key material" using the -d (--key-file) parameter, the -h (--hash) parameter is not parsed/validated because it isn't needed. The "key material" is accepted (possibly padded or truncated) as-is. Now I know that when using --key-file, I must hash the key myself as cryptsetup won't do it for me (even with correct parameters such as --hash sha256).

Hey, I and all other system admins can read my secret passphrase! hmy: For me this seems like the passphrase is used as master-key without any hashing.
The version of cryptsetup is 1.0.3. - very old!

Yes, any admin (anyone with root or disk permissions) will be able to see the key used for any encrypted volume. This is the case regardless of whether the key has been hashed or not. If the key had been hashed, then at least other super-users would not know the original plain-text key.

My point being that once your encrypted volume has been setup with cryptsetup, anyone with super-user access can view the key (hashed or not), and the decrypted contents. So although I agree it is a mistake to not hash the plain-text key (which was not my intention but a wrong assumption about cryptsetup), i wouldn't be too concerned about another super-user being able to read it.

I come to the result that a missing support for encrypted volumes in 6.2 would be no pitty because the security level is quite poor unless the user picks a very random passphrase.
You should probably check this. And when I am not totally wrong you should warn the other users.

Thanks for doing the research and bringing this to our attention. Aside from using aes-cbc-plain (accidentally), I disagree that the security level is quite poor. Can you explain how using a poor/weak password that is hashed (with any algorithm) would increase the security level against a brute force attack? My point being that a poor/weak password is still a poor/weak password regardless if it has been hashed or not (easily recoverable via brute force iteration).

If you are saying the security level is low because another super-user could read the plain-text key, then I disagree as well. First, you shouldn't be giving super-user access to those you don't trust, and secondly, even with a hashed password, I would still be able to read the key using dmsetup when the volume is created.

The security of the current implementation is not as good as it could be, nor is it as secure as was intended due to incorrect usage of cryptsetup. This will be corrected. I wish to be clear however, that there is no significant security threat for existing 5.x encrypted volumes.

Thanks again!

Thanks for the feedback Joachim - i'll ping your report on to the dev team