crypto devices (eg. accelerator cards). This component is called ENGINE,
and its presence in OpenSSL 0.9.6 (and subsequent bug-fix releases)
caused a little confusion as 0.9.6** releases were rolled in two
- versions, a "standard" and an "engine" verion. In development for 0.9.7,
+ versions, a "standard" and an "engine" version. In development for 0.9.7,
the ENGINE code has been merged into the main branch and will be present
in the standard releases from 0.9.7 forwards.
gets its own copy of it. As such, multi-threaded code (or code that
multiplexes multiple uses of 'dynamic' in a single application in any
way at all) does not get confused by 'dynamic' being used to do many
- independant things. Other ENGINEs typically don't do this so there is
+ independent things. Other ENGINEs typically don't do this so there is
only ever 1 ENGINE structure of its type (and reference counts are used
to keep order). The dynamic ENGINE itself provides absolutely no
cryptographic functionality, and any attempt to "initialise" the ENGINE
"-pre" syntax in the "openssl engine" utility is that some commands
might be issued to an ENGINE *after* it has been initialised for use.
Eg. if an ENGINE implementation requires a smart-card to be inserted
- during intialisation (or a PIN to be typed, or whatever), there may be
+ during initialisation (or a PIN to be typed, or whatever), there may be
a control command you can issue afterwards to "forget" the smart-card
so that additional initialisation is no longer possible. In
applications such as web-servers, where potentially volatile code may
hand such applications would only have the memory footprint of any
ENGINEs explicitly loaded using user/admin provided control commands.
The main advantage of not statically linking ENGINEs and only using
- "dynamic" for hardare support is that any installation using no
- "external" ENGINE suffers no unecessary memory footprint from unused
+ "dynamic" for hardware support is that any installation using no
+ "external" ENGINE suffers no unnecessary memory footprint from unused
ENGINEs. Likewise, installations that do require an ENGINE incur the
overheads from only *that* ENGINE once it has been loaded.
if OpenSSL itself is built as a shared library. The instructions are
the same in each case, but in the former (statically linked any
dependencies on OpenSSL) you must ensure OpenSSL is built with
- position-independant code ("PIC"). The default OpenSSL compilation may
+ position-independent code ("PIC"). The default OpenSSL compilation may
already specify the relevant flags to do this, but you should consult
with your compiler documentation if you are in any doubt.
PROBLEMS
========
- It seems like the ENGINE part doesn't work too well with Cryptoswift on Win32.
+ It seems like the ENGINE part doesn't work too well with CryptoSwift on Win32.
A quick test done right before the release showed that trying "openssl speed
-engine cswift" generated errors. If the DSO gets enabled, an attempt is made
to write at memory address 0x00000002.