Re: Broadcasts - addressing

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

>> 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.
>
>The main problem is how to avoid decrypting _most_ of the traffic,
>without giving away significant information about the recipient.
>One approach is to do something some political users have been asking for -
>implement support for very short keyids (e.g. 4 bits instead of 24-32),
>so that the keyid isn't a good identifier for the user.
>Another approach is to include a tag in the Subject: with either a hash
>of the key (substantially reducing the number of bits),
>or simply the last hex or two of the keyid - that lets you ignore
>15/16th or 255/256th of the traffic, without giving away much.


I am not completely clear on what sort of communication you are trying to
protect, and what your threat model is.

Are you worried about an attacker noticing that an anonymous ID is getting a lot
of messages? If you are using PGP and a message pool, any attacker can decrypt
all the messages, and see which correspond to which key, and therefor to which
anonymous ID. The only way around this is to use private key crypto. If you are
doing that, then you can also use a shared secret to generate a stream of one
use message IDs.
-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBLu09tlVkk3dax7hlAQHLkAP+L8j+9eLcwC7oPpq+OPxDb+C6QJ/H0OX5
3O7uQnU8OZY9YgHsMETh6AY7aTMZYrm9+p3wJu9znFYOwXRIzF+spfyxDDzLVuE1
kQBwGKQt/5YQd6i/jc1Jias6rb/GOBvckYcHKERjSBL638Gi65cC4OFEff5k6ujQ
YkkQXkh3JWg=
=o5nF
-----END PGP SIGNATURE-----

--------------------------------------------------
Lance Cottrell  who does not speak for CASS/UCSD
loki@nately.ucsd.edu
PGP 2.6 key available by finger or server. Encrypted mail welcome.
Home page http://nately.ucsd.edu/~loki/
Home of "chain" the remailer chaining script.
For anon remailer info, mail remailer@nately.ucsd.edu Subject: remailer-help

"Love is a snowmobile racing across the tundra.  Suddenly
it flips over, pinning you underneath.  At night the ice
weasels come."
                        --Nietzsche

> 
> I am not completely clear on what sort of communication you are trying to
> protect, and what your threat model is.

Let's say that agent-in-place X posts to his controller whenever
something of political significance happens in Foobarvia. A clever
traffic analyst will notice that a certain key posts to alt.anonymous
(or contributes to the pool, whatever it is) whenever something big 
happens in Foobarvia. Conclusions can be drawn -- there is a PGP-using 
spy in Foobarvia! By carefully limiting access to news tidbits, they
can use process of elimination to find the spy. (In reality, it could 
be much more mundane -- every time Peggy Sue tells Mary Beth a secret, 
there is a post by the same keyid, etc.)

However, if you use a public-key encryption scheme that doesn't store
the key-id on the outside of the packet (or store it at all), then you
are at liberty to identify the packets for decryption by the target
recipient however you want. I've suggested an approach using tokens,
which make all the messages from agent-in-place X unlinkable to one
another (thus hindering the detection of the aforementioned pattern),
while still allowing the recipient to sniff for them efficiently.

> 
> Are you worried about an attacker noticing that an anonymous ID is getting a lot
> of messages? If you are using PGP and a message pool, any attacker can decrypt
> all the messages, and see which correspond to which key, and therefor to which
> anonymous ID. The only way around this is to use private key crypto. If you are
> doing that, then you can also use a shared secret to generate a stream of one
> use message IDs.

Clearly this involves using something other than vanilla PGP, or
running some post- and pre- processing to delete and then add back
in the key-id. The mandatory external presence of the key-id has
always been less than optimal, IMHO.