Re: RSA performance on Athlon64 vs. Itanium
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? Thanks, --Lucky Green Was there ever a reply to this? If so, could someone forward it to me off-list, as I missed it :-( Thanks! -- Yours, J.A. Terranson [EMAIL PROTECTED] Every living thing dies alone. Donnie Darko
Palladium/TCPA/NGSCB
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. 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. Cheers - Bill - Bill Frantz| There's nothing so clear as a | Periwinkle (408)356-8506 | vague idea you haven't written | 16345 Englewood Ave www.pwpconsult.com | down yet. -- Dean Tribble | Los Gatos, CA 95032
Re: [mnet-devel] DOS in DHTs (fwd from amichrisde@yahoo.de)
On Wed, Oct 22, 2003 at 04:47:02PM -0700, Steve Schear wrote: I think the U.S. Constitution will stand in the way of widespread adoption of NDLs. They may have regulated firearms, though these laws are widely ignored by citizens, but I have yet to see a license for owning a typewriter or PC proposed. They have already ruled numerous times that the Internet is deserving of at least as free and access as print media and political flyers (which can be anonymnous and still pass legal muster). You are an optimist. Us pessimists see use of Palladium/TCPA/NGSCB as all too tempting a means of regulation of the net. Initially one will not be able to get high speed Internet service at affordable rates without the big brother inside, but as this voluntary commercial regulatory measure proves not to curb behavior that certain powerful lobbies want controlled, there will be mandatory requirements imposed by law as per the Fritz chip. Perhaps courts will not allow such to be used for explicit censorship of otherwise legal free speech, but I'd not bet that an ISP would be required to allow objectionable content to pass over its wires under such a scheme. And once one must register to obtain certificates for Palladium/NGSCB attestation, one really does have a form of net drivers license. steve -- Dave Emery N1PRE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493
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: RSA performance on Athlon64 vs. Itanium
-Original Message- From: J.A. Terranson [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 22, 2003 18:46 To: Lucky Green Cc: [EMAIL PROTECTED] Subject: Re: RSA performance on Athlon64 vs. Itanium 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? Thanks, --Lucky Green Was there ever a reply to this? If so, could someone forward it to me off-list, as I missed it :-( J.A., I since ran additional tests. All tests are for 1024-bit RSA signatures. 1) OpenSSL as shipping with the RedHat Taroon beta for Athlon 64: 921 RSA signatures/second 2) OpenSSL compiled manually: 1313 RSA signatures/second 3) Performance benchmark application made available to reviewers: Exceeding 3800 RSA signatures/second. Reading various gamer and over clocker websites, the Athlon 64 general performance is testing at about par with the Intel P4 3.2GHz, faster in some tests, slower in others. With the Athlon 64 being the slightly less expensive CPU based on the prices I have seen around here. You basically get a 64-bit CPU for the price of a 32-bit CPU. The CPU seems to be catching on amongst the early adopter crowd. A friend just bought one for 32-bit gaming and is very pleased. Motherboards for the Athlon 64 are appearing rapidly. Two weeks ago, Fry's stocked one Athlon 64 motherboard. Today, Fry's had 3 of them. Looks like AMD may have some done something right with this CPU. I am getting ready to buy a second one to upgrade my other box at home. --Lucky Green
Dept. of Defense IPv6 Interoperabilty Test Begins (fwd from brian-slashdotnews@hyperreal.org)
Bundesministerium fuer Verteidigung, too: http://www.heise.de/newsticker/data/anw-21.10.03-000/ /kraut - Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] Date: 22 Oct 2003 22:26:03 - To: [EMAIL PROTECTED] Subject: Dept. of Defense IPv6 Interoperabilty Test Begins User-Agent: SlashdotNewsScooper/0.0.3 Link: http://slashdot.org/article.pl?sid=03/10/22/1755258 Posted by: CowboyNeal, on 2003-10-22 20:01:00 Topic: internet, 259 comments from the let's-get-it-on dept. [1]securitas writes The [2]Department of Defense has launched Phase I of its delayed IPv6 interoperability test ([3]mirror) in a six-month project dubbed [4]Moonv6. It is the [5]largest North American IPv6 test ever and its goal is to evaluate IPv6 for 'network-centric military operations.' Phase II was originally scheduled to begin in January 2004 but may be delayed due to the late start of the current test. 'IPv4 addresses are 32 bits long, enough for around 4 billion unique addresses.' In contrast, the IPv6 address length is '128 bits, or 340 billion billion billion billion unique addresses.' Experts hope this will solve a predicted IP address shortage as more devices are created to use the Internet. [6]Click Here References 1. http://geartest.com/ 2. http://www.computerworld.com/governmenttopics/government/story/0,10801,86243, 00.html 3. http://www.linuxworld.com.au/index.php?id=1854687864fp=2fpid=1 4. http://www.moonv6.org/ 5. http://dc.internet.com/news/article.php/3095951 6. http://ads.osdn.com/?ad_id=78alloc_id=1118site_id=1request_id=168131op=cl ickpage=%2farticle%2epl - End forwarded message - -- 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]
Re: [mnet-devel] DOS in DHTs (fwd from amichrisde@yahoo.de)
ignored by citizens, but I have yet to see a license for owning a typewriter or PC proposed. They have already ruled numerous times that the Internet is deserving of at least as free and access as print media and There are precedents. In Franko's Spain, all typewriters had to be registered with the state, and all had serial numbers. It was illegal and punishable to possess one without license. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
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.
Re: Palladium/TCPA/NGSCB
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.
Re: Palladium/TCPA/NGSCB
On Thu, Oct 23, 2003 at 11:59:47AM -0700, Major Variola (ret) wrote: And virii that infect the immune system can be fun too --imagine a virus infecting your antiviral program. HIV for Windows. Or a virus that modifes your other programs to make them appear to be known virii. You'd have to turn off your AV progams to keep them from destroying your files (or moving them around, going crazy with warnings when you start any program, etc) I'd bet that no AV programs have safeguards against this sort of false positive attack. Eric
