Signal 2.0: Make Privacy an Ordinary Conversation

A private messaging system has at least two jobs. It must protect the message, and it must persuade two people to use the same system to send it.

The second job can look disappointingly mundane next to cryptographic protocol design. There are contacts to find, notifications to deliver and conversations to resume after a phone loses its connection. If those things are awkward enough, the protected conversation may never happen.

Signal 2.0, released for iPhone on March 2, 2015, brought TextSecure-compatible messaging together with private calls. Its announcement describes encrypted text, group, picture and video messages between Signal on iPhone and TextSecure on Android, using phone numbers and an existing address book rather than a separate collection of usernames.¹

That was a particular milestone, not Signal’s first appearance. The iPhone voice app had launched on July 29, 2014, with compatibility with Android’s RedPhone.² Android’s combination under the Signal name followed in November 2015.³

The important product achievement was to put private communication into the shape of ordinary mobile communication. The difficult part was that a familiar contact name could conceal an unfamiliar question about trust.

Where the protection begins and ends

Imagine Alice sending Bob a fictional message: Meet at seven. In a simplified end-to-end arrangement, Alice’s device protects the content before handing it to a delivery service. Bob’s device recovers the content after receiving it.

The delivery system has work to do even when it does not possess the conversation’s plaintext. It must accept something from Alice, arrange delivery and deal with Bob being temporarily unavailable. The endpoints have a different job: construct and interpret the protected message.

This boundary differs from protecting only the network connection between a client and a server. An encrypted transport can protect data while it crosses that connection, but the server may still receive readable content at the other end. End-to-end protection moves the relevant content boundary out to the participants’ devices.

For our example, a delivery envelope can be conceptually distinct from the note inside it. A service may need routing information to move the envelope. That does not make the note readable to it. Conversely, protecting the note does not by itself establish that every property of the envelope is hidden.

This is an architectural illustration, not a complete account of Signal 2.0’s wire fields or metadata exposure. The launch announcement establishes its end-to-end design proposition; it does not justify treating every observable aspect of communication as secret.

It also does not make the endpoints disappear. Alice sees the message before protection. Bob sees it after recovery. A compromised endpoint or an untrustworthy recipient is a different problem from somebody observing traffic between them.

A useful privacy explanation must keep those boundaries visible. Otherwise, a strong protection for one part of the journey becomes an implausible promise about the entire human situation.

Modern conceptual diagram, drawn in 2026. It distinguishes content protection from delivery; it does not reconstruct Signal’s 2015 packet format or prove metadata secrecy.

A contact label is not a cryptographic identity

Alice’s address book calls a number Bob. That label is useful. It is how she chooses whom to contact. It is not, by itself, evidence about a cryptographic key presented under that identity.

Here is an original teaching example using deliberately fake public-key stand-ins. Bob has an illustrative byte string bob-key-original. Alice’s client might be shown that same string, or it might be shown bob-key-replacement under the same contact label.

Compute a SHA-256 digest of each stand-in. The matching original strings produce the same digest. The replacement produces a different digest. The accompanying Python check confirms those equality relationships.

These strings are not usable public keys, and the check is not Signal’s fingerprint algorithm. It does not encrypt a message, validate a certificate, generate a secure identity or demonstrate resistance to an attack. It models only the distinction between a name attached to material and a comparison of that material.

That distinction is enough to expose the problem. If Alice and Bob can compare appropriate identity information through an independently trusted interaction, they have evidence that they are looking at the corresponding identities. If a third party controls both the supplied key and the purported comparison result, the second display adds little assurance.

The act of comparing therefore has two requirements. There must be meaningful information to compare, and the comparison must be tied to the person or device the participants intend to trust.

A recognizable name improves usability. An independently meaningful identity check improves a different property. Combining the two is a design task rather than a reason to pretend they are the same thing.

The comparison has a user interface

Signal’s November 2016 account of safety numbers describes the earlier fingerprint interface and the confusion users experienced when comparing separate identities. It explains the move toward one conversation-level comparison rather than two separate ones.⁴

The later date is essential. A current safety-number screenshot would be the wrong illustration for the March 2015 release. The article uses original diagrams instead, and the 2016 account supplies a clearly labeled later discussion of the problem.

