How I can safe public and private of ES_KEY and create new ES_KEY for sign and verify
Hello , I have problem in understanding and could you clarify for me what is the best way to extract and safe public and private keys from generated ES_KEY and then create new key for signature or verify . Example esdatest.c: if (!EC_KEY_generate_key(key)) goto x962_int_err; BIO_printf(out, .); If I would like to create new ES_KEY for verify to my opinion I need to perform following actions: - Extract and safe key-pub_key-X, key-pub_key-Y, key-pub_key-Y to safeX,safeY,safeY And then in the other application perform: if ((new_key = EC_KEY_new_by_curve_name(nid)) == NULL) //create new key for verify goto x962_int_err; pub_key = EC_POINT_new(new_key-group); -- copy big numbers safeX,safeY,safeY to pub_key-X, pub_key-Y, pub_key-Y EC_KEY_set_public_key(new_key, pub_key); Can I use now new_key for verify? Thanks in advance Best regards Mark Mark Shnaider | Software engineer | ARX phone: +972.3.9279543 | mobile: +972.54.2448543 | email: [EMAIL PROTECTED] | www.arx.com
valgrind and openssl
In the wake of the issues with Debian, is it possible to modify the source so that it is possible to use valgrind with openssl without reducing the key space? Are we really relying on uninitialized memory for randomness? -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 4:58 PM, John Parker [EMAIL PROTECTED] wrote: In the wake of the issues with Debian, is it possible to modify the source so that it is possible to use valgrind with openssl without reducing the key space? Sure. This might happen with the next release. Are we really relying on uninitialized memory for randomness? Not at all. It's just that OpenSSL in some situations tries to feed possibly uninitialized memory into the random number generator anyway, essentially just for fun and because their *might* be some actual randomness there from whatever happened earlier in the same process. The Debian-internal patch was blatantly overbroad in disabling the essential functionality of the RAND_add() function rather than just avoiding the one case where this function might have been called with uninitialized memory. (That one case is in RAND_load_file(), which would intentionally feed a complete 1024-byte buffer to RAND_add() even if fewer than 1024 bytes had been put into the buffer by fread().) Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On May 15, 2008 10:58:07 am John Parker wrote: In the wake of the issues with Debian, is it possible to modify the source so that it is possible to use valgrind with openssl without reducing the key space? It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. (we do it all the time here with WvStreams and Pathfinder, and it works like a charm). Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Patrick Patterson [EMAIL PROTECTED] writes: On May 15, 2008 10:58:07 am John Parker wrote: In the wake of the issues with Debian, is it possible to modify the source so that it is possible to use valgrind with openssl without reducing the key space? It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. Even with -DPURIFY there was (prior to 0.9.8f) some uninitialised memory got used if you didn't have a .rnd file (the stat() in crypto/rand/randfile.c). (I'm not sure whether that change ever got on to 0.9.7. Hmm, I think it didn't. Likely not critical, I guess, though Debian/stable is on 0.9.7. Backporting that (trivial) change seems like something a distribution could uncontroversially do.) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. (we do it all the time here with WvStreams and Pathfinder, and it works like a charm). The problem is that this may reduce the keyspace so that keys are guessable. http://blog.isotoma.com/2008/05/debians_openssl_disaster.html -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thursday 15 May 2008 11:52:08 John Parker wrote: It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. (we do it all the time here with WvStreams and Pathfinder, and it works like a charm). The problem is that this may reduce the keyspace so that keys are guessable. No it won't, it removes an entropy source whose quality is known to be unknown, ie. it may add nothing useful, it gets used just in case. Removing it does not reduce the keypsace at all. All you can say is that leaving it there *may* improve the PRNG depending on the user, the environment, the application, and quite probably, the alignment of the planets... The debian patch went further than -DPURIFY, as it removed more than just this unreliable source, it removed all use of reliable sources as well. http://blog.isotoma.com/2008/05/debians_openssl_disaster.html This blog does not suggest that building with -DPURIFY would a problem and nor should it. I think you may have misunderstood the details of this issue. Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
All of this is independent of proper entropy seeding to the PRNG, which is what the debian patch crushed and which in turn led to the high seismic reading in the blogosphere. But it may help explain why I do *not* want us to unilaterally remove the use of uninitialised data in the PRNG. That seems to be motivated by a capitulation to the weight of users (or packagers) who don't know how to read the FAQ. Perhaps what we should do instead is I think we should be less worried how things seem and more worried about the practical consequences. change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer intention, so that debug packages (or even base packages that want to be valgrind-friendly) have a straightforward mechanism to apply. Well, a straightforward mechanism that doesn't kill the PRNG outright, I mean (otherwise there is already a highly-publicised patch we could apply...) What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. Can someone provide a pointer to this highly-publicized patch? I'm afraid I'm dreadfully ignorant of the blogosphere. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. Actually on my system, just -DPURIFY doesn't satisfy valgrind. What I'm asking for is something that both satisfies valgrind and doesn't reduce the keyspace. (we do it all the time here with WvStreams and Pathfinder, and it works like a charm). The problem is that this may reduce the keyspace so that keys are guessable. No it won't, it removes an entropy source whose quality is known to be unknown, ie. it may add nothing useful, it gets used just in case. Removing it does not reduce the keypsace at all. All you can say is that leaving it there *may* improve the PRNG depending on the user, the environment, the application, and quite probably, the alignment of the planets... The debian patch went further than -DPURIFY, as it removed more than just this unreliable source, it removed all use of reliable sources as well. http://blog.isotoma.com/2008/05/debians_openssl_disaster.html This blog does not suggest that building with -DPURIFY would a problem and nor should it. I think you may have misunderstood the details of this issue. I am clearly misunderstanding something. You seem to be saying that -DPURIFY satisfies valgrind but doesn't reduce the keyspace. I'm prepared to take it on faith that -DPURIFY doesn't reduce the keyspace. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On May 15, 2008 12:38:24 pm John Parker wrote:
It is already possible to use openssl and valgrind - just build
OpenSSL with -DPURIFY, and it is quite clean.
Actually on my system, just -DPURIFY doesn't satisfy valgrind. What
I'm asking for is something that both satisfies valgrind and doesn't
reduce the keyspace.
What you simply need to do is make a supplemental ignore known issues file
for valgrind - for WvStreams, we use one that has the following in it:
{
more_fun_libcrypto_junk
Memcheck:Value4
fun:BF_encrypt
}
{
more_fun_libcrypto_junk_2
Memcheck:Value4
fun:AES_encrypt
}
{
more_fun_libcrypto_junk_3
Memcheck:Addr4
fun:AES_cbc_encrypt
}
{
more_fun_libcrypto_junk_4
Memcheck:Value4
fun:_x86_AES_encrypt
}
And then we run all of the unit tests through valgrind with the options:
valgrind --tool=memcheck --leak-check=yes --num-callers=10
--suppressions=$(WVSTREAMS_SRC)/wvstreams.supp
Between -DPURIFY and the suppressions, the unit tests come back clean (when we
haven't made any silly mistakes in our own code, of course :)
BTW: I'm not claiming that the above list of suppressions will work 100% for
you - the suppressions above are for things that our code tickles - you may
want to add more of them for those specific areas that your code touches that
ours does not.
Have fun.
--
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thursday 15 May 2008 12:38:24 John Parker wrote: It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. Actually on my system, just -DPURIFY doesn't satisfy valgrind. What I'm asking for is something that both satisfies valgrind and doesn't reduce the keyspace. If you're using an up-to-date version of openssl when you see this (ie. a recent CVS snapshot from our website, even if it's from a stable branch for compatibility reasons), then please post details. -DPURIFY exists to facilitate debuggers that don't like reading uninitialised data, so if that's not the case then please provide details. Note however that there are a variety of gotchas that allow you to create little leaks if you're not careful, and valgrind could well be complaining about those instead. This blog does not suggest that building with -DPURIFY would a problem and nor should it. I think you may have misunderstood the details of this issue. I am clearly misunderstanding something. You seem to be saying that -DPURIFY satisfies valgrind but doesn't reduce the keyspace. I'm prepared to take it on faith that -DPURIFY doesn't reduce the keyspace. Well, more generally than some keyspace is the randomness of the PRNG itself. (Your keys are only random if the PRNG's output is random.) But yes, I'm saying that -DPURIFY does not diminish the quality of the PRNG, except *possibly* by some unquantifiable amount that you couldn't safely depend on anyway. As for your other mail; On Thursday 15 May 2008 12:09:46 John Parker wrote: All of this is independent of proper entropy seeding to the PRNG, which is what the debian patch crushed and which in turn led to the high seismic reading in the blogosphere. But it may help explain why I do *not* want us to unilaterally remove the use of uninitialised data in the PRNG. That seems to be motivated by a capitulation to the weight of users (or packagers) who don't know how to read the FAQ. Perhaps what we should do instead is I think we should be less worried how things seem and more worried about the practical consequences. That is more or less what I was doing. I hope that was clear. change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer intention, so that debug packages (or even base packages that want to be valgrind-friendly) have a straightforward mechanism to apply. Well, a straightforward mechanism that doesn't kill the PRNG outright, I mean (otherwise there is already a highly-publicised patch we could apply...) What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. I believe this has been answered. For now, it's called -DPURIFY. Can someone provide a pointer to this highly-publicized patch? I'm afraid I'm dreadfully ignorant of the blogosphere. You started this mail thread, so you go and find it! :-) The patch I was referring to, tongue-in-cheek, is the debian patch that crippled the PRNG. As for the blogosphere, you aren't missing much, I'd recommend that continued ignorance would be far from dreadful - in fact I intend to join you in that respect, once this was-it-debian's-fault-or-openssl's-fault nonsense has died down a bit. Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
John Parker, 2008-05-15: It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. Actually on my system, just -DPURIFY doesn't satisfy valgrind. What I'm asking for is something that both satisfies valgrind and doesn't reduce the keyspace. Valgrind can be told to ignore specific errors, using a suppressions file. Never used this with OpenSSL, though. http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress Leandro __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
I forgot to mention something; On Thursday 15 May 2008 12:38:24 John Parker wrote: It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. Actually on my system, just -DPURIFY doesn't satisfy valgrind. What I'm asking for is something that both satisfies valgrind and doesn't reduce the keyspace. If you're using an up-to-date version of openssl when you see this (ie. a recent CVS snapshot from our website, even if it's from a stable branch for compatibility reasons), then please post details. -DPURIFY exists to facilitate debuggers that don't like reading uninitialised data, so if that's not the case then please provide details. Note however that there are a variety of gotchas that allow you to create little leaks if you're not careful, and valgrind could well be complaining about those instead. Note that you should always build with no-asm if you're doing this kind of debug analysis. The assembly optimisations are likely to operate at granularities and in ways that valgrind could easily complain about. I don't know that this is the case, but it would certainly make sense to compare before posting a bug report. Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote: change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer intention, so that debug packages (or even base packages that want to be valgrind-friendly) have a straightforward mechanism to apply. Well, a straightforward mechanism that doesn't kill the PRNG outright, I mean (otherwise there is already a highly-publicised patch we could apply...) What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. -DPURIFY *does* do what you want. It doesn't reduce the keyspace. The problem was that what Debian did went far beyond -DPURIFY. The Debian developer in question disabled one call that used uninitialized memory, but then later on, removed another similar call that looked the same, but in fact *was* using initialized data --- said initialized data being real randomness critically necessary for security. - Ted __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
John Parker wrote: change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer intention, so that debug packages (or even base packages that want to be valgrind-friendly) have a straightforward mechanism to apply. Well, a straightforward mechanism that doesn't kill the PRNG outright, I mean (otherwise there is already a highly-publicised patch we could apply...) What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. That is -DPURIFY. Can someone provide a pointer to this highly-publicized patch? I'm afraid I'm dreadfully ignorant of the blogosphere. The Debian patch is the highly publicized patch that kills the PRNG outright. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: valgrind and openssl
On Thu, May 15, 2008 at 7:53 PM, Theodore Tso [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote: What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. -DPURIFY *does* do what you want. It doesn't reduce the keyspace. The problem was that what Debian did went far beyond -DPURIFY. The Debian developer in question disabled one call that used uninitialized memory, but then later on, removed another similar call that looked the same, but in fact *was* using initialized data --- said initialized data being real randomness critically necessary for security. This similar call would, under certain conditions, use uninitialized data too. I guess Valgrind is more thorough than Purify, because it seems that those using Purify were not shown this as suspicious, and thus -DPURIFY didn't cover this particular case. Of course, totally disabling the offending call in md_rand.c as was done in Debian was blatantly wrong. The correct way would have been to change RAND_load_file() in randfile.c; that's the function thatt might sometimes pass uninitialized data to RAND_add() (intentionally, but without relying on this uninitialized data as a source of randomness). One of the offending RAND_add() calls has already been taken care of about a year ago: http://cvs.openssl.org/filediff?f=openssl/crypto/rand/randfile.cv1=1.47.2.1v2=1.47.2.2 However, another intentional use of potentially unitialized data is still left as of http://cvs.openssl.org/getfile/openssl/crypto/rand/randfile.c?v=1.47.2.2 : i=fread(buf,1,n,in); if (i = 0) break; /* even if n != i, use the full array */ RAND_add(buf,n,(double)i); Changing this into RAND_add(buf,i,(double)i) should make verification tools happier. Or it could be #ifdef PURIFY RAND_add(buf,i,(double)i); #else RAND_add(buf,n,(double)i); #endif (abusing the PURIFY macro with a more general meaning). Bodo __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 12:29 PM, Geoff Thorpe [EMAIL PROTECTED] wrote: I forgot to mention something; On Thursday 15 May 2008 12:38:24 John Parker wrote: It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. Actually on my system, just -DPURIFY doesn't satisfy valgrind. What I'm asking for is something that both satisfies valgrind and doesn't reduce the keyspace. If you're using an up-to-date version of openssl when you see this (ie. a recent CVS snapshot from our website, even if it's from a stable branch for compatibility reasons), then please post details. -DPURIFY exists to facilitate debuggers that don't like reading uninitialised data, so if that's not the case then please provide details. Note however that there are a variety of gotchas that allow you to create little leaks if you're not careful, and valgrind could well be complaining about those instead. Note that you should always build with no-asm if you're doing this kind of debug analysis. The assembly optimisations are likely to operate at granularities and in ways that valgrind could easily complain about. I don't know that this is the case, but it would certainly make sense to compare before posting a bug report. I'm still seeing a lot of errors from valgrind, even with the latest snapshot. 19 15:12 tar xvfz ../openssl-0.9.8-stable-SNAP-20080515.tar.gz 20 15:12 cd openssl-0.9.8-stable-SNAP-20080515/ 21 15:12 ls 22 15:12 ./config no-asm -DPURIFY 23 15:12 make 24 15:14 valgrind ./apps/openssl genrsa 1024 Please let me know if I'm doing something wrong with this test sequence. The problems occur on Red Hat 5.1 server x86_64. For what it's worth, I don't get errors on (updated :) Ubuntu 7.10. I do get errors even with Bodo's addition to randfile.c. I'd be happy to post the valgrind output if that would be helpful. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Theodore Tso wrote: On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote: change -DPURIFY to -DNO_UNINIT_DATA or something else which has a clearer intention, so that debug packages (or even base packages that want to be valgrind-friendly) have a straightforward mechanism to apply. Well, a straightforward mechanism that doesn't kill the PRNG outright, I mean (otherwise there is already a highly-publicised patch we could apply...) What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the default, but wouldn't reduce the keyspace either. -DPURIFY *does* do what you want. But thats a compile time option. I would prefer not to have to compile my own version of OpenSSL just to be able to valgrind my program which links against openssl. Erik -- - Erik de Castro Lopo - #!/bin/sh unzip ; strip; touch ; finger ; mount ; gasp ; yes ; more ; umount ; sleep ; __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Patrick Patterson wrote: On May 15, 2008 10:58:07 am John Parker wrote: In the wake of the issues with Debian, is it possible to modify the source so that it is possible to use valgrind with openssl without reducing the key space? It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. A compile time option is not enough. I would like the be able to valgrind my program linked against the standard openssl library I get from my Linux distribution. Erik -- - Erik de Castro Lopo - We reject kings, presidents, and voting. We believe in rough consensus and running code. -- Dave Clark (IETF 1992) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thursday 15 May 2008 16:56:17 Erik de Castro Lopo wrote: Patrick Patterson wrote: On May 15, 2008 10:58:07 am John Parker wrote: In the wake of the issues with Debian, is it possible to modify the source so that it is possible to use valgrind with openssl without reducing the key space? It is already possible to use openssl and valgrind - just build OpenSSL with -DPURIFY, and it is quite clean. A compile time option is not enough. I would like the be able to valgrind my program linked against the standard openssl library I get from my Linux distribution. Then tell your linux distribution to use -DPURIFY. Or order me an 8-core magic wand from Dell and I'll get right on it. Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erik de Castro Lopo schrieb: | Theodore Tso wrote: | | On Thu, May 15, 2008 at 11:09:46AM -0500, John Parker wrote: | What I was hoping for was a -DNO_UNINIT_DATA that wouldn't be the | default, but wouldn't reduce the keyspace either. | -DPURIFY *does* do what you want. | | But thats a compile time option. I would prefer not to have to compile | my own version of OpenSSL just to be able to valgrind my program which | links against openssl. Then configure your valgrind to ignore this uninitialized use of data. Normally usage of uninitialized data is an oversight done by the programmer that may cause unintended consequences. Because of that valgrind complains about them. But here the use of this uninitialized data is intentional and the programmer are very well aware of what they did. Perhaps it would be a good idea to add a README.valgrind containing a description of what happens and how to configure valgrind to ignore the uninitialized reads ? (Perhaps people that won't read the FAQ will read that) Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILKt52iGqZUF3qPYRAtkIAJ47deAtIXtN0DKJGN61CtZyimI3jACfUPDJ ddRbnQn5NF5h0Y6P6pLUHP4= =8wkC -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Geoff Thorpe wrote: Then tell your linux distribution to use -DPURIFY. Hangon, I've got a better idea. How about the OpenSSL develoeprs fix their library so that the standard version that they ship is valgrind clean. Then the distributions won't need to do anything other than compile it. Erik -- - Erik de Castro Lopo - The difference between genius and stupidity is that genius has its limits. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 11:41 PM, Erik de Castro Lopo [EMAIL PROTECTED] wrote: Goetz Babin-Ebell wrote: But here the use of this uninitialized data is intentional and the programmer are very well aware of what they did. The use of unititialized data in this case is stupid because the entropy of this random data is close to zero. It may be zero, but it may be more, depending on what happened earlier in the program if the same memory locations have been in use before. This may very well include data that would be unpredictable to adversaries -- i.e., entropy; that's the point here. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Bodo Moeller wrote: It may be zero, but it may be more, depending on what happened earlier in the program if the same memory locations have been in use before. This may very well include data that would be unpredictable to adversaries -- i.e., entropy; that's the point here. Do you know its unpredicatable or are you only guessing? Can a bad guy force it to be predicatable? How much entropy is actually there? Has anyone actually measured it? Erik -- - Erik de Castro Lopo - Using Java as a general purpose application development language is like going big game hunting armed with Nerf weapons. -- Author Unknown __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 4:41 PM, Erik de Castro Lopo [EMAIL PROTECTED] wrote: Goetz Babin-Ebell wrote: But here the use of this uninitialized data is intentional and the programmer are very well aware of what they did. The use of unititialized data in this case is stupid because the entropy of this random data is close to zero. The only sane way to deal with this it to either make it zero or make it truely random. Erik I disagree. If there's a performance cost to making openssl happy with valgrind, I'd rather have there be an option that defaults to optimize security and performance at the expense of debugging capability. Debugging is the infrequent case. Although I disagree, I understand your argument. However, you weaken your position by using the words stupid and sane; they make you seem disrespectful. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thu, May 15, 2008 at 11:51 PM, Erik de Castro Lopo [EMAIL PROTECTED] wrote: Bodo Moeller wrote: It may be zero, but it may be more, depending on what happened earlier in the program if the same memory locations have been in use before. This may very well include data that would be unpredictable to adversaries -- i.e., entropy; that's the point here. Do you know its unpredicatable or are you only guessing? Can a bad guy force it to be predicatable? How much entropy is actually there? Has anyone actually measured it? All this depends on the specific application. For many, there almost certainly won't be any unpredictable data. For others, in particular long-running interactive software, there certainly will be at least some information that is unpredictable to at least some adversaries. Even if it's just return addresses on the stack, the specific pattern will depend on the program's past, some aspects of which may be unknown to adversaries. We don't care if anyone can force this to be predictable, because we're in no way relying on it to deliver more than zero bits of entropy. We're just hoping there might be some entropy in there sometimes. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
Geoff Thorpe wrote: Then tell your linux distribution to use -DPURIFY. Hangon, I've got a better idea. How about the OpenSSL develoeprs fix their library so that the standard version that they ship is valgrind clean. Then the distributions won't need to do anything other than compile it. Erik Umm, why? 1) This is an unusual use case. 2) Zeroing memory that doesn't need to be zeroed has a performance cost. 3) It's very easy to recompile a debug build for debugging. IMO, the default build should always be a release build with release optimizations and tradeoffs. A debug build should be the exception. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
Bodo Moeller wrote: We don't care if anyone can force this to be predictable, because we're in no way relying on it to deliver more than zero bits of entropy. So it might end up being zero just by chance right? We're just hoping there might be some entropy in there sometimes. In the practice of engineering, we should try to avoid 'hoping' about anything. Erik -- - Erik de Castro Lopo - Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. -- Bruce Beizer's Pesticide Paradox __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
David Schwartz wrote: Umm, why? 1) This is an unusual use case. This is not an unusual case. I'm a developer and I valgrind my code all the time because fixing problems shown up by valgrind makes my code better. My code is targeting an embedded Linux box and I try to ensure that the system I develop and test on is as close as possible to the embedded target. Using a different version of openssl sort of defeats that aim. 2) Zeroing memory that doesn't need to be zeroed has a performance cost. Yep, I agree, for code that doesn't give valgrind warnings. A couple of years ago I attended a very interesting presentation by Andrew Tridgel of the Samba project. He explained that they avoided zeroing memory wherever possible. However, they used valgrind and had a rigorous policy of fixing all valgrind warnings. Tridge's claim was that doing this maximized performace and guarded against information leakage onto the wire. 3) It's very easy to recompile a debug build for debugging. But if I do that, my test system is no longer the same as my target. IMO, the default build should always be a release build with release optimizations and tradeoffs. A debug build should be the exception. I'm not asking for all uses of malloc to be replaced with calloc, I'm asking for the very small number of areas that produce valgrind warnings to be fixed. Since they are small in number it is unlikely that any performance decrease can even be measureed. Erik -- - Erik de Castro Lopo - The Earth is around 70% water. Fish rule the seas. Humans are over 90% water. It's only a matter of time. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
David Schwartz wrote: Umm, why? 1) This is an unusual use case. This is not an unusual case. I'm a developer and I valgrind my code all the time because fixing problems shown up by valgrind makes my code better. I didn't say it was an unusual use case for you. It's an unusual use case for OpenSSL. My code is targeting an embedded Linux box and I try to ensure that the system I develop and test on is as close as possible to the embedded target. Using a different version of openssl sort of defeats that aim. Then you have to make a tradeoff. You can either debug in a release build and suffer the added complexity or you can release a debug build and suffer the performance loss. But others don't have to make that tradeoff, and there's no reason your problem should force them to. 2) Zeroing memory that doesn't need to be zeroed has a performance cost. Yep, I agree, for code that doesn't give valgrind warnings. A couple of years ago I attended a very interesting presentation by Andrew Tridgel of the Samba project. He explained that they avoided zeroing memory wherever possible. However, they used valgrind and had a rigorous policy of fixing all valgrind warnings. Tridge's claim was that doing this maximized performace and guarded against information leakage onto the wire. He's absolutely right. Here, Tridge's argument works the other way. We *want* as much information as possible to leak into the PRNG. 3) It's very easy to recompile a debug build for debugging. But if I do that, my test system is no longer the same as my target. Then you are welcome to ship a debug build with your target. That's your tradeoff to make. The vast majority of people don't have such a tradeoff, so it's kind of silly that they should suffer its costs just because you have to. IMO, the default build should always be a release build with release optimizations and tradeoffs. A debug build should be the exception. I'm not asking for all uses of malloc to be replaced with calloc, I'm asking for the very small number of areas that produce valgrind warnings to be fixed. Since they are small in number it is unlikely that any performance decrease can even be measureed. Then you are welcome to compile with -DPURIFY even in your release build. That does exactly what you ask for. I've already explained why that's not the default -- your case is unusual and so it should *not* be the default. A single extra flag is an extremely minimal cost. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
Would a runtime flag for don't seed with uninitialized memory, rather than (or in addition to) -DPURIFY, satisfy everybody? John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
In the practice of engineering, we should try to avoid 'hoping' about anything. Don't know much about cryptography, do you? /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/
RE: valgrind and openssl
Would a runtime flag for don't seed with uninitialized memory, rather than (or in addition to) -DPURIFY, satisfy everybody? Everybody? It seems to me that only one or two people who don't really understand what's going on are complaining. OpenSSL should stay as it is. A contributed valgrind suppressions file would be useful. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/
RE: valgrind and openssl
Would a runtime flag for don't seed with uninitialized memory, rather than (or in addition to) -DPURIFY, satisfy everybody? John I don't think it's necessary, since compiling with '-DPURIFY' is so ridiculously easy, but I have no objection to it. An evironment variable would probably be the easiest way to do it. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
Everybody? It seems to me that only one or two people who don't really understand what's going on are complaining. Wanting to get accurate runtime analysis results with a release build is not an unreasonable request. OpenSSL should stay as it is. A contributed valgrind suppressions file would be useful. It certainly would, but Valgrind isn't the only analysis tool people might want to use. A runtime flag provides a means of obtaining accurate results with any tool. John __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Thursday 15 May 2008 17:31:45 Erik de Castro Lopo wrote: Geoff Thorpe wrote: Then tell your linux distribution to use -DPURIFY. Hangon, I've got a better idea. How about the OpenSSL develoeprs fix their library so that the standard version that they ship is valgrind clean. Then the distributions won't need to do anything other than compile it. What, you mean like how the standard version we ship has a good PRNG, so that the distributions don't need to do anything about that either? Funny, that doesn't work so well in the real world. Distributions always do something before compiling packages, as debian has so succinctly and spectacularly demonstrated. They pick target architecture settings for the distribution that are independent of the build host (eg. cross-compilation for non-x86 hosts, etc) and another other configuration options they think useful/necessary. Eg. static/dynamic, PIC or not, symbols or not, installation paths, optional features (and dependencies), documentation, [...]. Sometimes they even throw in patches, which is where they diverge dangerously from what we provide. If it is the distribution's preference to have openssl unnecessarily memset and/or unnecessarily restrict its seeding to pander to an unmodified and unconfigured valgrind, be that in the standard package or any other debug package, then that is their choice. We provide a (supported) method for doing this, it's called -DPURIFY. It doesn't require *any* source-code patching. ahem. Valgrind is a great tool and no doubt many non-noobs put it to good use on a daily basis. It helps find non-deterministic behaviour. That it finds non-deterministic behaviour in our PRNG should not be cause for basement-dwellers the world over to rise up against common-sense. We have a FAQ in case you get confused, and valgrind can also be taught to work around such cases as this. And again, you can build openssl to side-step the false-positives for a very small overhead. Just what level of base, ill-informed, and incompetent debugging help do we need to cater to? And to what non-technical extents are we prepared to go for it? Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Fri, May 16, 2008 at 12:39 AM, David Schwartz [EMAIL PROTECTED] wrote: 2) Zeroing memory that doesn't need to be zeroed has a performance cost. This particular argument doesn't actually apply here. We wouldn't have to zeroize any memory, we just wouldn't feed those bytes that are not known to have been initialized into RAND_add(). The cost of RAND_add() is a lot higher than that of memset(), so we'd even gain some performance. But we'd lose the randomness that is available when the bytes not currently known to have been initialized have in fact been previously initialized in a way not known by an attacker. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
