Hi, As far as I know, OpenSSL 1.0 is not meant to be binary compatible with OpenSSL 0.9.8x, at least for low-level APIs like the AES one you are referring to. So, as you suggest it, an application should know if it is using a 0.9.8 libeay32 or an 1.0 one, and depending on that it will use the correct prototype.
Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 7/28/2010 3:02 PM, John Skodon via RT wrote: > Hi guys: > > I'm probably wrong here, but it looks like you've changed some function > prototypes, e.g., aes.h, in version 1.0.0a to "size_t" from "unsigned long" > in 0.9.8o. > > E.g., > 0.9.8o, AES.H: > void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out, > size_t length, const AES_KEY *key, > unsigned char ivec[AES_BLOCK_SIZE], > unsigned char ecount_buf[AES_BLOCK_SIZE], > unsigned int *num); > > 1.0.0a, AES.H: > void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out, > const unsigned long length, const AES_KEY *key, > unsigned char ivec[AES_BLOCK_SIZE], > unsigned char ecount_buf[AES_BLOCK_SIZE], > unsigned int *num); > > The eccentric LLP64 model of Microsoft Windows AMD64 and Itanium has "long" > and "unsigned long" as 32-bits, and "size_t" as 64-bits. So, it would seem > that code that called AES_ctr128_encrypt() compiled under 0.9.8o would push > 32-bits less onto the stack on AMD/Itanium than code using the 1.0.0a headers. > > Just about every other popular compiler model I can think of, primarily W32, > Unix 32, and Unix 64 LP64 would not experience a problem. > > If I'm correct, code calling these functions on AMD/x64 would need maybe two > different function pointers defined for AES_ctr128_encrypt(), and on the fly > switching between the two, depending on the version retrieved from > LIBEAY32.DLL. > > Am I missing something here? > > Thanks in advance for your help, > JGS > > > > Hi guys: > I'm probably wrong here, but it looks like you've changed some function > prototypes, e.g., aes.h, in version 1.0.0a to "size_t" from "unsigned long" in > 0.9.8o. > E.g., > 0.9.8o, AES.H: > void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out, > * size_t length*, const AES_KEY *key, > unsigned char ivec[AES_BLOCK_SIZE], > unsigned char ecount_buf[AES_BLOCK_SIZE], > unsigned int *num); > 1.0.0a, AES.H: > void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out, > * const unsigned long length*, const AES_KEY *key, > unsigned char ivec[AES_BLOCK_SIZE], > unsigned char ecount_buf[AES_BLOCK_SIZE], > unsigned int *num); > The eccentric LLP64 model of Microsoft Windows AMD64 and Itanium has "long" > and > "unsigned long" as 32-bits, and "size_t" as 64-bits. So, it would seem that > code > that called AES_ctr128_encrypt() compiled under 0.9.8o would push 32-bits less > onto the stack on AMD/Itanium than code using the 1.0.0a headers. > Just about every other popular compiler model I can think of, primarily W32, > Unix 32, and Unix 64 LP64 would not experience a problem. > If I'm correct, code calling these functions on AMD/x64 would need maybe two > different function pointers defined for AES_ctr128_encrypt(), and on the fly > switching between the two, depending on the version retrieved from > LIBEAY32.DLL. > Am I missing something here? > Thanks in advance for your help, > JGS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
