My point is that comments of the nature "has anybody tried xyz, it looks nice" are completely unhelpful when delaing with secure implementation of crypto. Please refreain from giving them. Arno On Fri, Feb 22, 2008 at 10:19:40PM -0800, Bill Broadley wrote: > > Private message, forward as you please, didn't seem to warrant further > discussion on the list. > > Arno Wagner wrote: > >On Fri, Feb 22, 2008 at 11:45:14AM -0800, Bill Broadley wrote: > >>Do today's CPUs allow for pinning a small amount of data in cache? Say > >>16 bytes or whatever is needed for an encryption key? > > > >No. There is no structure for that. Caches do not work this way. > > After further research looks like CPU caches do worth that way for some > CPUs, alas not the common desktop ones. > > >You could put crypto-keys into CPU registerts. But for numerous > >reasons this is a very bad idea. And it would not help either. > > Why not? How do you propose that anyone with a can of freon and a spare > laptop could read a register from inside a CPU without cooperation from the > OS? > > >>Seems like it would be > >>significantly harder to remove a CPU (especially from a laptop) and that > >>CPUs likely initialize the cache when power is provided. y > >> > >>That way the key is never in memory, cache size is reduced by a trivial > >>amount, and the key would be significantly harder to recover. > > > >They key would still be in memory, as it can be derived from the > >cipher-setup. Also your "significantly harder" is pure conjecture. > > Er, not sure why, I understand a fair bit of what is involved, I'm open to > why this would be true. > > >Would you people please stop the half-backed suggestions and > >get a grip? This is not a major issue and it is not a surprise > >either! > > Sure, agreed. It's been well known for decades, it's common to see a frame > buffer for instance after a power cycle. I didn't think it was a major > problem, but if it was just a few lines of code why not. Seems like such > things are fairly common. ssh-agent for instance pins memory to avoid > ending up in swap. Not that swap attacks are common, or that if someone > can read the > binary contents of your swap that you don't have other problems as well... > but > why not? > > IBM fixed this problem by putting the key inside a TPM chip that has a temp > sensors and has no mechanism to allow for reading the key (it sits between > the > CPU and the disk). > > My java ring/ibutton does this by keeping the key inside a tamper resistant > shell that detects penetration and cold and has a local power source to > implement a quick overwrite if it detects an attempt to read it's memory. > > I know the via c3 has some AES encryption with 128,192, and 256 bit keys, > not sure where the key is stored, but certainly seems reasonable to think > it's not in ram. > > >Also when Ed Felton writes that "he could easily", then > >this does still not mean that your average industrial spy has > >a chance. If your attacker is above average, disk-encryption > > Sure. If properly motivated I think I could manage it, I suspect you could > as well. Sure munging large binary images looking for signatures related > to a key isn't easy. My original comment was mainly, is this easy... maybe > it's > worth it. Alas common CPUs don't support it... so it's probably not. > > >as the only protection of a running (!) system is obviously > >not enough. No competent security expert should be surprised > >by that. > > Sure. Although you could also argue that without physical security why > bother with dm-crypt since the next time the key is used it could be stolen. > > Certainly there are other attacks like: > FireWire Memory Dump of a Windows XP Computer: A Forensic Approach > > >This is not a new problem, the paper just puts some > >concrete numbers of an attack that everybody with the right > >knowledge expected to be feasible anyways. > > Right, so more people know about it, so the barrier to it's use is lower. > So a larger population of less clued people might attempt it. Someone > might even sell the tool that finds the key for you. The computer > forensics seems to be growing rather quickly to server the ever increasing > needs of governments and law enforcement. There are certainly tools to > crack all the poor encryptions out there (which there are many) from > lotus-1-2-3 on up. > > So in any case if there's a way to keep the key in a relatively secure place > that isn't trivially removed or read through a firewire port I think it > should be considered. Ideally everyone would have the ibm tpm chip for a > much higher degree of security where you can't read the key, only write a > new one, at least without significant magic beyond the means of mere code > jockies. > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > -- Arno Wagner, Dipl. Inform., CISSP --- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
