Lines Matching +full:hardware +full:- +full:based
5 ----------------
9 primitives, most notably for integrating hardware crypto devices.
12 by the [PROVIDER API](README-PROVIDERS.md), it is deprecated in OpenSSL
15 Support for new hardware devices or new algorithms should be added
19 Built-in ENGINE implementations
20 -------------------------------
22 There are currently built-in ENGINE implementations for the following
25 - Microsoft CryptoAPI
26 - VIA Padlock
27 - nCipher CHIL
40 --------------------------
48 ---------------------
54 based input to those ENGINEs, in the form of name-value pairs. This is an
56 that are specific to a given ENGINE (eg. for a particular hardware
57 device) but that should be consistent across *all* OpenSSL-based
64 with the various compiled-in ENGINEs (see further down for dynamic
67 openssl engine -vvvv
70 -------------
73 self-documenting, but some summaries and usage instructions are needed -
78 STABILITY & BUG-REPORTS
86 devices from common OpenSSL-based applications. Bugs and/or inexplicable
89 file), and in the case of implementations for commercial hardware
97 - openssl-users: if you are *using* the ENGINE abstraction, either in an
98 pre-compiled application or in your own application code.
100 - openssl-dev: if you are discussing problems with OpenSSL source code.
108 switch called "-engine". Also, if you want to use the ENGINE support in
112 Depending on the type of hardware, system, and configuration, "settings"
117 can allow the user/admin (and thus the hardware vendor's support desk
128 instructions are available by specifying the "-?" command line switch.
133 The new "dynamic" ENGINE provides a low-overhead way to support ENGINE
134 implementations that aren't pre-compiled and linked into OpenSSL-based
135 applications. This could be because existing compiled-in implementations
139 wish to use, and the ENGINE provider (eg. hardware vendor) is providing
140 you with a self-contained implementation in the form of a shared-library.
141 The other use-case for "dynamic" is with applications that wish to
142 maintain the smallest foot-print possible and so do not link in various
144 them, if you want them, in the form of "dynamic"-loadable
145 shared-libraries. It should be possible for hardware vendors to provide
146 their own shared-libraries to support arbitrary hardware to work with
147 applications based on OpenSSL 0.9.7 or later. If you're using an
148 application based on 0.9.7 (or later) and the support you desire is only
153 ------------------------
157 gets its own copy of it. As such, multi-threaded code (or code that
166 implementation from a shared-library. To see these control commands,
167 use the command-line;
169 openssl engine -vvvv dynamic
172 shared-library that contains the ENGINE implementation, and "NO_VCHECK"
175 "ID" is probably only needed if a shared-library implements
180 ENGINE's "id". For most applications, this isn't necessary - but some
184 the shared-library ENGINE implementation. If this command succeeds, the
186 that has been loaded from the shared-library. As such, any control
188 normal. For instance, if ENGINE "foo" is implemented in the shared-library
204 -pre SO_PATH:/lib/libfoo.so \
205 -pre ID:foo \
206 -pre LOAD \
207 -pre "CMD_FOO:some input data"
211 openssl engine -vvvv dynamic \
212 -pre SO_PATH:/lib/libfoo.so \
213 -pre ID:foo \
214 -pre LOAD
220 control the *actual* ENGINE used. Each command is actually a name-value
225 key-value pair may be used by some applications). The reason for the
226 "-pre" syntax in the "openssl engine" utility is that some commands
228 Eg. if an ENGINE implementation requires a smart-card to be inserted
230 a control command you can issue afterwards to "forget" the smart-card
232 applications such as web-servers, where potentially volatile code may
235 it has been initialised for use, and so the "-post" switch would be
238 ("-pre" is almost always what you're after, in reality).
241 ----------------------------------
243 This question is trickier - currently OpenSSL bundles various ENGINE
248 would have to use "dynamic" to load any such ENGINE - but on the other
252 "dynamic" for hardware support is that any installation using no
258 a shared-library that can be loaded by "dynamic" isn't automated in
260 Such a shared-library can either be built with any OpenSSL code it
265 position-independent code ("PIC"). The default OpenSSL compilation may
270 crypto/engine/ directory as a shared-library for use via the "dynamic"
273 1. "cd" to the crypto/engine/ directory of a pre-compiled OpenSSL
286 - add "-DENGINE_DYNAMIC_SUPPORT" to the command line switches,
287 - change the output file from "hw_atalla.o" to something new,
290 4. Link "tmp_atalla.o" into a shared-library using the top-level
293 known well to anyone who has worked with shared-library portability
296 gcc -shared -o dyn_atalla.so tmp_atalla.o -L../.. -lcrypto
299 previous section. Eg. from the top-level directory, you might try
301 apps/openssl engine -vvvv dynamic \
302 -pre SO_PATH:./crypto/engine/dyn_atalla.so -pre LOAD
304 If the shared-library loads successfully, you will see both "-pre"
306 displayed (because of "-vvvv") will be the control commands for the
308 the "-t" switch to the utility if you want it to try and initialise
309 the atalla ENGINE for use to test any possible hardware/driver issues.
316 -engine cswift" generated errors. If the DSO gets enabled, an attempt is made