[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSec for IP Telephony
Paul,
The significant advantage of a stream cipher, operating in OFB or
counter mode, over a CBC mode is that in a stream-cipher the keystream
can be calculated in advance of the voice/video data being available
from the codec. This essentially eliminates the 3DES (or other
codebook) processing time from the latency equation (except for the
exclusive-OR of keystream onto the data, which is essentially zero
time). Since latency is a cumulative phenomenon, it seems such a
simple cryptographic mode alternative would have some benefit without
any negative consequences. If an implementer is trying to make a
low-cost, IPSec-compatible telephone using only a low-end DSP, using
this mode may reduce round-trip latency by 10 msec or so. While this
may not seen like much, every little bit helps, and the savings
essentially come for free.
Frank Costantini
Costantini,> Is the intent of the IPSEC community that secure IP
Costantini,> Telephony applications utilize 3DES in CBC mode for
Costantini,> encryption? Considering the extreme sensitivity that IP
Costantini,> Telephony has for latency, CBC mode is not a good choice
Costantini,> for a cryptographic mode for that application. Has a
Costantini,> stream-cipher mode of operation for delay-sensitive
Costantini,> IPSEC applications been defined somewhere?
I don't understand the point. Encrypting a packet will add some
latency, but I don't see any reason to prefer a stream cypher over a
block cypher when doing packet oriented processing. Sure, 3DES may be
slow in some implementations, but that's an implementation matter, not
a fundamental property.
If you were transmitting byte stream data, things might (or might not)
be different, but we're talking IP packets...
We've been doing some latency measurements and the numbers come out
well below what would be an issue for VoIP (or for that matter, way
below the wire delay for T1 never mind slower stuff).
paul