Gutmann Soundwave Therapy

[Eric Rescorla]

At Thu, 7 Feb 2008 10:34:42 -0500 (EST),
Leichter, Jerry wrote:
> | Since (by definition) you don't have a copy of the packet you've lost,
> | you need a MAC that survives that--and is still compact. This makes
> | life rather more complicated. I'm not up on the most recent lossy
> | MACing literature, but I'm unaware of any computationally efficient
> | technique which has a MAC of the same size with a similar security
> | level. (There's an inefficient technique of having the MAC cover all
> | 2^50 combinations of packet loss, but that's both prohibitively
> | expensive and loses you significant security.)
> My suggestion for a quick fix:  There's some bound on the packet loss
> rate beyond which your protocol will fail for other reasons.  If you
> maintain separate MAC's for each k'th packet sent, and then deliver k
> checksums periodically - with the collection of checksums itself MAC'ed,
> a receiver should be able to check most of the checksums, and can reset
> itself for the others (assuming you use a checksum with some kind of
> prefix-extension property; you may have to send redundant information
> to allow that, or allow the receiver to ask for more info to recover).

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.


> 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.


-Ekr

[PG01] Philippe Golle, Nagendra Modadugu: Authenticating Streamed Data in the Presence of
Random Packet Loss. NDSS 2001

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com