[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: glxsb(4) doesn't appear to be working for me (was: AMD Geode LX Security Block)
On Fri, Oct 30, 2009 at 12:18:00PM -0400, Greg A. Woods wrote:
> At Thu, 29 Oct 2009 22:30:23 -0400, Thor Lancelot Simon
> <tls%panix.com@localhost> wrote:
> Subject: Re: glxsb(4) doesn't appear to be working for me (was: AMD Geode LX
> Security Block)
> > You may need to explicitly specify -engine cryptodev, and note that you
> > will not get *any* accelleration from openssl speed for any cipher
> > unless you specify it as an "evp" instead of by the shortcut name:
> > openssl speed -engine cryptodev -elapsed -evp aes-128-cbc
> I'm not sure I understand. None of the examples I saw on the NetBSD
> lists show this (and it's not explained at all in the manual page).
I can't say why people would post wrong examples to the NetBSD lists. I
do often wish that if people didn't know what they were talking about,
they'd pipe down already with the "helpful" advice on the lists...
I can say why the manual page is wrong: OpenSSL manual pages in general
just plain suck.
Here is what is going on: the OpenSSL "engine" interface is jammed in at
their abstract-algorithm layer (fsvo "layer") which lies between their
SSL-record-handling layer and the raw encryption routines. This layer
is called "EVP".
The openssl 'speed' utility calls the raw encryption routines when you
tell it to do a speed test for a cipher. So the cryptodev engine never
sees the requests. However, it calls the EVP routines when you tell it
to do a speed test for any other kind of algorithm, such as a hash
function like MD5 or SHA! This can be extremely confusing.
The workaround is to trick it into thinking it's testing some other
kind of block-oriented algorithm by telling it to look up the cipher
*by its EVP* which forces it to use the EVP layer, so the engine layer
sees the requests. This is what the -evp switch on the command line
Main Index |
Thread Index |