The weakness here is in the seed we use for generating the encryption
key. This is not a fatal weakness. There are several scenarios:
a) the environment is trusted at boot. It has not been compromised, yet.
In this scenario, the random state stored for the RG is pretty
chaotic; and we can read it in to initialize the RG, then immediatly
wipe it from disk. Assuming we are good about clearing the data, it
cannot be recovered; and the RG can be trusted to give us a good key.
In this scenario, you can not recover the key.
b) the environment is not trusted at boot. someone might have a dump of
the harddrive already, and is waiting to take a second dump.
If we wish, we can write algorithms which induce chaos into the RG by
thrashing the page table, the cache, and the harddrives. We could devote
a second or two on boot to doing this, and get a few thousand bytes of
entropy from the /physical/ chaos we'd be playing with.
Alternatively, physical RG devices exist; and are rather easy to
make. We install a device designed to be pyhsically chaotic, and write a
driver for it which constantly seeds the RG. This would give us very
good chaos.
In this scenario, you can not recover the key.
Do not assume that, since random number generation is patently
impossible with an algorithm; that it is impossible with a computer.
Computers /are/ machines, and minute timing differences, or devices
designed for the purpose, can be used to pull chaos out of the physical
world, and into our algorithms. In addition information which was once
predictable, but has been destroyed along with its sources, is still
lost to you.
-- Crutcher <crutcher@datastacks.com> GCS d--- s+:>+:- a-- C++++$ UL++++$ L+++$>++++ !E PS+++ PE Y+ PGP+>++++ R-(+++) !tv(+++) b+(++++) G+ e>++++ h+>++ r* y+>*$ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/