[openssl.org #1316] pkcs12 - deref before null check
this is already fixed in the cvs. Please try a recent snapshot. Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1319]
Nothing to see here...move on...move on __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1317] thers is a bug in openssl0.9.8a
wrote: I have founded a bug in openssl 0.9.8.a! when used EVP_des_ede3_cbc algorithm used EVP_DecryptInit(KCtx-ctx, KCtx-enc, KCtx-keystr, KCtx-iv); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptFinal(KCtx-ctx, (pbData[*pdwDataLen]), lastlen); *pdwDataLen += lastlen; could you send us a sample programm ? I'm not sure what you're really doing (and what should be the bug in openssl). Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1317] thers is a bug in openssl0.9.8a
wrote: I have founded a bug in openssl 0.9.8.a! when used EVP_des_ede3_cbc algorithm used EVP_DecryptInit(KCtx-ctx, KCtx-enc, KCtx-keystr, KCtx-iv); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptUpdate(KCtx-ctx, pbData, (int *)pdwDataLen, p, len); EVP_DecryptFinal(KCtx-ctx, (pbData[*pdwDataLen]), lastlen); *pdwDataLen += lastlen; could you send us a sample programm ? I'm not sure what you're really doing (and what should be the bug in openssl). Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1318] [PATCH] AES-CFB1 and DES-CFB1 mode only encrypts 1/8th of the source
Michael McDougall wrote:
diff -ur openssl-SNAP-20060415/crypto/aes/aes_cfb.c
openssl-SNAP-20060415.changed/crypto/aes/aes_cfb.c
--- openssl-SNAP-20060415/crypto/aes/aes_cfb.c2004-12-30
06:00:14.0 -0500
+++ openssl-SNAP-20060415.changed/crypto/aes/aes_cfb.c2006-04-17
22:18:11.0 -0400
@@ -191,18 +191,20 @@
}
/* N.B. This expects the input to be packed, MS bit first */
-void AES_cfb1_encrypt(const unsigned char *in, unsigned char *out,
+void
+AES_cfb1_encrypt(const unsigned char *in, unsigned char *out,
const unsigned long length, const AES_KEY *key,
unsigned char *ivec, int *num, const int enc)
{
unsigned int n;
unsigned char c[1],d[1];
+unsigned long length_in_bits = length * 8;
assert(in out key ivec num);
assert(*num == 0);
memset(out,0,(length+7)/8);
-for(n=0 ; n length ; ++n)
+for(n=0 ; n length_in_bits ; ++n)
{
c[0]=(in[n/8](1 (7-n%8))) ? 0x80 : 0;
AES_cfbr_encrypt_block(c,d,1,key,ivec,enc);
the problem here is that that EVP layer specifies the length of the
input in bytes whereas this functions expects the length in bits
(although is not clearly specified somewhere).
diff -ur openssl-SNAP-20060415/crypto/evp/e_des.c
openssl-SNAP-20060415.changed/crypto/evp/e_des.c
--- openssl-SNAP-20060415/crypto/evp/e_des.c 2004-03-28 13:00:11.0
-0500
+++ openssl-SNAP-20060415.changed/crypto/evp/e_des.c 2006-04-17
22:17:39.0 -0400
@@ -109,8 +109,9 @@
{
unsigned int n;
unsigned char c[1],d[1];
+unsigned int inl_bits = inl * 8;
-for(n=0 ; n inl ; ++n)
+for(n=0 ; n inl_bits ; ++n)
{
c[0]=(in[n/8](1 (7-n%8))) ? 0x80 : 0;
DES_cfb_encrypt(c,d,1,1,ctx-cipher_data,(DES_cblock *)ctx-iv,
agree, with this one.
Cheers,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1320] Memory handling bug in 0.9.8a AES assembler code for x86
When I run the the openssl evptest suite in purify runtime memory usage analysis tool it reports lots of memory segment errors in the AES crypto functions. If I build openssl with AES assembler code disabled (e.i AES in c-code) the same test runs without any errors from purify. The test was performed on a RedHat Enterprise Linux 3.0 x86 32-bit system Code compiled with gcc version 3.2.3 /Leif Output from purify below: rh3:~/src/openssl-0.9.8a/test:45 ./evp_test evptests.txt Purify or PureCoverage slave: Warning: Can't open display , using tty mode. Purify instrumented ./evp_test (pid 505 at Mon Apr 10 15:45:44 2006) * Purify 2003a.06.12 Linux (32-bit) (c) Copyright IBM Corp. 1992, 2004 All rights reserved. * For contact information type: purify -help * For Purify Viewer output, set the DISPLAY environment variable. * Options settings: -purify \ -purify-home=/opt/rational/releases/purify.i386_linux2.2003a.06.12 \ -gcc3_path=/usr/bin/gcc \ -cache-dir=/opt/rational/releases/purify.i386_linux2.2003a.06.12/cache * License successfully checked out. * Command-line: ./evp_test evptests.txt Testing digest SHA1 Plaintext 61 62 63 Digest a9 99 3e 36 47 06 81 6a ba 3e 25 71 78 50 c2 6c 0010 9c d0 d8 9d Testing digest MD5 Plaintext Digest d4 1d 8c d9 8f 00 b2 04 e9 80 09 98 ec f8 42 7e Testing digest MD5 Plaintext 61 Digest 0c c1 75 b9 c0 f1 b6 a8 31 c3 99 e2 69 77 26 61 Testing digest MD5 Plaintext 61 62 63 Digest 90 01 50 98 3c d2 4f b0 d6 96 3f 7d 28 e1 7f 72 Testing digest MD5 Plaintext 6d 65 73 73 61 67 65 20 64 69 67 65 73 74 Digest f9 6b 69 7d 7c b7 93 8d 52 5a 2f 31 aa f1 61 d0 Testing digest MD5 Plaintext 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 0010 71 72 73 74 75 76 77 78 79 7a Digest c3 fc d3 d7 61 92 e4 00 7d fb 49 6c ca 67 e1 3b Testing digest MD5 Plaintext 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 0010 51 52 53 54 55 56 57 58 59 5a 61 62 63 64 65 66 0020 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 0030 77 78 79 7a 30 31 32 33 34 35 36 37 38 39 Digest d1 74 ab 98 d2 77 d9 f5 a5 61 1c 2c 9f 41 9d 9f Testing digest MD5 Plaintext 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 0010 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31 32 0020 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 0030 39 30 31 32 33 34 35 36 37 38 39 30 31 32 33 34 0040 35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 Digest 57 ed f4 a2 2b e3 c9 55 ac 49 da 2e 21 07 b6 7a Testing cipher AES-128-ECB(encrypt) Key 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Plaintext 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff Ciphertext 69 c4 e0 d8 6a 7b 04 30 d8 cd b7 80 70 b4 c5 5a Purify instrumented ./evp_test (pid 505) MSE: Memory segment error: * This is occurring while in: AES_encrypt[libcrypto.a] __libc_start_main [libc.so.6] _start [crt1.o] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xbfffb6d4 for 4 bytes ending at 0xbfffb6d8, beginning in the stack which ends at 0xb000. Purify instrumented ./evp_test (pid 505) MSE: Memory segment error: * This is occurring while in: _x86_AES_encrypt [libcrypto.a] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xbfffb6cc for 4 bytes ending at 0xbfffb6d0, beginning in the stack which ends at 0xb000. Purify instrumented ./evp_test (pid 505) MSE: Memory segment error: * This is occurring while in: _x86_AES_encrypt [libcrypto.a] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xbfffb6d0 for 4 bytes ending at 0xbfffb6d4, beginning in the stack which ends at 0xb000. Purify instrumented ./evp_test (pid 505) MSE: Memory segment error: * This is occurring while in: _x86_AES_encrypt [libcrypto.a] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xbfffb6c4 for 4 bytes ending at 0xbfffb6c8, beginning in the stack which ends at 0xb000. Purify instrumented ./evp_test (pid 505) MSE: Memory segment error: * This is occurring while in: _x86_AES_encrypt [libcrypto.a] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xbfffb6c8 for 4 bytes ending at 0xbfffb6cc, beginning in the stack which ends at 0xb000. Purify instrumented ./evp_test (pid 505) MSE: Memory segment error: * This is occurring while in: _x86_AES_encrypt [libcrypto.a] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xbfffb6cc for 4 bytes ending at 0xbfffb6d0, beginning in the stack which ends at 0xb000. Purify instrumented ./evp_test (pid
Re: HP-UX Poblem
Hi, I've just tried compiling OpenSSL-0.9.8a for HPPA64 architecture (using gcc-4.1) and 'make test' ends with ... ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest *** Termination signal 139 Stop. *** Error exit code 1 Stop. Any known remedy? E.g. compiling specific files with lower optimiation level? Hm, replacing -O3 by -O0 for that platform in Configure and rerunning Configure ng with an no-asm and rebuilding every- thing didn't have any success either. Any suggestions? Regards, Stefan Neis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HP-UX Poblem
[EMAIL PROTECTED] wrote: Hi, I've just tried compiling OpenSSL-0.9.8a for HPPA64 architecture (using gcc-4.1) and 'make test' ends with ... ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest *** Termination signal 139 Stop. *** Error exit code 1 Stop. Any known remedy? E.g. compiling specific files with lower optimiation level? Hm, replacing -O3 by -O0 for that platform in Configure and rerunning Configure ng with an no-asm and rebuilding every- thing didn't have any success either. Any suggestions? Has using a different compiler been suggested already? might it be possible to tusc trace that specific test? rick jones __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PadLock engine SHA1 support
Hi Andy, I'm sorry for such a late reply ;-) I didn't have the hardware available during past few months and only got it up and running again recently. BTW, have you considered synergetic implementation, which would work as following. Arrange an intermediate buffer followed by non-accessible page [commonly would be done with anonymous mmap of two pages followed by mprotect(PROT_NONE) for the second page]. Upon *_init we call software SHA*_Init. Then all short inputs go directly through software SHA*_Update, while everything that is larger than certain value, say 256 bytes, is treated as following. Input stream is first purged/aligned by running single pass of SHA*_Update till SHA*_CTX-data is full. Then available 64-byte chunks are copied to the *bottom* of first page mentioned above. Then we set up SEGV signal handler, let hardware suffer from page fault and collect the intermediate hash values. The procedure is repeated if more than pagesize was availalbe at a time. SHA*_CTX-Nl,Nh are adjusted accordingly and remaning bytes [if any] are fed again to software SHA*_Update. Upon *_final we just call *software* SHA*_Final. A. Man that's a wicked idea ;-) Though I'm not sure how xsha would survive restarting after its segfault. Are you sure it flushes the intermediate results on exception? Well we can try ;-) Would such an approach work on all architectures (anonymous and protected pages, sighandlers, ...)? In the meantime could we go with the old fashioned patches that I sent some time ago? I'll realign them with current CVS head (or 0.9.8 branch). Michal __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
