[openssl.org #328] DH_compute_key incompatable with PKCS #3
No further reaction ten years later, I'm resolving this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #328] DH_compute_key incompatable with PKCS #3
On Wed, Dec 04, 2002 at 10:16:37AM -0500, Jack Lloyd wrote: 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. A safe way for clients to work around this problem for ephemeral DH is to try a new DH secret if the DH result has a leading zero byte. -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ 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
[[EMAIL PROTECTED] - Thu Nov 14 18:54:19 2002]: 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? None of the older version of Netscape implemented DH ciphersuites, dunno if any of their internal stuff ever did though. I did add EDH client only ciphersuite support to later versions of NSS which may be in some versions of Mozilla. It never had any interop problems with OpenSSL (other than a known issue with SSLv3 and DSS signature format). I could just have been lucky (or arguably unlucky). That uses their own internal security library, not sure what it does though. I'll dig out the NSS source and see if I can work out if it does the same as us. Steve. __ 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
No further reaction, so I'm making this ticket stalled. [levitte - Fri Dec 13 16:47:19 2002]: No further reactions, so I'm moving this to 0.9.7a. [[EMAIL PROTECTED] - Wed Dec 4 16:14:25 2002]: 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. -- Richard Levitte __ 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
No further reactions, so I'm moving this to 0.9.7a. [[EMAIL PROTECTED] - Wed Dec 4 16:14:25 2002]: 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. -- Richard Levitte __ 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
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. -- Richard Levitte __ 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]
[openssl.org #328] DH_compute_key incompatable with PKCS #3
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. Unless you can show that this incompatibility (which is very easy to deal with, BTW) creates an error, I can't really see that this should be changed. [[EMAIL PROTECTED] - Mon Nov 4 10:17:04 2002]: 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 -- Richard Levitte __ 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
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. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ 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
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. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ 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]
