With VoIP, signaling encryption and media encryption use two different keys. If you have the first, you do not have the second. This is difficult to understand without reading the SIP protocol (RFC 3261) and very few writers of blogs talk openly about it because most people outside of the niche of VoIP only care about HTTPS as the "secure protocol stuff" and stop there.
Here's the trick: SIP has nothing to do with sound or video. It "establishes sessions". The typical SIP dialog flow has a hierarchy of many other protocols. In order, they read like this
SIP->TLS->SDP->ZRTP->SRTP
That dude in the middle is the Session Description Protocol. This describes what will happen in the future regarding the media stream. When the clients agree on this (codecs, IP addresses, ports, etc), a full-duplex session is established between the two peers. The preceding TLS stuff, which depended on a CA is now over. We are ready for round two.
This is what you missed. We haven't even begun sending data over our media socket yet and the security stuff that depends on a central authority is finished.
Now that we can speak to each other, let's do that! But wait! My client has an alpha numeric string on the screen. This is called a Short Authentication String. When you read the SAS to me and I read mine to you, we click "OK" and now our conversation is encrypted. Because we agreed on a key with our words, not our fingers.
If you would like to try this IRL, you can call [email protected]. I'm online right now.
Regarding signalling encryption. The system uses SIP TLS with a certificate signed by a common CA. Check it out and walk up the chain manually if you're concerned. Certificate pinning is interesting but in this case the signalling isn't really what we care about, from a priority perspective. We care about the /content/ of the call, which in SIP land is a completely different protocol with a nice peer to peer key agreement system which is currently unbreakable according to public information. There's some classified NSA doc that allegedly says it could be done, read all about it...oh wait, you can't because it's classified. :(
So the reason there isn't a bunch of copywriting which discusses the importance of the key agreement in the signalling layer is because I don't think it's very important. Now, one could middle the signalling in a clever way and that could, possibly result in a dropped call, which could be classified as a DoS vuln. But that's unlikely and there wouldn't be any content leaked. I would be interested in a proof of this attack vector.
Finally, my favorite part about middled signalling is that even if you do it right and a whole forged SIP dialog is built up and Mallory answers on the other end when Bob thinks he's talking to Alice, you still get to hear Mallory's voice! So unless Mallory is pro at doing voice impressions, like that dude on SNL can do Jay-Z and Dr. Dre real good, it's gonna be obvs that something is not right.
Really Finally, I'm using Freeswitch to provide diagnostic services like an echo test. There's some crazy ideas about offering an IVR that does encrypted voicemail but I don't know much about that.
Some written music can be interpreted in extremely different ways, in performance, especially if the original composer and performers of the era are no longer living. Listen to Glenn Gould play Brahms B minor rhapsody and compare it to any other performance, then compare that to another random performance, say Arhtur Rubinstein.
As for the question, all music needs an audience for a really good performance. It makes a huge difference and helps in so many ways.
I'm confused by the OP's use of the word "Bitcoin currency". Did you mean to say "Bitcoin exchange between EUR and BTC"? I suspect the peeps in Cyprus are def dumping some cash into BTC already. So they probs already know about that currency.
Here's the trick: SIP has nothing to do with sound or video. It "establishes sessions". The typical SIP dialog flow has a hierarchy of many other protocols. In order, they read like this
SIP->TLS->SDP->ZRTP->SRTP
That dude in the middle is the Session Description Protocol. This describes what will happen in the future regarding the media stream. When the clients agree on this (codecs, IP addresses, ports, etc), a full-duplex session is established between the two peers. The preceding TLS stuff, which depended on a CA is now over. We are ready for round two.
This is what you missed. We haven't even begun sending data over our media socket yet and the security stuff that depends on a central authority is finished.
Now that we can speak to each other, let's do that! But wait! My client has an alpha numeric string on the screen. This is called a Short Authentication String. When you read the SAS to me and I read mine to you, we click "OK" and now our conversation is encrypted. Because we agreed on a key with our words, not our fingers.
If you would like to try this IRL, you can call [email protected]. I'm online right now.