Re: cold boot attack question

On 2008-09-15, Ilmari Karonen <usenet2@xxxxxxxxxxxxxx> wrote:
On 14.09.2008, Kusigrosz <tvkerase0196@xxxxxxxxxxxx> wrote:
On 2008-09-11, Ilmari Karonen <usenet2@xxxxxxxxxxxxxx> wrote:

You have a point there. Plain addition doesn't improve things that
much, though, since it's commutative: two bit decays in the same bit
position still yield only three possible outcomes, one of which is
twice as likely as the others.

Maybe alternating xor and addition?

Probably not that much better: both operations are still commutative,
and not so different from each other. Intuitively, the problem with
addition here is that carries only occur occasionally, and by throwing
some xor into the mix you're just reducing that rate.

The reason I thought about those simple and very fast operations is
that, for a given time limit to restore the expanded key, the speed
of the algorithm translates to the area of memory the expanded key
can occupy, an so to the expected number of decayed bits.

However, I now think you are right in advocating hash functions.
They obliterate patterns, and on some hardware decay patterns might
be particularly unfortunate for xors and additions.
If, for example. the first bits to decay were always in the same
word position, xors and additions would perform very poorly.

If some disk space could be sacrificed, and secure, fast key
generation was available, the two key scheme could be speeded up
somewhat by generating a new key K for each data chunk, and dumping
it to disk encrypted with both K1 and K2. That way only K would
undergo double encryption, the data would be encrypted only once,
with K. If the chunks were large enough, it might not be much slower
than ordinary disk encryption. The given chunk be vulnerable only as
long as its key sits in RAM.

That's a good idea. In fact, I can spot a slight improvement: instead
of encrypting the chunk key before saving it, store it on disk as it
was generated and encrypt it before _use_. The advantage here being
that the process for generating chunk keys doesn't have to be all that
secure, since being able to guess the chunk key won't help you decrypt
the chunk unless you also know the global keys. Of course, you still
want the chunk keys to be reasonably random to avoid leaking
information about disk access patterns, but a fast and simple CPRNG
ought to be enough for that.

What about generating the chunk key from the position of the given
chunk on the disk (encrypting it with K1 and K2 before use)? Then
there would be no need to store it at all.


To send mail, remove 'erase' from the address