On Wed, October 29, 2014 17:50, Milan Broz wrote: > On 10/29/2014 05:21 PM, Arno Wagner wrote: >> FAQ Item 6.10 should also apply to AES-NI, AFAIK. >> I do not have an AES-NI capable system though to >> thest that. > > I think AES-NI can help with some (cache) timing attack but > not with Cold boot. How so? I mean, no matter what, the key needs to get loaded into a register at some time (possible pipelining it through the cache first) and will sooner or later vanish from the cache (or the cache might get depleted) and needs to get loaded again. Keeping it in the cache is difficult, and I don't see any hint that AES-NI uses internal registers (unadressable ones) to keep the key there once it is loaded. And then there's still the possibility of debug interfaces (i.e. HALT+DUMP). > >> I think this whole idea of storing keys in cache >> was some demo at some conference, but is not fit for >> practical deployment, as CPUs are too differtent. > > If you mean idea of frozen-cache, it's impact to performance is huge. > > There is also TRESOR and loop-amnesia which tries > fix the cold boot problem. Didn't tresor try to keep the key within registers? Regards -Sven > > (Just Google for frozen cache, tresor+aes or loop-amnesia for more info.) > > But all is x86_64 only and there is a lot of problems > (the first one is that it is not in upstream kernel:-) > > (And dmcrypt has still one copy of key in its structs, > so deploying such solution requires some changes here as well, > not trivial because of device-mapper table logic.) > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
