Correct me if I'm wrong, but isn't such a system feasible by: 1. Having the network infrastructure available to support the continuous traffic loads. 2. Having a suitable RNG source that can cope with the reseeding/etc requirements of encrypting bulk data. 3. Having a mechanism to insert genuine information into these massive streams of data.
I suppose the issue is communicating to the third party which part of the data contains the interesting stuff. From what Rabin is saying, it appears that the increased security is achieved by the third party not knowing what is important and what isn't. How you communicate this with your trusted third party is the problem. You can't simply send a transmission when a new section of interesting stuff is coming through, because then the evil folk can simply watch for the notification, then capture that section of the traffic. Perhaps you could send a transmission that says "in x bytes time for the next x bytes, is the next message". That would include some latency that the evil third party can't reliably interperet. But does that work for frequent transmissions? Seems interesting nevertheless. Nick -- Real friends help you move bodies. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
