Comment Re:VOIP calls aren't encrypted? (Score 1) 112
I've scanned over the replies, and haven't seen this mentioned.
Don't assume that the difficult part of the "encryption" requires the plaintext. All you really need (and this is what GSM/UMTS does) is a way to "agree" on a psuedo-random number sequence. You can pre-generate that sequence (within certain constraints) and apply it by an xor to the plaintext. The receiving end does the same.
How do you agree on a psuedo random sequence? You run AES (or any block cipher) in one of its feedback/chaining modes. All you have to agree on then is the IV. Each frame sent from your phone is numbered in some manner. That number helps for packet ordering (I am not necessarily talking about IP header numbering) and also helps the receiver determine what pre-generated sequence to apply. In UMTS/GSM, that "number" is the count parameter and is part of the IV fed into the Rijandal (I doubt that is spelled correctly, sorry).
A pure voice call over POTS requires 64kbps (8bit PCM samples at 8khz sampling rate). A cell phone call requires around 12-15kbps to achieve reasonable voice clarity. The difference is achieved by a codec that takes the analog voice and encodes it into a fixed length vocoder frame. That fixed frame length allows me to pre-generate just enough pseudo random bits to apply "encryption". Note that each frame represents 20 (or so) ms of "speech". Loss of a single frame isn't going to kill you. I do not know the VoIP codec rate. They may even send a PCM stream to/from the VoIP "server".
sd_spot
Don't assume that the difficult part of the "encryption" requires the plaintext. All you really need (and this is what GSM/UMTS does) is a way to "agree" on a psuedo-random number sequence. You can pre-generate that sequence (within certain constraints) and apply it by an xor to the plaintext. The receiving end does the same.
How do you agree on a psuedo random sequence? You run AES (or any block cipher) in one of its feedback/chaining modes. All you have to agree on then is the IV. Each frame sent from your phone is numbered in some manner. That number helps for packet ordering (I am not necessarily talking about IP header numbering) and also helps the receiver determine what pre-generated sequence to apply. In UMTS/GSM, that "number" is the count parameter and is part of the IV fed into the Rijandal (I doubt that is spelled correctly, sorry).
A pure voice call over POTS requires 64kbps (8bit PCM samples at 8khz sampling rate). A cell phone call requires around 12-15kbps to achieve reasonable voice clarity. The difference is achieved by a codec that takes the analog voice and encodes it into a fixed length vocoder frame. That fixed frame length allows me to pre-generate just enough pseudo random bits to apply "encryption". Note that each frame represents 20 (or so) ms of "speech". Loss of a single frame isn't going to kill you. I do not know the VoIP codec rate. They may even send a PCM stream to/from the VoIP "server".
sd_spot
