RE: C3 Nehemia C5P with better hardware RNG and AES support
coderman [EMAIL PROTECTED] I have written some poor code and info regarding the C5XL (nehemiah) and linux: http://peertech.org/hardware/viarng/ I've got code to use it under Windows in the latest cryptlib snapshots (soon to be the 3.1 release), which you can grab via the download link at http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html. The RNG code is in misc/rndwin32.c, and is available under a dual license (BSD or GPL, your choice). Note though that I don't actually have a C5XL to play with, so at the moment I've only been able to verify that it won't crash when run on AMD and Intel CPUs. If anyone has a C5XL with Windows installed, I'd be interested in hearing about any problems. Peter.
RE: C3 Nehemia C5P with better hardware RNG and AES support
.. 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,
RE: C3 Nehemia C5P with better hardware RNG and AES support
Peter wrote: In case anyone's interested, there's a cpu die photo at http://www.sandpile.org/impl/pics/centaur/c5xl/die_013_c5p.jpg showing the amount of real estate consumed by the crypto functions (it's the bottom centre, a bit hard to read the label). I fail to understand why VIA bothered adding AES support into the CPU. When was AES last the bottleneck on a general-purpose CPU? The bottleneck tends to be modular exponentiations, yet VIA failed to include a modular exponentiation engine. Strange. --Lucky Green
RE: C3 Nehemia C5P with better hardware RNG and AES support
At 11:04 PM 10/22/2003 -0700, Lucky Green wrote: Peter wrote: In case anyone's interested, there's a cpu die photo at http://www.sandpile.org/impl/pics/centaur/c5xl/die_013_c5p.jpg showing the amount of real estate consumed by the crypto functions (it's the bottom centre, a bit hard to read the label). I fail to understand why VIA bothered adding AES support into the CPU. When was AES last the bottleneck on a general-purpose CPU? The bottleneck tends to be modular exponentiations, yet VIA failed to include a modular exponentiation engine. Strange. Cylink made it mark in the early 90s by building the first commercial modular exponentiation chips to power its encryptor boxes. So the need for it this was well known even then. steve
RE: C3 Nehemia C5P with better hardware RNG and AES support
At 11:04 PM 10/22/03 -0700, Lucky Green wrote: I fail to understand why VIA bothered adding AES support into the CPU. When was AES last the bottleneck on a general-purpose CPU? The bottleneck tends to be modular exponentiations, yet VIA failed to include a modular exponentiation engine. Strange. Lucky, the VIA chip is for SOHO not servers. Therefore modexp is not a bottleneck, its a one time cost well performed by the x86 in a few hundred msec. On the other hand, the AES hardware could provide a substantial relief for the CPU for VPN apps, despite its relative ease in software compared to DES. Remember that the modexp cores out there are generally intended for high end apps like commercial-server cards. Though their gate count isn't too bad, they tend to require a large number of RAM controllers and embedded RAM for the operands. If you've got a good fraction of a second to spend, and have a general purpose CPU, you don't need hardware acceleration for modexp. As I wrote previously, I'd expect to see better integrated peripheral support (eg integrated ether or two) before I saw modexp support. --- The generation of random numbers is too important to be left to chance. -Robert R. Coveyou ORNL mathematician
RE: C3 Nehemia C5P with better hardware RNG and AES support
At 07:04 AM 10/23/03 -0700, Steve Schear wrote: At 11:04 PM 10/22/2003 -0700, Lucky Green wrote: bottleneck tends to be modular exponentiations, yet VIA failed to include a modular exponentiation engine. Strange. Cylink made it mark in the early 90s by building the first commercial modular exponentiation chips to power its encryptor boxes. So the need for it this was well known even then. Yes, because CPUs couldn't/can't keep up with SSL's DH modexp at *commercial server* rates. For lower rates, eg initiating a secure phone call, or the client-side of SSL, you can tolerate the delay of using a CPU. You only dedicate hardware if you need to do something a lot, and fast. Could be polygons on a gaming video board, mbuff operations in a network processor [1], or modexp on an SSL enhancer. [1] look into Intel's IXA processors. They have hardware support for everything you do in IP stack processing. Amazing. Later versions also include linerate AES. For large values of linerate.
