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.
participants (2)
-
db＠Tadpole.COM -
lcottrell＠popmail.ucsd.edu