[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

Here's a follow up on the issues which I raised earlier which Ran
suggested might not have been addressed.  

      Please also see Bill Sommerfeld's note to the IPsec list with
      a subject of "Re: IPsec mailing list", date of 9 Oct 1995
      16:57:19

The crucial part of this (the possibility of using change_message to
replay the creation of an SPI which was previously deleted) has been
resolved.

I would, however, like to see some text in the draft regarding ways to prevent
SPI's from significantly outlasting the shared secret initially used
to create them.  I'd prefer to see text requiring the SPI to die when
the shared secret used to create it expires, but could live with
something more liberal..

The sender should stop using the SPI immediately when it expires.  The
receiver should allow a grace period of on the order of a minute or
two to allow for slews in real-time clock frequency between the
systems and to allow any packets in flight to be received.  

      and his note subject "Re: Security Problems in Photuris #2" dated
      12 Oct 1995 15:25:28 and the note from Ron Rivest with subject
      "Photuris terminology" dated 12 Oct 1995 19:54:57 for other 
      unresolved technical problems (generally all of those notes suggest
      easy simple changes to fix the problems).

The 12 Oct message raises some more important issues.

As best I can tell, a number of places in photuris-09.txt require the
use of the now-known-to-be-vulnerable hash(key | data | key) structure for
implementing a keyed MAC.

I'd like to echo Hugo's request to make a change to Photuris to
replace all occurances of

	hash (concat(key, data, key))

with

	keyed_hash(key, data)

There are a bunch of places where hash(key, data, key) is used:
	- section 5.4 privacy method key generation.
	- section 5.5 identity verification
	- section 5.6 session key computation
	- section 6.1.7 integrity verification on change_message

The way it's used in the change_message appears to me as if it might
allow the keyed hash to become a target for chosen-plaintext attacks.
I think the other uses are less of a risk, but then I'm not really a
cryptographer.

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		

	2) define the key used for validity-method, privacy-method keygen,
	   and SPI session keygen as the shared-secret

	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.

I believe that this could be done in a way which preserves
interoperability with existing implemenations of Photuris if this is a
concern.

I believe these answer Hugo's original objection, but naturally I'd
like to see a "real cryptographer" review these, especially #3.  These
perhaps go further than is strictly necessary (perhaps only the
validity-message change is really needed to avoid "bare" use of
key|data|key, but I think we should be conservative with how we use
the cryptographic primitives..)

						- Bill




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

iQCVAwUBMSz4NFpj/0M1dMJ/AQHY0wP8Durc4LS8/d2ylEVEHWBXr8BCZvR0Yazj
EQcXWLz7oJ9BS6bur0f0cSW/AhxQ7tbbojeHqZgLIdEivAVzazZ8MGYnugDSXaUB
rHXxWnyt3JhEOhE8m7rgqyyqfDawV4VU9eTEuzoOw/bu0lMiWB6HYg5qqsg7zgn6
Hwdej8cJafU=
=vNgI
-----END PGP SIGNATURE-----