At Thu, 7 Feb 2008 14:42:36 -0500 (EST), Leichter, Jerry wrote: > | > Obviously, if you *really* use every k'th packet to define what is in > | > fact a substream, an attacker can arrange to knock out the substream he > | > has chosen to attack. So you use your encryptor to permute the > | > substreams, so there's no way to tell from the outside which packet is > | > part of which substream. Also, you want to make sure that a packet > | > containing checksums is externally indistinguishable from one containing > | > data. Finally, the checksum packet inherently has higher - and much > | > longer-lived - semantic value, so you want to be able to request that > | > *it* be resent. Presumably protocols that are willing to survive data > | > loss still have some mechanism for control information and such that > | > *must* be delivered, even if delayed. > | > | This basically doesn't work for VoIP, where latency is a real issue. > It lets the receiver to make a choice: Deliver the data immediately, > avoiding the latency at the cost of possibly releasing bogus data (which > we'll find out about, and report, later); or hold off on releasing the > data until you know it's good, at the cost of introducing audible > artifacts. In non-latency-sensitive designs, the prudent approach is to > never allow data out of the cryptographic envelope until you've > authenticated it. Here, you should probably be willing to do that, on > the assumption that the "application layer" - a human being - will know > how to react if you tell him "authentication has failed, please > disregard what you heard in the last 10 seconds".
Well, since there's a much simpler procedure accept ~5-10% overhead, this doesn't seem like a particularly attractive design. -Ekr --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]