[tahoe-dev] 100-year cryptography
Jack Lloyd
lloyd at randombit.net
Wed Mar 10 07:42:07 PST 2010
On Tue, Mar 09, 2010 at 01:43:53PM -0800, Chris Palmer wrote:
>
> Although SHA-512 is two orders of magnitude slower/more power-hungry on ARM
> than SHA-256, that is *now*. In 5 or 10 years, we are likely to have faster
> machines, machines with larger word sizes (even small/low-power machines),
> and/or better power supplies/batteries.
[...]
> By then, of course, we will have migrated to SHA-3, which will be faster and
> maybe even safer. If only we had SHA-3 now...
Another factor: in 5-10 years, functions like SHA-3 will be widely
used, and commonly considered a 'benchmark function' to compare CPUs,
which will pressure CPU providers to either tweak their architectures
to support it well, or else provide straight-up hardware support. We
can see this with AES: the first CPUs supporting native AES
instructions were not Intel's big fast expensive chips, but rather
VIA's C7, the AMD Geode, and Amtel's AT91SAM7XC ARM chip, which are
all small, slow, low power chips. In order to make up the performance
difference, it was key to support with native hardware the most
essential CPU-intensive functions (which is why the VIA also includes
helper hardware for video codecs, SHA, and MPI arithmetic - because
two of the biggest CPU drains for normal user desktop machines are
video and SSL, and that's most noticable when your scalar CPU is 1/5
the speed of a competitors).
I actually was expecting that more ARM/PPC embedded systems would
support hardware AES, but looking at NIST's validation list [1], it
appears that most ARM/PPC chips using AES are used in systems like
handsets, radios, or line encryptors, all of which can probably get
away with software encryption. (For instance a 600 MHz ARM can do
AES-128 at around 50 Mbit/s, which is probably enough even for a VPN
concentrator hooked up to a T3 line)
-Jack
[1] http://csrc.nist.gov/groups/STM/cavp/documents/aes/aesval.html
More information about the tahoe-dev
mailing list