[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments from Paul Van Oorschot

Paul,

Many thanks for your comments. Here are a few in response:

>1. (section 1) The first discussion of "perfect forward secrecy" I 
>   am aware of is by Gunther in his Eurocrypt'89 paper, 
>   ``An identity-based key exchange protocol", pp.29-37,
>   though it is possible this term was defined earlier.
>   BTW, this paper is quite relevant background reading. 

Thanks for the citation. I'll try to find it.

>2. (section 3.3, Cookie Generation) If I understand correctly, it appears
>   the cookie party A creates to use with party B is time-invariant.
>   Does this imply that if B is a malicious party, then any party A which
>   ever gives to B a cookie is subject to a flooding attack by B?
>   If so, it would seem prudent to recommend cookies be time-variant.

The cookie exchange is designed to stop flooding only by parties using
false IP source addresses to which they cannot see reply
traffic. (Recent events on the Internet show that IP address spoofing
actually happens.)  I don't see any way to stop intentional flooding
by a remote party using its own IP address without either requiring
that party to share, a priori, a secret with the local IPSP entity
(e.g., a MD5 hash key) or by restricting access to certain remote IP
addresses. Both approaches run counter to my original design goals for
Photuris; the first by requiring that the local IPSP entity keep (and
protect!) a highly sensitive database of user secret keys, and the
second by not allowing a user to go anywhere on the network.

Photoris is designed to rely solely on the remote entity being able to
prove possession of the secret key that corresponds to a public key in
the local database that identifies an authorized user, regardless of
where that user may go in the Internet.

There *are* some ways that a site might react to a flooding when the
attacker uses his own IP address, such as blocking packets from the
offending IP address or by chasing down the perpetrator. Both are
beyond the scope of the protocol.

>3. (section 4.5, Moduli) It is only fair to list disadvantages
>   as well as advantages, of a fixed prime, including:
>   1) a fixed prime is a much more rewarding cryptanalytic target
>   2) the security of the whole system rests on this prime being good
>   3) changing this prime may lead to difficulties

Valid concerns. I've had to rely on those who understand the discrete
log problem far better than I. So far the consensus seems to be that
there's no problem with a fixed prime as long as it's sufficiently
large and is "strong" (both p and (p-1)/2 are prime). This thwarts the
precomputation step that seems to be the basis of most attacks on the
discrete log problem.

It's also not clear to me that generating ephemeral strong primes for
Diffie Hellman moduli will be practical any time soon.  My own code,
which I modestly assert is pretty well optimized, takes the better
part of an hour on average to generate a random 1024-bit strong prime
on a 66 Mhz 486. So it seems better to just standardize a single
well-chosen prime, or perhaps a small family of strong primes of
different sizes, say 512 bits, 1024 bits and even 2048 bits. This also
avoids the risk that the other party may accidentally or deliberately
choose a weak modulus.

>4. (section 5.1, Signature Transmission) The authenticated key exchange 
>   protocol seems very similar to the the Station-to-Station (STS) 
>   protocol described by Diffie, van Oorschot and Wiener
>   ("Authentication and authenticated key exchanges",
>   Designs, Codes and Cryptography vol.2 pp.107-125 (1992)),
>   including allowing identities to remain hidden from eavesdroppers, and 
>   encrypting a subset of the protocol data messages exchanged themselves.

>   I have sent a hard copy of this paper to you by post today,
>   presuming you do not have access to it.

Yes, I do not claim to have invented this particular technique. I
believe I first heard something like it from Jim Bidzos in person. I
look forward to receiving the paper.

>5. I strongly recommend against signing only a single exponential. 
>   Attacks are known against similar protocols which do so, and there
>   are general concerns (e.g. see pp.116-117 of STS paper). Signing both
>   exponentials provides entity authentication guarantees, which prevent 
>   one class of replay attacks; signing only one does not, and in general 
>   is vulnerable to a wide array of possible "interleaving" attacks.

This has been a major topic of debate. I have since decided to follow
your advice and sign the shared secret instead.

>6. Due to the incredibly embarrassing track record of newly proposed
>   authentication and authenticated key exchange proposals, I hesitate
>   to support any brand new protocol, and recommend the group consider 
>   choosing one (from the literature or elsewhere) which has already 
>   been well-studied by a large number of experts, or which can be 
>   proven to be cryptographically equivalent to such a protocol.

I am not wedded to Photuris or any of its specific details, as long as
any substitute meets all of the design goals I had in mind when I
started. And I am most interested in the best peer review I can get.

Thanks again for your comments, I found them helpful.

Phil
References: