[dm-crypt] Some questions about cryptsetup 1.6.x

[dm-crypt] Some questions about cryptsetup 1.6.x

[Cpp]

Greetings.

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?

# 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
zeros)?

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?

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?


Best regards!

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Arno Wagner]

Hi,

On Wed, Feb 12, 2014 at 10:49:54 CET, Cpp wrote:
> Greetings.
> 
> 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
iteration.

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
> zeros)?

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 [22],[23] and [40] here:
https://www.usenix.org/legacy/events/sec08/tech/full_papers/halderman/halderman_html/
[40] deals only with SRAM. While [22] and [23] 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 
for DRAM.

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 
concern.  

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. 

Arno
 
> 
> Best regards!
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Thomas Bächler]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Am 12.02.2014 15:19, schrieb Arno Wagner:
> -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
> iteration.

Are you sure?

I was under the impression that '-c' only affects the cipher parameter
passed to dm-crypt - a hash would then be relevant for cipher modes like
cbc-essiv, but xts-plain64 would ignore it. Thus, cryptsetup has default
like 'aes-cbc-essiv:sha256', since essiv needs a hash, and
aes-xts-plain64, since xts does not need a hash.

According to the manpage, -h is what is used in PBKDF2 in luksFormat
mode, or to hash the passphrase in plain mode.

To me, this makes much more sense than what you said.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Matthias Schniedermeyer]

On 12.02.2014 15:19, Arno Wagner wrote:
> Hi,
> 
> > 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
> > zeros)?
> 
> 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.

No.

The reports where that remanence (i'm using the term for magnetic 
storage. Don't know/remember if there is/was a specific term for DRAM) 
in DRAM is longer, the longer a specific value was in a specific cell.

That is for the attack:
- Switch of computer
- Rip out RAM (optionally cool them to extend the time further)
- Plug them into a device that dumps current memory contents

AFAIR the articles, the time varies between (milli-)seconds to minutes 
for cooled/non-cooled memory and also for "long term" vs. "short term" 
memory-contents. (So best-case is likely cooled & long term)


For e.g. loop-AES contains a mitigation for that. If you activate the 
option it holds 2 sets of keys in RAM. One is the "actual" key, the 
other one is (AFAIR) with it's bit inverted and then it bit-invertes and 
switches the sets in regular intervals. So that none of the 2 locations 
actually falls into the "long term" category. In the hope that when you 
switch of power (to memory) the keys fade fast enough to not be 
recoverable (or at least with sufficient severe loss of bits).


Cold-Boot is a slight variation of this, where you try to use the actual 
computer itself for the dump. You can (try to) mitigate using the 
computer for dumping the memory, so an attacker has to revert to "rip 
out". But if unsucessful the memory can be dumped with only a neglient 
amount of bit-loss. (You have to store & execute a programm in some way. 
So you have to overwrite at least a little bit of memory)

IIRC there was a description of a mitigation technique that "pin"s the 
key in L1 (and/or L2) cache without it being stored in RAM.
And an interesting question is, if AES-NI could be used as another 
mitigation technique.




-- 

Matthias

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Arno Wagner]

On Wed, Feb 12, 2014 at 16:04:08 CET, Matthias Schniedermeyer wrote:
> On 12.02.2014 15:19, Arno Wagner wrote:
> > Hi,
> > 
> > > 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
> > > zeros)?
> > 
> > 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.
> 
> No.

Yes, you do. Doing multiple overwrites has exactly no effect for DRAM
or SRAM. 
 
> The reports where that remanence (i'm using the term for magnetic 
> storage. Don't know/remember if there is/was a specific term for DRAM) 
> in DRAM is longer, the longer a specific value was in a specific cell.
>
> That is for the attack:
> - Switch of computer
> - Rip out RAM (optionally cool them to extend the time further)
> - Plug them into a device that dumps current memory contents
> 
> AFAIR the articles, the time varies between (milli-)seconds to minutes 
> for cooled/non-cooled memory and also for "long term" vs. "short term" 
> memory-contents. (So best-case is likely cooled & long term)

I believe that is inconsistent with the way DRAM works. It is true
for SRAM. Have a citation? 
 
> For e.g. loop-AES contains a mitigation for that. If you activate the 
> option it holds 2 sets of keys in RAM. One is the "actual" key, the 
> other one is (AFAIR) with it's bit inverted and then it bit-invertes and 
> switches the sets in regular intervals. So that none of the 2 locations 
> actually falls into the "long term" category. In the hope that when you 
> switch of power (to memory) the keys fade fast enough to not be 
> recoverable (or at least with sufficient severe loss of bits).
> 
> 
> Cold-Boot is a slight variation of this, where you try to use the actual 

It actually is something completely different, as the RAM stays powered
and modern DRAM is self-refresing. You are confusing two different things
here.

> computer itself for the dump. You can (try to) mitigate using the 
> computer for dumping the memory, so an attacker has to revert to "rip 
> out". But if unsucessful the memory can be dumped with only a neglient 
> amount of bit-loss. (You have to store & execute a programm in some way. 
> So you have to overwrite at least a little bit of memory)
> 
> IIRC there was a description of a mitigation technique that "pin"s the 
> key in L1 (and/or L2) cache without it being stored in RAM.

That would be really bad. L1/L2 cache is SRAM and that does suffer
from changes when values are stored long-term.

> And an interesting question is, if AES-NI could be used as another 
> mitigation technique.

There is very likely nothing to mitigate here.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Arno Wagner]

On Wed, Feb 12, 2014 at 15:30:10 CET, Thomas Bächler wrote:
> Am 12.02.2014 15:19, schrieb Arno Wagner:
> > -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
> > iteration.
> 
> Are you sure?

Not really, no. I was focussing on the "RAM" cell attenuation 
issues. 

> I was under the impression that '-c' only affects the cipher parameter
> passed to dm-crypt - a hash would then be relevant for cipher modes like
> cbc-essiv, but xts-plain64 would ignore it. Thus, cryptsetup has default
> like 'aes-cbc-essiv:sha256', since essiv needs a hash, and
> aes-xts-plain64, since xts does not need a hash.
> 
> According to the manpage, -h is what is used in PBKDF2 in luksFormat
> mode, or to hash the passphrase in plain mode.
> 
> To me, this makes much more sense than what you said.

Come to think of it, to me too. It is really irrelevant though,
there is no need to change these hashes to improve security.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Milan Broz]

On 02/12/2014 03:30 PM, Thomas Bächler wrote:
> Am 12.02.2014 15:19, schrieb Arno Wagner:
>> -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
>> iteration.
> 
> Are you sure?
> 
> I was under the impression that '-c' only affects the cipher parameter
> passed to dm-crypt - a hash would then be relevant for cipher modes like
> cbc-essiv, but xts-plain64 would ignore it. Thus, cryptsetup has default
> like 'aes-cbc-essiv:sha256', since essiv needs a hash, and
> aes-xts-plain64, since xts does not need a hash.
> 
> According to the manpage, -h is what is used in PBKDF2 in luksFormat
> mode, or to hash the passphrase in plain mode.

Yes, this is correct. The -h parameter is for LUKS header (PBKDF2 + AF splitter).
For plain mode it means algorithm to use when hashing password.

For -c it is cipher/mode for kernel dmcrypt (if there is a IV spec which requires
hash like ESSIV, then it contains hashspec as parameter).

Milan

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Milan Broz]

Hi,

just adding few facts, the discussion is already elsewhere in thread:)

On 02/12/2014 10:49 AM, Cpp wrote:
> 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
> zeros)?

The luksClose / dmsetup remove or any other correct dmcrypt device close
will cause removal of key from memory, with simple zeroing that part.

> 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?

In fact, it is stored in memory in several places. First, copy of
it in dmcrypt internal structures and then inside crypto API
(usually several times - depend on level of parallelism of crypto module).
 
> 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. You can recreate LUKS header, I wrote some script to do this,
it is part of cryptsetup source code
http://code.google.com/p/cryptsetup/source/browse/misc/luks-header-from-active

(I hope is still works though ;-)

Milan

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Matthias Schniedermeyer]

On 12.02.2014 16:57, Arno Wagner wrote:
> On Wed, Feb 12, 2014 at 16:04:08 CET, Matthias Schniedermeyer wrote:

