[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on Photuris
> From: ashar@osmosys.incog.com (Ashar Aziz)
> Photuris uses the "sign your own exponential only" version of
> authenticated DH exchange. Presumably this was done in order to
> allow the signatures to be precomputed, thereby speeding up the
> realtime aspects of the protocol. This message is focused on
> the potential vulnerabilities of such a scheme.
>
Pre-computation is an important feature of Photuris.
> Although it is possible to easily deal with some of the issues
> that are raised, section B is probably the greatest concern.
>
> A - Insecure combination of signature and hash algorithm
>
> The intruder chooses as her secret DH exponent the value 0, therefore
> the intruder's public DH value is g^0 = 1. The exchanged key is
> g^(0*y), which is 1, independent of y.
>
So? Value 0 is simply disallowed. A pretty easy check.
A good thing to add to the proposal.
> B - Knowing combination of {x, g^x, Signed(g^x)} allows impersonation
>
> This might seem harmless enough that a party may actually sign
> g. However, by obtaining signed g the intruder has now obtained the
> following tuple {1, g^1, Signed(g^1)}. The intruder can now
> impersonate the party who signed g by choosing 1 as her
> secret exponent when participating in a key-exchange.
>
OK. Value 1 is also disallowed. Straight-forward arithmetic so far.
> C - Known key attacks
>
> Should a party ever learn the other side's secret DH exponent
> after a successful key exchange, she can then impersonate that party
> because she now knows {x, g^x, Signed(g^x)}.
>
> It's not immediately obvious that one should never reveal the
> secret DH exponent in an exchange even to an authorized party,
> because it may appear that all the secret exponent allows one to
> do is compute g^xy which the connecting party already knows.
>
Seems obvious enough to me.
And Photuris explicitly periodically destroys old secrets. That perfect
forward secrecy that we've been talking about for some time....
> D - Requirement for Authentication-Only version of protocol
>
> If one is not performing encryption, but instead is doing authentication
> only, then it is a requirement to check the authenticity of the IP
> packet that contains the signed DH public value. Checking the signature
> of the signed DH value alone is not enough, as both the public DH value
> and its signed version may be played back from an earlier run with
> the real party.
>
This one makes no sense to me. How do you "check" the authenticity of
the IP packet?
Moreover, the current draft _requires_ encryption in the final step.
Since this is encryption for authentication purposes, there is no export
restriction, hence no "requirement for Authentication-Only".
Anyway, these are all pretty trivial, but probably should be included in
the next draft. Thanks.
Bill.Simpson@um.cc.umich.edu