Re: Risks of File Transfer on a Fully Switched Network

[Alan Amesbury <amesbury () OITSEC UMN EDU>]

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