Re: SHA-512 and long long - does SHA-512 depend on it?

2005-07-15 Thread Brian Hurt
On Fri, 15 Jul 2005, Andy Polyakov wrote: I don't find it hard to believe that there're 16-bit (or even 8-bit) systems out there. I find it hard to believe that the originator managed to get OpenSSL 0.9.8 working on a 16-bit system, even without SHA-512 support. A. Lots of embedded work is

Re: SHA-512 and long long - does SHA-512 depend on it?

2005-07-15 Thread Brian Hurt
On Fri, 15 Jul 2005, Jim Schneider wrote: Actually, my point about embedded systems wasn't that they'd necessarily have the full suite of OpenSSL, but that a pared-down version would be desirable. If all I want to do is triple DES with anonymous DH for key exchange on an embedded platform

Re: 0.9.8: cfb_enc.c bug? and AES speed on Win64/x64

2005-07-08 Thread Brian Hurt
On Fri, 8 Jul 2005, Andy Polyakov wrote: Do note [when] num [as in memcpy(ovec,ovec+num,8)] is guaranteed to be positive. Question was can you imagine memcpy implementation that would fail to handle overlapping regions when source address is *larger* than destination? Question was *not* if

Re: 0.9.8: cfb_enc.c bug? and AES speed on Win64/x64

2005-07-07 Thread Brian Hurt
On Thu, 7 Jul 2005, Jack Lloyd wrote: On Thu, Jul 07, 2005 at 07:42:37PM +0200, Andy Polyakov wrote: 1) In openssl-0.9.8/crypto/des/cfb_enc.c line 170 there is memcpy (ovec,ovec+num,8); and since ovec and ovec+num will overlap sometimes, this function relies on undocumented/undefined

Re: 0.9.8: cfb_enc.c bug? and AES speed on Win64/x64

2005-07-07 Thread Brian Hurt
On Thu, 7 Jul 2005, Andy Polyakov wrote: 1) In openssl-0.9.8/crypto/des/cfb_enc.c line 170 there is memcpy (ovec,ovec+num,8); and since ovec and ovec+num will overlap sometimes, this function relies on undocumented/undefined behavior of memcpy? The original reason for choosing of memcpy

Re: [openssl.org #1149] 0.9.8 size_t in md5.h breaks ruby ext/openssl

2005-07-06 Thread Brian Hurt
On Wed, 6 Jul 2005, Brian Candler via RT wrote: openssl-0.9.8/include/openssl/md5.h changed some definitions of 'unsigned long' to 'size_t', but forgot to #include sys/types.h Actually, stddef.h is what you want to include to get size_t. Brian

RE: OpenSSL use of DCLP may not be thread-safe on multiple processors

2005-04-08 Thread Brian Hurt
On Fri, 8 Apr 2005, David Schwartz wrote: No. The C standard is not telling the compiler what to do. It is saying what the system must do when it runs the particular source code. If the compiler cannot generate code that makes the system as a whole comply with the standard, then the

RE: OpenSSL use of DCLP may not be thread-safe on multiple processors

2005-04-08 Thread Brian Hurt
On Fri, 8 Apr 2005, David Schwartz wrote: Right, and the standard doesn’t require them to. Nor does it require them to perform the operations in order as seen by another processor. OK- my apologies. I was misreading what you were saying. We're on the same page. Right, and I’m