Date: Mon, 25 Jan 1999 18:51:08 -0800
From: David Brownell <db@Eng>
To: satyendra dhingra <satyen@digitalmarket.com>
Subject: Re: Assymetric encryption & JCE
satyendra dhingra wrote:
>
> At 04:30 PM 1/25/99 -0800, you wrote:
> >satyendra dhingra wrote:
> >>
> >> The problem I am running into i
> >>
> >> - the session keys are DES, and encryption of message data using
> >> session keys works fine, by using the DES cipher.
> >> - the private/public keys pairs are DSA, and there is no
> >> cipher avbl for encryption using these keys.
> >
> >Normally one would
>
> thanks for your quick reply,
>
> our communication framework is building on store-and-forward model
> very much like sendmail, this is done for the sake of fault tolerance,
> where the messages will not get lost even during network breakdowns, or
> remote systems being down.
That has some implications for key management in your protocol ...
> So any protocol that relies on live exchange of data to agree on
> encryption parameter will not work in our scheme of thigs. So, it
> looks like we will have to pre-agree on some parameters to drive
> the encryption.
Right. One way to do this is to use Diffie-Hellman keys in
the X.509 certificates, though I'm not sure that works right
now in the JDK (or with JCE). You can arrange to have those
D-H keys pre-exchanged, and perhaps include a nonce in the
(plaintext) envelope of each message to hash with the key
from the D-H exchange, generating the encryption key. That'll
mean you can do steps A and B in advance, at least for two-party
non-live key exchanges. I think that's pretty much what PGP
does in its non-RSA mode.
> I will be nice to have implementation of a asymmetirc key
> generation + cipher algorithm that work together,
It should be pretty easy to do (a small class can wrap up
all the logic) though I can understand wanting a proven
implementation to safely manage all the key storage issues.
- Dave
p.s. out of curiousity, are you using the JMS (Java Messaging
Service) APIs for this store-and-forward messaging?
> thanks,
> satyendra
>
> >
> > A: * agree on Diffie-Hellman [D-H] parameters (e.g. pick a
> > fixed set -- but preferably, negotiate!)
> >
> > * Each member of a session generates a D-H key pair
> >
> > * Signs the public D-H key from that pair using their DSA
> > private key, sending that key and the signature along
> > with cert to everyone else that wants to be in the session
> >
> > B: * Use the Diffie-Hellman key exchange algorithm to
> > generate a shared secret, the "session key"
> >
> > * This will have been authenticated!
> >
> > C: * Use that session key to generate a key that'll be
> > driving the traffic encryption ... e.g. a 128 bit
> > Blowfish, or 162 bit Triple-Des, key.
> >
> >That is, the encryption is symmetric (for speed) and uses the
> >key in the DSS/DSA certificate for authentication, but the key
> >is exchanged using a third algorithm that stresses D-H.
> >
> >I suggest you look at the SSLv3 "DHE_DSS" key exchange protocol.
> >Also, Bruce Schneir's "Applied Crypto" 2nd edition.
> >
> >- Dave
> >
> >