Patch for 0.9.7-stable (mingw)
I sent the following to [EMAIL PROTECTED], but there don't seem to be any
tickets created after 20040722. I am copying this to openssl-dev in
case rt isn't working properly.
It has been about 11 months since I last compiled openssl for mingw. I
found several problems when compiling 0.9.7-stable which are addressed
by the attached patch. This is against the 20040725 snapshot.
1. The current version of gcc defaults to using -fstrict-aliasing
with -O2 or greater, but the code is not written for strict aliasing,
leading to several warnings. I turned off the strict-aliasing
optimization for the mingw platform. This may need to apply to other
platforms, too unless the code is changed to be compatible with strict
aliasing.
2. Make clean was not removing apps/openssl.exe, since the EXE_EXT
was not being passed to makefiles in subdirectories.
3. Make install was overwriting several man pages with links to
nothing, since mingw is case independent (although it is case aware).
Hence links such as HMAC.3 to hmac.3 wiped out the hmac.3 manpage,
leaving only the link.
I think this patch fixes the problems for mingw. When I get a chance,
I'll compile for DJGPP. I suspect it needs a fix for strict-aliasing,
also.
I am also sending a copy to the US Bureau of Industry and Security
since I am in the USA.
Doug
--
Doug Kaufman
Internet: [EMAIL PROTECTED]
--- Configure.ori 2004-06-28 15:04:20.0 -0700
+++ Configure 2004-07-25 16:48:02.0 -0700
@@ -516,7 +516,7 @@
BC-16,bcc:::(unknown):WIN16::BN_LLONG DES_PTR RC4_INDEX SIXTEEN_BIT:::,
# MinGW
-mingw, gcc:-DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -mno-cygwin
-Wall:::MINGW32:-mno-cygwin -lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}:win32.dll,
+mingw, gcc:-DL_ENDIAN -fomit-frame-pointer -fno-strict-aliasing -O3 -march=i486
-mno-cygwin -Wall:::MINGW32:-mno-cygwin -lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${x86_out_asm}:win32.dll,
# UWIN
UWIN, cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}::win32,
@@ -938,6 +938,7 @@
$exe_ext=.exe if ($target eq Cygwin);
$exe_ext=.exe if ($target eq DJGPP);
+$exe_ext=.exe if ($target eq mingw);
$exe_ext=.pm if ($target eq vos-gcc or $target eq debug-vos-gcc or $target eq
vos-vcc or $target eq debug-vos-vcc);
$openssldir=/usr/local/ssl if ($openssldir eq and $prefix eq );
$prefix=$openssldir if $prefix eq ;
--- Makefile.org.ori2004-06-28 15:04:20.0 -0700
+++ Makefile.org2004-07-26 05:51:30.0 -0700
@@ -626,7 +626,7 @@
do \
if [ -d $$i ]; then \
(cd $$i echo making clean in $$i... \
- $(MAKE) SDIRS='${SDIRS}' clean ) || exit 1; \
+ $(MAKE) SDIRS='${SDIRS}' EXE_EXT='${EXE_EXT}' clean ) || exit 1; \
rm -f $(LIBS); \
fi; \
done;
@@ -878,7 +878,7 @@
@pod2man=`cd util; ./pod2mantest $(PERL)`; \
here=`pwd`; \
filecase=; \
- if [ $(PLATFORM) = DJGPP -o $(PLATFORM) = Cygwin ]; then \
+ if [ $(PLATFORM) = DJGPP -o $(PLATFORM) = Cygwin -o $(PLATFORM) =
mingw ]; then \
filecase=-i; \
fi; \
for i in doc/apps/*.pod; do \
--- e_os2.h.ori 2004-06-28 15:04:20.0 -0700
+++ e_os2.h 2004-07-25 17:43:16.0 -0700
@@ -110,6 +110,9 @@
# undef OPENSSL_SYS_UNIX
# define OPENSSL_SYS_WINCE
# endif
+# if defined(OPENSSL_SYSNAME_MINGW32)
+# define OPENSSL_SYS_MINGW32
+# endif
# endif
#endif
--- apps/speed.c.ori2004-06-28 10:01:16.0 -0700
+++ apps/speed.c2004-07-25 22:15:48.0 -0700
@@ -1791,6 +1791,7 @@
results[alg][run_no]=((double)count)/time_used*lengths[run_no];
}
+#ifdef HAVE_FORK
static char *sstrsep(char **string, const char *delim)
{
char isdelim[256];
@@ -1822,7 +1823,6 @@
return token;
}
-#ifdef HAVE_FORK
static int do_multi(int multi)
{
int n;
--- crypto/engine/hw_aep.c.ori 2002-06-27 10:07:10.0 -0700
+++ crypto/engine/hw_aep.c 2004-07-25 16:39:10.0 -0700
@@ -60,7 +60,7 @@
#include string.h
#include openssl/e_os2.h
-#if !defined(OPENSSL_SYS_MSDOS) || defined(__DJGPP__)
+#if !defined(OPENSSL_SYS_MSDOS) || defined(__DJGPP__) || defined(OPENSSL_SYS_MINGW32)
#include sys/types.h
#include unistd.h
#else
[openssl.org #924] Patch for 0.9.7-stable (mingw)
It has been about 11 months since I last compiled openssl for mingw. I found several problems when compiling 0.9.7-stable which are addressed by the attached patch. This is against the 20040725 snapshot. 1. The current version of gcc defaults to using -fstrict-aliasing with -O2 or greater, but the code is not written for strict aliasing, leading to several warnings. I turned off the strict-aliasing optimization for the mingw platform. This may need to apply to other platforms, too unless the code is changed to be compatible with strict aliasing. 2. Make clean was not removing apps/openssl.exe, since the EXE_EXT was not being passed to makefiles in subdirectories. 3. Make install was overwriting several man pages with links to nothing, since mingw is case independent (although it is case aware). Hence links such as HMAC.3 to hmac.3 wiped out the hmac.3 manpage, leaving only the link. I think this patch fixes the problems for mingw. When I get a chance, I'll compile for DJGPP. I suspect it needs a fix for strict-aliasing, also. I am also sending a copy to the US Bureau of Industry and Security since I am in the USA. Doug P.S. For those reading this on openssl-dev, the patch can be found via the response tracker. -- Doug Kaufman Internet: [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
SSL resumed handshake
Hi list, In actual OpenSSLlibrairie, the client and the server may resume a session by verifying their cache. Did any of you do the same using a file containeattributes security session (session_id, master_secret, cipher_suite, compression_methode, ...) instead of using the cache. Thank you Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage ! Créez votre Yahoo! Mail Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. Téléchargez GRATUITEMENT ici !
Re: Any 386 users?
Hi Andy!
I hope I addressed all your wishes w.r.t. the PadLock engine. Attached
is the interdiff since the last version, on my PadLock page is the full
patch (http://www.logix.cz/michal/devel/padlock).
Most recent changes are:
- Rewritten the aligner to use only a fixed-size buffer on the stack
instead of malloc()ed space.
- Control word, IV and KEY are now in ctx-cipher_data
- Extended key is computed in place.
- Using padlock_bswapl() instead of htonl().
Do you now like it more? :-)
Michal Ludvig
--
* A mouse is a device used to point at the xterm you want to type in.
* Personal homepage - http://www.logix.cz/michal
Index: crypto/engine/eng_padlock.c
===
--- crypto/engine/eng_padlock.c.orig
+++ crypto/engine/eng_padlock.c
@@ -65,8 +65,6 @@
#include string.h
#include inttypes.h
-#include netinet/in.h/* we need htonl() */
-
#include openssl/crypto.h
#include openssl/dso.h
#include openssl/engine.h
@@ -323,14 +321,10 @@
sizeof(padlock_cipher_nids[0]));
/* Function prototypes ... */
-static int padlock_aes_init_key_128(EVP_CIPHER_CTX *ctx, const unsigned char *key,
- const unsigned char *iv, int enc);
-static int padlock_aes_init_key_192(EVP_CIPHER_CTX *ctx, const unsigned char *key,
- const unsigned char *iv, int enc);
-static int padlock_aes_init_key_256(EVP_CIPHER_CTX *ctx, const unsigned char *key,
- const unsigned char *iv, int enc);
+static int padlock_aes_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
+ const unsigned char *iv, int enc);
static int padlock_aes_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out,
- const unsigned char *in, unsigned int inl);
+ const unsigned char *in, unsigned int nbytes);
/* Some AES-related constants */
#define AES_BLOCK_SIZE 16
@@ -341,14 +335,31 @@
#define AES_KEY_WORDS (4 * (AES_MAXNR + 1))
#defineAES_KEY_BYTES (AES_KEY_WORDS * 4)
+/* Control word. */
+union cword {
+ uint32_t cword[4];
+ struct {
+ int rounds:4;
+ int algo:3;
+ int keygen:1;
+ int interm:1;
+ int encdec:1;
+ int ksize:2;
+ } b;
+};
+
/* Here we store the plain key for AES128
and the extended key for AES192/AES256 */
-struct padlock_aes_key
+struct padlock_cipher_data
{
- uint32_t aes_key[AES_KEY_WORDS];
- int extended;
+ uint8_t iv[AES_BLOCK_SIZE]; /* Initialization vector */
+ union cword cword; /* Control word */
+ AES_KEY ks; /* Encryption key */
+ uint8_t *key; /* Encryption key pointer */
};
+#define ALIGNED_CIPHER_DATA(ctx) ((struct padlock_cipher_data *)(ctx-cipher_data +
((0x10 - ((size_t)(ctx-cipher_data) 0x0F)) 0x0F)))
+
/* Declaring so many ciphers by hand would be a pain.
Instead introduce a bit of preprocessor magic :-) */
#defineDECLARE_AES_EVP(ksize,lmode,umode) \
@@ -358,10 +369,10 @@
AES_KEY_SIZE_##ksize, \
AES_BLOCK_SIZE, \
0 | EVP_CIPH_##umode##_MODE,\
- padlock_aes_init_key_##ksize, \
+ padlock_aes_init_key, \
padlock_aes_cipher, \
NULL, \
- sizeof(struct padlock_aes_key), \
+ sizeof(struct padlock_cipher_data) + 16,\
EVP_CIPHER_set_asn1_iv, \
EVP_CIPHER_get_asn1_iv, \
NULL, \
@@ -442,100 +453,72 @@
return 1;
}
-/* Generate an extended AES key in software. Needed for AES192/AES256 */
-static int
-padlock_aes_init_key (EVP_CIPHER_CTX *ctx, const unsigned char *key,
- const unsigned char *iv, int enc,
- int key_len)
+/* Our own htonl()/ntohl() */
+static inline void
+padlock_bswapl(uint32_t *arg)
{
- AES_KEY ks;
- struct padlock_aes_key *tmp_aes_key = NULL;
- int i;
-
- tmp_aes_key = (struct padlock_aes_key *) (ctx-cipher_data);
- memset(tmp_aes_key, 0, sizeof(struct padlock_aes_key));
- if (key) {
- if (enc)
- AES_set_encrypt_key(key, key_len, ks);
- else
- AES_set_decrypt_key(key, key_len, ks);
-
- /* OpenSSL internal functions use byte-swapped extended key. */
- for (i = 0; i AES_KEY_WORDS; i++)
- tmp_aes_key-aes_key[i] = htonl(ks.rd_key[i]);
-
- tmp_aes_key-extended = 1;
- }
-
- return 1;
+ asm volatile (bswapl %0 : +r(*arg));
}
-/* PadLock can generate an extended key for AES128 in hardware */
+/* Prepare the encryption key for PadLock usage
Re: Any 386 users?
I hope I addressed all your wishes w.r.t. the PadLock engine. Attached
is the interdiff since the last version, on my PadLock page is the full
patch (http://www.logix.cz/michal/devel/padlock).
Do you now like it more? :-)
I hope that you don't really think that it's matter of *liking*:-)
Problem.
... padlock_aes_cipher(... const uint8_t *in_arg,...)
{ ...
if (in_arg_aligned) {
in = (uint8_t*)in_arg;
if (out_arg_aligned)
out = out_arg;
else
out = in;
Last line is no good. in_arg is declared const and is not expected to be
modified. This is of course unfortunate, but you can't take advantage of
the fact that input buffer happens to be aligned.
Further comments.
Throw in pushfl;popfl; at the end of padlock_aes_init_key. This would be
required if we try to optimize pushfl;popfl; in padlock_aes_cipher, but
we can as well do it now.
Have you considered to rearrange switch and loop in padlock_aes_cipher?
I mean right now you have switch in loop, while you could have loop for
every case in switch. It might make difference to performance...
Can you explain what's the deal with IV? I don't quite undestand why do
you save EAX value after xscrypt and use at as a pointer. Where does it
point at exit? The way I understand the manual you simply can't rely on
value in EAX being preseved and I can't see that it's meaningful after
xcrypt...
What's padlock_cipher_data-key for? It only pollutes the cache... You
can as well padlock_cipher_data-ks.rd_key, can't you? A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Any 386 users?
Does it actually pass the tests by the way? Point is that push %ebx is not accounted to stack pointer and if m(iv) is on stack (and it is), then attempt to reference it from assembler template results on off-by-4 effective address... Provided that we compile with -fomit-frame-pointer (as we do)... What you should do is following: asm volatile ( pushl %%ebx\n leal 16(%%eax),%%edx\n leal 32(%%eax),%%ebx\n opcode popl %%ebx\n : +a(cdata),+S(input),+D(output) : c (count) : edx); We can use leal instructions, because we've collected all the bits in one aligned structure. I assume that eax doesn't have to be saved. If it has to, then I can think of a way... For those who wonder. Why we can't use b(something) in templates or mark ebx as clobbered? We can't use b(something) because compiler won't let us to and we try to compile position independent code. We can't mask ebx as clobbered, because compiler does not respect it, again when we try to compile position independent code (must be a bug, but it's there is several compiler versions). Which by the way brings us to the following: asm volatile (cpuid; movl %%ebx, (%%edi); movl %%edx, 4(%%edi); movl %%ecx, 8(%%edi) : +a(eax) : mD(vendor_string) : ebx, ecx, edx); It should also be surrounded by push %ebx and pop %ebx, because as above ebx comes out corrupted in PIC [at lest with compilers I've tested]. If it's OK with you I can fix the code to my liking and send it back... A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Any 386 users?
Andy Polyakov wrote: Does it actually pass the tests by the way? Point is that push %ebx is not accounted to stack pointer and if m(iv) is on stack (and it is), then attempt to reference it from assembler template results on off-by-4 effective address... Provided that we compile with -fomit-frame-pointer (as we do)... What you should do is following: For me it worked because I only tested without -fomit-... -O2 but with -g instead and built a static libcrypto.a... Now I recall - that's why I used movl %xxx,-4(%esp) instead of pushl %xxx in my previous patches. That's it... asm volatile (cpuid; movl %%ebx, (%%edi); movl %%edx, 4(%%edi); movl %%ecx, 8(%%edi) : +a(eax) : mD(vendor_string) : ebx, ecx, edx); It should also be surrounded by push %ebx and pop %ebx, because as above ebx comes out corrupted in PIC [at lest with compilers I've tested]. But this should be surrounded by push %ebx/pop %ebx by the compiler, shouldn't it? If it's OK with you I can fix the code to my liking and send it back... A. Indeed ;-) Thanks! Michal Ludvig __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Mail System Error - Returned Mail
Bonjour, Je suis en congés jusqu'au 9 août inclus, je lirai donc votre message à mon retour. En cas d'urgence, merci de contacter Dominique Manenc [EMAIL PROTECTED]. Vous ne recevrez ce message qu'une seule fois. Merci. Hello, I'm on vacation until august, the 9th, then I'll read your mail. If necessary, please contact Dominique Manenc [EMAIL PROTECTED]. You'll receive this message only once. Thanks. -- Erwann ABALEA [EMAIL PROTECTED] - It takes months to find a customer, but only seconds to lose one... The good news is that we should run out of them in no time. Demotivators, 2001 calendar __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Any 386 users?
Andy Polyakov wrote:
... padlock_aes_cipher(... const uint8_t *in_arg,...)
{ ...
if (in_arg_aligned) {
in = (uint8_t*)in_arg;
if (out_arg_aligned)
out = out_arg;
else
out = in;
Last line is no good. in_arg is declared const and is not expected to be
modified. This is of course unfortunate, but you can't take advantage of
the fact that input buffer happens to be aligned.
I see. Hmm. So in this case I'll run the realignment loop as well.
Throw in pushfl;popfl; at the end of padlock_aes_init_key. This would be
required if we try to optimize pushfl;popfl; in padlock_aes_cipher, but
we can as well do it now.
I wouldn't do it. Say that you first initialize two contexts with two
keys and then use them concurrently. You must force key reloading
whenever the other context is to be used, not while it is being created.
Have you considered to rearrange switch and loop in padlock_aes_cipher?
I mean right now you have switch in loop, while you could have loop for
every case in switch. It might make difference to performance...
Do you mean quadruplicating the realigner code for each case? Or take
it to a separate function? I believe that this simple switch with four
cases and inlined xcrypt functions can be very well optimized by the
compiler. I will probably only put the 'mode' to a variable in advance
to avoid dereferrencing ctx every time...
Can you explain what's the deal with IV? I don't quite undestand why do
you save EAX value after xscrypt and use at as a pointer. Where does it
point at exit? The way I understand the manual you simply can't rely on
value in EAX being preseved and I can't see that it's meaningful after
xcrypt...
As I understand it: when you have a large buffer that should be
encrypted in (say) CBC mode and you encrypt it per partes (e.g.
because of the limited-size realign buffer), you need to save the
current IV at the end of each round to can to continue with the next
piece. IIRC in all modes but ECB the IV is different after every basic
block (i.e. 16 bytes in case of AES) is encrypted. That's why it has to
be saved. (and it doesn't work without saving anyway :-)
What's padlock_cipher_data-key for? It only pollutes the cache... You
can as well padlock_cipher_data-ks.rd_key, can't you? A.
Yes I can. I hope the AES_KEY structure won't be modified, especially
that rd_key will always be the first item. Otherwise the alignment will
break.
Michal Ludvig
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Resumed session then full SSL sessions
Dear all, I am currently developping a program that will works as following: 1) I get as hypothesis that the client and the server share a pre-established SSL session) reuse the shared session to perform an abbreviated (resumed) handshake by sending the session_id to the server. 2) use the channel established in (1) to securely exchange a new SSL session. 3) update the shared session by the new one established in (2). I see that OpenSSL already allows us to use a counter and/or a timer for resumed sessions. My case will use a counter since the SSL session will serve for one time :) I would like to hear your comments and your replays about if this will be feasable using the OpenSSL. I read olds mails from the mailing list and I go out with two methods. I am sorry for this big mail but I have to achieve the program in same days :( 1) the first one was written by Arnulf Kost and available at : http://marc.theaimsgroup.com/?l=openssl-usersm=94473593624193w=2 You can however retrieve the session while it is still there. I do write them to disk, since I have to share them between independent processes, using PEM_write_SSL_SESSION(fp, session). I can later reload it from disk with session = PEM_read_SSL_SESSION(fp, NULL, NULL, NULL) and then SSL_CTX_add_session(ctx, session), SSL_set_session(con, session). And it seems to work for me 2) The second was suggested by Bodo Moeller and available at http://marc.theaimsgroup.com/?l=openssl-usersm=94476459115263w=2 You can pass the pointer obtained by SSL_get_session to i2d_SSL_SESSION to obtain a BER representation of the SSL_SESSION data structure (well, of most of it). Then you can keep it in memory, store it in a disk cache, or whatever you want. Later d2i_SSL_SESSION can be used to create an SSL_SESSION data structure from the BER representation; then you can use SSL_set_session. (SSL_set_session increments the reference count of the SSL_SESSION. Call SSL_SESSION_free when you no longer need the SSL_SESSION structure). I kindly ask your help to know if these two methode can help me in my code and to choose between one of them :) Sincerely, Badra __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Any 386 users?
asm volatile (cpuid; movl %%ebx, (%%edi); movl %%edx, 4(%%edi); movl %%ecx, 8(%%edi) : +a(eax) : mD(vendor_string) : ebx, ecx, edx); It should also be surrounded by push %ebx and pop %ebx, because as above ebx comes out corrupted in PIC [at lest with compilers I've tested]. But this should be surrounded by push %ebx/pop %ebx by the compiler, shouldn't it? Yes, it should, but it does not. And as the problem seem to be present in various versions, we better preserve %ebx... If it's OK with you I can fix the code to my liking and send it back... A. Indeed ;-) I'll post my suggestion shortly. I'm fixing even out=in thing problem... A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Any 386 users?
out = in; Last line is no good. in_arg is declared const and is not expected to be modified. This is of course unfortunate, but you can't take advantage of the fact that input buffer happens to be aligned. I see. Hmm. So in this case I'll run the realignment loop as well. Fixed below. Also note that I've chosen to loop even if output is aligned and input is not. For better cache utilization. Imagine user wanted to encrypt large chunk. If I copy unaligned input to aligned output completely, then by by time I encrypt data is *guaranteed* to be out of cache. Throw in pushfl;popfl; at the end of padlock_aes_init_key. This would be required if we try to optimize pushfl;popfl; in padlock_aes_cipher, but we can as well do it now. I wouldn't do it. Say that you first initialize two contexts with two keys and then use them concurrently. You must force key reloading whenever the other context is to be used, not while it is being created. But say that we try to optimize pushfl;popfl as suggested in attached code and user managed to reuse context. In such case you have to pushfl;popfl after context is reused... Have you considered to rearrange switch and loop in padlock_aes_cipher? I mean right now you have switch in loop, while you could have loop for every case in switch. It might make difference to performance... Do you mean quadruplicating the realigner code for each case? Yes. Switches are commonly done with indirect jumps and they are more expensive. Quadruplicating the realigner results in about 700 extra bytes or extra 25% of binary code. Can you explain what's the deal with IV? As I understand it: ... I see. New template simply returns eax... And it works correctly with push/pop %ebx. What's padlock_cipher_data-key for? It only pollutes the cache... You can as well padlock_cipher_data-ks.rd_key, can't you? A. Yes I can. I hope the AES_KEY structure won't be modified, We can ensure this by putting explicit comment in aes.h. A. /* * Support for VIA PadLock Advanced Cryptography Engine (ACE) * Written by Michal Ludvig [EMAIL PROTECTED] *http://www.logix.cz/michal * * Date: May 13, 2004 */ /* * Copyright (c) 1999-2001 The OpenSSL Project. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/) * * 4. The names OpenSSL Toolkit and OpenSSL Project must not be used to *endorse or promote products derived from this software without *prior written permission. For written permission, please contact *[EMAIL PROTECTED] * * 5. Products derived from this software may not be called OpenSSL *nor may OpenSSL appear in their names without prior written *permission of the OpenSSL Project. * * 6. Redistributions of any form whatsoever must retain the following *acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit (http://www.OpenSSL.org/) * * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * * * This product includes cryptographic software written by Eric Young * ([EMAIL PROTECTED]). This product includes software written by Tim * Hudson ([EMAIL PROTECTED]). * */ #include stdio.h #include string.h #include openssl/crypto.h #include openssl/dso.h #include openssl/engine.h #include openssl/evp.h #include openssl/aes.h #ifndef OPENSSL_NO_HW #ifndef
AES_ctr128_inc( ) on 64bit platform
Hi,
(B
(BAlthough I try to perform AES-CTR on 64bit platform(Solaris2.8),
(BIncrement of a counter does not go satisfactorily.
(B
(BIt turns out that this cause is in AES_ctr128_inc().
(Bthe following code(cvs.openssl.org version 1.2.2.3) is the part.
(BJust this cause is "unsigned long c"(line 67).
(B
(BGETU32 and PUTU32 are macro for 32 bit. Therefore only on 32 bit,
(Boverflow check of "c" operates normally(line 75).
(B
(B aes_ctr.c --
(B66 static void AES_ctr128_inc(unsigned char *counter) {
(B67$B!!(B unsigned long c;
(B68
(B69 $B!!(B /* Grab bottom dword of counter and increment */
(B70 c = GETU32(counter + 12);
(B71 c++;
(B72 PUTU32(counter + 12, c);
(B73
(B74 /* if no overflow, we're done */
(B75 if (c)
(B76return;
(B .
(B .
(B .
(B--
(B
(Bthe following data is each result of AES_ctr128_inc().
(B--
(B[32bit]
(B(in) counter:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
(B 0x00,0x00,0x00,0x00,0xFF,0xFF,0xFF,0xFF
(B
(B(out) counter:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
(B 0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x00
(B
(B
(B[64bit]
(B(in) counter:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
(B 0x00,0x00,0x00,0x00,0xFF,0xFF,0xFF,0xFF
(B
(B(out) counter:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
(B 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
(B--
(B
(B
(BThanks,
(BKan
(B
(B__
(BOpenSSL Project http://www.openssl.org
(BDevelopment Mailing List [EMAIL PROTECTED]
(BAutomated List Manager [EMAIL PROTECTED]
