* Matthias Schniedermeyer <ms@xxxxxxx> wrote: > The only question for loop-aes is, when used in V3-Mode with 65 keys, > does it allow to "shuffle" the keys fully or at least partially. I haven't looked at the source, but I guess the keys are right next to each other in memory and not scattered. It's logical to write code like that. > I mean IF you can't pair with 65 keys belong to each other, you > don't need that many keys to make an attack this way as impratical > as an attack against the keys itself. Interesting, I hadn't thought of that. My thoughts were along the lines of spamming the memory with keys, obscuring the actually used ones and also applying a multi-layer loop-crypto setup like tripl, http://tripl.sourceforge.net/ > But i don't think this is the case, with no memory decay at all, > you should be able to find data wich loop devcies existed and which > keys belong to them, just like loop-aes has to know that > information itself. What we lack is a DRAM chip database about memory decay. Concerning desktops and laptops, there are numerous ways to slow down or even prevent the removal of intact chips. (superglue, enclose the chips with a strong fine metal band that contracts significantly if cooled down sufficiently and thus destroys the chip physically, a small EMP device to fry the chips, deadman switch, in-wall setups, ...) Servers, well, ... Also, what effect does overclocking have on memory decay? > So with an attack-tool specifically designed for loop-aes, the gain > (even with hundreds of loops) shouldn't be more than single digit > seconds. Yes, but that both depends on the setup used and on a non-decayed memory image (in places where the key material resides). -- left blank, right bald loop-AES FAQ: http://mareichelt.de/pub/texts.loop-aes.php#faq
Attachment:
pgpVJS3gdGUHS.pgp
Description: PGP signature
