Hello everyone! Before writing some fancy patch to re-encrypt/scramble key material, might it be possible to go the full hog? I mean from a rather macroscopic point of view the whole DRAM-part turns out to be a leakage. Since at least photorec is able to produce usable files from /dev/mem on a running system, this area becomes unprotected to some extent. Once again I emphasize photorec is *not* limited to jpg headers! It looks for some 80 kinds of file types, including text files. That was why I was asking for a distinct string appearing in loop-aes related key material. Key question is: What happens at boot time when kernel is loaded form usb memory? A part of the physical DRAM memory must be allocated for the uncompressed kernel. But what then? First modules are loaded, an environment to enter the passphrase and finally mount the encrypted root partition is needed. At the time when /dev/mem is created, would it be possible to set a random key and encrypt the user-part of the system´s memory? Encrypting swap can already be handled in such a way, with generic keys for single usage and no user interaction needed. Of course, this would put memory throughput over the edge. Such a scenario is intended for rather strong PCs with several megabytes of CPU cache and at least two cores to do some work beyond the de-/encrypting. In my eyes embedded systems (routers, dsl modems and the like) aren´t that vulnerable to a cold-boot attack as their memory is soldered & the cases bolted together, Perhaps this approach is easier to implement than a code that assures key material is set up and erased properly in otherwise unencrypted memory. Any countermeasure will show an impact on system performance and this one here seems to provide highest protection at the cost of maximum processing power. Hence, is it actually possible to encrypt all of DRAM memory? The code for this would have to reside in the CPU cache. How far is this from being realistic? Can it be compared to some compression software used to extend RAM size advertised in the early era of Windows 95? How about a RAM disk used as encrypted swap partition so that no DRAM memory is free but swap space increases by that same size? The encrypted RAM disk could be assigned with a higher priority. So, how sick sounds this idea? 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/
