On 10/10/2013 02:20 PM, Ray Dillinger wrote:

> split the message stream
> into channels when it gets to be more than, say, 2GB per day.

That's fine, in the case where the traffic is heavy.

We should also discuss the opposite case:

*) If the traffic is light, the servers should generate cover traffic.

*) Each server should publish a public key for "/dev/null" so that
 users can send cover traffic upstream to the server, without
 worrying that it might waste downstream bandwidth.

 This is crucial for deniabililty:  If the rubber-hose guy accuses
 me of replying to ABC during the XYZ crisis, I can just shrug and 
 say it was cover traffic.


*) Messages should be sent in standard-sized packets, so that the
 message-length doesn't give away the game.

*) If large messages are common, it might help to have two streams:
 -- the pointer stream, and
 -- the bulk stream.

It would be necessary to do a trial-decode on every message in the
pointer stream, but when that succeeds, it yields a "pilot message"
containing the fingerprints of the packets that should be pulled 
out of the bulk stream.  The first few bytes of the packet should 
be a sufficient fingerprint.  This reduces the number of trial-
decryptions by a factor of roughly sizeof(message) / sizeof(packet).

>From the keen-grasp-of-the-obvious department:

*) Forward Secrecy is important here.

The cryptography mailing list

Reply via email to