Re: Broadcasts - Bandwidth Problem ?

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

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

Jonathan Rochkind writes:
> Many people seemed to think that a newsgroup for this sort of a thing was a
> waste of bandwith.  I don't really agree, and think that the bandwith is
> neccesary for a distributed method of making the remailer net more robust
> to remailers popping into and out of existence.

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.

- - -L. Futplex McCarthy; PGP key by finger or server  "We've got computers, 
we're tapping phone lines; I know that that ain't allowed" --Talking Heads

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.1

iQCVAwUBLuwe/Wf7YYibNzjpAQFK4AP/YFtRJMd0emeRJgZf4QaL4qPvMFKNn3Uv
MYFhJ8GR2M4x1q/ZAwhJsP3NuIeRk5UAWc1Ti1OYKjDkNvoQ52DK3uOW6aCqxYp0
3REpK53F0PkuVL9EnfGImrUWAyeUr2oZOzp1O67hD0eCYhM4IdcdDudA/97Xh0R+
zRIhgC6/Gfo=
=n6qM
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLuwgPSoZzwIn1bdtAQFFgAF+LXvBnjZEZxsMx9MU+fGX9ynuAnrqKs6S
EFbgsBG8aFvul2skOsgIBrVW5luJm4c7
=iPbm
-----END PGP SIGNATURE-----

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.

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

	Keys are cheap.  Everyone should have a bunch.  To foil
TA, hand out a key to each correspondant.  Give them id's like
'latex.limb.malaise <alt.anonymous.mesages>'


Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume

> 
> | 
> | 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. 
> 
> 	Keys are cheap.  Everyone should have a bunch.  To foil
> TA, hand out a key to each correspondant.  Give them id's like
> 'latex.limb.malaise <alt.anonymous.mesages>'
> 

Yes, but any set of messages sent under a particular key are 
linked for purposes of traffic analysis. You would need to hand
out (potentially) a key per message, or stacks of keys. At
which point, you're doing something very similar to what I 
suggested. I personally think that it would be easier to manage
fewer keys and use something very simple (like a large random
number) for message tagging, but this is just me.

Doug