[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A Photuris variant
Hugo,
I'm slowly catching up on my mail, so I just read your message. And yes,
I have a few comments.
Photuris uses DH + PK digital signatures only. The digital signature
scheme could be either RSA or DSA. If you choose DSA and it withstands
a PKP challenge, the whole Photuris scheme could be unencumbered as
early as 1997 when the DH patent expires.
On the other hand, your scheme requires a full public key encryption
algorithm, i.e., RSA...the patent for which doesn't expire until 2000.
Of course, all this is moot unless or until IBM is willing to place
your scheme in the public domain. Please advise on this point before
we spend too much time discussing it.
Aside from that, I see a serious technical problem in your share
phase. How does each party know the public key of the other party so
it can encrypt the half-keys K1 and K2? If you first send your public
key in the clear, then you've just identified yourself to a passive
eavesdropper. But you'd have to do this since your correspondent can't
infer your public key (e.g., from a table) solely on the basis of your
IP source address -- it could well have been dynamically assigned by a
dialup PPP router or DHCP server. (A major purpose of IPSP is to
divorce authentication identities from IP addresses.)
Photuris does the DH exchange first specifically to help cover the
authentication exchange that follows, to provide anonymity against
passive eavesdropping. I consider this to be a pretty important
feature.
Re DH overhead, we've discussed this at length before and I don't
think anything has changed. DH just isn't that expensive, especially
if you use an exponent length that's appropriate to your symmetric
cipher. Furthermore, you do NOT have to re-execute DH everytime you
establish a new session key. My current plan is to generate session
keys by MD5 hashing the DH secret, the SAID and the cookies. So after
a given host pair has done DH once, they can create as many new
uniquely-keyed SAIDs as they need for only one MD5 operation each. (Of
course, they'd always have the option of re-executing the DH exchange
at any time.) Doesn't this satisfy your desire for a quick way to
rekey your weak symmetric ciphers?
Phil