Gutmann Soundwave Therapy
Eric Rescorla
ekr at networkresonance.com
Thu Feb 7 16:24:54 EST 2008
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 majordomo at metzdowd.com
More information about the cryptography
mailing list