Well, I am not just a software engineer I am much more a kind of embedded
engineer.
In fact we are not doing just software security products like KeyTool SSL,
Unicert..., we are doing secure hardware too. Our tamper resistant devices
have got the certification FIPS level 4 and ITSEC 3 is on its
From: Corinne Dive-Reclus [EMAIL PROTECTED]
CDive If I need to follow some specific procedure to add a new type
CDive of ENGINE hook to OpenSSL, let me know I will do it with
CDive pleasure.
Procedure to follow is:
- if you'd like to see support for your hardware in OpenSSL, please
-Original Message-
From: Richard Levitte - VMS Whacker [mailto:[EMAIL PROTECTED]]
Sent: 08 February 2001 10:10
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: ENGINE_load_key
From: Corinne Dive-Reclus [EMAIL PROTECTED]
CDive If I need to follow
Corinne Dive-Reclus wrote:
CDive Anyway, any help about key generation (no ENGINE hook
CDive available? cannot dynamically create a key into an ENGINE ?)
CDive and key management will be greatly appreciated.
So far, we've extended the collection of engine hooks when there's
On Wed, Feb 07, 2001 at 07:15:25PM +0100, [EMAIL PROTECTED] wrote:
+ *) Update Rijndael code to version 3.0 and change EVP AES ciphers to
+ handle the new API. Currently only ECB, CBC modes supported. Add new
+ AES OIDs. Add TLS AES ciphersuites as described in the "AES
Richard Levitte - VMS Whacker wrote:
CDive Even if the hardware is capable of symmetric operations, it is
CDive probably to slow to go down to it to perform the operation.
Depends. If it takes load away from the central CPU, it might be a
good thing from that point of view, by increasing
Many thanks, I have got it now ( I can be slow sometimes )
Cheers
Corinne
Corinne Dive-Reclus, Principal Software Engineer
Baltimore Technologies, Focus 31, West Wing,Cleveland Road, Hemel Hempstead,
Hertfordshire, HP2 7BW, England
Tel: +44 (0) 1442 342600 Fax: +44 (0) 1442 347399
E-mail
From: Dr S N Henson [EMAIL PROTECTED]
drh Then PEM_*_PrivateKey() should be able to handle it largely
drh transparently and applications should be able to use the keys
drh even if they aren't ENGINE aware.
Uhmmm, applications that use ENGINE will have to be ENGINE aware
enough to "load" the
Richard Levitte - VMS Whacker wrote:
From: "Florian Oelmaier" [EMAIL PROTECTED]
Subject: RE: cvs commit: openssl/ssl s3_lib.c ssl.h ssl_algs.c ssl_ciph.cssl_locl.h
tls1.h
Date: Thu, 8 Feb 2001 16:43:31 +0100
Message-ID: [EMAIL PROTECTED]
flo I did some test with the OCSP-client code of
Hi there,
On Thu, 8 Feb 2001, Michael [iso-8859-1] Ströder wrote:
Richard Levitte - VMS Whacker wrote:
CDive Even if the hardware is capable of symmetric operations, it is
CDive probably to slow to go down to it to perform the operation.
Depends. If it takes load away from the
Hi there,
On Thu, 8 Feb 2001, Dr S N Henson wrote:
Personally I'd like to see symmetric support at some point. I like the
idea of being able to increase security by not keeping secret keys in
memory but only references to them. Unfortunately that's a bit tricky
with OpenSSLs current EVP
At first, I do not think that RFC2560 is that bad. In fact I think its one
of the most readable RFC Ive ever seen.
Now, tell me, if you look
intelligently at it, how do you bind the request and the response to
avoid replay attacks without requiring the exact same nonce to be
returned? I ask
I haven't looked at the openssl OCSP code recently... well, okay I just
took a look. The comment for OCSP_check_nonce says it is wrong for a
server to send a nonce if a client doesn't send one. That's wrong: a
server is always free to send a nonce, that's the only way it can
guarantee its
From: "Florian Oelmaier" [EMAIL PROTECTED]
flo 2) Given an OCSP-Responder, that does not append its own certificate (in the
flo delegated case): I could not give an OCSP-Certificate to trust using the
flo command line that helped me verify the response. You should be aware that
flo there are use
Rich Salz wrote:
I haven't looked at the openssl OCSP code recently... well, okay I just
took a look. The comment for OCSP_check_nonce says it is wrong for a
server to send a nonce if a client doesn't send one. That's wrong: a
server is always free to send a nonce, that's the only way it
From: "Florian Oelmaier" [EMAIL PROTECTED]
flo Let me try hard to think intelligent: We have a PKI. All people
flo share the same time (i.e. using NTP). Our CA generates
flo OCSP-responses for its 10 Sub-CAs every 2 minutes with a
flo "nextUpdate" interval of 2 minutes. As OCSP-Responses for
Is it? I must admit that I regard RFC2560 as ambiguous in this and many
other regards and I have to imply some "interpretation" on what should
be done.
Yeah, it's surprising / disappointing how imprecise it is.
As Florian pointed out, 4.1.2 and 4.4 say either side can do anything
since none
From: [EMAIL PROTECTED]
steve Urgh.. this conflicted with the -VAfile patch I hope I haven't
steve broken it.
From reading the code, it doesn't look like you did.
--
Richard Levitte \ Spannvgen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
Richard Levitte - VMS Whacker wrote:
From: [EMAIL PROTECTED]
steve Urgh.. this conflicted with the -VAfile patch I hope I haven't
steve broken it.
From reading the code, it doesn't look like you did.
Ah good. As you gathered I'd just done a dirty great patch to add load
of
Richard Levitte - VMS Whacker wrote:
Those are *your* conditions. You might as well get responses that
have "nextUpdate" intervals of an hour!
Actually one public responder I've tried (which shall remain nameless)
throws out a thisUpdate field for one certificate 6months old and no
Bodo Moeller wrote:
Ulf Moeller [EMAIL PROTECTED] in epsilon.openssl.dev:
It is more convenient to have the range; also the previous
prototype was misleading because max was larger than
the actual maximum.)
OK, so it would make sense to rename the variable in the prototype.
"Florian Oelmaier" [EMAIL PROTECTED] writes:
We do the same, as we directly connect to the CA-database, but we set
thisUpdate to the actual time as this seems to make more sense. It would be
fine to have an option within OpenSSL that says: "Trust only responses with a
thisUpdate not more than x
Geoff Thorpe wrote:
Hi there,
On Thu, 8 Feb 2001, Dr S N Henson wrote:
Personally I'd like to see symmetric support at some point. I like the
idea of being able to increase security by not keeping secret keys in
memory but only references to them. Unfortunately that's a bit tricky
I realise this is an old thread but it has some interesting implications
wrt server security policies and the MS SGC bug...
Lutz Jaenicke wrote:
- An OpenSSL server (and probably most other servers) will strictly follow the
clients preference and choose the first cipher in the
I don't know of rsautl, but for RSA encryption in general the data being
encrypted must be shorter than the key length (modulus length). For PKCS1
padding, the data length must be at least 11 bytes shorted than the key
length. It's of course possible to encrypt consecutive blocks until all
data
What about a combined version of BN_rand_range (see below)? Then
dsa_ossl.c needs just this:
/* Get random k */
if (!BN_rand_range(k, BN_value_one(), dsa-q, NULL)) goto err;
/* random number r: minimum + offset = r range + offset
* If 'minimum' is used, it should be small!
From: Dr S N Henson [EMAIL PROTECTED]
drh That got bitten by some responders which set thisUpdate and
drh nextUpdate to exactly the same time.
I'm not gonna look if that is allowed by the RFC. The paranoid would
probably reject such a response, since it's basically invalidating
itself
27 matches
Mail list logo
