Re: Regarding Bill's draft... another Bill's open issues with

[William Allen Simpson <[e-mail]>]

> From: Bill Sommerfeld <[e-mail]>
>    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.

[e-mail]
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2