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

Re: comments on Photuris



>And if you replaced the signatures in the STS protocol design with
>ICVs computed with cached pairwise SKIP master keys, then this
>too would allow no advantage from smart cards being tricked
>into signing/encrypting various quantities. Furthermore, this

Thanks BTW for explaining this to me in person at the ISOC conference.
But after thinking about it for a while, despite its seeming
differences what you proposed is almost equivalent to Photuris!  (I
tried to find you Friday afternoon to talk about this more but you
seem to have left early).

You said that you could sign the DH public key in your protocol with,
say, PGP. But how does this really differ from Photuris, where I also
sign a DH public part with RSA? The main difference is that I
regularly generate new DH public/private pairs while you consider them
to be fairly static. This may admittedly be a *practical* advantage in
that your DH public keys can be signed offline in a presumably more
secure fashion than my ephemeral DH keys, which have to be signed
online because they change frequently. This may make the signature
function somewhat more vulnerable to compromise.

You suggested that I then do an ephemeral DH exchange (for perfect
forward secrecy) and sign the result of this exchange with the static
DH pairwise key in a fast keyed hash function. But I already do
essentially the same thing in Photuris. Remember that in Photuris the
RSA signature exchange is encrypted in the session key that was just
generated with DH. Unless the attacker knows the secret DH value that
goes with the (stolen) signed public DH value, he won't be able to
generate the session key and therefore won't be able to encrypt the
signature properly.  The recipient will decrypt it to garbage and
notice that it doesn't verify. (Although my original reason for
encrypting the signature exchange was to protect the identities of the
parties, it now seems to have other uses.)

So this puts your protocol in the same boat as Photuris: if the DH
secret component is compromised then the protocol is broken.

This is the crux of the problem. There seems to be no way to reconcile
my desire to minimize online delay by computing signatures in advance
with the stated need to sign something in real time with a
well-protected secret. Comments?

>As Hugo mentioned, attacks are not about fairness. One could make the same 
>argument about protocols that dont support perfect forward secrecy, i.e, 

I know, I know, I typed hastily. Attacks are never "fair" in the sense
that your opponent will always try anything that's possible. I was
trying to make the point that *any* cryptographic system has to rely
on *something* being secret, i.e., a key. Sure, you can design it to
minimize the damage done if a key leaks out, but you can't eliminate
it entirely. I don't care how good your protocol is; if I know it,
your crypto algorithms and *all* your keys (long and short term), I
think I can break it. :-)

Once again, we have to consider the threat model. In the real world,
which threats are credible and which aren't? Comments?

Phil




References: