In message <[EMAIL PROTECTED]> on Thu, 31 Oct 2002 22:45:26
+0100 (MET), "[EMAIL PROTECTED] via RT" <[EMAIL PROTECTED]> said:
rt> I would like to use your Open SSL 0.9.6 for web project for security
rt> purpose..
rt> These are the Steps we did.
rt>
rt> 1) Downloaded the files( openssl-engine-0.9
The AES library (0.9.7-dev, 0.9.8-dev) abuses assert() to check
for invalid function parameters.
For aes_cbc.c, this includes the case where 'length' is not
a multiple of AES_BLOCK_SIZE. For consistency with other ciphers,
the library should not require 'length' to be a multiple
of the block siz
[[EMAIL PROTECTED] - Wed Aug 21 09:34:00 2002]:
> Is this the correct list to post bug reports to?
Yes.
> There is a bug in cryptlib.c when using app locks. It is in both
> 0.9.6c and 0.9.7 beta 3. In
> 0.9.7 beta3 CRYPTO_NUM_LOCKS is 31. When requesting an app lock
this
> code gets called:
On Fri, 1 Nov 2002, [iso-8859-1] Frédéric Giudicelli wrote:
> Well Microsoft support tells me it's openssl's fault, and you tell me it's
> microsoft's ?
> It's dead end, what am I supposed to tell my clients ?
Well. Since Microsoft's history if full of bugs, security problems, and
non-comformity
On Sat, 2 Nov 2002, Vadim Fedukovich wrote:
> On Fri, Nov 01, 2002 at 12:51:24AM +0100, Frédéric Giudicelli via RT wrote:
> >
> > Well Microsoft support tells me it's openssl's fault, and you tell me it's
> > microsoft's ?
> > It's dead end, what am I supposed to tell my clients ?
>
> Well, Micros
On Thu, 31 Oct 2002, Frédéric Giudicelli via RT wrote:
> ROOT CA's authorityKeyIdentifier extension gives its own DN as issuer (normal)
> INTERMEDIATE CA's authorityKeyIdentifier extension gives ROOT CA's DN as issuer
>(normal)
> A certificate signed by INTERMEDIATE CA, gives ROOT CA's DN as issu
I'm compiling SSL for Arm linux. I'm using the uclibc wrapper around
arm-linux-gcc so that gcc is arm-uclibc-gcc. There are appropriate
symlinks for all tools with all of them prefixed by arm-uclibc-. My
machine is an i686 running Slackware 8.1 To compile I do:
./Configure linux-elf-arm shared
m
Hi,
It seems that DH_compute_key is slightly incompatable with PKCS #3, if the
derived secret z is too small. In particular, section 8.3 of PKCS #3
"Integer-to-octet-string conversion", specifies that that output of the
operation should be exactly k bytes long (where k is the number of bytes in
t