Re: valgrind and openssl
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. If this is environment/OS-specific, then it's probably indicative of a libc (or valgrind, or gcc) issue with the fixed-in-the-past versions of those packages on RH5.1-64bit. If compiling and running the same openssl source on a different system doesn't give you problems, that would seem to imply that the problem appears and disappears based on elements that vary rather than elements that are invariant. :-) It's environment dependent. I'm not able to reproduce the valgrind errors even on other 64 bit RH5.1 machines. As far as I'm concerned, openssl valgrinds clean with ./config no-asm -DPURIFY: my goals are achieved. -JP __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Mon, May 19, 2008 at 10:48 PM, dean gaudet [EMAIL PROTECTED] wrote: On Thu, 15 May 2008, Bodo Moeller wrote: 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. on the other hand it may be a known plaintext attack. OK, so I'll seed my random number generator with a bunch of bits you don't know, then you give me however much known plaintext you want, and I'll update the state with that too. Then, I'll start generating random numbers. If you can guess them, you win! Right? Essentially what you're claiming is that you can predict the output of SHA-1 when you know part of the input, but not all of the input. Please explain how! -JP what are you guys smoking? -dean __ 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]
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
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
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 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
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]
