
How the Textsecure Protocol Works - LForLambda
http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html
======
sdrapkin
An important part of the Signal Protocol is Triple-DH. I did not find a good
illustration of how it works, so I made one:
[https://twitter.com/sdrapkin/status/738419956371628033](https://twitter.com/sdrapkin/status/738419956371628033)

------
Canada
This post doesn't explain the protocol all that well.

This is a great explainer:

[https://vimeo.com/117532499](https://vimeo.com/117532499)

I can't seem to find the PDF of the slides of this talk anymore.

These are also very useful for understanding:

[https://whispersystems.org/blog/advanced-
ratcheting/](https://whispersystems.org/blog/advanced-ratcheting/)

[https://whispersystems.org/blog/private-
groups/](https://whispersystems.org/blog/private-groups/)

[https://github.com/trevp/double_ratchet/wiki](https://github.com/trevp/double_ratchet/wiki)

~~~
binaryanomaly
PDF of the talk can be found here:

[https://deepsec.net/docs/Slides/2014/TextSecure_and_RedPhone...](https://deepsec.net/docs/Slides/2014/TextSecure_and_RedPhone-
bring_them_to_iOS_-_Christine_Corbett.pdf)

------
jlgaddis
Is there any information available (or has there been any analysis done) on
the quality of any random number generators in use on mobile phones,
especially Android and iOS?

------
Zhenya
Since What'sApp uses textsecure, can we be sure that they are blind to the
content of our messages? Is there any way for them to get the key, still claim
it's e2e encrypted, except for when they want to hand the key over to various
states etc?

~~~
FabHK
\- we don't have access to the source code, so who knows what they have
implemented?

\- even if they have implemented it faithfully, you should compare
fingerprints. If they don't line up, you might be subject to a MITM attack

~~~
tptacek
1\. Anyone who can read a control flow graph.

2\. Yes.

~~~
ChoHag
I just love reading post-optimisation machine code.

~~~
stouset
The point was _you_ don't, but plenty of people do. And those people haven't
sounded the alarm on any red flags.

~~~
verbify
We had access to openssl code, and yet heartbleed happened.

~~~
niftich
It's about incentives. The heartbleed bug was present in the code for almost
two full years before someone who discovered it exercised responsible
disclosure. It's possible that others have noticed it before this, but it's
highly likely that the only people looking were security researchers, power
users (like Google, the ones who first reported it to the authors), or actors
looking to exploit it for their own agenda.

As it stands, average people (or average developers) have little incentive to
go trawling through the existing body of open source code, mostly because they
probably have better things to do with their time. In the commercial world,
bug bounties attempt to skew the incentives to encourage the 'more eyes' part
of the axiom 'given enough eyeballs, all bugs are shallow'.

~~~
verbify
Granted Heartbleed was only exploitable for a few years, but Shellshock was
available since '89

And I'm pretty sure bug bounties would apply to shellshock and heartbleed as
long as you can find a company with a bounty program that also used openssl or
could be exploited via bash.

------
theduckling1883
Nice overview. I only wish for there to be an implementation of the signal
protocol that fits my needs. In WhatsApp and Allo there are concerns of ad
companies using your metadata, and the Signal app is lackluster in the UX
department and OWS's affinity with Google is rather disappointing also.

~~~
FabHK
Wire seems fairly fully featured, open source, and claim to have a feasible
"freemium" business model, i.e. later selling premium services on the
platform.

They claim they use the Axolotl double ratchet, though Moxie/OWS claims Wire
uses a variation of the protocol they don't recommend.

~~~
oakwhiz
I would be interested to know exactly what it is about Wire that OWS doesn't
seem to approve of

~~~
eatbitseveryday
> Wire does not use Signal Protocol, they used some of our code to create a
> protocol of their own devising that we do not recommend.

4 days ago, no follow-ups to questions for details.

[https://news.ycombinator.com/item?id=12688012#12690148](https://news.ycombinator.com/item?id=12688012#12690148)

------
Arathorn
isn't the "double ratchet" describing the presence of both a DH ratchet as
well as a hash ratchet, rather than "send" and "receive"?

~~~
Natanael_L
Triple DH + the double hash ratchet makes up two of the big (separate) parts
of the crypto in the protocol. One does key exchange, the other does per-
message PFS.

------
ChoHag
> Instead, copies of the server's role in the key negotiation are stored by a
> centralized server for potential clients to fetch and use. This

"centralised" and "server" are just about the worst words you want to hear in
the description of a system like this and yet they are just thrown in there in
a flippant comment at the end of a section?

I think a more detailed description of this glorified cache is warranted.

~~~
detaro
The server role seems quite clearly described in more detail in the actual
protocol description, is there something missing? The section you quote just
describes the high-level idea of why and how to introduce the server in the
scheme.

~~~
ChoHag
No. If the section beginning "Protocol" is what you refer to as the "actual
protocol description" then no, the server role does _not_ seem clearly
described in _any_ level of detail.

To cut a long story short: Alice gives the cache, aka Mallory, a set of secret
data which are implied but not proven to be able to be used by Bob to create
cryptographic text which Alice can decrypt but this magic cache, _aka Mallory_
, cannot. This document provides few hints and no detail on how we can be
assured that the magic cache, _A.K.A. MALLORY_ , is unable to make use of the
secret data provided by Alice (and "promised not to be shared") to make
inferrences on the crypyographic text provided by Bob.

~~~
dfox
The cache contains ephemeral _PUBLIC_ keys, that would otherwise be
transmitted to anyone who requests them by the message recipient (perhaps
through some encrypted channel, but without meaningful authentication). In
essence it's the same thing as PGP's encryption subkeys, which are completely
published, but the cache contains more of them as the keys are preferably only
used once (there is one difference in that the cache gives only one key at a
time and will not give the same public key again as long as it contains enough
of them).

So: making the whole thing completely public only enables adversary to match
session initializations with receivers, which the server can do by definition
as it has to route the messages to correct recipient. (In the case without
such central server, anybody observing the traffic could do that, as another
role of the central server is to mask sender addresses on the lower protocol
layers)

~~~
ChoHag
Good! Say that! Then the entire protocol and its description can be reduced to
"this is a cache of ephemeral public keys and messages encrypted using them".

I know that doesn't sound quite so impressive, but that's because it isn't.

~~~
dfox
Cryptographic protocols are not supposed to be impressive. But on the other
hand your shortened description describes the main difference between Signal
and traditional OTR, it does not describe how the protocol works after you get
the ephemeral key of the receiver.

Additional and to some extent non-trivial difference from traditional OTR is
in how these ephemeral keys are used in key exchange, whose result depends not
only on DH with ephemeral keys but also on DH exchange that mixes ephemeral
keys with long term ones. This causes that the ephemeral key of the passive
side does not have to be signed and allows anyone to produce arbitrary session
transcripts, both of these points allow significant reduction of size of the
exchanged messages.

~~~
ChoHag
That was made apparent in their documentation.

Or would have been, if they had any.

