[openssl.org #2772] Bug w/ patch: OpenSSL 1.0.1 rejects empty NewSessionTicket
RFC 5077 section 3.3 says:
If the server determines that it does not want to include a
ticket after it has included the SessionTicket extension in the
ServerHello, then it sends a zero-length ticket in the
NewSessionTicket handshake message.
However an OpenSSL 1.0.1 client will reject this message, it appears
due to the fact that OPENSSL_malloc returns failure on attempting to
allocate 0 bytes. Here's s_client in action:
TLS 1.2 [length 000a]
04 00 00 06 00 00 00 00 00 00
139933926663848:error:1411B041:SSL routines:SSL3_GET_NEW_SESSION_TICKET:malloc
failure:s3_clnt.c:2077:
A quick patch of adding
if(ticklen == 0)
{
s-session-tlsext_tick = NULL;
return 1;
}
before attempting the malloc at line 2075 seems to do the right thing
both for empty and regular session ticket messages.
Regards,
Jack Lloyd
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2240] Missing Supported Point Formats Extension in ServerHello should be ignored
RFC 4492 says: A client that receives a ServerHello message containing a Supported Point Formats Extension MUST respect the server's choice of point formats during the handshake (cf. Sections 5.6 and 5.7). If no Supported Point Formats Extension is received with the ServerHello, this is equivalent to an extension allowing only the uncompressed point format. OpenSSL 1.0.0 rejects such a negotiation, always requiring the extension to exist in the ServerHello: CONNECTED(0003) TLS 1.0 Handshake [length 00cd], ClientHello 01 00 00 c9 03 01 4b cc f2 87 fc 1d 05 2d 0c 1f 4a 74 8b 8c 6f 20 c3 56 fb 35 4a 73 b0 9c e0 c1 6f 34 1b 10 f9 9f 00 00 5c c0 14 c0 0a 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00 84 c0 12 c0 08 00 16 00 13 c0 0d c0 03 00 0a c0 13 c0 09 00 33 00 32 00 9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 00 ff 01 00 00 44 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32 00 01 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 0e 00 0f 00 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17 00 18 00 19 00 23 00 00 TLS 1.0 Handshake [length 002a], ServerHello 02 00 00 26 03 01 20 3f 72 c5 29 9f 22 b1 a6 af 4b 81 31 eb 4c 85 bf bb 3a a5 8b b8 21 86 16 c5 7c 84 5c 73 4a 4a 00 c0 08 00 139742562498200:error:1411809D:SSL routines:SSL_CHECK_SERVERHELLO_TLSEXT:tls invalid ecpointformat list:t1_lib.c:1440: 139742562498200:error:14092113:SSL routines:SSL3_GET_SERVER_HELLO:serverhello tlsext:s3_clnt.c:942: OpenSSL 1.0.0 29 Mar 2010 built on: Mon Apr 19 19:52:35 EDT 2010 platform: linux-x86_64 options: bn(64,64) rc4(1x,char) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM OPENSSLDIR: /usr/local/ssl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1585] NIST CMAC, AES-CCM and AES-GCM modes
On Sat, Oct 06, 2007 at 02:55:19PM -0500, Aaron Christensen wrote: Also, since I haven't taken time to learn about CCM, yet, are there serious restrictions on implementing an incremental interface for it? My next step was going to be an attempt to get some of the new SSL/AEAD stuff written, and it would be nice to be able to use a common EVP-like interface... As I understand it, CCM is mostly used in packet-based protocols (and in fact you have to know the length of the whole message to even start processing). So a complete transform mechanism without any incremental support isn't that bad; the expectation is that you'll pull small packets off the wire (or radio interface), and decrypt them sequentially and then (perhaps) reassemble them into a stream. -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] OpenSSL vs GCC 4.2.0
On Wed, May 23, 2007 at 03:07:30AM +0200, Dr. Stephen Henson wrote: Would the compiler (or possibly other compilers) give out a warning that a test was always true? Unlikely, that would set off code like: #define DEBUG 1 [...] if(DEBUG) printf(some debug info); Which isn't perhaps the best style but a lot of code does get written like this under the assumption the compiler will detect the trueness or non-trueness of the expression at compile time and not emit any code for it. (It also has the advantage that your debug-specific code will be typechecked, etc, in every build regardless of the value of DEBUG, unlike the code in an '#if DEBUG' block). -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Bug in DSA_generate_parameters_ex in 20070227 snapshot
In dsa_gen.c:
for (i = qsize-1; i = 0; i--)
{
buf[i]++;
if (buf[i] != 0)
break;
}
i is a size_t, so the expression i = 0 is always true. If the value
of seed is 0xFF...FF, the break will never be triggered either, and
it will modify memory after seed.
Test case:
int main()
{
DSA* dsa = DSA_new();
unsigned char seed[20] = { 0 };
memset(seed, 0xFF, 20);
DSA_generate_parameters_ex(dsa, 1024, seed, sizeof(seed), 0, 0, 0);
}
Under valgrind (after compiling with -DPURIFY) the error is visible:
==27347== 1 errors in context 1 of 1:
==27347== Conditional jump or move depends on uninitialised value(s)
==27347==at 0x40C583: dsa_builtin_paramgen (in
/home/jack/sources/openssl-SNAP-20070227/dsa_gen)
==27347==by 0x40CBD5: DSA_generate_parameters_ex (in
/home/jack/sources/openssl-SNAP-20070227/dsa_gen)
==27347==by 0x401764: main (dsa_gen.c:283)
Adding
seed[19] = 0xFE;
before the call to DSA_generate_parameters_ex allows the loop to exit
before it walks off the end, and no error shows up under valgrind.
-Jack
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: RSA 1024 in certificate
On Mon, Feb 06, 2006 at 10:50:18PM +0530, jimmy wrote: majorsoul (sent by Nabble.com) wrote: why does the DER encoding of public key modulus begins with 02 81 81 00 and not with 02 81 80 ?? ASN.1 specifies integers cannot be negative. so the leading zero makes it positive. Not quite; integers _can_ be negative in ASN.1. They are represented in 2s-complement, so a leading high bit signifies an negative number. So, when you want to encode a positive number that would happen to have the high bit set (such as a 8*n bit RSA modulus), you need to add a leading zero byte. -J __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PEM_read_bio_X509:BIO_gets:unsupported method
On Fri, Jan 06, 2006 at 08:37:25PM +0100, Per Hedeland wrote: Wow. Sun should be embarassed. Well, how *do* you fix it without breaking binary backwards compatibility? The layout of the FILE struct is embedded in all binaries using the stdio macros (e.g. getc()/putc()). Introducing fopen_256(), *printf_256() etc etc to get around it doesn't sound all that appealing. Actually, it's worse than that, depending on how much you care about backwards comptability. For example, if I pass a FILE* from a newly compiled application to a function living in a shared library built on (say) Solaris 2.2, I might well expect that to just work. That said, I agree that it's laughable that a modern Unix would have a limitation such as this. Why not at least add a macro -DMAKE_MY_STDIO_NOT_BROKEN that gives you more than 256 files but breaks compatability? That has proven to be acceptable for 64-bit file support on Unix, and I don't see why this stdio problem would be different. Anyway, this is probably getting really offtopic for the list. The bug exists and needs to be worked around (or not). Sun's suckage or lack thereof does't really come into that issue. -J __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Alternate RAND_poll for XP/2003 Server/Vista
On Sat, Dec 03, 2005 at 10:25:19PM +1100, Steven Reddie wrote: Can you elaborate on the situation where repeatedly initializing and shutting down CryptoAPI causes a large memory leak, See http://support.microsoft.com/default.aspx?scid=kb;en-us;258000 particularly why you needed to do this. It was simple more convenient and useful for me, in that I didn't have to maintain state about Crypto API across entropy generation calls. Since typically (in my code) CryptGenRandom will be called exactly once, at application start up when the PRNG is seeded, there didn't seem to be much reason to keep the whole thing around in memory throughout the application's execution. It also made the code cleaner. -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Alternate RAND_poll for XP/2003 Server/Vista
On Fri, Dec 02, 2005 at 01:44:49PM +1100, Steven Reddie wrote: CryptGenRandom is available on all Windows back to Windows 95. RtlGenRandom is only available since XP, however CryptGenRandom makes use of it. Presumably RtlGenRandom has always been around, it's just never been documented or made generally available until now. From what I can tell, up until recently the PRNG was embedded into CryptoAPI, and could not be accessed without going through that. I would imagine that what happened is that the PRNG implemented by CryptGenRandom was split off into its own distinct chunk of code starting with XP. Keep in mind that right now it doesn't even have an entry point - you have to get ahold of it dynamically through a DLL load. It seems pretty obvious that RtlGenRandom was supposed to just be used internally, with CryptoAPI being the primary interface. Probably someone at Microsoft finally realized that it might be useful to get random bits without having to pull all of CryptoAPI into the mix. Why is there a reluctance to deal with CryptoAPI? I've used CryptGenRandom in my own code and never had a problem with it. I don't have huge issues with it myself (in terms of entropy generation, CryptGenRandom has been fairly painless compared to some other mechanisms), but CryptoAPI is somewhat big, and there are various annoyances, such as the fact that repeatedly initializing and shutting down CryptoAPI causes a large memory leak on some older systems. -J __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Alternate RAND_poll for XP/2003 Server/Vista
On Fri, Dec 02, 2005 at 12:45:44AM +1100, Steven Reddie wrote: That's an interesting blog article. The 2nd comment is by the author and lists the entropy sources. I recall there was discussion on this list quite some time ago where it was stated that OpenSSL wouldn't use only the CryptoAPI random number generator since Microsoft hadn't provided details of how the entropy was gathered. Perhaps the information in that post provides enough detail to warrant dropping all of the heap walking guff that has been known to trip up OpenSSL on occasion. That wouldn't work if you still wish to support Windows systems prior to XP/2003 - and I know for a fact that people are still deploying new code on NT4 right now, so that decision might be unpopular. That's not to say it is not the right decision (personally I'd love to forget supporting Windows XP/2K3, just as I don't have to make sure my code works on RedHat 5.0 or HP-UX 9), but certainly it will cause complaints. Also, in theory, CryptGenRandom can be better than the new function, since, *if* you have a alternate crypto provider (such as one that pulls in entropy from the old i810 motherboard RNG, or an HSM, or whatever) you might get a better entropy source. Now, the question is if that benefit is worth the overhead and mess of dealing with CryptoAPI... I would tend to say it is not, because so few people will actually have such special hardware/providers installed. But it is worth considering. -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: ideas on replacing where ERR_STATE is stored?
On Mon, Oct 17, 2005 at 02:43:19PM -0700, Lev Walkin wrote: Michael Sierchio wrote: Steven Reddie wrote: Hi Michael, I'm familiar with that approach, having used it many times myself. The choice of poll over select isn't important since they're basically the same; in fact, poll is sometimes implemented with select. Who implements poll with select should suffer a fate worse than death -- waking up a thousand sleeping threads to see if one has some i/o ready is what poll was designed to avoid. I think you're confusing a file I/O notification with mutual exclusion and condition variables paradigm, another kind of IPC. The following page provides necessary background information: I believe Michael is actually talking about the thundering herd problem, when many processes are all waiting on a single event, which only one of them will end up responding to. That is a classic problem affecting some uses of select (and also accept, and IIRC a few other socket calls as well). Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: GMP vs BigNum
I am not an OpenSSL developer, but I think I can safely comment on this based on my own experience. First, GNU MP is another dependency, and last I checked GNU MP does not run very well or at all on a number of important platforms. And of course there is always the NIY syndrome at work. OpenSSL does actually support GNU MP, as an engine, which means it can be used if available, and if not, OpenSSL still works fine. I have implemented backends to both OpenSSL's BN and to GNU MP for my own crypto library, as both of them are noticably faster than my own BN code. :) I found RSA/DSA/DH speeds to be about 1.5x-2x as fast with GNU MP as compared to OpenSSL's BN. However, that is not the complete picture, as Botan does not use OpenSSL's higher level operations (for example the RSA calls), but rather implements things by direct calls to BN. Thus, it skips any interesting algorithm-specific optimizations which might be made in OpenSSL, though in benchmarks I found Botan w/BN engine to be nearly exactly as fast as what is reported by OpenSSL's `speed` program [*], suggesting that any optimizations that are there are not of any major consequence. [*] With small keysizes there seems to be some per-call overhead which comes into account, which is not surprising; Botan w/BN's 512-bit public key RSA operations are only about 2/3 as fast as OpenSSL, but for slower private operations, or with larger keys, Botan w/BN and OpenSSL run within 5% of each other. Hope this helps answer your question. -Jack On Wed, Aug 10, 2005 at 07:55:06PM +0400, [EMAIL PROTECTED] wrote: Hello openssl-dev, Did anyone attepmpt a comparison of the speed in the GMP vs BN? Maintainer of GMP (Torbjorn Granlund) says that his tests show 2~3 times better speed with GMP. Can anyone validate this? If this is indeed the case - why OpenSSL does not use GMP? -- Best regards, Tony mailto:[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8: cfb_enc.c bug? and AES speed on Win64/x64
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 behavior of memcpy? The original reason for choosing of memcpy was a) it's comonly inlined by compilers [most notably gcc], but not memmove, b) I fail to imagine how it can fail with overlapping regions if num is guaranteed to be positive, even if the routine is super-optimized, inlined, whatever. Can you? This doesn't make any sense - if memcpy can handle overlapping regions without any slowdown, then wouldn't it make sense to implemenent memmove as a #define (or inline call to) memcpy? Either memcpy does not handle overlaps while memmove does, or memcpy and memmove work at the same speed, because the ability to handle overlapping memory regions is the only difference between the two. The only other alternative is that memcpy and memmove do the exact same thing, but memmove is slower. That seems quite unlikely. -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: X509 path validation
On Thu, Jan 20, 2005 at 01:17:29PM -0500, Jim Schneider wrote: On Thursday 20 January 2005 13:03, Samuel Meder wrote: Got a question: It seems that OpenSSL allows the cert chain to be any number of certificates which it then treats as a pool to build the cert chain from whereas RFC 2246 says the certificate chains must be ordered and no redundant certs are allowed (+/- CA cert): I'm not sure I understand this - are you saying you've found a way to get OpenSSL to create a chain that contains the same CA cert more than once? Based on the OP's reference to RFC 2246, I presume he means the list of certs in the Certificate message. The RFC states that the list should only include exactly the certs needed: The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Apparently OpenSSL isn't checking for this. What would the patch tighten up? Presumably, change it so OpenSSL ensures the other side is not sending totally random extra certificates in the Certificate message during the SSL/TLS handshake. -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Why is top bit forcibly set in DH secret exponent?
None of that FAQ applies to the DH exponents, though.
On Wed, Dec 08, 2004 at 03:28:25PM -0500, Jim Schneider wrote:
This is probably another one for the FAQ:
Setting the highest bit of a random string guarantees that it's N bits long.
Technically, a bit string with the highest order several bits set to zero is
also N bits long, but not mathematically. If you are generating a pair of N
bit primes to use for keying operations, you want to make sure that their
product is as difficult to factor as possible. If the top-most several bits
are zero, the effective key length is reduced.
On Wednesday 08 December 2004 14:40, David Martin wrote:
Hi all,
Looking through openssl's DH code (0.9.7d, see below),
when choosing the secret exponent, openssl chooses a
random number where the most significant bit of the
exponent is always set to be 1 (that's what top=0 does
as the 3rd argument to BN_rand). I can't figure out
any security justification for it. PKCS #3 also
indicates that a central authority may stipulate that
high bits be set on DH exponents-- but I can't find any
explanation there either. Can anyone explain what I'm
missing?
if (generate_new_key)
{
l = dh-length ? dh-length : BN_num_bits(dh-p)-1;
/* secret exponent length */
if (!BN_rand(priv_key, l, 0, 0)) goto err;
}
Thanks,
David
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: SSL session ID generation
On Wed, Nov 24, 2004 at 10:06:10PM +, Ben Laurie wrote: victor sherbinin wrote: I'm wondering whether generation of SSL session ID has to be based on random numbers. In my system, it would be more comfortable for me to generate a sequentially incrementing 64-bit or 128-bit session ID, with some constant padding. Does this violate the security of SSL in any way? Definitely. If someone can steal your session, they can steal authentication. Huh? Wouldn't the attacker have to know the master secret for that session to actually do anything useful? After all, anyone can see the session id as it passes in the clear in the server hello -- if SSL could be broken by someone who knows or can guess a session id, there is something in desperate need of a fix. The only problem I can think of is someone reconnecting for that session and then sending junk, so the session is invalidated. This will cause a performance hit when the legit client reconnects, and that's about it AFAICT. And if you want to DoS a SSL server, it seems better to establish a ton of connections and terminate each one after sending the client key exchange message, which will probably make their CPU(s) very unhappy doing all the RSA decrypts. -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #960] OpenSSL 0.9.7e fails on Linux
Here's a WAG: ldd the test binaries on the FC2 box -- it's possible they ended
up getting linked with the FC2 OpenSSL libs.
If that's not it, I'm out of ideas. :)
-Jack
On Wed, Oct 27, 2004 at 02:57:08PM +0200, Andreas M. Kirchwitz via RT wrote:
Hi OpenSSL team!
I downloaded the new OpenSSL 0.9.7e and compiled it on various
platforms. On Solaris 9 (SPARC) with GCC 3.2.3, everything is
fine.
On all my Linux boxes with Fedora Core 2 (Kernel 2.6.8,
GCC 3.3.3), make test fails after four of the
AES-256-CBC(encrypt/decrypt) tests as follows:
Testing cipher AES-256-CBC(encrypt/decrypt)
Key
60 3d eb 10 15 ca 71 be 2b 73 ae f0 85 7d 77 81
0010 1f 35 2c 07 3b 61 08 d7 2d 98 10 a3 09 14 df f4
IV
39 f2 33 69 a9 d9 ba cf a5 30 e2 63 04 23 14 61
Plaintext
f6 9f 24 45 df 4f 9b 17 ad 2b 41 7b e6 6c 37 10
Ciphertext
b2 eb 05 e2 c3 9b e9 fc da 6c 19 07 8c 6a 9d 1b
Can't find AES-128-CFB1
make[1]: *** [test_evp] Error 3
make[1]: Leaving directory `/usr/local/src/openssl-0.9.7e/test'
make: *** [tests] Error 2
Well, that doesn't mean much to me, but it obviously looks
like something I don't want to trust in.
OpenSSL 0.9.7d successfully completes the tests. (No wonder,
test/evptests.txt doesn't contain AES-128-CFB1 stuff. ;-)
Does it mean that OpenSSL is broken? Or does it mean that
the test procedure is broken in this respect?
Why does it work on the Solaris box?
Greetings, Andreas
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Segfault in speed measurements with aes ecb decrypt
What version of GCC are you using? Many older GCCs have problems with -O3 (or even -O2). I presume this is x86? -J On Wed, Jun 23, 2004 at 09:58:32AM +0200, Roman Pletka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello All, When performing speed measurements with aes-xxx-ecb I get the following errors and segmentation fault: [EMAIL PROTECTED] bin]$ ./openssl version OpenSSL 0.9.7d 17 Mar 2004 [EMAIL PROTECTED] bin]$ ./openssl speed -evp aes-128-ecb -decrypt Doing aes-128-ecb for 3s on 16 size blocks: 10922830 aes-128-ecb's in 3.01s Doing aes-128-ecb for 3s on 64 size blocks: 3756843 aes-128-ecb's in 3.00s Doing aes-128-ecb for 3s on 256 size blocks: 1052700 aes-128-ecb's in 2.99s Doing aes-128-ecb for 3s on 1024 size blocks: 272960 aes-128-ecb's in 3.01s Doing aes-128-ecb for 3s on 8192 size blocks: 34463 aes-128-ecb's in 2.99s OpenSSL 0.9.7d 17 Mar 2004 built on: Tue Jun 22 10:05:29 CEST 2004 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H - -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall - -DSHA1_ASM -DMD5_ASM -DRMD160_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-ecb 58061.55k80145.98k90130.84k92860.81k 94421.70k 12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad decrypt:evp_enc.c:450: 12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad decrypt:evp_enc.c:450: 12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad decrypt:evp_enc.c:450: 12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad decrypt:evp_enc.c:450: 12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad decrypt:evp_enc.c:450: Segmentation fault I get similar output for aes-192-ecb and aes-256-ecb. Any ideas? Thanks, Roman -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA2Tgo9GOBmbEdi04RAj83AJ9COBLBdfnaGim1h9y1Hj/rhrV2rACfcbfu 44h5cNA1cz383WDExTE74sY= =UXx3 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Segfault in speed measurements with aes ecb decrypt
Hmm. If you increase BUFSIZE in speed.c, the segfaults go away, but it still complains about bad decrypts. The code causing the crash seems to be: if(decrypt) for (count=0,run=1; COND(save_count*4*lengths[0]/lengths[j]); count++) EVP_DecryptUpdate(ctx,buf,outl,buf,lengths[j]); It looks like it is going a bit over the allocated space in this loop, though I can't see where (that code is _not_ easy to follow). The default BUFSIZE is 8*1024+1, when using a 8K buffer size this loop writes to one full block of memory beyond the end of the allocated space in buf (block of memory == 1 block size for the cipher in use). As for the bad decrypt errors - seems to be something else. If you modify it to only test with 3 different buffer sizes, you get only three 'bad decrypt' errors. Suspicious. -J On Wed, Jun 23, 2004 at 04:58:50PM +0200, Roman Pletka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I tried gcc version 3.3.3 on gentoo and gcc version 3.2 on redhat. Same result. Yes it is x86. The problem exists with 64bit (AMD) and 32bit (Intel/AMD). I think the problem is related to 'speed' when used with evp and decryption only; not to AES itself. Here is a backtrace: #0 0x4207401d in _int_free () from /lib/i686/libc.so.6 #1 0x42074a2c in free () from /lib/i686/libc.so.6 #2 0x080a038c in CRYPTO_free (str=0x81a5988) at mem.c:378 #3 0x0806baec in speed_main (argc=0, argv=0xb2f8) at speed.c:1735 #4 0x0804a255 in do_cmd (prog=0x818ef60, argc=4, argv=0xb2e8) at openssl.c:381 #5 0x08049f2a in main (Argc=4, Argv=0xb2e8) at openssl.c:300 #6 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 - -- Roman Jack Lloyd wrote: | What version of GCC are you using? Many older GCCs have problems with -O3 (or | even -O2). I presume this is x86? -J | | On Wed, Jun 23, 2004 at 09:58:32AM +0200, Roman Pletka wrote: | |-BEGIN PGP SIGNED MESSAGE- |Hash: SHA1 | |Hello All, | |When performing speed measurements with aes-xxx-ecb I get the following |errors |and segmentation fault: | |[EMAIL PROTECTED] bin]$ ./openssl version |OpenSSL 0.9.7d 17 Mar 2004 | |[EMAIL PROTECTED] bin]$ ./openssl speed -evp aes-128-ecb -decrypt |Doing aes-128-ecb for 3s on 16 size blocks: 10922830 aes-128-ecb's in 3.01s |Doing aes-128-ecb for 3s on 64 size blocks: 3756843 aes-128-ecb's in 3.00s |Doing aes-128-ecb for 3s on 256 size blocks: 1052700 aes-128-ecb's in 2.99s |Doing aes-128-ecb for 3s on 1024 size blocks: 272960 aes-128-ecb's in 3.01s |Doing aes-128-ecb for 3s on 8192 size blocks: 34463 aes-128-ecb's in 2.99s |OpenSSL 0.9.7d 17 Mar 2004 |built on: Tue Jun 22 10:05:29 CEST 2004 |options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) |idea(int) blowfish(idx) |compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H |- -DOPENSSL_NO_KRB5 -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -m486 -Wall |- -DSHA1_ASM -DMD5_ASM -DRMD160_ASM |available timing options: TIMES TIMEB HZ=100 [sysconf value] |timing function used: times |The 'numbers' are in 1000s of bytes per second processed. |type 16 bytes 64 bytes256 bytes 1024 bytes 8192 |bytes |aes-128-ecb 58061.55k80145.98k90130.84k92860.81k |94421.70k |12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad |decrypt:evp_enc.c:450: |12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad |decrypt:evp_enc.c:450: |12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad |decrypt:evp_enc.c:450: |12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad |decrypt:evp_enc.c:450: |12794:error:06065064:digital envelope routines:EVP_DecryptFinal:bad |decrypt:evp_enc.c:450: |Segmentation fault | |I get similar output for aes-192-ecb and aes-256-ecb. Any ideas? | |Thanks, |Roman -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFA2Zqq9GOBmbEdi04RAjniAJ96uQYW7UTzyCCcUh9fz/US3WkuOQCfdTmU geYGpOC1jalgX3oULBxivas= =jaSZ -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #895] AEP engine breaks on Linux with pthreads
Summary: Threaded applications using the AEP engine break badly on Linux.
The AEP engine has the following code to see if the application has forked, and
if so, shutdown and reinitialize the library (in aep_get_connection,
crypto/engine/hw_aep.c):
/*Check if this is the first time this is being called from the current
process*/
if (recorded_pid != curr_pid)
{
recorded_pid = curr_pid;
/* initialize the AEP library */
}
where recorded_pid is a global static (initial value 0). The problem is that on
Linux different threads have different pids (with LinuxThreads; NPTL fixes
this), so every time there is a switch to a new thread, aep_get_connection
think that the process has forked and reinitializes the libary. This leads to a
few problems:
Connections leak (aep_close_all_connections isn't called), so in fairly
short order the process runs out of file descriptors (Unix domain socket
connections to the AEP daemon).
Sometimes the shutdown/restart of the library stomps on other threads that
happen to be in the middle of using the library - this leads to various
failures, such as the API returning various socket errors, or in a few cases
I saw, the AEP library complaining that no callbacks were set for BN-AEP
format conversions, because in between the calls to AEP_Finalize and
AEP_SetBNCallBacks, some other thread started running and tried to do an
operation on the card.
My quick and dirty fix was to change the condition from
if (recorded_pid != curr_pid)
to
if (recorded_pid == 0)
so the library is only initialized once, when aep_get_connection is first
called. This fixed it for me (since my test app doesn't fork) but obviously
breaks a fork() based application. On !Linux, the current behavior is fine. I
can think of a couple possible solutions for Linux, of various quality/work
required:
*) Register a pthread_atfork call to handle shutdown/init
*) Have a rwlock on the library itself, with readers being regular users of
the card (aep_mod_exp, etc), and writers being aep_get_connection if it
decides to shutdown/restart the library.
*) Test if thread callbacks have been set by the user - if so, assume they
are using threads and not forking.
*) Tell people to use NPTL
AFAIK the current OpenSSL threads interface doesn't handle anything more
complex than simple mutexes, which makes a rwlock or pthread_atfork solution
somewhat more troublesome. The third option (check the mutex callbacks) might
work, but some applications (Apache 2, I think?) like to both fork and thread.
The fourth is obviously trivial to implement. :)
Jack
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #895] AEP engine breaks on Linux with pthreads
On Fri, Jun 11, 2004 at 04:34:17PM +0200, Richard Levitte - VMS Whacker via RT wrote: [ We should really use pthread_atfork() ourselves anyhow when available, considering there's always a risk for deadlocks otherwise (at least on Solaris, only the thread that calls fork() is reproduced in the child, which means a whole lot of locks may be left locked in the child with noone to unlock them, if other threads in the parent were doing something protected by a lock of some sort). But that's a different issue... ] AFAIK that is POSIX mandated behavior. I know that Linux and AIX5 do this as well, presumably most others as well. But yes, different issue. -J __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #895] AEP engine breaks on Linux with pthreads
On Fri, Jun 11, 2004 at 02:58:00PM +0200, [EMAIL PROTECTED] via RT wrote: On June 11, 2004 03:00 am, Jack Lloyd via RT wrote: Summary: Threaded applications using the AEP engine break badly on Linux. I see. The problem seems more about the model used by AEP though. Ie. we could use CRYPTO_thread_id() instead of getpid() (because unless CRYPTO_set_id_callback() is called, this devolves into getpid() anyway). I'm looking at the head of CVS right now, so I don't know off the top of my head about 0.9.7, but the connection-pooling in engines/e_aep.c suggests that there is thread-safety between use of these pools, so setting the id_callback() on NPTL to something that has a common return value between threads but not between processes *should* solve the problem. That's assuming that p_AEP_Finalize() closes the connection pool too, otherwise things leak. That seems reasonable. Are you able to move to CVS snapshots by any chance? It would make further discussion of this (and potential changes to the code) easier to manage. No problem. This was just a benchmark/test tool so I could compare OpenSSL against an AEP driver I was writing for another crypto library. I'd be curious how you get on if you use CRYPTO_set_id_callback() from your app to detect real process distinctions (ie. returning the same process id from sibling threads), and to replace the getpid() call in the AEP engine with CRYPTO_thread_id(). (You're probably better in this case to change the pid_t types to unsigned long too, matching the CRYPTO_thread_id() prototype.) Hmm... wouldn't this break other uses of CRYPTO_thread_id? Since they would expect this function to return different values for different threads. -J __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
I asked Eric Rescorla, and he agreed the section of the TLS RFC was definitely unclear, but he wasn't totally sure which way it should go as far as stripping any leading 0s before using the shared secret to generate keys. It basically depends on what various implementations have decided to do. -J On Wed, 4 Dec 2002, Richard Levitte via RT wrote: I haven't heard any news about this. I also mailed ietf-tls asking about this, but had no response there either. That means there will most probably be no fix in 0.9.6h. 0.9.7 still has a week... I think I'll change the miestone for this fix. [[EMAIL PROTECTED] - Thu Nov 14 19:05:29 2002]: In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
I asked Eric Rescorla, and he agreed the section of the TLS RFC was definitely unclear, but he wasn't totally sure which way it should go as far as stripping any leading 0s before using the shared secret to generate keys. It basically depends on what various implementations have decided to do. -J On Wed, 4 Dec 2002, Richard Levitte via RT wrote: I haven't heard any news about this. I also mailed ietf-tls asking about this, but had no response there either. That means there will most probably be no fix in 0.9.6h. 0.9.7 still has a week... I think I'll change the miestone for this fix. [[EMAIL PROTECTED] - Thu Nov 14 19:05:29 2002]: In message [EMAIL PROTECTED] on Thu, 14 Nov 2002 18:54:21 +0100 (MET), Jack Lloyd via RT [EMAIL PROTECTED] said: rt Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone rt should contact the TLS WG and ask for a clarification on this issue? [I'll rt do it if nobody else is interested] Please do. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
On Thu, 14 Nov 2002, Richard Levitte via RT wrote: Can it be shown that this is a problem at a TLS level? I'd hate to make the proposed change just to discover that it breaks interoperability with other TLS clients and servers. RFC 2246 is very vague: 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. [looks like this was copied directly from Netscape's SSLv3 docs] What conventional is supposed to mean in this case is totally unclear to me. If I read this with no other knowledge, I would probably assume conventional == compatible with PKCS #3, since that was the DH standard of choice around the time SSLv3 came out, and since Netscape probably used B-SAFE for the initial SSL implementations. OTOH, who knows? Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone should contact the TLS WG and ask for a clarification on this issue? [I'll do it if nobody else is interested] -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
On Thu, 14 Nov 2002, Richard Levitte via RT wrote: Can it be shown that this is a problem at a TLS level? I'd hate to make the proposed change just to discover that it breaks interoperability with other TLS clients and servers. RFC 2246 is very vague: 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. [looks like this was copied directly from Netscape's SSLv3 docs] What conventional is supposed to mean in this case is totally unclear to me. If I read this with no other knowledge, I would probably assume conventional == compatible with PKCS #3, since that was the DH standard of choice around the time SSLv3 came out, and since Netscape probably used B-SAFE for the initial SSL implementations. OTOH, who knows? Looks like the 1.1 TLS draft spec uses the same wording. Perhaps someone should contact the TLS WG and ask for a clarification on this issue? [I'll do it if nobody else is interested] -Jack __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #328] DH_compute_key incompatable with PKCS #3
Hi, It seems that DH_compute_key is slightly incompatable with PKCS #3, if the derived secret z is too small. In particular, section 8.3 of PKCS #3 Integer-to-octet-string conversion, specifies that that output of the operation should be exactly k bytes long (where k is the number of bytes in the prime p). This seems to be regardless of how big the derived secret actually is (for example if z ends up being 5, and p is ~ 2^512, the output should still be 64 bytes long, with 63 of the leading bytes being 0). OpenSSL does not do it this way: it coverts the shared secret integer into a byte string of a length equivalent to the number of significant bytes in the shared integer. I initially noticed this while reading the dh manpage, and confirmed it by reading dh_key.c as included in openssl-0.9.6g I believe this can be fixed by memset'ing the key parameter to all 0s before doing any operations, then returning DH_size(dh) regardless of the size of the resulting integer. Regards, Jack __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
