| So, this issue has been addressed in the broadcast signature context | where you do a two-stage hash-and-sign reduction (cf. [PG01]), but | when this only really works because hashes are a lot more efficient | than signatures. I don't see why it helps with MACs. Thanks for the reference.
| > 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". (If you record the data, the human being doesn't have to rely on memory - you can tell him exactly where things went south.) There are certainly situation where this isn't good enough - e.g., if you're telling a fighter pilot to fire a missile, a fake command may be impossible to countermand in time to avoid damage - but that's pretty rare. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]