[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Regarding Bill's draft... another Bill's open issues with
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
> More importantly, the attack requires a large number of different
> chosen-messages. Since it is not possible for an attacker to "choose"
> the parameters being verified, this attack is impossible.
>
> That's not at all clear to me. In particular, it seems that in a
> system using per-user or per-transport-connection SPI's, an active
> attacker could easily induce a system to create large numbers of SPI's
> with a third party, each having similar, but not identical parameters.
>
I am not following you; since it's apparently easy, please give a
concrete example of such an exchange.
> Most importantly, the attack requires an incredibly large number of
> known-messages, on the order of 2**65 or more! That makes it utterly
> impractical (also stated by the authors).
>
> That's an upper-bound on the strength of this construction, not a
> lower bound.
>
How true (although the number I gave was the smallest bound in the
paper). In fact, it could be guessed on the very first try. It's just
not very likely (1:2**65). And there would be no confirmation of success.
> As an engineer, not a cryptographer, the existance of this weakness
> makes me suspicious of tying photuris so closely to
> hash(concat(key,data,key)) instead of a more flexible
> keyed_hash(key,data).
>
Thanks for your opinion.
> They already are. That is, a hash over the key. MD5 is used in the
> base document, but other hashes are possible for other Exchange-Schemes.
> (See Extensions draft for details.)
>
> I'm sorry, but a keyed hash and a hash over a key and some other data
> are *NOT* necessarily the same thing. Hash(concat(key,data,key)) is just one
> way to implement a keyed hash -- it's not necessarily the *best* way.
>
Never-the-less, it is _one_ way, and at this time is the one with field
experience and both qualitative and quantitative analysis.
> Hugo's work suggests that hash(key1, hash(key2, data)) may be better,
> but there's no way to cleanly define photuris extensions which use
> that structure in the future if the base draft insists on the
> key,data,key form.
>
Huh? You mean Kaliski and Robshaw. Hugo suggested some other variant
for another purpose.
And I don't understand your latter assertion, as Photuris has clear and
clean extension mechanisms.
> > 2) define the key used for validity-method, privacy-method keygen,
> > and SPI session keygen as the shared-secret
> >
> This is a cryptographically unsound idea.
>
> Why? That's exactly what photuris is doing today! It's doing a keyed
> hash using the shared secret as the "key" and other fields as the
> "data".
>
I don't see any "data" or "hash" in your suggestion. If you are
suggesting that Photuris use the same method that it does today, then we
are in complete agreement.
> > 3) define the key used for the identity-choice algorithm as
> > the shared secret, concatenated or otherwise combined with the
> > authentication secret-key if there was one.
> >
> Again, an incredibly insecure idea.
>
> Again, this is exactly what photuris is doing today. It's doing a
> keyed hash using the shared secret as the "key" and other fields as
> the "data".
>
Again, ditto.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: