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

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



-----BEGIN PGP SIGNED MESSAGE-----

content-type: text/plain; charset=us-ascii

   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.

   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.

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).
   
   > Recommended high-level changes:
   > 	1) Redefine the following hash algorithm families as keyed hashes:
   > 		validity-method
   > 		identity-choice
   > 		privacy-method key generation
   > 		SPI session key generation		
   >
   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.

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.

   > 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".

   > 	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".

						- Bill




-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMS32y1pj/0M1dMJ/AQFXkQP9HoFnI4wUlUnCQtaQLRFMv1lGn90ys6Kn
pEeGX/UFkHF77TQomeXxFQ9fOVC4jYocWV0nTJR3R4Y0PM7hIektneApD96pDEW6
vwL2I6rFB1y5SCmjSVA0ATnlLs1I4TUgoM19dWgqp4bSqmsGJJNfkc50deCtTPBv
9ZAsPlHaM9c=
=iK8b
-----END PGP SIGNATURE-----


References: