[dm-crypt] Some questions about cryptsetup 1.6.x
arno at wagner.name
Wed Feb 12 15:19:09 CET 2014
On Wed, Feb 12, 2014 at 10:49:54 CET, Cpp wrote:
> I have a few questions about the use of cryptsetup and its security.
> First I'd like to know something about the command line options. I've
> seen people specify the digest (hash) in two different places in
> cryptsetup. Consider the following line:
> # cryptsetup -c aes-xts-plain64:sha512 -h sha512 -s 512 -y -i 5000
> --use-random -y -v luksFormat /dev/sda1
> What is the difference between specifying the hash in the -c parameter
> i.e. aes-xts-plain64:sha512 or by using the -h parameter? Do they both
> do the same thing meaning that the following two are equivalent?
-h is the hash that the plain-text password is put through
to turn it into a binary value of certain defined length.
-c specifies the hash that goes into pbkdf2 for the hash
Probably not too clear in the man-page, come to think of it.
"cryptsetup --help" is clearer.
> # cryptsetup -c aes-xts-plain64:sha512 -s 512 -y -i 5000 --use-random
> -y -v luksFormat /dev/sda1
> # cryptsetup -c aes-xts-plain64 -h sha512 -s 512 -y -i 5000
> --use-random -y -v luksFormat /dev/sda1
> Next I'd like to ask about the memory management of the master key.
> Suppose I mounted a volume using luksOpen (or --type luks open). What
> happens when I invoke luksClose (close) on that container? Does the
> master key get securely erased from memory (several overwrites with
> random data) or is it simply blanked out (single overwrite with
That makes no difference for memory. For DRAM, it is refreshed to
its actual setting periodically anyways, something like 10x...100x per
second. For SRAM (caches, maybe small embedded use), overwriting with
the same value has no effect.
You are confusing this with techniques to delete magnetic storage.
> How is the master key stored in memory? I read somewhere that having
> the same data in the exact same location in RAM for an extended period
> of time (like a 24/7 server) can "burn in" the data into the RAM
> module, which can be later recovered. Is this of any concern with
> current cryptsetup i.e. for attacks like cold boot?
It is a concern for SRAM, but not/less for DRAM. And for SRAM, it
becomes a concern if the same value is in the same place for years.
What happens then is that the chip changes slowly and makes it more
likely that it goes to the previous state on power-up.
Look for example at references , and  here:
 deals only with SRAM. While  and  deal with DRAM
also, it is more a suspicion for DRAM, but not a really strong
threat. While I believe this attack has been demonstrated for
SRAM, I am not aware of it having ever been done succcessfully
There are several factors that make this less relevant for DRAM:
- DRAM cells are much smaller than SRAM cells and there is
less room for change before the cell starts to break.
- In a DRAM cell there is less that can change. A DRAM
cell is one capactiro and one transistor and ythe transistor
is unpowered most of the time. In an SRAM cell, there are the
two transistors of the Flip-Flop, and one of them is powered all
the time, according to the cell state.
- DRAM always comes up empty when it was unpowered for a while
so reading such changes is difficult, while SRAM always
comes up in a random state with ideally both states of
the same probability. Now, if a SRAM cell is just 0.01%
more likely to come up with one state than the other, that
is simple to test: Power it up 1 million times, and
you see it. It is not that simple for DRAM. There, you
likely have to mess with the read amplifiers on the chip
and do other things that are difficult and expensive.
It might not work at all, either.
In addition, the attack in general is not too relevant.
Chip structures have gotten a lot smaller and significant
changes in chip elements are a lot more likely to break the
chip and hence have to be limited much more strongly then
when Gutman looked at it.
Also take note that in order to extract a key this way,
the attacker needs to find the location the key is in as
well. If you have a perfect memory dump (such as a hot-boot
attack or a freeze-and-remove attack gets you), you can
just try every location in decryption. However if there
is just one changed bit, this fails.
That said, for tokens storing keys in SRAM in an exactly
known location for years and years, these attacks are a
And finally, zeroing a key-storage location several times
does exactly nothing to help with the problem. What secure
tokens do is flip all bits periodically to prevent the
SRAM cells from changing in a specific way.
> Finally I'm interested to know about removing all the keyslots.
> Suppose I mounted a container and erased every available keyslot
> (please don't ask why). I know this would in theory make the data
> irrecoverble, but the container is still mounted for the time being.
> Assuming that the power doesn't disappear, is there a way to
> reintroduce a new key slot into the LUKS container after all slots
> have been erased, provided that the container is mounted and I can
> read the master key from memory?
Yes. See FAQ item 6.10.
> Best regards!
> dm-crypt mailing list
> dm-crypt at saout.de
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
A good decision is based on knowledge and not on numbers. - Plato
More information about the dm-crypt