cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: OpenSSL ENGINE 2nd version

From: Götz Babin-Ebell <babinebell_at_trustcenter.de>
Date: Mon, 17 Dec 2001 20:57:29 +0100

Daniel Stenberg wrote:
>
> On Mon, 17 Dec 2001, Götz Babin-Ebell wrote:
>
> Hey again! ;-)
Hello Daniel,

> While applying your patch and reading the new code, I stumbled over this
> (again) and I really can't see the use case for these two:
>
> CURLOPT_SSLENGINE
>
> It sets the engine to use in the curl handle for the upcoming SSL
> connection. Fine.
>
> CURLOPT_SSLENGINE_DEFAULT
>
> Now, this sets the default engine. Default for what? For all SSL sessions
> universally?
>
> Does this mean that if we use both these options, we don't have to set any of
> them in the next one and it'll automaticly use the ENGINE anyway?

The difference is:
* CURLOPT_SSLENGINE sets the crypto engine for the private key used in
the
  CURL object.
  You have to set it for every CURL object you use.
* CURLOPT_SSLENGINE_DEFAULT sets the crypto engine for all other
cryptographic
  (mostly asymetric) operations.

> I understand we're not to blame for silly OpenSSL design decisions (that sets
> global things for a library!), but if we have the CURLOPT_SSLENGINE set for
> the handle, why would we ever use the CURLOPT_SSLENGINE_DEFAULT?

To use CURLOPT_SSLENGINE_DEFAULT is good for two reasons:
* asymetric cryptography (especially RSA) requires calculations with
numbers
  of some hundred bit lengths. Normal processors are not build for such
use.
  On the other hand is a cryptography module specially designed to do
such
  operations. This not neccessarily means that a cryptographic module
  allways accelerates a single handshake (transfering the data to the
HSM requires
  some overhead...) but is especially usefull on a heavy loaded server,
since
  it frees the processor to do other tasks...
* Professional cryptography modules (exception: chip cards) come with a
good
  (hardware) source of random data. And this is something you need in
cryptography...
  Normal computer don't have hardware random generators, they calculate
the random
  data from internal system states (if they provide a random pool at
all...)
  The reason why chip cards normally have very slow random generators is
that a
  (hardware) random generator needs some (electrical) power that is not
available
  in a chip card.

Bye

Goetz

-- 
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126

Received on 2001-12-17