On Sat, Feb 23, 2008 at 02:31:35PM -0800, Jacob Appelbaum wrote: > Richard Zidlicky wrote: > > Hi, > > > >> As a reaction to this "attack" I wonder if it might be possible to > >> use level 2 cache of the processor to store keys in highly volatile > >> memory space. 2 or more megabytes on the CPU die might be a last > >> resort. As gpg prevents leaking keys from kernel ram to swap > >> partitions, newer disk encryption might prevent keys to be stored > >> in DRAM cells. Of course, elderly processors might not do this > >> stunt due to lack of level 1/2/3 cache but newer architectures > >> offer ever increasing megabytes. Is that a worthwhile option? > > > > there is aonether option that is well doable with todays technology. > > On a multi-CPU machine run a dedicated noninterruptible kernel > > thread on one of the cores which keeps essential parts of the key in > > CPU registers at all times. > > > > I'm curious how you would account for the key schedule information and > other sensitive information. you can store at least 256 bits of information in registers of most architectures or even more than 2048 on some while retaining full turing capability of that CPU. This should be enough to encrypt all key derived information in main memory in a way that would make your kind of attack significantly harder to perform. > > Using some of the coprocessors would be another interesting idea but > > much less portable. > > Yes, it is less portable but it is tamper resistant and specifically > designed to thwart many types of attacks. designed by whom? I trust common CPUs more than I would trust the clipper:) Richard - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
