RE: valgrind and openssl
You mean you're not testing *all* of the real code. That's fine, you can't debug everythign at once. if you haven't tested your final production binary then you haven't tested anything at all. You: Two plus two is five. Me: Are you crazy? Two plus two is not five. You: If you don't realize that three plus three is six, then you don't know any math at all. Err, what?! What does testing your final production binary have to do with debugging on code other than your final production binary? Good luck finding people who agree with you. I've been a professional software developer for about 18 years and I've worked on debugging with i've been a professional for longer than you. big whoop. -dean It really doesn't matter how long you've been doing it when you spout nonsense like the above. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: valgrind and openssl
on the other hand it may be a known plaintext attack. what are you guys smoking? -dean This argument has already been refuted in the posts you are replying to. Such an attack would require the algorithm to not meet its specific design security objectives. In other words, you are arguing that this might be a problem if the algorithm is fundamentally broken. Well, duh, using it might be a problem if the algorithm is fundamentally broken. A primary security objective of the PRNG is that mixing in known data can never, ever hurt you. It may not increase the entropy in the PRNG, but it cannot decrease it. This is a specific design object, and you can rely on the PRNG to meet this object. If you don't think the PRNG meets this objective, you should not use it at all because this is one of its primary objectives and the entire design is premised on it. The only issue is that you might not mix in enough unknown data. Mixing in known data can never hurt you. If it can, the PRNG is totally and completely broken. If you have any reason to think it is, please explain why. We will all change the algorithm because this would be a major breakage. You might as well argue that after you sign something with RSA, you should keep the signature secret. After all, there might be some attack where the signature leaks parts of the private key. Sure, there might be. But if you really thought there was any chance of that, you'd abandon the signature algorithm, not work harder to keep the signatures secret. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
REQUEST TO MODERATOR: valgrind and openssl
Hi there, Can you please unsubscribe anyone who posts on this subject again. The participants should long ago have taken this debate off list. It's degenerated into a discussion without any value whatsoever. Kind regards -paul __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: OpenSSL_0_9_8-stable: openssl/crypto/rand/ randfile.c
Lutz Jaenicke wrote:
OpenSSL CVS Repository
http://cvs.openssl.org/
Server: cvs.openssl.org Name: Lutz Jaenicke
Root: /v/openssl/cvs Email: [EMAIL PROTECTED]
Module: openssl Date: 16-May-2008 09:14:58
Branch: OpenSSL_0_9_8-stable Handle: 2008051608145800
Modified files: (Branch: OpenSSL_0_9_8-stable)
openssl/crypto/rand randfile.c
Log:
Another occurance of possible valgrind/purify uninitialized memory
complaint related to the PRNG: with PURIFY policy don't feed uninitialized
memory into the PRNG.
Submitted by: Bodo Moeller [EMAIL PROTECTED] :-)
Summary:
RevisionChanges Path
1.47.2.3+4 -0 openssl/crypto/rand/randfile.c
patch -p0 '@@ .'
Index: openssl/crypto/rand/randfile.c
$ cvs diff -u -r1.47.2.2 -r1.47.2.3 randfile.c
--- openssl/crypto/rand/randfile.c2 Mar 2007 17:44:55 - 1.47.2.2
+++ openssl/crypto/rand/randfile.c16 May 2008 07:14:58 - 1.47.2.3
@@ -127,7 +127,11 @@
i=fread(buf,1,n,in);
if (i = 0) break;
/* even if n != i, use the full array */
This comment should be inside the #else clause :-)
+#ifdef PURIFY
+ RAND_add(buf,i,(double)i);
+#else
RAND_add(buf,n,(double)i);
+#endif
ret+=i;
if (bytes 0)
{
@@ .
__
OpenSSL Project http://www.openssl.org
CVS Repository Commit List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
--
http://www.apache-ssl.org/ben.html http://www.links.org/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
on the other hand it may be a known plaintext attack. Using those words in this context makes it sound that you not only don't understand what is being discussed right here and now, but also that you don't understand the term you just used. Are you sure you understood, e.g., Ted Tso's postings in this thread? Perhaps I'm missing something, but can you show me something that talks about known plaintext attacks in the context of hashing/digests? what are you guys smoking? Indeed. /r$ -- STSM, DataPower Chief Programmer WebSphere DataPower SOA Appliances http://www.ibm.com/software/integration/datapower/
[openssl.org #1675] RSA_set_method(3) inconsistency
2 issues with RSA_set_method(3) man page: 1. the function prototypes for RSA sign and verify functions in RSA_set_method(3) man page do not match reality - crypto/rsa/rsa.h lists them as: int (*rsa_sign)(int type, const unsigned char *m, unsigned int m_length, unsigned char *sigret, unsigned int *siglen, const RSA *rsa); int (*rsa_verify)(int dtype, const unsigned char *m, unsigned int m_length, const unsigned char *sigbuf, unsigned int siglen, const RSA *rsa); but the man page says this: /* sign. For backward compatibility, this is used only * if (flags RSA_FLAG_SIGN_VER) */ int (*rsa_sign)(int type, unsigned char *m, unsigned int m_len, unsigned char *sigret, unsigned int *siglen, RSA *rsa); /* verify. For backward compatibility, this is used only * if (flags RSA_FLAG_SIGN_VER) */ int (*rsa_verify)(int type, unsigned char *m, unsigned int m_len, unsigned char *sigbuf, unsigned int siglen, RSA *rsa); (notice ths missing 'const') 2. the man page is missing rsa_keygen member of RSA_METHOD structure v. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1674] bug report - fipsld not working with Solaris 9 sparc (64 bit architecture) for 32 bit shared library creation.
Hi, I am using fipsld to create 32 bit (using -m32) statically linked shared object library from fips capable openssl on SOLARIS 9 SPARC. But fipsld hangs at link step (when creating shared object lib).I guess this is a bug in fipsld script or openssl? To reproduce the problem please follow the steps mentioned in attached document. System info: uname -a: SunOS qa-sun9 5.9 Generic_117171-12 sun4u sparc SUNW, UltraAX-i2 Thanks Satyadev Hi, I am using fipsld to create 32 bit (using m32) statically linked shared object library from fips capable openssl on SOLARIS 9 SPARC. But fipsld hangs at link step (when creating shared object lib).I guess this is a bug in fipsld script or openssl? To reproduce the problem please follow the steps mentioned in attached document. System info: uname a: SunOS qa-sun9 5.9 Generic_117171-12 sun4u sparc SUNW, UltraAX-i2 Thanks Satyadev Steps followed on solaris.doc Description: MS-Word document
How get encoding EC_params fro EC_KEY?
Hello, I can get encoding of an ANSI X9.62 ECDSA public key from previously generated EC_KEY using function i2d_EC_PUBKEY. Is where way to get Ec_params encoding of an ANSI X9.62 from EC_KEY? I did not found function for this purpose. Best regards Mark Mark Shnaider | Software engineer | ARX phone: +972.3.9279543 | mobile: +972.54.2448543 | email: [EMAIL PROTECTED] | www.arx.com
Re: valgrind and openssl
On Monday 19 May 2008 15:27:24 dean gaudet wrote: 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. you know, this is sheer stupidity. you're suggesting that testing the no-asm code is a valid way of testing the assembly code? Whoa, you're getting a tad trigger happy there. I'm not suggesting that testing the no-asm code is a valid way of testing the assembly code, you're putting words in my mouth. I think my last sentence is pretty clear. Debugging and optimising the assembly code is a different ball-game than identifying C-level leaks or other bugs in openssl. That's why I suggested comparing with a no-asm build. If valgrind sees equivalent problems in both, fine. If it sees it only with the assembly optimisations, that's useful information too, right? additionally the suggestion of -DPURIFY as a way of testing the code is also completely broken software engineering practice. No, it's not. This is a PRNG, not a menu widget. You might also want to test with support for symbols and core-dumps, but run without either in production. Heisenburgs can also up when running in a debugger vs not running a debugger, using optimisation flags selectively, [...]. We have a PRNG, the accent is on the R, not the P. This is not valgrind's fault, just a one-off incompatibility with the notion that uninitialised==catastrophe. any special case changes for testing means you're not testing the REAL CODE. With respect, please check the though shalts at the door, thanks. for example if you build -DPURIFY then you also won't get notified of problems with other PRNG seeds which are supposed to be providing random *initialized* data. This is not true. -DPURIFY does *NOT* compile out the use of *initialised* data - that is the whole point. It compiles out any use of *uninitialized* data. (Or at least it's supposed to, Bodo thinks there's another case where an #ifdef would be needed in the corner case where there's a short width parameter - that's beside the point.) not to mention that a system compiled that way is insecure -- so you either have to link your binaries static (to avoid the danger of an insecure shared lib), or set up a chroot for testing. Also not true. in any event YOU'RE NOT TESTING THE REAL CODE. which is to say you're wasting your time if you test under any of these conditions. You haven't got your facts straight. In fact, I'm starting to suspect you've got them deliberately organised in a circle, for the sake of argument. Please make sure you're aware of *precisely* what's going on here, and *precisely* what -DPURIFY changes in openssl. Otherwise your second sentence is theologic, at best. openssl should not be relying on uninitialized data for anything. even if it doesn't matter from the point of view of the PRNG, it should be pretty damn clear it's horrible software engineering practice. More thou shalts. As for your other mail; On Monday 19 May 2008 23:48:14 dean gaudet wrote: On Thu, 15 May 2008, Bodo Moeller wrote: 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. For that sentence to be other than BS, it is a minimum requirement that the PRNG be fundamentally broken algorithmically. Please publish, or refrain from muddling the issue. what are you guys smoking? The charred remains of a debian package, it's very noxious. Cheers, Geoff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Make ssleay_rand_bytes more deterministic
On Tue, May 20, 2008 at 12:09 AM, Bodo Moeller [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 11:57 PM, Richard Stoughton [EMAIL PROTECTED] wrote: - do not mix the PID into the internal entropy pool, and The OpenSSL PRNG uses the PID twice: Once it is used as part of the intitial seeding on Unix machines, to get some data that might provide a little actual entropy. This part wasn't functional in the Debian version, because the content of each and every seed byte was ignored. But then the PRNG also mixes the PID into the output (via a hash). This is why the PID did influence the output bytes on Debian. The point in using the PID here is *not* to collect entropy. Rather, it is to ensure that after a fork() both processes will see different random numbers. Without this feature, many typical Unix-style server programs would be utterly broken. I see. As far as I can understand the code, the suggested usage pattern for the RNG would be ssleay_rand_bytes(ssleay_rand_add ^ n) with n 0. If consecutive calls to ssleay_rand_bytes without intermediate calls to ssleay_rand_add are allowed, your objection is obviously more than justified. - do not mix bits of the given output buffer into the internal entropy pool. Note that the second improvement may totally break already broken client software. Why would it? Clients that do not call ssleay_rand_add at all would probably get a random series with even less variance than the debianized one has. However, I cannot see that the second point would make the correctly used RNG weaker. Would it? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: valgrind and openssl
On Tue, 20 May 2008, Richard Salz wrote: on the other hand it may be a known plaintext attack. Using those words in this context makes it sound that you not only don't understand what is being discussed right here and now, but also that you don't understand the term you just used. Are you sure you understood, e.g., Ted Tso's postings in this thread? Perhaps I'm missing something, but can you show me something that talks about known plaintext attacks in the context of hashing/digests? yes i abused the term. the so-called uninitialized data is actually from the stack right? an attacker generally controls that (i.e. earlier use of the stack probably includes char buf[] which is controllable). i don't know what ordering the entropy is added to the PRNG, but if all the useful entropy goes in first then an attacker might get to control the last 1KiB passed through the SHA1. yes it's unlikely given what we know today that an attacker could manipulate the state down to a sufficiently small number of outputs, but i really don't see the point of letting an attacker have that sort of control. -dean __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
