[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A Photuris variant
Phil,
Thanks for your comments. Some clarifications are needed.
> 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.
You are right on what you say about your scheme, but not on what you
say about my variant. The same way you can use DSA for signatures
in your scheme, you can use ElGamal encryption with mine.
Moreover, while by using DSA you MAY eventually need to pay royalties
until 2007 when Schnorr's patent expires, for ElGamal you WON'T pay
anything after 1997. So, in this sense, if there is an advantage it
is to my scheme (I am saying this because you brought the issue
not because I see this as a significant reason to prefer mine).
> 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.
Is there an implicit assumption here that the scheme is patented?
Well, to the best of my knowledge there are no patents (except the
PKP ones) covering this proposal. Do you know of any?
If somebody knows of any relevant patents please let us know.
(Same for the basic Photuris).
> 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.
Anonymity is indeed a significant feature required in some situations.
This is why I thought it should be accomodated in my scheme.
And, indeed, my scheme achieves that in a natural (and, as I said
in my original note, transparent) way.
The initiator encrypts its identity, together with K1, under the
responder's public key in the first message (if anonymity
is not required, this identity is just omitted from the encryption).
I believe that in most cases
a relatively short identity will suffice (e.g., a DNS name).
However, if you want to support the sending of I's public-key
(in that case I guess you want to send also a validating certificate)
then there is no room in the public-key encryption to send all
this information. In that (I believe, not so common) case,
you will use K1 to encrypt that information (using a symetric algorithm).
Now, if you are talking of an inititiator I that communicates to
a responder R, and I does not have a way to get R's public key before
the communication, then we have a problem.
Before discussing this problem you'll need to convince me that this
is a realistic situation. (If so, then the performance of a first
phase of unauthenticated DH, as in your scheme, is the ONLY solution).
Let me stop here and I'll continue in another message.
Hugo