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
[[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
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 basi
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 uncle
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 th
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
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
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]:
>
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 conve
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 e
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 el
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 conv
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 reall
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
t
14 matches
Mail list logo
