Rosen Penev wrote:
One downside of this is that in the case of iterated hashes(PBKDF2) this
only speeds up the first iteration. I do not believe that TLS uses
iterated HMAC-SHA1.
And that is a good thing! Anything that speeds up or otherwise reduces
the computation effort of PBKDF2 only
John Gardiner Myers via RT wrote:
However my point of view is:
Actually there is. It is important for OpenSSL to convey back to the
application when it has successfully carried out all the following tasks:
* to encode SSL control packet (with the way OpenSSL is imlemented
this actually
John Gardiner Myers via RT wrote:
There's no good reason for SSL_shutdown() to ever return a value of 0.
The attached patch simplifies things.
One point of view is:
Maybe so. But this is how it has always worked and is documented as
such. Your patch does not attempt to update the
John Gardiner Myers via RT wrote:
There's no good reason for SSL_shutdown() to ever return a value of 0.
The attached patch simplifies things.
One point of view is:
Maybe so. But this is how it has always worked and is documented as
such. Your patch does not attempt to update the
This patch is against version openssl-1.0.0d.
Please find attached a patch that works for me. Works means it builds
without error, the test.bat executes the tests ok and even the make
install works to some degree. It has also been test built against
zlib zlib-dynamic options.
Background
Roumen Petrov wrote:
Try with ./Configure mingw .
Roumen
Thanks for the suggestion.
But from what I can understand ms\mingw32.bat calls:
perl Configure mingw ... [ with the arguments I give mingw32.bat ]
I have tried using perl Configure mingw ... manually but I have not
been able
Roumen Petrov wrote:
May be issue is to find working version of mingw make.
Another case is the shell . At least some make commands require unix
like shell either bash from msys or bash from cygwin.
Well I also did set MAKE=mingw32-make and the perl Configure mingw
... does do the correct
I am not able to get OpenSSL to build with MinGW (from mingw.org) and
Perl (from ActiveState) installed. Both tools are available in %PATH%
and I'd like the build to run from cmd.exe (no CYGWIN bash prompt, see
below for more info). I have been working with OpenSSL 1.0.0d.
Tried using:
Jeff Saremi wrote:
That's right. Not only the actual implementation but more the API do not
support 64bit values being passed around.
jeff
That's right. Not only the actual implementation but more the API do not
support 64bit values being passed around, even on systems where the
native
Stephen Henson via RT wrote:
SSL structures should only ever be initialised by calling SSL_new().
Allocating and initialising an SSL structure manually in an application
is itself a very non-portable thing to do and requires setting of many
undocumented internal fields which will change across
Robin Seggelmann via RT wrote:
The latest patch was modified to maintain the previous values of new_session
for legacy applications. We can either break compatibility of a few
applications, if any, by adding a new field or by adding new values. I don't
see any possibility to avoid this at
Bodo Moeller wrote:
Ideally this would be true, but in practice various applications do
access some fields directly.
The big change to stop that would be to move all the struct details
completely out of the externally visible header files. Of course, that
change too would be rather painful for
Robin Seggelmann via RT wrote:
Note that since we need to retain binary compatibility between 1.0.0 and
1.0.1 we will need to either avoid having to add a new field to ssl.h or
move it to the end of the structure.
As things are any application accessing a field after the new member
would
Robin Seggelmann via RT wrote:
Note that since we need to retain binary compatibility between 1.0.0 and
1.0.1 we will need to either avoid having to add a new field to ssl.h or
move it to the end of the structure.
As things are any application accessing a field after the new member
would
While it is possible to make a Valgrind clean (as in memory leaks)
executable, that loads OpenSSL DSO/DLLs exactly once during the
executable lifetime.
I'm not sure it has ever been a feasible goal to make OpenSSL DSO/DLLs
able to be unloaded (with the aim of subsequently loading). Let
David Schwartz wrote:
Actually, that wouldn't work. What if you're using a threading library that
permits threads to run in different SMP domains? In that case, the atomic
instructions would only synchronize between threads running in the same SMP
domain.
As I hinted in another post, the less
Rene Hollan wrote:
And how, pray tell, should OpenSSL know the threading model the
application uses?
Unless I'm missing something, it strikes me as perfectly reasonable for
OpenSSL to require a reasonable threading API to implement SSL data
integrity, and for the application to provide an
Mark Phalan wrote:
Except setting up locking at library setup time is inherently racy and
*cannot* be done safely. The *only* safe place to setup locking
callbacks is from the application. libraries cannot safely setup the
locking callbacks.
Just to make it clear why this is a problem imagine
David Schwartz wrote:
Joakim Tjernlund wrote:
I once wrote this patch to solve a problem which I logged to be:
Let EAGAIN be fatal for write to socket. Needed
to unlock a hung connection where the www client has
stopped reading its socket.
Umm, if your code asks to wait forever until
Joakim Tjernlund wrote:
Sure, but this is the BIO interface and I am at loss on how to do this
with BIO. It seems like I am stuck somewhere inside BIO and it keeps
retrying.
From my understanding, your patches are against the default BIO
implementations for sockets not against the BIO
Joakim Tjernlund wrote:
You did not confirm if you had the sockets in non-blocking mode or not
(at the time you observed the condition for which the patch improved).
As far as I can tell it is in non blocking mode. Can one have
EAGAIN otherwise?
Well that is a question to ask, if your
David Schwartz wrote:
Mark Phalan wrote:
In this case, I presume 'pkinit' only supports one threading model
(or one
set of compatible threading models). So it can set the callbacks.
It can set the callbacks but it can't set them in a way which is safe
from races.
It can set them before it
Howard Chu wrote:
Darryl Miles wrote:
Still don't get it. Lets use Linux as an example.
This is actually one of the easiest to solve. Of course the bigger
problem is that solutions here are all platform-dependent, and
maintenance will be a pain.
ELF shared libraries support .init
Howard Chu wrote:
ELF shared libraries support .init and .fini sections to contain code
that should be executed just after load and just before unload. Assuming
you had a default set of callbacks in the library, it would be simple to
set them here. Likewise any other shared library that
Mark Phalan wrote:
On 29 Mar 2010, at 20:20, David Schwartz dav...@webmaster.com wrote:
Will existing libraries continue to
not set the locking callbacks and fail horribly if the system OpenSSL
isn't
compiled with this flag?
Or will they set sane locking callbacks to be safe
-- making this
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set
Replies below v
Thor Lancelot Simon wrote:
The pattern is like this:
1) I have data to write, and the SSL session's descriptor
selects as ready-to-write.
2) I call SSL_renegotiate. I do understand that in a server
application this merely sends the
I hope I am using the RT correctly in this manner.
At this time I am seeking approval / consensus / agreement in principal
on this patch inclusion. Once that is reached then I'd like to work on
related matters about this issue like updating man pages / API
documentation, having a new FAQ
With the announcement of OpenSSL 1.0.0 on the way, may I attempt to get
some attention on this issue for which:
* a patch exists
* a test case exists (that exposes the problem, that verifies the fix
doesn't break anything)
* multiple users have shared their concern over the years (some
nicolas sitbon wrote:
Sorry but Tim Hudson said me the answer previously, so now I know
what's the problem.
Can you make available the smallest test case please, the re-creates the
problem.
Darryl
__
OpenSSL Project
nicolas sitbon wrote:
Hi, I'm currently developping an application using libcrypto, I find
some memory leak with valgrind (please don't say me to compile with
-DPURIFY, I know that and in fact, my problem is not uninitialized data,
but rather memory leak) :
==26823== 1,552 (168 direct, 1,384
Thor Lancelot Simon wrote:
I have an application which reads data into fixed-size buffers which it
maintains per session. It uses non-blocking IO and select() when a read
returns SSL_ERROR_WANT_{READ,WRITE}.
To conserve memory I reduced the buffer size from 16384 to 8192 and saw
sessions
Lutz Jaenicke wrote:
Thor Lancelot Simon wrote:
On Fri, Aug 01, 2008 at 03:49:01PM +0200, Lutz Jaenicke wrote:
This leads to another problem, actually:
A malicious peer which sends data as fast as it can can get _more_ data
into the socket buffer while the application is trying to read to
Thor Lancelot Simon wrote:
Darryl (who wrote the patch) has a set of regression tests for nonblocking
operation with OpenSSL. He posted about it here way back in 2006 when he
originally pointed out this problem. It's kind of hard to figure out which
message in some of these old, old mailing
Paul Sheer wrote:
Well my hybrid threaded app now seems to be stable - even under extreme
loads.
2. Use my own RAND object (RAND_set_rand_method) so that
OpenSSL does
not try lock static globals.
How are you sure of this ? Did you manually remove the object code
://marc.info/?l=openssl-devm=116525974320575w=2 (single email in
this thread)
Darryl
Thor Lancelot Simon wrote:
On Mon, Oct 01, 2007 at 08:06:04PM +0100, Darryl Miles wrote:
Would Davide be so kind as to look over the following openssl-dev list
post for the semantics I suggest and confirm
David Schwartz wrote:
This is insane. Imagine if SSL_want_read and SSL_want_write both returned
false. Then you wouldn't ever notice that the socket had been closed, you
could wait for new inbound data forever, and your proxy would stall.
But end-of-stream is an error condition, so you should
Nanno Langstraat wrote:
That's the very reason Darryl Miles asked me to change the thread title,
if you'll remember.
LOL, but you also have to remove your References: header, but still too
late now. This is still in the same thread, to start a new thread post
a new email (do not use
Nanno Langstraat wrote:
* Remote side completely closes its socket.
This causes read()=0 and write()=-1/EPIPE on the local side.
* Our TCP proxy gets read()==0 on the TCP socket.
* In response, our proxy does shutdown(WR) on the local drain file
descriptor (the other side of
David Schwartz wrote:
Nanno Langstraat wrote:
* Our TCP proxy gets read()==0 on the TCP socket.
* In response, our proxy does shutdown(WR) on the local drain file
descriptor (the other side of the proxy).
This propagates the read()==0 event to the local endpoint
process
Nanno Langstraat wrote:
It turns out that the problem does *not* directly involve
SSL_shutdown(), but it *is* attributable to OpenSSL, and specifically
OpenSSL's non-blocking shutdown semantics.
Okat thats cleared that up, it is indeed unrelated to the OP of this
thread. Please move replies
Nanno Langstraat wrote:
David Schwartz wrote:
The socket is not and never again will be readable. It's passed on. It's
bereft of life. It's not pinin' for the fjords. Etc.
And more importantly, OpenSSL is the only party who knows this
underlying cause, and SSL_want_read() is the designated
Nanno Langstraat wrote:
Can we agree on the convention that as long as no OpenSSL call has
returned -1, there is no error condition in effect, at least as far as
the application knows?
Nope. A return value of 0 from SSL_read() is also a special case. The
same is true of the kernel call
Nanno Langstraat wrote:
So I can add one more voice to the choir: the current SSL_shutdown() API
appears to give trouble to every non-blocking developer (I remember I
lost serious time noticing + tracking down this 100% CPU bug), and
afterwards things still don't really work right.
I can't
Darryl Miles wrote:
2) SSL_read() already has a return value -1/ZERO_RETURN which indicates
end-of-stream. You may then call SSL_shutdown() to look to see if 1 is
returned or not. Or even SSL_get_shutdown() and take whatever security
action your application needs to take in the event
What is the difference between this an my patch from a year or so ago ?
http://marc.info/?t=11509972822r=1w=2 '[PATCH] Fix for
SSL_shutdown() with non-blocking not returning -1'
http://marc.info/?t=11515400401r=1w=2 '[PATCH2] Fix for
SSL_shutdown() with non-blocking not returning
Davide Libenzi wrote:
On Sat, 29 Sep 2007, Richard Salz wrote:
I seriously doubt ppl are using SSL_shutdown() with non-blocking BIOs,
together with the current API semantics. Seriously.
Are you new here? This library has been around for more than a decade.
There are *lots* of people using
Richard Salz wrote:
double/triple check over it). Whatever fix you guys come up with, as
long
as SSL_shutdown() ends up having sane (somehow aligned to SSL_read,
SSL_write, etc...) semantics WRT non-blocking BIOs.
Nope. Maybe a new shutdown that has your semantics, but do not break
Davide Libenzi wrote:
Can this be worked around? Sure. With some woodoo/ugly magic code in the
async status code handling. You *cannot* always wait for readwrite, since
you'll be exiting the event selection loop immediately, every time.
You need to bolt-in the shutdown logic *outside* the
David Schwartz wrote:
If I'm misunderstanding the man page and/or the source code
please speak up.
My man page says:
If the underlying BIO is non-blocking, SSL_shutdown() will also
return
when the underlying BIO could not satisfy the needs of SSL_shutdown()
to continue
Andy Polyakov wrote:
DES_LONG *can* be 8 bytes, it's just that it can't be 8 if you want to
deploy des_enc-sparc.S module. As mentioned adding DES_INT in stable
branch is inappropriate as it may break installations which are opted
for 64-bit ABI, but started compiling the toolkit with no-asm.
Andy Polyakov wrote:
The problem was the setting for linux64-sparcv9 within Configure.
Minimum change needed to fix problem:
SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
BF_PTR:::des_enc-sparc.o fcrypt_b.o
i.e. the addition of DES_INT is enough to fix the problem.
The
Andy Polyakov via RT wrote:
On my old Debian box during OpenSSL 0.9.7 build, make fails:
make[2]: Entering directory `/usr/local/openssl/crypto/rand'
gcc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHA VE_DLFCN_H -DOPENSSL_NO_KRB5 -m64 -DL_ENDIAN -DTERMIO -O3
David Schwartz wrote:
What return value makes sense with your model? If it says it sent
everything, you will not call into SSL again unless you have something to
write or expect to read something. If neither is the case, when will OpenSSL
get the chance to send those C bytes left over?
If the
David Schwartz wrote:
Honestly I think a better job of mimicking TCP's semantics is preferable.
OpenSSL should be able to handle its own send buffer flushing and receive
buffer filling, in the background without me having to ask it, just like TCP
does.
This can easily be done with OpenSSL
Mark Pietras wrote:
you’ll have the general population of application writers up and running
with much less support/headache. The 10% (or whatever) that are worried about
a memcpy or two (yes I’m oversimplifying) can use the advanced methods.
But it requires threads and OpenSSL does not
David Schwartz wrote:
if ((s-s3-wpend_tot (int)len)
|| ((s-s3-wpend_buf != buf)
!(s-mode SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER))
|| (s-s3-wpend_type != type))
{
The problem was the setting for linux64-sparcv9 within Configure.
Currently in 0.9.8e:
SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR:::des_enc-sparc.o fcrypt_b.o
Minimum change needed to fix problem:
SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
Is this a known issue for Linux Sparc when building for 64bit ? 0.9.8e
fails, 0.9.8 fails, 0.9.7m pass (with minor s/-march/-mcpu/ fix) ?
It seems all version of 0.9.8 series fail the same way ( tried 0.9.8e
and 0.9.8). The build itself appears to complete successfully.
When building for
Nanno Langstraat wrote:
The intended use of the patch is to call SHA1_Load_State() directly, not
SHA1_Init() followed by SHA1_Load_State().
In other words:
* The application starts by freely choosing either SHA1_Init() or
SHA1_Load_State()
* The application ends by freely choosing
Nanno Langstraat wrote:
I think you may have misread my quoted text. It specifically says that
the application can choose the beginning operation freely and choose the
ending operation freely.
I.e. that the application can mix freely.
Point understood. The man page just needs to be clear
This seems like a good time to air my thoughts. OpenSSL used to have
digest algorithms which the state could be saved (with a simple memcpy),
but then introduced 'engine' based generic methods.
I really would like to see OpenSSL support BOTH usage. That is have a
generic API which can
Nitin M wrote:
Darryl, What is your opinion on this finding? As you were also keen on
knowing the result of this experimentation. :)
What is you opinion?
Here is the valgrind output for the above program for your reference.
==10877== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17
Kyle Hamilton wrote:
On 3/28/07, Darryl Miles [EMAIL PROTECTED] wrote:
The problem occurs after the beginning of the function. If the
compare is
done on a cached copy in a register. Look at this example:
if (variable!=NULL)
{
free(variable);
variable=NULL;
}
This could easily
Richard Salz wrote:
This is the precise optimization that 'volatile' inhibits. 'volatile'
requires that the value not be cached in cheap-to-access locations
like registers, instead being re-loaded from expensive-to-access
locations like the original memory -- because it may be changed from
Kyle Hamilton wrote:
Oh. I'm sorry. Someone needs to use a keyword 'volatile'.
Bingo. Problem solved on the improper optimization issue.
Actually 'volatile' doesn't provide a useful fix.
Ignoring the fact there is no problem with any CPU that currently
exists. The volatile is most
David Schwartz wrote:
1287 void SSL_free_comp_methods(void)
1288 {
1289 if (ssl_comp_methods == NULL)
1290 return;
1291 CRYPTO_w_lock(CRYPTO_LOCK_SSL);
1292 if (ssl_comp_methods != NULL)
1293 {
1294
Nitin M wrote:
I wrote a simple program like this to find out the possibility of a
memory leak. The program goes like this.
#includeopenssl/ssl.h
int main()
{
SSL_library_init();
EVP_cleanup();
}
when I run this programm through the valgrind I get the following output.
Ok, it is not
Nitin M wrote:
Does this mean that in such scenario the application need not call
SSL_library_init since it does not need those extra initialisations and
can achieve only the required initialisations with specific calls?
If this is true I have two more questions here,
1. In what scenario
David Schwartz wrote:
The function SSL_library_init() is observed to be introudcing
memory leak in
the application code. There is still some amount of memory leak left even
after the series of cleanup calls suggested in the openssl FAQ.
Can someone help understand that technically what is the
Robin Redeker wrote:
On Sat, Mar 17, 2007 at 09:36:45PM -0700, David Schwartz wrote:
I would be even more trustfull if someone of the openssl developers
would say a word about this. Something like:
'Yes yes, the man pages are a bit obsolete, you can pass different buffers
to SSL_read for
David Schwartz wrote:
This is all irritating legacy cruft. Any sane non-blocking OpenSSL user
should set SSL_MODE_ENABLE_PARTIAL_WRITE and
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER.
If I could reassert the status of these flags as potentially meaningless
anyway in the current source code.
My
Peter Waltenberg wrote:
Valgrind runs on unmodified binaries - and it's not always possible to
get someone else to recompile their code so that you can find problems.
OpenSSL is used in commercial products where source isn't always
available.
This does not mean the valgrind ready version
Richard Salz wrote:
Can't someone just create a valgrind suppression entry for this?
Valgrind can read a file that tells it things to ignore, like lint's old
NOTREACHED comment.
Valgrind reports at the point of use where it considers the usage
potentially harmful.
This means you can copy
Erik de Castro Lopo wrote:
Brad House wrote:
I assume you didn't forget to compile OpenSSL with
-DPURIFY before testing it with Valgrind, right? That
typically resolves most issues with Valgrind and false
positives. (Purify is a commercial valgrind competitor).
I am aware of the -DPURIFY
Martin Simmons wrote:
On Thu, 01 Mar 2007 11:40:24 +0100, Peter Sylvester said:
The crtl function basically would do:
CRYPTO_add(ctx-references,1,CRYPTO_LOCK_SSL_CTX)
assuming that calling this directly in the application is not an external
interface.
I think you are kind of right, but
durgaprasad jammula wrote:
I have a question. How is OpenSSL affected by changes to Daylight Saving
Time (DST) in 2007?
When running under Linux (or any other GNU timezone/locale platform)
then no different than any other year. Just ensure you have the
correct and updated timezone file
them.
Thanks
Darryl
Darryl Miles wrote:
A while ago I submitted a patch under this subject header. What is the
procedure for having this investigated further for committing ?
Maybe I can assist one of the committers in observing the bug and
testing the patch using the same methods I did
A while ago I submitted a patch under this subject header. What is the
procedure for having this investigated further for committing ?
Maybe I can assist one of the committers in observing the bug and
testing the patch using the same methods I did.
Thanks
Darryl
And if you email to [EMAIL PROTECTED] coming from either of the two
addresses, can you ask the list robot if you are currently subscribed.
Maybe Google search for majordomo instructions but I'm pretty sure its
possible to ask it for all the lists your address is subscribed to; to
be able to
Erik de Castro Lopo wrote:
Wow, I didn't know about most of those functions.
Calling these is a vast improvement but there are still a small
leak. Here's is the one and only valgrind report after doing:
I may not have recited all of the available cleanup functions maybe
there are more.
Erik de Castro Lopo wrote:
Anybody have any idea why this is happening? Can this be fixed
somehow?
Both times I have replied to your emails my Mail User Agent (Mozilla
SeaMonkey) did not offer to put your email address into the address box,
it only but the single address (that of the
Erik de Castro Lopo wrote:
Unfortunately, it seems that openssl allocates memory inside the
call to SSL_library_init() that seems to never get deallocated.
Would you people be interested in a patch that adds an
SSL_library_release() function that releases all memory and returns
the SSL
A while ago I submitter a patch under this subject header. What is the
procedure for having this investigated further for committing ?
There were a couple of other patches but this one is the most blocking
and actually a verifiable defect of OpenSSL.
I also submitted a patch under:
Mikhail Gusarov via RT wrote:
Failing testcase is attached (pass rsa key as first argument)
FYI: Attachment not seen, can't private mail you as your email address
wasn't preserved. Are you sure you attached it?
Darryl
__
I have tested the situations out in brought up in my previous thread and
this patch seems to do the correct thing when using non-blocking BIO
layer for all situations I tried.
The correct thing as I see it is:
* Return -1 WANT_WRITE if the send notify alert has not been committed
into
Tut! Here is the ssl/sslregress/Makefile for it.
Darryl
#
#
#
#
# This is about the only thing you need to configure, the location
# to your OpenSSL build or installation.
ifeq (../../openssl.spec, $(wildcard ../../openssl.spec))
OPENSSL_BASEDIR = ../..
else
OPENSSL_BASEDIR =
Kyle Hamilton wrote:
2) I want to determine what the boundaries of each function are, and
document them appropriately (and perhaps write up patches to fix any
problems that I find). The OpenSSL documentation has been FAR too
sparse and incomplete since the project's inception (building on
Opps, need to add const in 3 places to change:
void HMAC_CTX_copy(HMAC_CTX *dest, HMAC_CTX *src);
into:
void HMAC_CTX_copy(HMAC_CTX *dest, const HMAC_CTX *src);
For hmac.c, hmac.h and hmac.pod. I can prepare a new patch if necessary.
Darryl Miles wrote:
--- openssl-0.9.8b/crypto/hmac
Please review this patch for inclusion in OpenSSL.
Following the recent thread in openssl-users here is a patch allow
poll() interface to be used instead of select() in rand_unix.c.
This patch is necessary for big-fd users of openssl, as the libc
implementation of FD_SET() may inadvertently
Ignore the last patch, this corrects the error in the sample calculation
(for non-linux platforms).
sizeof(fd_set)/8 into sizeof(fd_set)*8
Darryl Miles wrote:
+ * but that value is a tad dull on modern hardware. So
+ * I ended up trying sizeof(fd_set)*8 which should be
+ * closer
Hello,
Over the past few days I have managed to put together a regression
testing framework for OpenSSL that allows test cases to be created to
synthetically setup a specific application, OpenSSL and networking layer
interaction scenario (and validate for expected error returns, or ensure
a
Please review this patch for inclusion in openssl-0.9.8b, maybe it also
works with 0.9.7 too.
This patch maybe incomplete. As in I would like someone with more
knowledge than me to confirm that:
* s-method-ssl_dispatch_alert(s) already sets up the WANT_WRITE
situation if it returns -1
Opps I meant to add that, I need to setup WANT_WRITE condition, marked
below:
Darryl Miles wrote:
diff -u -r -N -x '*~' openssl-0.9.8b/ssl/s3_pkt.c openssl-0.9.8b-me/ssl/s3_pkt.c
--- openssl-0.9.8b/ssl/s3_pkt.c 2005-10-01 00:38:20.0 +0100
+++ openssl-0.9.8b-me/ssl/s3_pkt.c 2006
Thinking through the possibility here is another one (I dont know how to
fix), commented below. With other related issues.
diff -u -r -N -x '*~' openssl-0.9.8b/ssl/s3_lib.c openssl-0.9.8b-me/ssl/s3_lib.c
--- openssl-0.9.8b/ssl/s3_lib.c 2006-01-15 07:14:38.0 +
+++
Please review this patch in inclusion in 0.9.8. This patch adds some
new HMAC context functions, maybe the exact naming of the functions
needs some debate to fall into line with the rest of libcrypto.
In a way these patches are necessary to allow application user to do the
following
I have an application that pre-initialises a HMAC with some computed
data, then at high throughput it is copied for different requests into
a unique context and used from there.
The main reasons were to save calling HMAC_Init() and HMAC_update() with
the same data before I could start a
97 matches
Mail list logo
