Educause Security Discussion mailing list archives
Re: Risks of File Transfer on a Fully Switched Network
From: Alan Amesbury <amesbury () OITSEC UMN EDU>
Date: Tue, 6 Dec 2005 11:04:59 -0600
Robert Kerr wrote: [snip]
Running an openssl speed test on a P4-3GHz tends to disagree with that: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des ede3 19308.92k 19761.15k 20062.09k 19968.68k 19649.88k Maybe the addition of SSE2 is a big advantage here? Obviously this test is slightly synthetic as it's only testing the raw encryption and not any of the other overheads SSL brings (ie the HMACs).
At the risk of getting a bit off-topic..... There are hardware accelerators that can be used to offset the computational cost of using encryption. However, not all accelerators are created equal. When running 'openssl speed' on a 3.2GHz Xeon, I found that the system was around 10-20% slower *WITH* the hardware accelerator installed than without it. When I looked at the source code for clues as to why this was happening, I found the following information in hw_cryptodev.c (part of the OpenSSL source): * XXXX just disable all digests for now, because it sucks. * we need a better way to decide this - i.e. I may not * want digests on slow cards like [REDACTED] on fast machines, * but might want them on slow or loaded machines, etc. * will also want them when using crypto cards that don't * suck moose [REDACTED] - would be nice to be able to decide something * as reasonable default without having hackery that's card dependent. * of course, the default should probably be just do everything, * with perhaps a sysctl to turn algoritms off (or have them off * by default) on cards that generally suck like the [REDACTED]. Lesson learned: The cheap crypto card may not really be worth it. While the card we bought might be ideal for a Pentium II 400, it was a poor match for something like a relatively new Xeon. Newer processors do crypto pretty quickly. Many of the advances developed to speed up graphics processing (think MMX, SSE, SSE2, 3DNow, etc.) also happen to work really nicely for crypto as well. Case in point: I think the distributed.net client (the one used for the RC5-64 challenge?) gained a huge speed increase when it was rewritten to take advantage of the MMX instruction set. I think there's already groups out there trying to figure out ways to use the GPUs on newer graphics cards (later ATI RADEON and Nvidia GeFORCE chips, for example) as crypto engines. Getting back on topic, though..... We generally recommend that academic units here opportunistically encrypt data where possible, even if the users don't think such protection is necessary. It helps establish (what I consider to be) good habits, and the speed hit is usually not as noticeable as one might think. -- Alan Amesbury University of Minnesota
Current thread:
- Re: Risks of File Transfer on a Fully Switched Network, (continued)
- Re: Risks of File Transfer on a Fully Switched Network Dunker, Mary (Nov 30)
- Re: Risks of File Transfer on a Fully Switched Network Gary Flynn (Nov 30)
- Re: Risks of File Transfer on a Fully Switched Network Gary Dobbins (Nov 30)
- Re: Risks of File Transfer on a Fully Switched Network Huba Leidenfrost (Nov 30)
- Re: Risks of File Transfer on a Fully Switched Network Russell Fulton (Nov 30)
- Re: Risks of File Transfer on a Fully Switched Network Bradley Ellis (Nov 30)
- Re: Risks of File Transfer on a Fully Switched Network Cal Frye (Dec 01)
- Re: Risks of File Transfer on a Fully Switched Network Scholz, Greg (Dec 01)
- Re: Risks of File Transfer on a Fully Switched Network Gary Dobbins (Dec 01)
- Re: Risks of File Transfer on a Fully Switched Network Robert Kerr (Dec 02)
- Re: Risks of File Transfer on a Fully Switched Network Alan Amesbury (Dec 06)