Re: cold boot attacks on cgd?

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

> (There's an amusing corollary to this.  If the attacker has to go
> after the key, which may have some bits reset, there's suddenly an
> advantage to AES-128 -- more bits to try...)

If you really want to exploit that, secret-split the key, so it's
spread over several thousand bits, then reconstruct it on the fly when
it's needed.  For these purposes, even an (n,n) splitting technique is
good enough, such as XOR with a lot of equal-sized random blocks.

Ideally, you want to spread the key over so many bits that the error
rate introduces at least as much uncertainty as there is entropy in the
key.  I don't know what the error rate is like; if it's 1% (picked out
of the air), a 64-bit key needs only on the order of 6400 bits - 800
bytes - to achieve this; I'd be hesitant to recommend any specific
amount without doing tests to see how far down I could pull the error
rate.  (You might be able to reuse the RAM that holds the key
schedule....)  Of course, the lower the error rate, the more spreading
you need to do.  And if, as I suspect, errors are preferentially in one
direction (eg, 1s becoming 0s), it gets more complicated.

And hey, this may be the first case I've heard of where ECC RAM is a
distinct *dis*advantage!

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               mouse%rodents.montreal.qc.ca@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B