On Tue, Nov 27, 2001 at 01:06:49PM +0100, Richard Levitte - VMS Whacker wrote:
I've looked at util/mk1mf.pl and wondered for a long time why it does
it's own configuration stuff (from all the util/pl/*.pl files) instead
of relying on data created by Configure. When one looks in Configure,
On Fri, Nov 30, 2001 at 10:36:23PM -0500, Matt Cooper wrote:
The 0.9.6b distribution contains the following in Objects.h: (~line 455)
#define SN_ld_ce ld-ce
#define NID_ld_ce 81
#define OBJ_ld_ce 2L,5L,29L
If you recreate the
Doug Moore [EMAIL PROTECTED]:
Failure during big number tests. Make report output is attached...
[...]
test BN_sqr
Square test failed!
Please repeat the test using the current 0.9.6 snapshot available
at URL: ftp://ftp.openssl.org/snapshot;type=d. A bug in BN_sqr()
was recently fixed.
OpenSSL version 0.9.6c released
===
OpenSSL - The Open Source toolkit for SSL/TLS
http://www.openssl.org/
The OpenSSL project team is pleased to announce the release of version
0.9.6c of our open source toolkit for SSL/TLS. This new OpenSSL version
is mostly a
On Fri, Dec 21, 2001 at 01:15:46PM -0800, d p chang wrote:
There appears to be a bug in s3_read_bytes when trying to make a
connection to a port open for a non-tls service. As the comment
indicates, tls client just ignores records that it doesn't know about,
but the current code does not try
On Mon, Dec 10, 2001 at 11:23:53AM +0100, Daniel Pettersson wrote:
I have seen the same problem, the server just hangs forever when connecting with
Netscape 6.[1|2].
On Sat, 1 Dec 2001, Tim Regovich wrote:
New subscriber. I checked the archives,m didnt find
anything appropriate.,
run
Tim Regovich [EMAIL PROTECTED]:
Interesting. I see what you mean wrt Netscape.
So I tried two things :
1) wrapped the SSL_accept call with a sigaction/alarm
scheme. it ends up timing out, and continuing, and
everything is fine (provied of course that I assume
the timeout means that
On Thu, Jan 10, 2002 at 08:18:34PM +, Joe Orton wrote:
Have we changed CRYPTO_NUM_LOCKS between patch levels? I can't recall
that we have. If we have, that's unfortunate.
Yes, afraid so, these changed between b and c... the only other
Hmm. Thinking of it, I'm not sure if that should
[EMAIL PROTECTED]:
I've attached a test program that spits them out to you.
a=0;
b=0;
do {
do {
idea_mul1(r1,a,b,ul);
r2=idea_mul3(a,b);
if(r1!=r2)
fprintf(stderr, ?? r1!=r2 (a=0x%04x,b=0x%04x) (r1=0x%04x,r2=0x%04x)}
\n,a,b,r1,r2);
} while(++a !=
Anyway. That has not been the initial question. Is there anything
wrong with the three different implementations of the mul procedure ?
I think that's more important. Since (as you might have seen) mul1 and mul2
do generate different results due to the fact that the idae_mul1 macro
Verdon Walker [EMAIL PROTECTED] in epsilon.openssl.bugs:
We ran into a small piece of code in ssl_rsa.c that is confusing us. In
SSL_CTX_use_certificate_chain_file(), the following code fragment
exists:
ret=SSL_CTX_use_certificate(ctx,x);
if (ERR_peek_error() != 0)
ret = 0; /*
Sebastian Kloska [EMAIL PROTECTED]:
Please provide example inputs where the results differ. A single a, b
pair is enough.
The program iterates through all a's and and b's from 0-0x
That should be sufficient
Given that you already ran the program and don't have to fight with
the
On Wed, Feb 06, 2002 at 04:40:10PM +0100, Richard Levitte - VMS Whacker wrote:
This looks like an incompatible change (not just a bugfix), so it
definitely should be documented in CHANGES. (Or, if compatibility is
important here, the change should not be done at all.)
I'm a little unsure
Wei Dai [EMAIL PROTECTED]:
[Posted to sci.crypt and the IETF SSH working group mailing list.]
Phil Rogaway observed that CBC mode is not secure against chosen-
plaintext attack if the IV is known or can be predicted by the attacker
before he choses his plaintext [1]. Similarly, CBC mode
Dax Kelson [EMAIL PROTECTED]:
I'm having a problem where two RHL7.2 LDAP clients out of many don't
authenticate against an OpenLDAP server. They are using starttls to
connect to the server. The chain is sshd - pam_ldap - openldap -
OpenSSL.
In openldap-2.0.21/libraries/libldap/tls.c
On Wed, Feb 13, 2002 at 03:57:59PM +0200, Hugo Krawczyk wrote:
[...]
Thus, future revisions of TLS should also take this into account.
That is, either transmit a fresh (unpredictable) IV with each msg,
or implcitly compute this IV in an *unpredictable* way, for example by
applying a prf to
On Mar 25, 2010, at 6:33 PM, Jean-Marc Desperrier wrote:
OpenSSL wrote:
Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m
How comes the vulnerability doesn't touch 0.9.8e though the patched
file wasn't modified between 0.9.8e and 0.9.8f ?
But that code was modified between
On Mar 30, 2010, at 3:04 PM, Adam Langley wrote:
On Tue, Mar 30, 2010 at 7:35 AM, Thomas Jarosch
thomas.jaro...@intra2net.com wrote:
28141:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad packet
length:s3_clnt.c:878:
openssl is compiled with the no-tlsext option. no-tlsext was
added
On Sep 6, 2010, at 10:39 AM, Darryl Miles wrote:
The only user of these field(s) is libssl.so itself. The exact
meaning, usage and interpretation of the field(s) is a matter of
implementation detail which is encapsulated and presented to the
application via the document OpenSSL APIs.
p4qKI7363uBnLgLGQIgS8BBar0n8QARYv4t6c7O+HR3Kn7VCix8cErUm5MkoL79n
C2YJVRKPmpuwoPkLGwC6beB1fBiwvUaJd/n+BSU5LO534QcSzF+u4UKczsGnPX72
HSA/Mzf8C6w=
=Rpu4
-END PGP SIGNATURE-
--
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org
.
Neel Mehta (Google) identified the vulnerability. Adam Langley and
Bodo Moeller (Google) prepared the fix.
Which applications are affected
- ---
Applications are only affected if they act as a server and call
SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX
.
Neel Mehta (Google) identified the vulnerability. Adam Langley and
Bodo Moeller (Google) prepared the fix.
Which applications are affected
- ---
Applications are only affected if they act as a server and call
SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX
p4qKI7363uBnLgLGQIgS8BBar0n8QARYv4t6c7O+HR3Kn7VCix8cErUm5MkoL79n
C2YJVRKPmpuwoPkLGwC6beB1fBiwvUaJd/n+BSU5LO534QcSzF+u4UKczsGnPX72
HSA/Mzf8C6w=
=Rpu4
-END PGP SIGNATURE-
--
Bodo Moellerb...@openssl.org
OpenSSL Project http://www.openssl.org
On Tue, Feb 8, 2011 at 7:48 PM, Corinna Vinschen vinsc...@redhat.comwrote:
OpenSSL version 1.0.0d released
I'm missing an official release mail for 0.9.8r. Will you create one?
I wasn't planning to -- http://www.openssl.org/news/secadv_20110208.txt also
announces 0.9.8r for those using the
Thanks, Rob; I have updated the Security Advisory at
http://www.openssl.org/news/secadv_20110208.txt.
Bodo
On Wed, Oct 19, 2011 at 4:48 PM, Kenneth Robinette
supp...@securenetterm.com wrote:
The openssl-1.0.1-stable-20111019 build fails as follows:
fips_premain.c
link /nologo /subsystem:console /opt:ref /debug /dll /map /base:0xFB0
/out:o
ut32dll\libeay32.dll /def:ms/LIBEAY32.def
It appears there is no way to specify that only a subset should be used?
Yes, this is a know deficiency in the current code. I'm more familiar with
the server side, but I think it's similar: if you set up *one* curve, then
negotiation should happen accordingly; if you use a callback to provide
On Thu, Mar 1, 2012 at 11:16 AM, Erik Tkal et...@juniper.net wrote:
I looked around and found RFC 5430 - Suite B Profile for Transport Layer
Security (TLS), which states:
RFC 4492 defines a variety of elliptic curves. For cipher suites
defined in this specification, only secp256r1(23)
On Thu, Mar 1, 2012 at 4:06 PM, Erik Tkal et...@juniper.net wrote:
You mentioned previously that you can get it to specify none or one curve?
I don’t see how you would specify this, as it appears the client hello
preparation adds all of them is any EC cipher suite is specified?
Oh, sorry, you
On Thu, Mar 1, 2012 at 11:28 PM, Erik Tkal et...@me.com wrote:
So then the question is will this be addressed in 1.0.1 or later?
Probably a bit later.
Bodo
On Sat, Mar 17, 2012 at 3:53 PM, Stephen Henson via RT r...@openssl.orgwrote:
My reading of RFC4492 is that the ECC ciphersuites apply only to TLS
1.0 or later. According to it: This document describes additions to TLS
to support ECC, applicable both to TLS Version 1.0 [2] and to TLS
We've managed on a few occasions now to reproduce an issue where OpenSSL
deadlocks while trying to acquire a mutex it already has. I filed
http://rt.openssl.org/Ticket/**Display.html?id=2866http://rt.openssl.org/Ticket/Display.html?id=2866
about this issue. I
currently have a server where
On Wed, Sep 5, 2012 at 3:06 PM, Bodo Moeller bmoel...@acm.org wrote:
We've managed on a few occasions now to reproduce an issue where OpenSSL
deadlocks while trying to acquire a mutex it already has. I filed
http://rt.openssl.org/Ticket/**Display.html?id=2866http://rt.openssl.org/Ticket
Doh. I see it doesn't write to it. Nevertheless, seems like a bad
piece of code - its assuming errno is thread local, right?
This code uses the address of errno as a default thread ID for OpenSSL
purposes. This works precisely because you typically have something like
#define errno
On Tue, Feb 5, 2013 at 9:20 AM, Ted Krovetz t...@krovetz.net wrote:
At last month's Workshop on Real-World Cryptography at Stanford
University, Phil Rogaway released a new license for OCB, granting free use
for all open-source implementations.
On Tue, Feb 5, 2013 at 1:41 PM, Ted Krovetz t...@krovetz.net wrote:
There are actually two licenses. The second allows all software (even
closed), but only for non-military use.
http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm
Thanks. Is some explanation of the non-military use
On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie b...@links.org wrote:
It is therefore suggested that I pull this patch:
https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
The behavior change applies only if new option
SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of
Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared
libraries are updated to include the patch existing applications wont set
it:
they'd all need to be recompiled.
That's a valid point.
This is true, unfortunately.
Possibly alternative is to reuse one of the
Most other libraries I've seen handle this by saving the pid in a static
variable, and then comparing the current pid to it. This has the advantage
of not needing pthreads, and also of only adding the entropy to the child
if it is actually needed (i. e. it doesn't exec after fork).
We may
On Thu, Aug 22, 2013 at 4:50 AM, Bodo Moeller bmoel...@acm.org wrote:
Most other libraries I've seen handle this by saving the pid in a static
variable, and then comparing the current pid to it. This has the advantage
of not needing pthreads, and also of only adding the entropy to the child
(So we probably should use the current time in addition to the PID to
get a
general solution to the PID wrap-around problem even on systems where
actual independent reseeding isn't possible.)
The FIPS PRNG uses a combination of PID, a counter and a form of system
timer
for the DT vector
Geoffrey Thorpe ge...@geoffthorpe.com:
First, you're right, pthreads_locking_callback() is collapsing everything
to a mutex.
I was well aware of this and thought we did this for compatibility reasons
(because I couldn't think of any other reasonable explanation, I guess).
If actual read-write
Geoffrey Thorpe ge...@geoffthorpe.com:
So I'm going to propose that we initially put this patch into the
development head only, and defer a decision on whether to cherry-pick it
into stable branches until that testing is in place.
Sure, sounds right. (Will you go ahead and handle the patch?)
Thor, can you quantify what you mean by much more expensive? (And
qualify it - what platform, what operations?)
The way we use the locks, in heavily multi-threaded applications, you can
have a lot of contention with mutexes that wouldn't exist with read/write
locks, because often all threads
Does openssl handle a clientHello (or any handshake message) that splits
across records?
Mostly yes (I know because I made the changes to allow this a long time
ago). A notable exception is that the cross-version code in s23_srvr.c
requires that the first fragment contain at least 6 bytes of
balaji marisetti balajimarise...@gmail.com:
In the EC_METHOD structure, the pointers to methods for converting
between affine and projective coordinates are named:
`point_set_Jprojective_coordinates_GFp` and
`point_get_Jprojective_coordinates_GFp`
Does that mean any implementation of
Thulasi Goriparthi thulasi.goripar...@gmail.com:
Wouldn't it have been simpler to name these function pointers just
projective instead of Jprojective?
This way, EC methods that use different projective system than jacobian
could have their own implementation to set/get projective co-ordinates
Here's a patch for the OpenSSL 1.0.1 branch that adds support for
TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack
(CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf).
Note well that this is not about a bug in OpenSSL -- it's a protocol issue.
If SSL 3.0 is disabled in
mancha manc...@zoho.com:
Any reason for the s_client -fallback_scsv option check to be within an
#ifndef OPENSSL_NO_DTLS1 block?
Thanks for catching this. No, there's no good reason for that; I should
move it elsewhere.
Bodo
This is not quite the same discussion as in the TLS Working Group, but I
certainly think that the claim that new SCSV does not help with [the SSL
3.0 protocol issue related to CBC padding] at all is wrong, and that my
statement that TLS_FALLBACK_SCSV can be used to counter CVE-2014-3566 is
right.
mancha manc...@zoho.com:
Bodo Moeller wrote:
I certainly think that the claim that new SCSV does not help with
[the SSL 3.0 protocol issue related to CBC padding] at all is wrong,
and that my statement that TLS_FALLBACK_SCSV can be used to counter
CVE-2014-3566 is right.
The point
Jeffrey Walton noloa...@gmail.com:
Is there a way to compile without the patch? I think I would rather
'config no=ssl3' and omit the additional complexity. Its additional
protocol complexity and heartbleed is still fresh in my mind.
There's no way to compile without the patch, other than
The fix will be in the next version.
Note that OpenSSL servers aren't expected to see TLS_FALLBACK_SCSV in
normal operation (the code is sufficiently version tolerant, etc.), and if
you've enabled TLS 1.2, there isn't even a higher protocol version that the
client could be falling back from, so
2. When will RT2574 be integrated to protect our ECC keys in the
inevitable presence of software defects like this?
http://rt.openssl.org/Ticket/Display.html?id=2574user=guestpass=guest
Reportedly, Cryptography Research (i.e., Rambus) alleges to have broad
patents on techniques like this
[[EMAIL PROTECTED] - Fri Jun 7 14:22:15 2002]:
even though Netscape still works, this should be considered a bug
since
IE is now broken when in the past it worked fine
It is a bug in IE, not in OpenSSL. Note that the problem is avoided
when using RC4 ciphersuites, and these are typically
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
[...]
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like this:
d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length);
ie., without a const on
If you run 's_client' with the '-debug' option, you will see that
this server (ebmx.extra.daimlerchrysler.com:443) sends a cleartext
string starting with 'HTTP/' when it is supposed to send SSL 3.0
encrypted data. This is where the 'wrong version number' error
message comes from -- 0x54 0x54
The CBC vulnerability countermeasure that cannot be handled by some
broken SSL/TLS implementations can now be disabled with the new
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option, which is also part of
SSL_OP_ALL and thus will be automatically enabled in many OpenSSL
applications designed to be
Status was (automatically?) changed from resolved to open by
additional correspondance. The actual status is resolved.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Not a bug in OpenSSL, should have been sent to openssl-users
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Not an OpenSSL bug, this should be discussed elsewhere (openssl-users).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List
Avery Pennarun [EMAIL PROTECTED]:
On Thu, Jun 13, 2002 at 01:26:42PM +0200, Bodo Moeller via RT wrote:
[[EMAIL PROTECTED] - Thu Jun 6 18:39:34 2002]:
It appears the openssl guys goofed in 0.97beta. The prototype for the
d2i_RSAPrivateKey function in 0.9.6c, which I use, is like
I have totally removed that '#ifdef' condition, now we include
string.h on all systems (which is what we do in most other header
files anyway, so this cannot break anything unless it is broken
elsewhere too).
__
OpenSSL Project
While the AES cipher suites from draft-ietf-tls-ciphersuite-06.txt are
disabled by default and not part of ALL (the AESdraft group alias
can be used to enable them), they might be accidentily enabled by using
cipher suite strings such as RSA. The reason for disabling them
unless explicitly
RFC3268 makes the AES cipher suites official, so the AESdraft problem
no longer exists.
However, it would still be a good idea to create a NONE cipher suite
group alias because it is useful in the other scenarios given in the
problem description.
Martin Sjögren:
When you write a zero-length string with SSL_write, OpenSSL signals a
protocol-violating EOF even though no such thing has happened. My
guess is that a zero returned is misinterpreted somewhere though I have
not had time to dig through the source.
SSL_write() with length 0
Lutz Jaenicke:
I have already worked in the cipher selection routines yesterday with
respect to PR#130. I will add an appropriate NOTDEFAULT selection
keyword that will cover cipher suites not selected by default.
As this is a new feature I intend to only add it to 0.9.7 (and later).
Often, the cert/key directory is not used at all; otherwise it should be
easy to use symbolic links to get the desired effect. Thus it should be
possible to do without the '--certdir' patch.
A reason for *not* introducing '--certdir' is that the
'--prefix'/'--openssldir' situation is already a
In similar configurations with gcc version 2.95.2, I observe none of
these problems. This suggests that the problems may be due to compiler
bugs in your gcc version; please try gcc 2.95.2 or a different newer
release and report if the problems persist.
This is not a report on an actual problem in OpenSSL, and there has been
no updated to the original request since June 25th; so nothing to do for
us about this at the moment.
__
OpenSSL Project
apps/ca.c has now been changed as suggested; thanks for the patch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
On Fri, Jul 19, 2002 at 10:39:21AM +0200, Martin Sjögren via RT wrote:
Note that it's perfectly valid to call write(2) with an empty string [...]
This is true only for regular files. According to the The Single UNIX
Specification, Version 2, and related write() manual pages on systems
such
On Tue, Jul 30, 2002 at 06:08:46PM +0300, Arne Ansper wrote:
attached is a patch for openssl-0.9.6e that removes the usage of die.
please review it carefully. all changes are localized but the action i
take in some places where error reporting is not possible might be little
bit wrong (i.e.
Patch applied.
Please send unified or context diffs in the future.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List
This problem is fixed in 0.9.6f. (You might prefer to wait for 0.9.6g,
which will be out very soon.)
__
OpenSSL Project http://www.openssl.org
Development Mailing List
On Tue, Aug 13, 2002 at 12:28:06PM +0200, via RT wrote:
Line 14 in util/pod2mantest should read:
try_without_dir=true
otherwise 'first iteration' in the for-loop is never executed.
The code as it currently is doesn't make too much sense
(try_without_dir could be totally abolished), but
We now call pod2man directly if this works (without explicit invocation
of perl).
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Ticket 207 is resolved, too (if pod2mantest finds a working pod2man,
this is now called directly without explicitly invoking perl).
__
OpenSSL Project http://www.openssl.org
Development Mailing
[EMAIL PROTECTED]:
Failure!
[...]
Failed! bc: stack empty
Can you condense the bc test file into a single-line test so that we can
automatically test if bc has this bug?
__
OpenSSL Project
[levitte - Thu Aug 15 16:04:15 2002]:
[guest - Thu Aug 15 14:21:45 2002]:
Since isalist displays the available native instruction sets ordered
in the sense of best performance, I guess the best choice for target
would be the leftmost in the list displayed. Under no circumstances
should the
FIPS PUB 180-2, which defines SHA-256, SHA-384 and SHA-512 in addition
to SHA-1, has been published on August 1:
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
These new hash algorithms should be added to the 0.9.8-dev branch.
Can you elaborate what you think is buggy?
'make test' still succeeds if you substitute 10 for
SSL3_RT_MAX_PLAIN_LENGTH in ssl3_write_bytes (ssl/s3_pkt.c),
which sort of simulates very long certificate chains.
There is a limit to certificate chains (SSL_MAX_CERT_LIST_DEFAULT by
Please obtain OpenSSL 0.9.6g. OpenSSL 0.9.6d was the last version
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager
Thanks, the bug has been fixed now in 0.9.6-stable, 0.9.7-stable and
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List
This SSLeay/OpenSSL behaviour appears to be correct; from RFC 2246:
session_id_length
This field must have a value of either zero or 16. If zero, the
client is creating a new session. If 16, the session_id field
All (most?) similar cases clear the 'init' flag *after* having set up
the data structures appropriately, e.g. see ssl/s3_meth.c.
No locking should be needed because the assignments are idempotent.
__
OpenSSL Project
Sorry, the RFC 2246 quote was incorrect -- the value 16 is for
SSL 2.0 session IDs only, and the SSLeay/OpenSSL interpretation
indeed is buggy.
__
OpenSSL Project http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
On Thu, Sep 19, 2002 at 06:28:16PM -0700, Patrick McCormick wrote:
No locking should be needed because the assignments are idempotent.
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char
On Fri, Sep 20, 2002 at 06:19:48PM -0700, Patrick McCormick wrote:
Here's one step by step scenario.
You are absolutely right about the bug. I somehow had not realized
that the memcpy accesses the same struct as the following assignments.
We need a lock to fix this.
--
Bodo Möller [EMAIL
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
On Tue, Sep 24, 2002 at 03:47:14PM -0700, Patrick McCormick wrote:
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
[...]init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So,
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
On Wed, Sep 25, 2002 at 09:22:20PM +0200, Patrick McCormick via RT wrote:
I was looking at some other code in the ssl directory, and the *_method
functions in the *_meth.c files appear to use the same initialization idiom
I believe they need to be thread-protected also.
Fixed.
--
Bodo
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
Thanks for the report. Actually by coincidence I noticed this typo
(which has been in OpenSSL for quite a while) a couple of days ago and
corrected it.
__
OpenSSL Project http://www.openssl.org
On Fri, Jan 31, 2003 at 08:12:41AM +0100, Cameron Gregory via RT wrote:
for num 15 .. always get the same result.. and it's larger than
expected...
Reason: The internal OpenSSL function 'probable_prime' (in
crypto/bn/bn_prime.c) uses a built-in list of small primes for sieving
out candidate
On Wed, Dec 04, 2002 at 10:16:37AM -0500, Jack Lloyd wrote:
I asked Eric Rescorla, and he agreed the section of the TLS RFC was
definitely unclear, but he wasn't totally sure which way it should go as
far as stripping any leading 0s before using the shared secret to generate
keys. It
In OpenSSL, the 'info_callback' gets a 'const SSL *' argument;
the application in question used 'SSL *', which caused the compiler
warning for 0.9.7 (earlier OpenSSL versions did not declare the
'info_callback' argument list at all).
The problem has been solved by changing the application
Note that SSL_get_error() is not meant to be used on SSL_shutdown()
return values (although it would be good to have some API that behaves
similarly to SSL_read, SSL_write, SSL_do_handshake etc. in this respect).
If SSL_shutdown() always returns 0 when called multiple times, this is
probably
501 - 600 of 636 matches
Mail list logo
