<p dir="ltr">Den 20 maj 2014 03:00 skrev <<a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>>:<br>
><br>
> I think I may have bored many of you with my last message in this thread. lol<br>
><br>
> Regardless of answers, I've kept looking for resources, one fact I found interesting is that MIPS has more registers than ARM, maybe then that would offset the need for debug registers. See this comparative regarding the MIPS-3000 architecture performance by register allocation, page 90, table 1:<br>

><br>
> <a href="http://researchbank.rmit.edu.au/eserv/rmit:2517/n2001000381.pdf">http://researchbank.rmit.edu.au/eserv/rmit:2517/n2001000381.pdf</a><br>
><br>
> By that comparative, we don't need to use small keys and we could use twofish. Yet for each extra register used to store the key, more operations will be necessary to encrypto/decrypt stuff, thus knocking performance down.<br>

><br>
><br>
> Coming back to the small keys issue. I found this paper that promises good crypto for small keys:<br>
><br>
> <a href="http://www-scf.usc.edu/~adityaav/BE_Project_Paper.pdf">http://www-scf.usc.edu/~adityaav/BE_Project_Paper.pdf</a><br>
><br>
> Can you crypto-nerds make an evaluation of that? How much of a compromise in security would we get if we reduced the 112 bit keys to 96 bit keys?<br>
><br>
> This would be done for MIPS machines, which are the lowest of the low on which we could apply something like a crypto-core. Other architectures would work with other solutions, ie. most ARM 7 CPUs have 6 or more registers that could be used.<br>

><br>
> Of course we could make things for the latest processors, 64 bits, run twofish and forget it. But then only a fraction of people would benefit from having a crypto-core in their CPUs. Our goal is to make a crypto-core that runs in most machines, even more so in unattended routers and cellphones than servers (which already have options to encrypt memory portions and can run serious PRNGs at little processor cost).</p>

<p dir="ltr">How much do you trust NSA? They published the lightweight ciphers Simon (intended for hardware implementation) and Speck (for software, including on microcontrollers). They're meant to perform well. There's a real chance they're backdoored, though, but they might be useful for experimenting. But they have versions of Speck with block size/key size of 48/96 and 64/96 bits, up to 128/128 (still faster than AES).</p>

<p dir="ltr">Note that 80 bit keys is considered the current upper limit of what's practically bruteforcable by large organizations, and that's assuming a strong cipher. I would not trust 96 bits for very long considering the risk of a small fast cipher having half it's effective key strength undone by cryptanalysis and the continuous advancements in hardware, I want a better security margin. It is ok if it only needs to protect temporary secrets, though.</p>

<p dir="ltr">Then you also need some secure cipher mode on top of that, ideally an authenticated one (don't ever do ECB). Don't know any that's fast even on microcontrollers.</p>