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: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)
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.
(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
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
