From: Noob on
Thomas Pornin wrote:

> One can still plausibly predict that AES-NI instructions should rock,
> because not only they have great cycle counts (Intel promises about 1.3
> cycle/byte on long runs)

They've now published performance results.

http://software.intel.com/file/24917
Intel AES Instructions Set White Paper (26/01/2010)

> Also it is my cue to point out that x86 hardware of the Core2-or-more
> class is the least susceptible to have actual performance issues on
> encryption. Limited hardware, such as what is found in cheap mobile
> phones and in home routers and WiFi access points, is much more starved
> on CPU, and is in the position to do crypto all day long. A 40$ home
> router typically has a MiPS or ARM derivative with little cache (8 kB L1
> cache for code on the Linksys router I have besides me), low power (200
> MHz, and not super-scalar), no special AES instruction, no big registers
> (no SSE2, no MMX, no FPU, only 32-bit general purpose registers) and yet
> is hooked to a high-bandwidth network (54 Mbit/s WiFi, 100 Mbit/s
> Ethernet). There are millions of such beasts out there.

Is Intel planning on bringing AES-NI to Atom?

(To compete against Via PadLock)

http://en.wikipedia.org/wiki/VIA_Nano
http://en.wikipedia.org/wiki/Intel_Atom

Regards.
From: Peter Gutmann on
Thomas Pornin <pornin(a)bolet.org> writes:

>A commonly used AES implementation is the one from Brian Gladman
>(see his home page on http://www.gladman.me.uk/ ). If your code is
>an implementation of AES, then mimicking his API would mean that your
>code would be usable wherever his code has been used.

I was going to suggest exactly the same thing, you really don't want to do an
entire CSP just for an AES implementation, but providing a version that's
plug-compatible with Brian's code would be a good way to get it used.

(Having said that, you'd then need to convince people that it's worth using,
since the original is already pretty good - efficient, portable, has support
for hardware AES, etc).

Peter.