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. Also: *) 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 email@example.com http://www.metzdowd.com/mailman/listinfo/cryptography