> > The reports where that remanence (i'm using the term for magnetic 
> > storage. Don't know/remember if there is/was a specific term for DRAM) 
> > in DRAM is longer, the longer a specific value was in a specific cell.
> >
> > That is for the attack:
> > - Switch of computer
> > - Rip out RAM (optionally cool them to extend the time further)
> > - Plug them into a device that dumps current memory contents
> > 
> > AFAIR the articles, the time varies between (milli-)seconds to minutes 
> > for cooled/non-cooled memory and also for "long term" vs. "short term" 
> > memory-contents. (So best-case is likely cooled & long term)
> 
> I believe that is inconsistent with the way DRAM works. It is true
> for SRAM.

DRAM is in effect a little capacitor, it takes a little time for the 
charge to fade. 

There was an article a few years back that said that modern DRAM 
actually got better at holding that charge. And that (or a separate) 
article further said that the time gets extended when a specific cell 
holds a particular charge for a long time.

> Have a citation? 

Unfortunatly no.

> > For e.g. loop-AES contains a mitigation for that. If you activate the 
> > option it holds 2 sets of keys in RAM. One is the "actual" key, the 
> > other one is (AFAIR) with it's bit inverted and then it bit-invertes and 
> > switches the sets in regular intervals. So that none of the 2 locations 
> > actually falls into the "long term" category. In the hope that when you 
> > switch of power (to memory) the keys fade fast enough to not be 
> > recoverable (or at least with sufficient severe loss of bits).
> > 
> > 
> > Cold-Boot is a slight variation of this, where you try to use the actual 
> 
> It actually is something completely different, as the RAM stays powered
> and modern DRAM is self-refresing. You are confusing two different things
> here.

The basic "attack vector" is getting ahold of the memory contents.
With cold boot you try to do that "inline" (RAM still plugged in).
In the "rip out" case it's "out-of-line" (RAM in another device).

So i personally see little difference, both require protection against 
physical access to the computer. Only what an attacker can do if s/he 
gets ahold of the physical computer is slightly different and they 
ce be tried in order (cold-boot, then "rip out").

> > computer itself for the dump. You can (try to) mitigate using the 
> > computer for dumping the memory, so an attacker has to revert to "rip 
> > out". But if unsucessful the memory can be dumped with only a neglient 
> > amount of bit-loss. (You have to store & execute a programm in some way. 
> > So you have to overwrite at least a little bit of memory)
> > 
> > IIRC there was a description of a mitigation technique that "pin"s the 
> > key in L1 (and/or L2) cache without it being stored in RAM.
> 
> That would be really bad. L1/L2 cache is SRAM and that does suffer
> from changes when values are stored long-term.

The theory is that after the CPU is reset (Cold-boot) or switched off 
(rip-out) you have no way of getting ahold of the cache contents.

DRAM is easy, they have a standard connector (assuming a standard PC) 
and building a device where you connect the DRAM and that then copies 
the contents is relativly easy. At least for a qualified attacker.

Building a device that dumps the contents of a CPU should be quite 
difficult and as an "active" component the CPU can't be simply read. You 
have to create the all interfaces a CPU needs to start/run and then you 
have to write a program that the CPU needs to execute that does the 
dumping. And then it may still not be possible. I'm guessing CPUs mark 
valid cache-contents and i would further guess that marker/flag get's 
reset upon a reset of the CPU.

Same goes for the cold-boot-case, at least the theory is that you can't 
get to the cache-contents after a reset, or that the memory usage while 
booting is enough to evict the complete cache. Altough i would go with 
the theory that CPUs don't have any cache-contents marked valid after 
the CPU got a reset signal.





-- 

Matthias

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Arno Wagner]

On Wed, Feb 12, 2014 at 17:29:40 CET, Matthias Schniedermeyer wrote:
> On 12.02.2014 16:57, Arno Wagner wrote:
> > On Wed, Feb 12, 2014 at 16:04:08 CET, Matthias Schniedermeyer wrote:
> 
> DRAM is in effect a little capacitor, it takes a little time for the 
> charge to fade. 
> 
> There was an article a few years back that said that modern DRAM 
> actually got better at holding that charge. And that (or a separate) 
> article further said that the time gets extended when a specific cell 
> holds a particular charge for a long time.
> 
> > Have a citation? 
> 
> Unfortunatly no.

So lets keep that as "myth". The SRAM attenuation has been 
known for a long, long time, I heard about it first when I studied
cryptology 25 years ago, but for DRAM I have never heard of it.
 
I suspect it would have to happen in the cell transistor, not the 
capacitor.  And then it will be far, far less pronounced than in 
SRAM as that transistor is unpowered most of the time, quite unlike
SRAM. It is only a pretty weak effect even there. 

> > > For e.g. loop-AES contains a mitigation for that. If you activate the 
> > > option it holds 2 sets of keys in RAM. One is the "actual" key, the 
> > > other one is (AFAIR) with it's bit inverted and then it bit-invertes and 
> > > switches the sets in regular intervals. So that none of the 2 locations 
> > > actually falls into the "long term" category. In the hope that when you 
> > > switch of power (to memory) the keys fade fast enough to not be 
> > > recoverable (or at least with sufficient severe loss of bits).
> > > 
> > > 
> > > Cold-Boot is a slight variation of this, where you try to use the actual 
> > 
> > It actually is something completely different, as the RAM stays powered
> > and modern DRAM is self-refresing. You are confusing two different things
> > here.
> 
> The basic "attack vector" is getting ahold of the memory contents.

