REPOST : Un-forgeable Cancels

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/

Jon Baber <jbaber@mi.leeds.ac.uk> writes:
> 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))
> 
> Any comments/glareing weaknesses that I have missed?

Sounds good to me.  I thought there was someone doing something like
this with hashes.  But then I never really looked into any of the
systems.  What does Greg Rose's PGPMoose do?  (One presumes it
involves PGP sigs?)

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

I think you don't even need this much uniqueness of hashing
material...

Say you just chose a random R and store it in ~/.news-preimage, and
HASH( R ) in ~/.news-image.

Now you post all of your posts with HASH( R ) in a header as you are
suggesting.

Now if you didn't want to be coerced in to cancelling your own posts
you just remove .news-preimage instantly.

You have to update your preimage for each cancel you do, but how many
cancels do people do anyway?  (Not many for their own benefit I
reckon).


This is a low security application, and ease of use over user typed
passwords will win I think.

Conceivably you could cope with the above by making .news-image
readable to the news system on your local net news service.  This
could transparently do the job without needing to update any clients
-- only an INN patch required.  Sounds like a phun project for
someone.

Issueing cancels would be more manual, but you could easily knock up a
perl script to instruct the NNTP server to do that.  (Or windows
program, or whatever).

If you really wanted to integrate cancels without updating clients,
for those that support them you'd have to give the NNTP news server
access to your preimage, R.  Not sure this is a good idea, as now your
ISP can be coerced into cancelling your message for you without your
cooperation.

Course all these problems go away if you do update clients, but it's
usually nice to offer an easy interim migration path, else no-one will
use it.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

jbaber@mi.leeds.ac.uk writes:

> Any comments/glareing weaknesses that I have missed?

Well, you missed credited guys named Franz and Huusinen with proposing this
exact scheme a couple of years ago. You also missed my discussion on how to
allow the local admin to issue cancels as well.

I used to think this scheme is very cool.  Later I realized it had a serious
problem with forgeries in one's name.

Suppose X forges an article in Y's name, and specifies a cancel lock; then
Y can't cancel this forgery.

The retraction server which David is reported to be working on doesn't
rely on passwords on authenticate Y; if Y can demonstrate the ability
to receive a cookie sent to Y, then the server can issue a signed 'hide'
NoCeM for an article that purports to be from Y.  Works for forgeries too.

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

Dimitri Vulis <dlv@bwalk.dm.com> writes:
> jbaber@mi.leeds.ac.uk writes:
> 
> > Any comments/glareing weaknesses that I have missed?
> 
> I used to think this scheme is very cool.  Later I realized it had a
> serious problem with forgeries in one's name.
>
> Suppose X forges an article in Y's name, and specifies a cancel
> lock; then Y can't cancel this forgery.

But that's cool!  Y shouldn't be able to cancel the forgery ... he
didn't write it.  That's the definition of censorship, removing some
one else's content.

I mean this seriously.  People should stop misplacing any value on
>From fields.  You need to use digital signatures to recognize
persistent personas.

The quicker people realise this the better.

It is in cypherpunks interests to see as many forgeries as possible.
Because then the natural solution is for people to use digital
signatures.  More people using crypto, the harder it is to outlaw.

(Dimitri: perhaps you need to code some easy to use high quality
forgery software to go with your cancel bot).

> The retraction server which David is reported to be working on
> doesn't rely on passwords on authenticate Y; if Y can demonstrate
> the ability to receive a cookie sent to Y, then the server can issue
> a signed 'hide' NoCeM for an article that purports to be from Y.
> Works for forgeries too.

(David = David Formosa?)

What's the point of this?  To provide a way to stop unsophisticated
forgeries without needing NoCeM support in the client? 

I guess it would work well enough, but it's really a bit centralised.
The operator of the retraction server might be over trusted by a lot
of people.  If the operator turns out to be untrustworthy, or
whatever, you're out of luck.

Also break into his machine and steal his secret key and you could
have a _lot_ of fun.  And it's only one machine, what if his security
isn't up to much.

Think decentralised.  That's the whole advantage NoCeM, it's
decentralised approach to providing a third party USENET news article
rating system.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

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

On Fri, 8 Aug 1997, Adam Back wrote:

[...]

> But that's cool!  Y shouldn't be able to cancel the forgery ... he
> didn't write it.  

[...]

> I mean this seriously.  People should stop misplacing any value on
> From fields.  You need to use digital signatures to recognize
> persistent personas.

This is true but with everthing there is a trade off between securaty and
efficency.  There are many posts on usenet that are just not worth the
cost of checking there sigs.  If I had to depend only on the sig reather
then having the chouse of only checking the sig on susouse posts I
wouldn't be able to read as much usenet as I do.

> (David = David Formosa?)

Yes.

> What's the point of this?  To provide a way to stop unsophisticated
> forgeries without needing NoCeM support in the client? 

Not mean clients have the capsity to issue NoCeMs,  a lower number of
peaple have anough reputation to issue them.

> I guess it would work well enough, but it's really a bit centralised.

Not realy, when finished I will distrabute the sourse.  The hope is that
we will have a number of compeating retraction servers around the world.

> The operator of the retraction server might be over trusted by a lot
> of people.

True.  But building up that type of trust is possable.

> If the operator turns out to be untrustworthy, or whatever, you're out
> of luck.

No you simply more to the other retraction server.  There will be nothing
unqueek about one server then anouther.

> Also break into his machine and steal his secret key and you could
> have a _lot_ of fun.

This is true of cause.

>  And it's only one machine, what if his security isn't up to much.

Its not going to only be one machine.

> Think decentralised.

We are.

- -- 
Please excuse my spelling as I suffer from agraphia see the url in my header. 
Never trust a country with more peaple then sheep.  ex-net.scum and proud
You Say To People "Throw Off Your Chains" And They Make New Chains For
Themselves? --Terry Pratchett

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBM+0dOqQK0ynCmdStAQGU7gP/c9NRABskCeUTF93BhGjEeWVSeKIMG+Ma
TeXXzzKiOcRcUsebBc4smOIprPKmVavwFizH6hmmpr8G8BZZVchaNgCeo1IkeY8w
rdT/WB4i3UUFBVT4l4nToUJPim9GxvNh3YFCK3rkWDza50rrVFN3MFF3FvI2bc1G
7wAgzlMOjX0=
=C/ey
-----END PGP SIGNATURE-----