From: jbaber@mi.leeds.ac.uk
Date: Fri, 8 Aug 1997 17:32:24 +0800
To: cypherpunks@Algebra.COM
Subject: REPOST : Un-forgeable Cancels
Message-ID: <12867.9708080920@misun2.mi.leeds.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain




I don't think this got through the first time so I am resending it......

--------------------------------------------------------------------------

OK so this has probably been thought of before or has some horrible problem
that I have missed but how's about this as a method of verifying that cancels
have actually come from the author of a message.

I have seen a number of solutions that use various signature algorythms to
check that the cancel has been sent by the original author of the message.
However these require that the news program has access to the public key of
the author in order to verify the signature before honouring the cancel. 
Since there are millions of authors on usenet I believe that this is 
impractical and, not suprisingly, key management again turns out to be a
major problem which I believe can be solved using one way hash functions.

1	When any message is sent a hash X is calculated as :

			X = HASH(Mid,S)

	where	Mid is the Message ID 
		S is a secret controlled by the author (eg a pass phrase)

2	The hash value Y is then calculated such that:

		Y = HASH(X) = HASH(HASH(Mid,S))

3	The value calculated for Y is then included with the message as

		X-Cancel-Ref: Y

This does assume that message IDs are available by the news program and are
not allocated after sending. If this is not the case then it would be necessary
to use other header information to calculate the hash such as the date/time
and subject, or to store some kind of key at the authors end in order to
reference the message (although in this case X may as well just be generated
randomly and stored).

If the user later decided that the message should be canceled he must
re-calculate X using the message ID and his pass phrase and include this
value in the cancel :

		X-Cancel-Key: X

News programs can then be set to check that a valid value of X such that
HASH(X)=Y has been received before honouring the cancel.

Note - I realise that this does not stop anyone who can change the X-Cancel-Ref
header from canceling the message but if they can do that they can probably 
just delete the message anyway.

Any comments/glareing weaknesses that I have missed?

Jon
http://chem.leeds.ac.uk/ICAMS/people/jon/