RE: C3 Nehemia C5P with better hardware RNG and AES support
>Also, Centaur indicated that with the SHA on die, they can produce >statistically perfect RNG output. No kidding. With any crypto-quality hash, I can produce statistically perfectly uniformly distributed pseudorandom data from *successive integers*. 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) Johnny's whitener removes a particular kind of bias but does not reduce other kinds of regularity at all. Whitening don't mean squat for entropy. (Perhaps you can think of it as spread-spectrum for regularity, if the whitener isn't crypto-secure.) Dataset size is irrelevent except for detectability, you need more samples to be sure that nuances you see are there. >If you are using the hardware rng via a user space daemon feeding >/dev/random then this is no longer an issue. You MUST use some "hardware" (analog) input, and you SHOULD use whitening on the output, and most probably should do other operations in between (mixing partially unbiassed but imperfect input with a pool, for instance).
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
"Lucky Green" <[EMAIL PROTECTED]> writes: >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? 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. 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). >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. Peter.
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".
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
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
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). Peter.
Re: C3 Nehemia C5P with better hardware RNG and AES support
At 11:06 PM 10/15/03 +0200, Ralf-P. Weinmann wrote: >On Wed, Oct 15, 2003 at 05:14:17PM +0200, Eugen Leitl wrote: >> latest VIA C3 C5P does 1 GHz at 7 W power dissipation, >> has now two hardware RNG engines (and two x86 opcodes to >> read them), and an Advanced Cryptography Engine >> which can do AES (Rijndael128? doesn't say) at >> 12.5 GBit/s rate. > >Look at the PadLock ACE programming guide [1]. Only seems to support Rijndael >with a block size of 128 bits (= AES); it allows both key scheduling in >hardware and in software, the latter allowing you to have your own custom >key schedule. It also allows you to increase the number of rounds if you >think Rijndael-128's security margins are too low. Props to the VIA engineers >for both the customizability. Which is unlikely to be used, at it would be incompatible with everything else. The "customizability" is likely a flexibility they built for their own (debug, architectural) reasons and decided to expose to users. What they need is a USB or Ethernet interface to catch up to others. However the attraction of a relatively fast x86 (vs say a 100 Mhz MIPS or ARM) might offset this lack of integration for some designs. Am surprised not to see a little DES core stuffed into the spare space on the die, but kinda nostalgically pleased to see DES's EOL. RIP. >The errate are funny as well. Looks like the I found the following lexical rule mildly amusing, because I have seen the same thing added to military docs to make them politically correct (he -> he or she) without editing the whole damn thing. "NOTE: Throughout this document, a reference to encryption generally means both encryption and decryption."
Re: C3 Nehemia C5P with better hardware RNG and AES support
"Ralf-P. Weinmann" <[EMAIL PROTECTED]> writes: >Look at the PadLock ACE programming guide The security app note is also entertaining reading. For example it lists one of the motivations for getting security right as "your husband may find out ..". On why they didn't save a copy of the test data for the NIST suite: "(Hey, do you have 10TB of disk drives lying around? We can fill a 30 GB drive with raw bits in a little more than 30 minutes - if the drive controller can keep up with us.)". And a little further on it refers readers to "Marketing quote from CRI" (which was a slip-up this time). The app note was actually written by humans. Cool. Peter.
Re: C3 Nehemia C5P with better hardware RNG and AES support
On Wed, Oct 15, 2003 at 05:14:17PM +0200, Eugen Leitl wrote: > News in from San Jose microprocessor forum: > > latest VIA C3 C5P does 1 GHz at 7 W power dissipation, > has now two hardware RNG engines (and two x86 opcodes to > read them), and an Advanced Cryptography Engine > which can do AES (Rijndael128? doesn't say) at > 12.5 GBit/s rate. Look at the PadLock ACE programming guide [1]. Only seems to support Rijndael with a block size of 128 bits (= AES); it allows both key scheduling in hardware and in software, the latter allowing you to have your own custom key schedule. It also allows you to increase the number of rounds if you think Rijndael-128's security margins are too low. Props to the VIA engineers for both the customizability. The errate are funny as well. Looks like the current stepping has a bug in the key schedule for 192 and 256 bit keys. Cheers, Ralf [1] VIA PadLock ACE programming guide http://www.via.com.tw/en/images/Products/eden/pdf/PadLock_ACE_prog_guide.pdf -- Ralf-P. Weinmann <[EMAIL PROTECTED]>
