October 2003 - cypherpunks-legacy

RE: RSA performance on Athlon64 vs. Itanium
by pgut001＠cs.auckland.ac.nz 23 Oct '03

23 Oct '03

"Lucky Green" <shamrock(a)cypherpunks.to> writes: >I since ran additional tests. All tests are for 1024-bit RSA signatures. Taking some guesses here at the code being used: >1) OpenSSL as shipping with the RedHat Taroon beta for Athlon 64: > >921 RSA signatures/second x86-32 hand-tuned asm optimised for Pentium Pro. >2) OpenSSL compiled manually: > >1313 RSA signatures/second x86-64 code, gcc optimised for Athlon64. >3) Performance benchmark application made available to reviewers: > >Exceeding 3800 RSA signatures/second. x86-64 hand-tuned asm optimised for Athlon64. I'm guessing this one has the same catch as the Itanium speed test. >I am getting ready to buy a second one to upgrade my other box at home. My PoS hardware test PC and a $25 Broadcom chip beats your Athlon 64 :-). Peter.

1 0

Re: RSA performance on Athlon64 vs. Itanium
by pgut001＠cs.auckland.ac.nz 23 Oct '03

23 Oct '03

"J.A. Terranson" <measl(a)mfn.org> writes: >On Sun, 12 Oct 2003, Lucky Green wrote: >> I just picked up an Athlon64 3200+, which runs at a 2 GHz clock speed. >> Using the Red Hat for AMD64 beta and the version of OpenSSL that ships >> with that beta, I get 922 1024-bit RSA signs per second. This is a tad >> less RSA signatures per second than I have seen on an 800MHz Itanium >> using highly optimized assembler. That's rather poor performance on the >> Athlon64. >> >> Are the figures that I am seeing typical for OpenSSL on the Athlon64? >> Has anybody here seen different figures using optimized code? > >Was there ever a reply to this? If so, could someone forward it to me off- >list, as I missed it :-( The reply, sent off-list, was something like "You're running x86-32 code on an x86-64 CPU in emulation mode, what do you expect?" :-). In addition the Itanium RSA demo code works by turning the CPU into a $1000 ASIC, so you'd need to test it for SSL handshakes per second or something similar where the CPU has to do some other work besides RSA crypto ops. Peter.

1 0

Re: Palladium/TCPA/NGSCB
by Major Variola (ret) 23 Oct '03

23 Oct '03

At 11:06 PM 10/22/03 -0700, Bill Frantz wrote: >Mark Miller pointed out to me that currently much of our protection from >viruses comes from people at the anti-virus companies who quickly grab each >new virus, reverse engineer it, and send out information about its payload >and effects. You could be talking about biology as well. Any system which hides code from reverse engineering will >make this process more difficult. To the extend that Palladium/TCPA/NGSCB >hides code, and to the extent it succeeds at this hiding, the more it >encourages new and more pervasive viruses. A virus that contains "friendly" IFF codes can evade an immune system. Some cloak themselves in membranes derived from cells they were born in. Thus they present the right IFF response. A virus that appears to Palladium to be friendly and worthy of the full protection -the right hashes, etc- will be a fun thing. Some virii are innocuous except when they pick up a piece of virulence code. Then they kill. IIRC anthrax is like this, some of the streps. One can imagine writing a virus which is in fact merely a bit of virulence code taken in by an other innocuous but replicating program. Its common in biolabs to cross a hard-to-grow nasty with an easy-to-grow labbug so you can study the nasty. Sometimes, the result is dangerous. See the synthetic mousepox which killed the mice. And virii that infect the immune system can be fun too --imagine a virus infecting your antiviral program. HIV for Windows.

2 1

RE: C3 Nehemia C5P with better hardware RNG and AES support
by Major Variola (ret) 23 Oct '03

23 Oct '03

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".

1 0

RE: C3 Nehemia C5P with better hardware RNG and AES support
by Major Variola (ret) 23 Oct '03

23 Oct '03

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

1 0

Re: C3 Nehemia C5P with better hardware RNG and AES support
by pgut001＠cs.auckland.ac.nz 23 Oct '03

23 Oct '03

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.

3 2

Dept. of Defense IPv6 Interoperabilty Test Begins (fwd from brian-slashdotnews@hyperreal.org)
by Eugen Leitl 23 Oct '03

23 Oct '03

Bundesministerium fuer Verteidigung, too: http://www.heise.de/newsticker/data/anw-21.10.03-000/ </kraut> ----- Forwarded message from brian-slashdotnews(a)hyperreal.org -----

1 0

RSA performance on Athlon64 vs. Itanium
by Lucky Green 23 Oct '03

23 Oct '03

I just picked up an Athlon64 3200+, which runs at a 2 GHz clock speed. Using the Red Hat for AMD64 beta and the version of OpenSSL that ships with that beta, I get 922 1024-bit RSA signs per second. This is a tad less RSA signatures per second than I have seen on an 800MHz Itanium using highly optimized assembler. That's rather poor performance on the Athlon64. Are the figures that I am seeing typical for OpenSSL on the Athlon64? Has anybody here seen different figures using optimized code? Thanks, --Lucky Green

2 2

Inferno: Why War?: All the President's Votes? (fwd)
by Jim Choate 22 Oct '03

22 Oct '03

---------- Forwarded message ---------- Date: Wed, 22 Oct 2003 19:18:22 -0500 (CDT) Subject: Inferno: Why War?: All the President's Votes? Interesting read from our chief black-box voting researcher, martini... ---------- Forwarded message ---------- Date: Wed, 22 Oct 2003 16:41:12 -0500 (CDT) Subject: heya.. seen this? http://www.why-war.com/news/2003/10/14/allthepr.html I'm still reading through it, but thought I'd send it forward sooner than later.

1 0

J2ME + crypto + mobile
by Eugen Leitl 22 Oct '03

22 Oct '03

Anything beyond http://www.bouncycastle.org/ to experiment with crypto on J2ME-capable mobiles? Is it at all possible to use traffic remixing for SMS-like messages with J2ME infrastructure? -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 0.97c removed an attachment of type application/pgp-signature]

1 0