1994-12-13 - Re: Broadcasts - addressing

Header Data

From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
To: db@Tadpole.COM
Message Hash: 0cbfcd520660aaecaced97daf10c21a750bb2ad93ad2ba7a31d4fd48665517e1
Message ID: <9412122353.AA08749@anchor.ho.att.com>
Reply To: N/A
UTC Datetime: 1994-12-13 04:04:52 UTC
Raw Date: Mon, 12 Dec 94 20:04:52 PST

Raw message

From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Mon, 12 Dec 94 20:04:52 PST
To: db@Tadpole.COM
Subject: Re:  Broadcasts - addressing
Message-ID: <9412122353.AA08749@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain


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





Thread