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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
