C3 Nehemia C5P with better hardware RNG and AES support

[coderman]

... delayed response

 > From: Peter Gutmann

> "Lucky Green" <[EMAIL PROTECTED]> writes:
> >...
> >I fail to understand why VIA bothered adding AES support into the CPU. When
> >was AES last the bottleneck on a general-purpose CPU? 
> 
> Apart from the obvious "what cool thing can we fit in -> <- this much spare
> die space?", the obvious target is SOHO routers/firewall boxes.  My spies tell
> me that it's already being used in a number of products like this, and the
> addition of AES will help the process.

I am working on a linux distribution that is using the hardware RNG for
seeding/rng in number of things (IPSEC, ssh, ssl, gpg, etc) and this is
definitely the angle I am excited about.

A 1Ghz proc goes a long way, but in a media intensive system (video,
audio, streaming over wireless) you want to keep CPU load as light as
possible so that latency is minimal.

With the C5P you can now do VPN with AES, rng via the hardware entropy,
and video offload via the CLE266.  This leaves the CPU free to handle
various interrupts for the wireless network, disk i/o, etc.

Very nice move, I think.

I have written some poor code and info regarding the C5XL (nehemiah)
and linux:

    http://peertech.org/hardware/viarng/

[ I'll be cleaning code up and releasing new patches/srcs soon ]


 
> Hardware SHA-1 in the next rev makes
> it even better, since you can now do IPsec and SSL tunneling purely in
> hardware (and then you lose it all again in the crappy Rhine II NIC, but
> that's another story).

A lot of peer networking applications use SHA digests for securely
identifying resources in a network.  The overhead of this for large
volumes of content will make this a welcome addition :-)

Also, Centaur indicated that with the SHA on die, they can produce
statistically perfect RNG output.  The von neumann whitener does let
a small bias through for very large data sets IIRC (i.e. a
statistical bias is detectable in 1G or more data)

If you are using the hardware rng via a user space daemon feeding
/dev/random then this is no longer an issue.



> >The bottleneck tends to be modular exponentiations, yet VIA failed to include
> >a modular exponentiation engine. Strange.
> 
> Not for SOHO use it isn't, the initial handshake overhead is negligible
> compared to the constant link encryption overhead.  The alternative is to do
> the crypto externally, for which you're paying for an expensive and power-
> hungry crypto core capable of doing a zillion DH/RSA ops/sec that gets used
> once every few hours.  The alternative is to load or load your standard
> firewall firmware into a Nehemiah and offload all the crypto and RNG stuff.

I am also curious about crypto-loop file system acceleration / CPU offload.
There are a number of uses I am anxious to try with this hardware.

Best regards,