Slashdot Mirror

← Back to Stories (view on slashdot.org)

RC4 Code Achieves 319 MB/s On AMD64 Opteron

Posted by timothy on from the even-more-thingy dept.

Marc Bevand writes "This recent paper is about optimizing RC4 for AMD64 processors. A working implementation is provided. Its encryption/decryption throughput reaches 319 MB/s on a single AMD Opteron x44 processor running at 1.8 GHz. This makes it, as of today, the world's fastest RC4 symmetric cipher implementation for general purpose CPUs. As the author of this work, I would like to point out that many CPU-hungry applications have not been optimized for AMD64 yet. In other words: such speedups can be expected in other areas." An anonymous reader adds some figures for the old implementation: "Opteron 244 1.8 GHz (32-bit) 163 MB/s; Opteron 244 1.8 GHz (64-bit) 135 MB/s."

14 of 177 comments (clear)

  1. Optimisation is definately the key by datajack · · Score: 5, Informative

    I was initially disappointed with the performance of my Athlon64. CPU intensive 64bit code often seemed much slower than it's (heavily optimised) 32bit counterpart.

    Every now & then I come across some code optimised for 64bit processors, and it just flies - as more & more stuff gets the treatment, it will be like upgradingin for free :)

  2. Somewhat OT, but... by bhtooefr · · Score: 4, Informative

    If all a machine is doing is encrypting, A64s and Opterons are a bit overkill. The VIA C3 C5P has an encryption engine that makes top-of-the-line processors look sad. I couldn't find results for RC4, but is a page from a review of the EPIA MII-12000 which shows AES results. First graph is EPIAs in software, second is a few Intel and AMD CPUs (software), and the MII-12000 in software (which gets creamed by the AXP 2500+ and the P4@2.4) and hardware (which totally obliterates everything).

    1. Re:Somewhat OT, but... by mczak · · Score: 5, Informative
      AFAIK, the VIA's *only* do AES, as they're designed to make good VPN endpoints. This is cos some hefty AES subroutines are built into the hardware (with software drivers doing the rest).
      True. VIA padlock (as they call it) can currently only do AES in hardware (and it can also generate true random numbers). The next VIA chip called C7 (C5J Esther) however should be able to also do SHA-1, SHA-256 and parts of RSA in hardware (I think it should be available first half of 2005). That's of course still a limited set of encryption algorithms, but it's certainly an improvement.
    2. Re:Somewhat OT, but... by swillden · · Score: 2, Informative

      The government agency that selected and approved of AES are the same ones who approved of DES, oh so many years ago.

      And the same ones who were apparently surprised when flaws were found in SHA-1, which they also selected and approved. And the same ones who developed the Law Enforcement Access Field (LEAF) for Clipper, which was quickly broken by Matt Blaze.

      Thirty years ago when the NSA fixed IBM's Lucifer, which became DES, the NSA clearly had a huge amount of cryptologic knowledge that the public research community did not. Indeed, there really wasn't a public research community. That has changed. Although it's certain that the NSA has some tricks the public community does not, and it's obvious that there's nothing the public community knows that the NSA does not, it appears that the gap has closed considerably, and that it's entirely feasible for people to find flaws in NSA-approved, and even NSA-created ciphers.

      AES/Rijndael concerns lots of cryptographers because it is, by the only measure we really have available, the weakest of all of the AES candidates. All of the candidates use multiple "rounds" of computation, and all of them have been broken for some number of rounds less than the full algorithm. The difference between the number of rounds in the full algorithm and the largest number of rounds that has been broken is called the "margin of security", and Rijndael has a very thin margin of security, meaning that existing attacks only have to be extended by a little bit to break the full algorithm.

      Does this mean it's likely to be broken? No one knows, and only time will tell. Contingency plans are a good thing if you really care about security, though.

      I think that alone means it deserves the benefit of the doubt.

      You're insufficiently paranoid. Or, more likely, you just don't have anything you really need to protect. That's most people, actually.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  3. Not worth the outlay at present by cheezemonkhai · · Score: 4, Informative

    Don't get me wrong it's good that code is optimised, but I think that RC4 would fly faster on an IA64 than an opteron if specifically optimised to take advantage of the CPU's features.

    RC4 isn't really that relavent in real life as wep is crap & also easily done in hardware anyway.

    The 64 bit advantage will suffer thesame fate as the 32bit advantage did for the 486, pentium & especially the Pentium Pro.

    486 = 32bits, faster but people still bought 386's due to cost.

    Pentium = 32bits, sometimes faster but again costs meant 486's stayed popular.

    Pentium Pro = 32bit, 16 bit instrucations stalled it. WHen running pure 32bit code ran like the dogs, when running 16bit code (win 98) ran like a dog.

    Problem is that your generally better off saving your cash, buying a cheap CPU (32bit in this case) and waiting for the 2nd/3rd Generation CPU. By that time prices will more reasonable and you will see the full advantages as programs will use the extra bits properly.

    I mean come on MS still hasn't released a final AMD64 version of Winblows yet.

    1. Re:Not worth the outlay at present by joib · · Score: 3, Informative


      486 = 32bits, faster but people still bought 386's due to cost.

      The 386 was also a 32-bit processor...

    2. Re:Not worth the outlay at present by Anonymous Coward · · Score: 1, Informative

      The 386SX was 16/32 the DX was fully 32.

      The 486 SX & DX were both fully 32 but the DX had a math Co-Processor onboard.

    3. Re:Not worth the outlay at present by Bert64 · · Score: 4, Informative

      Actually, the majority of SSL websites are using RC4..
      If you use Mozilla and Apache, you can use 256-bit AES encryption for SSL (try loading up paypal with a mozilla based browser) but if either the server or client is microsoft-based your stuck with the much weaker 128bit RC4...
      MS - always behind the curve, no 256bit encryption, no 64bit os

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    4. Re:Not worth the outlay at present by nick-less · · Score: 2, Informative

      That's kinda vague. The 386 was a 32 bit processor with a 16bit data bus. It still could perform 32-bit arithmetic natively, but the bus was strangled.

      thats the 386SX you're taking about, the regular 386DX which came out before the SX was full 32bit..

    5. Re:Not worth the outlay at present by RangerElf · · Score: 2, Informative

      Regural x86 has 8 GP-register, AMD64 has 16.

      Not if you want to actually use the stack pointer and your stack-frame base pointer; you have 4 GP regs (EAX .. EDX), two kinda- specific-purpose regs (ESI, EDI), one crippled-kinda-general-purpose-pointer reg (EBP) and one specific-purpose register (ESP).

      AND, if you want to do multiplications and divisions (the worst offenders, IMO), then two of the GP registers are already spoken for (EAX, EDX).

      So actually, the grandparent poster was right.

      -gus

  4. Re:until by IWannaBeAnAC · · Score: 2, Informative

    Err, AMD have had developers working on optimizing GCC for quite a while now....

  5. Re:until by RupW · · Score: 5, Informative

    Sorry it's not immediately obvious to me. Who are they?

    AFAICR AMD paid SuSE to do the original work. I think the main developers were Jan Hubicka, the current x86-64 maintainer, and Andreas Jaeger. SuSE have a few more well-known GCC contributors: look at MAINTAINERS.

  6. Re:PowerPC G5 by Anonymous Coward · · Score: 4, Informative
    What ouch? You're looking at something different; RC4 is not RC5-72...

    From distributed.net's pages, here's what it has to say on the Opterons for RC5-72 (uniprocessor)
    The Opteron 2420 achieved a score of 9,547,969.00.

    The 2GHz G5 for RC5-72 (uniprocessor) achieved a score of 15,057,412.00 (there are 2.5GHz chips available...) The best multi-cpu scores?
    A 2-way 2 GHz Opteron achieved a score of 15,145,274.67, but
    a 2-way 2.5GHz G5 smoked it with a score of 37,441,192.00.

    Apples to apples, my friend, apples to apples.

  7. RC4 is not cryptographically strong by SiliconEntity · · Score: 2, Informative
    The RC4 stream cipher has a number of weaknesses. See Itsik Mantin's RC4 page; he is a crypto student who did his master's thesis on RC4. Among other weaknesses, the 2nd byte of the output is twice as likely to match the plaintext as it should be; there are weak keys; and it is possible to distinguish the output from randomness. Some of the attacks are practical and have been used to break the WEP wireless encryption algorithm, which uses RC4.

    If you really need speed, you can use RC4 securely but you have to know what you are doing and be aware of these attacks so you can employ protective countermeasures. Otherwise you are better off to use a cipher like AES which is actually secure.