I've included two patches which fix issues introduced in OpenSSL 0.9.6e/f/g
(I found them when upgrading from d to g).
The first patch is a single character change that resolves ticket#260. The
bug is that in EVP_txt2obj() the content length rather than the length of
the tag+length+content is
I've traced this down to ASN1_get_object. It fails at line 128 which had
previously been ifdef'd out:
if (*plength (omax - (p - *pp)))
{
ASN1err(ASN1_F_ASN1_GET_OBJECT,ASN1_R_TOO_LONG);
/* Set this so that even if things are not long
previously been indef'd out had
been disabled due to this bug, ie. the symptom fixed rather than the
cause.
Steven
-Original Message-
From: Reddie, Steven
Sent: Friday, 30 August 2002 11:09 AM
To: [EMAIL PROTECTED]
Subject: RE: [openssl.org #260] OBJ_txt2nid not working after upgrading
to 0.9.6g
I'm not clear on the problem here (I'm asking on behalf of someone). They
claim that keys created with OpenSSL are not useable with BSAFE. They are
also calling them BER keys. My understanding is that DER, being a subset of
BER, is used for encoding all keys. Therefore a DER file is a BER
Zoran, I'd be happy to test your implementation. The PKCS#11 devices that I
have at my disposal are:
Eracom CSA7001/7002
nCipher nFast SCSI HSM
GemPlus PC410 smartcard reader
Litronic Netsignia 210 smartcard reader
and I think there may be a Rainbow HSM and
-
From: Erwann ABALEA [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 6:58 PM
To: [EMAIL PROTECTED]
Subject: RE: PKCS#11 engine support
On Thu, 3 May 2001, Reddie, Steven wrote:
Zoran, I'd be happy to test your implementation. The PKCS#11 devices
that I
have at my disposal
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
You're code looks correct.
To be accurate, there is no "public modulus". The modulus is the same for
both the public and private key, and is therefore simply referred to as the
modulus.
I assume that you've also set:
template[0].type = CKA_MODULUS;
template[1].type =
The problem with only locking during the assignment is that potentially
mutliple threads will be doing [extensive] work that will be thrown away
when they discover that another thread beat them to it. The result could be
that the lock is held for less time, but all threads do more work and
PROTECTED]]
Sent: Wednesday, December 20, 2000 7:38 AM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit: openssl/crypto/rsa rsa_eay.c
Hi,
On Wed, 20 Dec 2000, Reddie, Steven wrote:
The problem with only locking during the assignment is that potentially
mutliple threads will be doing
: Re: My patch to rsa_eay.c didn't seem to get accepted
On Thu, 14 Dec 2000, Richard Levitte - VMS Whacker wrote:
From: "Reddie, Steven" [EMAIL PROTECTED]
Steven.Reddie I've come across four race conditions in the following
Steven.Reddie functions in rsa_eay.c:
Ste
Hi core team,
On 4th October I submitted a patch to crypto/rsa/rsa_eay.c to fix some
multithreaded race conditions. Nobody replied to my message at the time,
and I've just noticed that the latest snapshot doesn't include these fixes.
Did this just get overlooked, or was it purposely rejected?
Sounds a little confusing. If there's no easy way to tell at decryption
time which blocks use which padding type then you've got a problem. If you
don't mind potentially having an extra block, perhaps you should use
PKCS1_PADDING for all blocks (ie. encrypt the first "key size - 11 bytes",
then
-
From: Ben Laurie [SMTP:[EMAIL PROTECTED]]
Sent: Friday, October 27, 2000 5:12 PM
To: [EMAIL PROTECTED]
Subject: Re: openssl on windows CE environment?
"Reddie, Steven" wrote:
I've been doing this outside of work. I'll post some patches soon
(within
the next wee
I've been doing this outside of work. I'll post some patches soon (within
the next week if I get the time). The biggest problem with Windows CE is
that there's no C runtime library, and it doesn't support the full Win32
API.
Steven
(Note: contact me on this list or my external email address,
Not all values that fit into a 128-byte buffer can be encrypted/decrypted.
RSA doesn't treat the message merely as a buffer, but rather as a big
number. The integer value of the message must be less than the integer
value of the modulus. This is why PKCS#1 padding uses leading values of
0x00,
I've determined the exact cause of my trouble. It is a result of using
OpenSSL in conjunction with the pthreads-win32 library, and implementing
id_callback as a call to pthread_self, and may be a gotcha for other Win32
developers.
The pthreads-win32 library implements pthread_self, and other
[Firstly, I'm working with 0.9.5a, but the relevant 0.9.6 source seems to be
unchanged.]
This may be a bigger problem than just my specific case, but here is what
I've found:
We are using BIO_do_handshake() to accept socket connections, which results
in a call to BIO_accept(). Calling
I've come across four race conditions in the following functions in
rsa_eay.c:
RSA_public_encrypt
RSA_public_decrypt
RSA_eay_mod_exp (x2)
These can cause unexpected failure of the RSA_eay_ encryption/decryption
functions for both public and private key operations. The
I create my own RSA_METHOD structure which contains pointers to my RSA
public/private encrypt/decrypt functions. It also contains a flags member
which is where I set RSA_METHOD_FLAG_NO_CHECK. I have the private key
stored on the Hardware Security Module (HSM) and the certificate is
available to
Greg, I'm not sure about the state of PKCS#11 support in relation to the
latest snapshot, however I can give you some answers in relation to the
latest release, OpenSSL 0.9.4.
Firstly, I work for a US company and I am unsure about the current state of
the export restrictions, and therefore
21 matches
Mail list logo
