Gutmann Soundwave Therapy

[Eric Rescorla]

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