[Asterisk-Dev] proposal for channel driver

[Michael Sandee]

>
>
>> e. add on aes for security ?
>
>
> This could be added to IAX2. However, it will add significant latency 
> if you wish to be able to cope with dropped packets vaguely elegantly. 
> AES is a stream cipher. If you miss a chunk, it will invalidate the 
> rest of the decrypt. Of course, you can encrypt each packet 
> individually (not the audio stream itself) but that would seriously 
> weaken the encryption. This is relative - it'd probably good enough 
> anyway. :)


This is wrong, AES is not a stream cipher. AES can work on single byte
streams... but it can also work as a block cipher (more secure
actually). You will have to encrypt each IAX packet as a whole... and
you miss some point in network layering regarding the added latency.

ECB will have no problem in recovering from packet drops, but is less
secure. CBC and CTR for example, with the last one used in SRTP iirc,
have problems with recovering and will take 1 block (128bits in AES) to
recover. The latency is only a problem for the reliably transmitted
packets, and noone cares about a few extra ms there... With CBC/CTR
drops will be twice more audible since two voice frames are dropped
instead of one...

I will pick up this occasion again to note that using a fixed crypto
cipher such as AES in CTR mode is extremely retarded... if someone
manages to crack AES in general (or just CTR) in a while, you will have
to redistribute the entire protocol stack in all devices... while it
could be just a matter of "disallow=aes-ctr" with a decent
implementation. (Lets not discuss the likelyhood of this, just the
possibility... and learn from the... "You HAVE to support DES" nonsense
in IPSec)

Regards,

Michael Sandee