Quote from: kmfkewm on October 26, 2012, 11:07 pmQuote from: bon qui on October 26, 2012, 03:47 pmJust use a prepaid. This reeks of hushmail.h, Encrypted voice is certainly far better than nothing, but all kinds of fingerprinting attacks can gather information from encrypted voice streams. The CIA has been able to identify the language being spoken for some years now, even when the actual voice content is encrypted. There are also attacks that can pick out entire phrases and words through the encryption. This is because different languages / sentences create different interpacket timing characteristics that can be fingerprinted, and encryption doesn't hide the time delay between various packets of voice data. To protect from this sort of attack you will need to pad the voice data stream. I take it this is different from the attacks described on Phil Zimmermann's Zfone project homepage, where he advised people not to use variable compression codecs? QuoteQ: What if I use a Variable Bit Rate (VBR) codec? Won't that leak information?A: Johns Hopkins University researchers have observed that when voice is compressed with a variable bit-rate (VBR) codec, the packet lengths vary depending on the types of sounds being compressed. This leaks a lot of information about the content even if the packets are encrypted, regardless of what encryption protocol is used. We strongly recommend that you avoid using VBR codecs if you want to make a secure phone call. Most codecs are not VBR, so it's not hard to avoid using VBR. If you plan to use Zfone with a VoIP client, open the preference panel in the VoIP client and disable the VBR codecs from the menu.Some codecs have a VBR mode and a non-VBR mode, so you should disable the VBR mode. If you are the implementor of a VoIP client, you can disable the VBR feature while still allowing the codec to be used. But if you are the end user, most VoIP clients do not have preference panels that allow such fine granularity of control, so you will be lucky to be able to just disable the whole codec. Some VoIP clients don't allow the user any choice at all about what codecs are used.Some safe non-VBR codecs include GSM 6.10, iLBC, G.711 (A-LAW, u-LAW, and PCMU), G.722, and G.726. It's not a problem if the codec adapts the bit rate to the available channel bandwidth. The dangerous codecs are the ones that change their bit rate depending on the type of sound being compressed.Skype's VBR codec leaks information regardless of the quality of the encryption, which may allow phrases to be identified with an accuracy of 50-90%.Let me be clear about this leakage of information-- it doesn't leak any cryptographic key material, and it doesn't help the attacker actually break the crypto. The VBR codec is leaking information about the content of the voice packets, because some sounds compress more than other sounds. By looking at how much each packet of sound was compressed, which can be inferred by the packet size, it is possible to infer something about what kind of sound it is, like a vowel, or a sharp consonant. This undermines the usefulness of the encryption. Some phrases can be identified with an accuracy of 50% to 90%. This is a serious vulnerability.Fortunately, not too many codecs use VBR. Speex has a VBR-capable codec, and some VoIP applications that use Speex allow the user to choose which codecs to enable. iSAC is a commercially licensed VBR codec, used by Skype, Google Talk, and Gizmo. This means that Skype is vulnerable to VBR leakage regardless of the quality of Skype's built-in crypto. Sadly, this also means Gizmo and Google Talk are not the safest VoIP clients to use with Zfone. And it appears the user cannot disable the use of this codec in those products. Microsoft's RT Audio also appears to be a VBR codec, and is used in Microsoft Office Communicator.It also appears that voice activity detection (VAD) leaks information about the content of the conversation, but to a far lesser extent than VBR. This effect can be mitigated by lengthening the VAD "hangover time" by about 1 to 2 seconds. That would sharply reduce the information leakage, but it may be something that only the VoIP application developer can do, if the VAD parameters are tunable. For an end user, a simpler solution would be to avoid the use of VAD, if this is feasible in your situation. Examples of codecs that use VAD include AMR and G.722.2. If it's not convenient to avoid all VAD codecs, keep in mind that the leakage from VAD is much less than the leakage from VBR.Some researchers have suggested that the VAD hangover time should be lengthened by a random amount. For example, a random normal distribution over the range of 1 to 2 seconds. Most codecs that use VAD only allow a fixed amount of VAD hangover to be easily configured. It remains unclear whether a random hangover time is worth the extra effort. This requires further research.Source: http://www.zfoneproject.org/faq.html