Hi,
will be in OpenSSL created engine (I mean ENGINE) that will communicate with
HW using PKCS11?
I think, this is way how to create universal engine.
Martin
__
OpenSSL Project
From: "Martin Szotkowski" [EMAIL PROTECTED]
martin.szotkowski will be in OpenSSL created engine (I mean ENGINE)
martin.szotkowski that will communicate with HW using PKCS11?
There's been some talking about doing that, but hasn't been started
yet.
--
Richard Levitte \ Spannvägen 38, II \
On Tue, Oct 31, 2000 at 02:58:48PM +, Ben Laurie wrote:
Bodo Moeller wrote:
Talking about "real servers" -- I think Apache 1.3.14 still uses
blocking sockets in its select-accept-loop, which doesn't work
reliably on BSD.
What do you mean "doesn't work reliably"? Works for me!
Isn't
Geoff Thorpe wrote:
On Tue, 31 Oct 2000, Ben Laurie wrote:
Yes, your answer is satisfactory.
If I understand then I can't use openssl.exe main application for
testing my new engine
(of course after compilation of openssl with new engine features).
Exactly, and this is wrong
Geoff Thorpe wrote:
On Tue, 31 Oct 2000, Ben Laurie wrote:
BTW: Right now, all the existing engine implementations typically work
immediately without any "setup" beyond what they work out for themselves
before, during, or after initialisation.
Indeed, but its possible to imagine
Dr S N Henson wrote:
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
Would carve the way to store the engine configuration in stone...
By
Goetz
--
Goetz Babin-Ebell, TC TrustCenter
Attached is the patches for OpenSSL 0.9.6 to enable the AES
winner:Rijndael. Also attached is the files that is not included in the
patch and is new.
Nine files:
1. rijndael.diff - The diff file to use with "patch -p3 -u"
2. cmd - The command executed to create the diff file.
3. exclude - The
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
or you can encode the parameters into string and pass this string around.
file-based configuration is not always the best.
every engine
Hi:
I have been having spurious problems with one of my client server
programs. It uses a DH Key exchange to generate a blowfish key and
encrypts the data using that key. I believe I have isolated the problem
to the minimum of code. I'm attaching the test program, Makefile, and a
bash script
Dr S N Henson wrote:
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
The reason I suggested a handle instead of a filename was so that the
data could come from elsewhere.
Cheers,
Ben.
On Wed, Nov 01, 2000, Lawrence MacIntyre wrote:
When you run the program 1000 times, somewhere between 3 and 9
times the length of the public key will be 55 bytes instead of 56, as it
should be. This breaks my client:-( Once, the key was actually 54
bytes.
You really should fix the
Ben Laurie wrote:
Dr S N Henson wrote:
The idea behind this is that a simple engine aware application could
then just call ENGINE_load_config("filename.cnf") and forget about any
other details.
The reason I suggested a handle instead of a filename was so that the
data could come from
Regarding the problem of binary incompatibility between versions of
shared libraries, I think the big problem is probably the way the
shared library is named. Since the internal names (set with -soname)
normally are 'libcrypto.so.0' and 'libssl.so.0', I imagine it looks
like the same version of
13 matches
Mail list logo
