Across the RedPhone architecture, there are three places where data is transmitted, and thus needs to be encrypted:

1. The standard signaling protocol. All signal-based communication with master and relay switches needs to be encrypted.
2. The compressed signaling protocol. Signals transmitted over SMS, C2DM, and GCM need to be encrypted.
3. The call content itself. Naturally, the actual call audio needs to be encrypted as well.

Encrypting the Standard Signaling Protocol

All communication between RedPhone clients and servers is encrypted using TLS. We do not use certificates signed by CAs, however. Instead, we have our own "CA certificate" that is distributed with the RedPhone client. Individual RedPhone servers have certificates that are signed by and validated against this "CA certificate," eliminating any requirement to trust CAs.

Encrypting the Compressed Signaling Protocol

These messages are encrypted using a very simple protocol:

Version     [1 Byte]   : A one byte version number.
IV (Random) [16 Bytes] : A random 16-byte IV
Ciphertext  [Variable] : AES-128 in CBC mode
MAC         [10 Bytes] : Hmac-SHA1 over the preceding bytes (encrypt-then-authenticate), truncated to 80 bits.

The AES and MAC keys are chosen by the client and transmitted to the server at registration time. These keys are static, do not provide forward security, and might be better implemented using a counter with keys that roll forward.

Encrypting the Call

The call is encrypted using SRTP. The key material is negotiated using ZRTP.