Re: Messages lost on sci.crypt ?

Francois Grieu <fgrieu@francenet.fr> wrote:
>On the Usenet servers of my two competing ISPs (free aka proxad,
>noos aka lyonnaise communication), all sci.crypt traffic
>from Sep 24, 2005 to Oct 22, 2005 seems gone.
>
>Google groups seems to have trouble too
>http://groups.google.com/group/sci.crypt
>
>The problem does not seem to affect nearby sci.* groups
>
>
>Any idea of what is going on ?

The same thing happened in July. At the time, I think it was said
that somebody is forging cancel messages to the group. ISPs that
accept cancel messages drop all the traffic. Some ISPs do not accept
cancel messages (because they are easy to forge), and therefore do
not see this.

This is very annoying. In order to inject a bit of cryptographical
discussion again, here's a proposal:

How do we protect against such attacks? What if every message
includes a commitment to a secret (say a hash of a random string)?
The newsreader records the secret for every message it posts. When
you need to cancel a message, you include the secret in the cancel
message. Every news server verifies that the secret matches the
commitment.

Here's my proposal: When posting a message, you generate a random
string SECRET. Add to the posted message an X-Cancel-Commitment
header, containing SHA-1(SECRET) encoded in (say) Base-64.

When you send a cancel message, you add a header X-Cancel-Secret
containing SECRET encoded in (say) Base-64.

The newsreader must keep track of SECRET to be able to cancel
messages. How this should be accomplished is up to the newsreader,
but I'll make two proposals.

1. Since most newsreaders store posts in local folders, they can
store the X-Cancel-Secret header in the local copy.

2. An alternative is to use a "cancel key" to generate the secret:
select a pseudo-random function f_k, and then generate SECRET as
f_k(MSG-ID). One possible choice could be f_k(x) = HMAC-SHA1(k,x).
The newsreader could then generate SECRET based on the message-id
of the message you want to cancel, and this reduces the need for
storage to one key.

All of these strategies are fairly easy to implement, they are not
very costly in terms of bandwidth (add an extra 40 bytes to each
message), the processing of the cancel message does not require a
lot of processing.

Storing cancel-secrets is a bit of a pain for the newsreader and
the user, but not that much of a pain in these days with cheap
disks. The program should document that it can only cancel messages
that have been retained in the archive of posted messages. If the
archive is lost through disk crash or stupidity or whatever, all
that is lost is the ability to cancel messages.

Store a cancel key is somewhat easier (it can be stored with the
rest of the newsreader configuration parameters). Since anyone who
steals the key only gains the ability to cancel newsgroup posts,
it isn't an important secret that requires a lot of protection.
Also, a lost key only amounts to being unable to cancel messages.

The main argument against implementing something like this is that
a much simpler solution is to disable cancel messages. How often
do you really need to cancel messages? But even so, we can discuss
cryptographic solutions, just for the fun of it.

-- 
Kristian Gjøsteen