Broadcasts - addressing

[db@Tadpole.COM (Doug Barnes)]

I have been contemplating how to mark broadcast messages as being 
'for' someone. To foil traffic analysis, you don't want to include 
their nym or key-id, for the sake of the your poor CPU, you want to 
avoid the need to attempt decryption on everything that passes through. 

My first thought on this is to standardize a way for marking messages 
with either the nym _or_ a one-time-address (a large random number). 
The sniffer would need to be loaded with lists of unused one-time-
addresses, which could be given out in blocks to correspondents. The
one-time-address method would obviously not work the first time you 
contacted a nym, but on further conversation it could significantly 
hamper traffic analysis and would also render the messages from X->Y 
unlinkable (if you were thinking of a "X's alias for Y is <foo>"
approach.)

This is just a first-order brainstorm, I'm curious what others have
thought about this.

Also...

> In case the bandwidth on {alt.anonymous, alt.anonymous.messages} started to
> bother news admins, we could actively encourage them to put the groups on
> very short expiration periods, i.e. articles might expire after only a day.
> Assuming people are using automated sniffers to collect their anonymous mail,
> this shouldn't present any obstacle to the use of the groups as message pools.
> Keeping the ciphertext around in public for a shorter time sounds like a
> Good Thing (tm), anyway. 
> I agree that bandwidth seems essential to foiling traffic analysis.

In order for there to be enough bandwidth to rival some of the really 
classic Usenet bandwidth hogs (e.g. alt.binaries.*), then there would
likely be enough interest and bandwidth to come up with something
that is less leveraged off of Usenet, or that mitigated the load.

Remember, there are people sending sound and video around the net, 
not to mention the huge amount spent to move .GIFs from hither to
yon. I think that you could make a case that experimenting with 
anonymous protocols is potentially a very worthwhile educational 
endeavor, possibly more so than some of the other common uses for
the net, and that it is, by comparison, relatively low-bandwidth.

I agree it can and should be expired quickly once the volume
becomes significant.