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/
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.
From fields. You need to use digital signatures to recognize
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 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-----
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`
participants (4)
-
? the Platypus {aka David Formosa} -
Adam Back -
dlv＠bwalk.dm.com -
jbaber＠mi.leeds.ac.uk