[Cryptography] How to lock registers with GCC?

[Natanael]

Den 20 maj 2014 03:00 skrev <tpb-crypto at laposte.net>:
>
> I think I may have bored many of you with my last message in this thread.
lol
>
> 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:
>
> http://researchbank.rmit.edu.au/eserv/rmit:2517/n2001000381.pdf
>
> 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.
>
>
> Coming back to the small keys issue. I found this paper that promises
good crypto for small keys:
>
> http://www-scf.usc.edu/~adityaav/BE_Project_Paper.pdf
>
> 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?
>
> 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.
>
> 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).

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).

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140520/05484234/attachment.html>