The underlying usability issue is visible without copying either interface. Suppose Alice sees an identifier for herself and an identifier for Bob. Bob sees the corresponding pair. Comparing Alice’s own identifier with Bob’s own identifier is not the same operation as confirming that Bob has the correct view of Alice.

A person can understand the goal—make sure this really is our private conversation—while misunderstanding the arrangement of values on the screen. More cryptographic information is not necessarily a clearer explanation of what to do with it.

This is one reason the contact-list success and the identity problem belong in the same history. Removing unnecessary ceremony can make a secure system usable. Removing a meaningful distinction without explaining it can make the system’s assurances harder to judge.

Signal’s development had to negotiate both pressures. The aim was not to make everybody become a protocol engineer before saying goodnight. The meaningful trust decisions still needed a comprehensible place in the conversation.

Modern original model, drawn in 2026. SHA-256 comparisons use fictional strings and are not Signal fingerprints, safety numbers or encryption tests.

Messages do not always arrive in a polite order

Mobile communication also makes cryptographic state inconvenient. Bob’s phone may be disconnected. Alice may send several messages before he answers. A delayed message may arrive after a later one.

A protocol built around an orderly live conversation must account for those conditions if it is to work as ordinary mobile messaging.

Open Whisper Systems’ November 2013 ratcheting explanation describes the distinction between chain keys and message keys, and why keeping a delayed message’s key need not mean retaining material from which later message keys can be derived.⁵ This predates Signal 2.0 and explains part of its TextSecure lineage, rather than a new feature invented at the iPhone launch.

The useful general idea is to evolve key material while separating the ability to handle one delayed message from the ability to reconstruct a whole chain. A mailbox full of asynchronously delivered messages is a different operating environment from two clients maintaining one uninterrupted session.

This article does not attempt a security proof or substitute a homemade cryptographic demonstration for the protocol. The original fingerprint model tests equality only. Ratcheting’s security properties depend on the actual construction, implementation, key handling and assumptions.

Nor should forward secrecy be translated into a claim that a phone contains no readable message history. Limiting what a later key compromise reveals about recorded encrypted traffic is distinct from handling plaintext already present at an endpoint.

That distinction keeps an impressive cryptographic property from being asked to solve a storage problem it was not defined to solve.

Compatibility was a practical privacy feature

The March release’s interoperability mattered because a conversation requires at least two participants. An iPhone user could message somebody on Android’s TextSecure without waiting for both platforms to display the same application name.

The November Android announcement explicitly describes combining TextSecure messaging and RedPhone calling. Historical names therefore need to remain visible: the early cross-platform conversation was not initially a uniform installation of today’s app on every device.

The product’s familiar address-book approach reduced another coordination burden. Participants did not have to exchange a second set of account names simply to find one another in the system. The launch also advertised asynchronous delivery and push notifications, fitting ordinary interruptions in mobile availability.

These details are quieter than the cryptography but belong to the same achievement. A private channel unused by the intended recipient has failed at communication, even if its encryption is excellent.

Ease of use does not prove confidentiality, and a launch announcement’s absolute assurances should not replace an audit. It does establish what the developers were trying to make ordinary: choosing a contact, sending a message and coming back to a conversation without configuring a separate security project first.

Signal 2.0 helped join that ordinary interaction to end-to-end protection across the two major mobile platforms. Its history is most instructive when the separate jobs remain separate: deliver the message, protect its content, identify the intended party and maintain usable behavior when phones and networks are unreliable.

Alice can still choose Bob from an address book. The name is the beginning of the conversation’s trust story, not the whole of it.

Sources

Footnotes

1. Open Whisper Systems, “Signal 2.0: Private messaging comes to the iPhone”, March 2, 2015. Contemporary release scope and usability; absolute promotional privacy wording not adopted as an audited guarantee. ↩

2. Open Whisper Systems, “Free, Worldwide, Encrypted Phone Calls for iPhone”, July 29, 2014. Actual voice release distinguished from planned text features. ↩

3. Open Whisper Systems, “Just Signal”, November 2, 2015. TextSecure/RedPhone combination and rollout. ↩

4. Open Whisper Systems, “Safety number updates”, November 17, 2016, earlier-interface comparison and later design. Not a March 2015 UI specification. ↩

5. Moxie Marlinspike, “Advanced cryptographic ratcheting”, November 26, 2013. Contemporary simplified protocol account, especially chain/message-key separation; no security proof claimed. ↩