Hello everyone! Somehow this discussion goes in circles. Several months ago my first reflex on this cold-boot attack was the proposal of moving sensitive data from DRAM to processor cache. Gisle supported this by arguing that level 1 and 2 cache consists of SRAM with higher volatility. SRAM as such is static as it needs no refresh cycles to maintain data integrity but deteriorates all information once its power supply is shut off. Theoretically, processor cache seems to be the best place for key material. Newer processors came with increasing cache sizes and also increasing heat sinks, which are also more and more cumbersome to remove. Ripping a processor off its socket will physically break it, while removing all clamps and screws involves enough time for the cache content to decay. Apart from that, a processor is the hottest spot in each PC. Practically, the authors of this cold-boot attack have given no evidence for the existence of the described physical backdoor. Altering loop-aes to store keys only in processor cache might lead to problems with older hardware which had less cache. Apart from that, it becomes increasingly platform dependent and may not compile/work with some kernels. The impact on computing performance is unclear since I have no idea how much precious cache memory would be needed for keys alone. A look back remembers me of how happy I was to get a patch for loop-aes to make full use of my 64-bit processor/kernel. Just think of the increase of throughput at even lower system load. Sell it all out for a patch that protects me against a source-less phantom? No, I wonder if Jari would waste his time before some code is at hand to launch test runs and find key material, at least on a running machine. Writing a kernel module and attributing variables to be stored in processor cache *alone* seem to be two different things to me. Since OSes like Linux feature virtual memory management, this project looks to be quite challenging. How to redirect all file/keyboard input to cache memory, bypassing all virtual memory? The idea with the processor cache was just a snapshot! Kind regards, Peter -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
