[Asterisk-Users] Encryption

[Michael Sandee]

My first words, merry xmas to everyone...
And may your voip packets be safer in 2004 :P

All details supplied below might be subject to my complete retardness 
and incompetence because its early and I didn't have any coffee yet :)

Steven Critchfield wrote:

>On Wed, 2003-12-24 at 19:11, Mahoney, Matt wrote:
>  
>
>>Hi,
>>
>> 
>>Does asterisk support any kind of voice encryption?
>>    
>>
>
>Not right now. As I understand it, it is a problem with the fact that
>each packet would have to be able to be decrypted even if packets in the
>stream are lost. In the long run it is going to be a question of how
>secure do you need it to be. Afaik, the good encryption methods are
>stream based, and the loss of packets would kill the decryption. 
>
Most block and stream ciphers can recover from loss... And if you don't 
use block chaining, you have no loss at all... (but it's less secure, 
however this is always relative to what you try to protect) (With block 
chaining, you lose the next block)
(Afaik block ciphers are more secure, but well... i'm no cryptographer, 
nor cryptanalyst... or mathematician... or ...)

Things like plaintext attacks... are still possible... think about the 
same voice data going through an encrypted channel (even trunk), and 
then ending up on the sip phone of our attacker... or some unencrypted 
voice channel (sip, mgcp, etc)... so he then knows a part of the plain 
text of the encrypted trunk... possibly revealing some of the keys' 
info... possibly revealing all the calls over that trunk during the use 
of that exact key.
It is questionable how feasible such an attack would be, but this is not 
the question we should ask ourselves...

So, how would you encrypt a trunk? per channel? that would seem horrible 
considering you would need a key exchanged for each channel etc., and 
the overhead would go up quite a bit...

Would you want to use stream ciphers? (we have blocks of voice data? not 
much streaming in * to my knowledge)

Would you want to use a different key for voice and commands? 
Considering implementation... you will get even more overhead if you 
decide to stay backwards compatible with iax2, unless you do some really 
funky (ugly) things, which are prone to errors in the implementation.

>Add to that the problem of finding some encryption method that can deal
>with small packets without adding a lot of overhead. Each voice packet
>in IAX with GSM compression isn't very long. The voice data is only 33
>bytes. 
>

The overhead? Well the block ciphers come in 2 tastes... 64 and 128bit 
block sizes (mind you... block size != key size)
64: *DES, Blowfish, ...
128: AES, Twofish, ...

So with a blockcipher the overhead would be:
33 times 8 = 264 bits
64: 5 blocks = 320 bits = 56 bits overhead per packet
128: 3 blocks = 348 bits = 120 bits overhead per packet

(Yes, this is exactly worst case since you are 1 byte over the "exact 
fit" limit...)
(264 - 8 = 256)

These are just some of my thoughts, please don't pin yourself by just 
looking at the "best" cipher... which is considered to be AES-CTR 
(block) by many people... as you see it has 120bits of overhead when 
used with GSM... (If the 33 bytes figure presented before is right)
Cipher capabilities could be exchanged just like codec capabilities... 
and if a device (IAXy?) only happens to support plain AES... so be it, 
but please don't restrict the protocol to that :)

Michael