With that reasoning, all attacks are the same...

Beware of abstracting away necessary detail.

> With cold boot you try to do that "inline" (RAM still plugged in).
> In the "rip out" case it's "out-of-line" (RAM in another device).
> 
> So i personally see little difference, both require protection against 
> physical access to the computer. Only what an attacker can do if s/he 
> gets ahold of the physical computer is slightly different and they 
> ce be tried in order (cold-boot, then "rip out").

"Cold boot" could be possible over the net, via IPMI, for example.
Freeze&remove is not.
 
> > > computer itself for the dump. You can (try to) mitigate using the 
> > > computer for dumping the memory, so an attacker has to revert to "rip 
> > > out". But if unsucessful the memory can be dumped with only a neglient 
> > > amount of bit-loss. (You have to store & execute a programm in some way. 
> > > So you have to overwrite at least a little bit of memory)
> > > 
> > > IIRC there was a description of a mitigation technique that "pin"s the 
> > > key in L1 (and/or L2) cache without it being stored in RAM.
> > 
> > That would be really bad. L1/L2 cache is SRAM and that does suffer
> > from changes when values are stored long-term.
> 
> The theory is that after the CPU is reset (Cold-boot) or switched off 
> (rip-out) you have no way of getting ahold of the cache contents.

Nonsense. Just power the CPU up in debug mode and read its cache contents. 
And you can try as often as you like as this is a physical change in the 
SRAM cells you are trying to detect. It does not go away when power is gone
or when you write other data into the cells. 

I think you are still not clear on what we are discussing here:
We have two different effects:

1. RAM cells keep their state a little while after power is gone.
   In SRAM this is due to parasitic capacitors in the cells and
   can be very short (microseconds). In DRAM it is due to the data 
   actually being stored in capacitors and they keep their charge 
   for seconds to minutes after they are not refreshed anymore. 
   In fact, DRAM cells are not powered in normal operation, only
   during read, write or refresh of that particular cell.
   SRAM cells are.

2. Carrying a specific bit value for a long time changes  
   an SRAM memory cell physically in a way that can be detected and that
   does mot go away (unless being overwritten with another pattern 
   that stays in there very long). It is rather unclear
   whether the same happen for DRAM and for DRAM it is very hard to 
   detect. For SRAM, ideally you just power it up and the attenuated
   cells come up with the bits they held for so long. 

Having the key in main menory means having it in DRAM. Having it
in the CPU cache means having it in SRAM, and in a very specific
location in addition, which strikes me as exceedingly stupid given
that SRAM cell attenuation is a known phenomenon.

It also degrades system performance.
 
> DRAM is easy, they have a standard connector (assuming a standard PC) 
> and building a device where you connect the DRAM and that then copies 
> the contents is relativly easy. At least for a qualified attacker.
> 
> Building a device that dumps the contents of a CPU should be quite 
> difficult and as an "active" component the CPU can't be simply read. 

You obvisouly have never heard of things like JTAG. I am sorry,
but I strongly suggest you read up on technology before making 
any more nonsensical claims. Also note the difference I pointed
out above.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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

Re: [dm-crypt] Some questions about cryptsetup 1.6.x

[Arno Wagner]

On Wed, Feb 12, 2014 at 17:10:40 CET, Milan Broz wrote:
> On 02/12/2014 03:30 PM, Thomas Bächler wrote:
> > Am 12.02.2014 15:19, schrieb Arno Wagner:
> >> -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
> >> iteration.
> > 
> > Are you sure?
> > 
> > I was under the impression that '-c' only affects the cipher parameter
> > passed to dm-crypt - a hash would then be relevant for cipher modes like
> > cbc-essiv, but xts-plain64 would ignore it. Thus, cryptsetup has default
> > like 'aes-cbc-essiv:sha256', since essiv needs a hash, and
> > aes-xts-plain64, since xts does not need a hash.
> > 
> > According to the manpage, -h is what is used in PBKDF2 in luksFormat
> > mode, or to hash the passphrase in plain mode.
> 
> Yes, this is correct. The -h parameter is for LUKS header (PBKDF2 + AF splitter).
> For plain mode it means algorithm to use when hashing password.
> 
> For -c it is cipher/mode for kernel dmcrypt (if there is a IV spec which requires
> hash like ESSIV, then it contains hashspec as parameter).
> 
> Milan

Just added clarifications for -c and -h to the man-page. That
I was confused about their meaning shows that it was not clear
enough ;-)

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@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