Re: how is this working...

David Brownell (David.Brownell@Eng)
Tue, 10 Mar 1998 15:56:35 -0800

Date: Tue, 10 Mar 1998 15:56:35 -0800
From: David.Brownell@Eng (David Brownell)
Message-Id: <199803102356.PAA14629@argon.eng.sun.com>
To: java-security@web1.javasoft.com, frank@uccs.jpl.nasa.gov,
Subject: Re: how is this working...

In particular, "Applied Cryptography" by Bruce Schneier is good.

You can probably also find a description of this key exchange algorithm
in the "Secure RPC" documentation of most SunOS releases. I suspect
that JPL has some of that around! That's where I learned about it,
about ten years ago ... :-)

What's now called AUTH_DES relies on Diffie-Hellman key exchange to
establish the key which is used to encrypt a timestamp; it was the
original "Secure RPC" protocol, and is still one of the most widely
deployed RPC security tools.

- Dave

> From Jeff.Nisewanger@Eng Tue Mar 10 15:47:39 1998
> Date: Tue, 10 Mar 1998 15:44:03 -0800
> From: Jeff.Nisewanger@Eng (Jeff Nisewanger)
> To: java-security@web1.javasoft.com, frank@uccs.jpl.nasa.gov
> Subject: Re: how is this working...
>
> > I am using SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 as my enabled cipher
> > suite. I realize this is turning off authentication and that I am
> > vulnerable to the "man in the middle" attack. My question is, how are
> > the SSLSocket and the SSLServerSocket get a key to encrypt the channel?
> > Usually what happens here is that one uses the public key to encrypt and
> > the other uses the private key to decrypt. Since this is not being done
> > (?), how is the session key known to both parties?
>
> Using the above SSL cipher suite, the exchange of keys for
> encrypting the channel is done using the DH or Diffie-Hellman
> key exchange algorithm. This has been around for awhile and is a commonly
> used way for 2 parties to anonymously create a shared secret from which
> they can derive shared symetric encryption keys such the RC4 40-bit
> keys implied by the above cipher suite. You can usually find details of the
> algorithm in any book on security or encryption.
>
>
>
> Jeff
>