Comments inline. On Feb 3, 2008, at 5:56 PM, Eric Rescorla wrote:
- If you use DTLS with AES in CBC mode, you have the 4 byte DTLS header, plus a 16 byte IV, plus 10 bytes of MAC (in truncated MAC mode), plus 2 bytes of padding to bring you up to the AES block boundary: DTLS adds 32 bytes of overhead, increasing packet size by over 50%. The IPsec situation is similar. - If you use CTR mode and use the RTP header to form the initial CTR state, you can remove all the overhead but the MAC itself, reducing the overhead down to 10 bytes with only 17% packet expansion (this is how SRTP works)
Depending on the lifetime of the keys involved, you can probably truncate the MAC tags much more than this. Using the RTP counter for use in some appropriate stateful MAC may mean a 3- or 4-byte tag is enough security. Additionally, in order to conserve bandwidth you might want to make a trade-off where some packets may be forged with small probability (in the VOIP case, that means an attacker gets to select a fraction of a second of sound, which is probably harmless), but it is hard to forge many packets.
In (http://eprint.iacr.org/2006/095), John Black and I treat this model in depth, and suggest a MAC scheme which may be most appropriate for this scenario. A stateful, highly-truncated HMAC will also work fine, but is slower than the scheme we propose.
Martin Cochran --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
