User talk:Gothmog.todi

From ArchWiki

LUKS

Why did you revert my good changes here http://wiki.archlinux.org/index.php/LUKS_Encrypted_Root ?

-s 256 to -s 384 could be OK.

Take a look at http://en.wikipedia.org/wiki/Disk_encryption_theory#LRW for information about keysize with lrw.
-- gothmog.todi 08:01, 2 February 2008 (EST)

1) If you don't use "-h sha256" it will default to "ripemd160":

man cryptsetup

      --hash, -h
      specifies hash to use for password hashing. This option is  only
      relevant  for  the "create" action. The hash string is passed to
      libgcrypt, so all  hashes  accepted  by  gcrypt  are  supported.
      Default is "ripemd160".
You gave the answer yourself:
This option is  only relevant  for  the "create" action.
The luksFormat action ignores the -h switch and always uses sha1. If you don't believe me, do a:
#cryptsetup luksDump /dev/<any luks encrypted device>
and look at the hash line.
-- gothmog.todi 08:01, 2 February 2008 (EST)
Uh... yeah, it makes sense :-D ekerazha 08:12, 2 February 2008 (EST)

2) Why don't you use LRW on the swap partition?

OK, I've read your notes... however,

This may be an issue for software that encrypts the partition of an operating system under which this encryption software is running (at the same time). The operating system could write the LRW tweak key to encrypted swap/hibernation file.

Well... the swap partition is encrypted, so this shouldn't be an issue because you don't have another swap partition that could store the key you used for the "first" swap partition. Before the swap partition is encrypted & activated you don't have any active swap partition.

That links aren't saying "don't use LRW for swap partitions" they are saying, "don't create an encrypted partition if the swap file/partition is exposed".

It clearly states in your quote that:
The operating system could write the LRW tweak key to encrypted swap/hibernation file.
The weakness does in fact only affect systems where the swap partition is encrypted with lrw and the key for the swap partition is swapped out onto this partition. So the cleartext key is stored on the partition encrypted with that key.
-- gothmog.todi 08:16, 2 February 2008 (EST)
Yeah, but this is not the point... if the key for the swap partition is randomly generated and the partition still isn't active, when this key could be swapped to the encrypted swap file/partition? Never because it doesn't exist. What's the point? The point is that you should disable the swap before encrypting partitions, especially if the key you'll use to encrypt these partitions is the same you used to encrypt the swap partition. Isn't it? ekerazha 08:34, 2 February 2008 (EST)
Ah, now i see your point. But the problem is that the key does exist. It's in the kernel memory space (otherwise it wouldn't be possible to write to the partition). And that memory could be swapped onto the swap partition. And than said weakness could occur.
-- gothmog.todi 08:43, 2 February 2008 (EST)
Good point ekerazha 11:14, 2 February 2008 (EST)
However... are you sure kernel space memory could be swapped just like user space memory? ekerazha 11:25, 2 February 2008 (EST)
Here http://www.oreillynet.com/cs/user/view/cs_msg/91571 the guy says kernel space memory isn't moved to swap space: Now the second question, could the kernel over-allocate? In practice, no (well... memory is always allocated in kernel mode, the question is about the kernel itself and its modules and the memory allocated for the user space applications). ekerazha 12:04, 2 February 2008 (EST)
You are right, kernel memory can't be swapped. After reading through the mailinglist archive of the IEEE P1619 group, I think that the main concerns are, that an attacker could social engineer you into view your key (which would load it into userspace memory) and this could lead to said weakness. I must admit, the probability of this to work is very small with a random key that only exists in kernel memory. (I won't say it's impossible. As long as it stored somewhere, even in memory, it may be possible to access it somehow).
-- gothmog.todi 06:36, 3 February 2008 (EST)

Another point: We should move this whole discussion to the discussion page of the article. -- gothmog.todi 06:39, 3 February 2008 (EST)

I've added a link to this page ekerazha 07:12, 3 February 2008 (EST)