Dispatch Gets Feedback on Cryptography

Kanak Biscuitwala

From the outset of the development of Dispatch, our primary goal has been to protect the identities, content, and credibility of anyone using Dispatch to disseminate information. In cryptographic language, this means we needed to develop a protocol that would encrypt messages end-to-end to prevent snooping. Further, that protocol needed to support transmitting digital signatures so that the recipient could be sure that the message was unchanged during the transmission process.

Clearly, traditional cryptographic schemes like RSA support encryption and signature generation, and could serve as an underlying message encoding solution. Unfortunately, public keys are long strings of random bytes and are nearly impossible to communicate without relying on some form of digital transfer. In addition, both the sender and the recipient would be required to establish keys before any communication could take place.

Fortunately, a team of experts in cryptography developed a scheme called Identity-Based Cryptography (IBC) [1] that allows a participant to use an identity he owns (e.g. an email address, phone number, or social network username) as a public key for encryption and signature verification, provided that he can prove he owns the identity. Additionally, the Dispatch routing system allows queuing of messages sent to arbitrary identities; when a new user claims his identity, she is able to decode the messages sent to her. [2]

As we were evaluating the real-world feasibility of IBC, we quickly saw that, just as in the case of RSA, performance constraints would not allow us to directly encrypt and sign entire messages with identity-based schemes. For RSA, the typical workaround is to encrypt and sign a much smaller AES-CBC message key for each message. Then, the message key would allow for much faster symmetric key decoding of the message, while the verification of the signed message key ensures integrity.

For IBC-encrypted messages, however, performance constraints would even prevent per-message key decryption and verification. Thus, we added a second level of indirection to further improve performance. Using IBC, we encrypt and sign a conversation key that is unique between each sender-recipient pair; in fact, two such keys exist for the pair for each direction of communication. This conversation key is valid for subsequent messages sent and received in the same time frame that each user’s IBC secrets are valid; currently, we expire each user’s keys every 30 days. Therefore, on average, each pair of participants only needs to directly use IBC every 15 days. Each message has a new randomly-generated initialization vector (IV) to ensure that AES-encrypting the same content twice yields different encrypted data.

The conversation key encrypts three key components: the message hash, a sequence number, and the message key. The encrypted message hash was designed to ensure integrity because only conversation key holders would be able to encrypt and decrypt the hash, and IBC is needed to obtain a conversation key. Encrypting the message key ensures that the content remains unseen during transmission. Thus, to use the initial system, one would need to prove his identity to obtain his IBC secrets, use the secrets to encode or decode a conversation key for each new person with whom he wishes to communicate, and then for each message use the conversation key to obtain the message key to read the message. He also decrypts and checks the messages hash for integrity.

The full message format is below:

Though IBC has been well-vetted by the security community, our particular message format had only been informally checked. Thus, we contacted Justin Troutman, a well-respected independent cryptographer. Justin agreed that our scheme was sufficient for ensuring that messages are safe from unauthorized snooping. However, he pointed out that though encrypting a message hash may be sufficient for providing message integrity guarantees in practice, it is generally viewed as risky. AES-CBC is vulnerable to cut-and-paste attacks, so it is theoretically possible to construct content that correctly decrypts, but is not what the sender had created.

Though such attacks are likely infeasible in practice, we agreed that it’s much better to add integrity verification that has been mathematically proven to be reliable. Therefore, along with the conversation key, we also now transmit to each recipient an IBC-encrypted and signed HMAC key whose validity time period matches that of the conversation key. Then, for each recipient, the message includes a HMAC-SHA256 signature of the encrypted message body. A keyed hash of encrypted content provides IND-CCA2 /\ INT-CTXT, essentially a mathematical guarantee that forgery is infeasible.

With the latest changes, Dispatch users can be assured that cryptographic attacks cannot be used to allow unauthorized parties to view or forge messages. Combined with the existing cryptographic protections against snooping, the Dispatch message format is able to guarantee that messages will not be viewed or tampered with in transit.

Adding extra fields for integrity appears to have strengthened our position from a cryptographic standpoint. Certainly, there are security concerns requiring attention outside the realm of cryptography, and we will continue to work with security experts to improve our system in any way possible.

1. D. Boneh and M. Franklin. Identity-Based Encryption from the Weil Pairing. In CRYPTO 2001, 2001
2. T. J. Purtell, I. Vo, and M. S. Lam. A Mobile Social Network on ESP: an Egocentric Social Platform.

Posted in digital security news, dispatch news

Leave a Reply

Your email address will not be published.

Dispatch updates
Sign up here to stay updated on Dispatch:

On Twitter