What Is the Signal Encryption Protocol?
wired.com
wired.com
Having spent a lot of time reviewing Signal and secure messaging applications as part of my job, I wanted to be able to explain how the protocol worked in the most educative way possible. feedback is welcomed :D
[1]: https://www.manning.com/books/real-world-cryptography?a_aid=...
[2]: https://livebook.manning.com/book/real-world-cryptography/ch...
What is the real-world impact of a weak Signal PIN code? Can a compromised Intel SGX process or the Signal server intercept our messages, if the PIN code is known?
>Perfect forward secrecy is useless, it's important to note, if users don't delete their messages periodically.
Then:
>The Signal app offers disappearing messages that are automatically deleted after a certain time limit.
Which is not turned on by default. The user has to somehow know that they have to do this to get the benefit of forward secrecy. This seems all too common with contemporary encrypted messaging stuff. Really great features that depend on having the users behave in a way they normally would not.
Of course the app can do this wrong simply by failing to do a secure delete that actually removes the messages from the storage device. In the end the actual communications protocol doesn't make very much difference in the face of counter productive implementations; conceptual and/or technical.
on Android you have to do it manually and its by no means easy or intuitive if you are an everyday user. Whatsapp nails this experience on Android with the back up and transfer capability
Note that Whatsapp’s backups are in plaintext and sent to a Google property, while Signal’s backups (even if more cumbersome to set up) are encrypted with a key that only you know.
I hope in 2021 Signal can improve their new transfer method by allowing transfers between Android devices or even ( albeit far more difficult) android and ios
The phones create their own ad-hoc Wi-Fi network, similar to Wi-Fi Direct.
The lack of good message backups on iOS makes me hesitant to recommend Signal more.
It's a horribly shitty user experience all but most mindful techies.
The issue with Signal is that their developers fundamentally don't value the content of conversations in the way that millions of other people do - people send photos of their loved ones, have meaningful conversations and they fundamentally care about not losing them. Signal developers think that that's all worthless and needs to be destroyed ASAP.
And no, it's not simple at all to provide this technology in a meaningful way that is both as secure as you need and as convenient as you want. Nor should it be free if it ever exists.
Why shouldn't it be free?
Another may be that texts are like emails for some people, and some people have reason to save important emails. I know a real estate agent that does a ton of stuff via text.
I delete texts after I process them. If I get a pic I want to keep I save it and back it up on the computer. I don't really save emails, either (I empty my trash every couple of months)
EDIT: added email comparison
I do completely understand archiving specific texts (sorry if this wasn't clear in my original statement), but the mass saving is weird to me. It feels akin to having a conversation with my friend and them just pulling out a microphone and recording our conversation. And then when asking why the answer is "for my records" or "it's my data". And I'm accused of being the weird one. I guess I just fundamentally don't understand.
I do think saving specific messages is the best solution. But you can even see in this thread that people compare Signal (i.e. text) to physical mail or email and that's why saving all messages is "normal." So... if we're mixing that paradigm then I think gmail is an acceptable answer to the question.
But the thing that gets me is that that kind of justification is more about "but it is normal because we've been doing x for a long time." But email and texting isn't that old. It is very new to the world. Even text being the primary form of communication is extremely new. We're all still trying to this all out too.
I have. In fact, over time I have searched my texts at least a dozen times for stuff that happened years ago. It might be links/references that I'm looking for or answers to questions like "When did Paul and I go to X?" and "When exactly did I meet Sara?" in which case Paul and Sara often don't remember the answer, either. Also, I have a dozen or so friends & acquaintances that I only get in touch with about once a year (mostly because they're living on the other end of the world) and, in this case, knowing what we last chatted about is a tremendous help in picking up the conversation where we left off. (Suddenly I magically "remember" that they told me they had started a new job.)
"Hey, remember when we went to $ski_resort last spring? What week was that in, the conditions were great!"
"Hey, did you request vacation time for next week half a year ago? $employer says he doesn't remember you asking that.."
"Hey, since grandma passed away we need to contact her brokerage.. she told you what it was when she signed up a few years ago, right?"
"Hey, you remember the date of our first date, right?"
Being able to search my old text messages is just as, if not more, important than being able to search my old emails.
[1] https://github.com/signalapp/Signal-Android/issues/1764 (2014)
We all have a need to amend our messages after ruminating on them for sometime. The three hour limit doesn’t gel well with how humans work (on this matter, even the HN edit limit duration is very short).
Once you've sent a message, the message is sent. Once it's on my device, it's mine. If you don't want someone to have a message, don't send it.
I think many people believe that if you create data it is your data. GDPR suggests that legally we lean towards this position as well.
There are arguments for addressing the power asymmetry in mass data collection. Those arguments do not extend to individuals communicating with each other, and they certainly do not extend to forcing those individuals to use technological measures that reduce the amount of control those individuals have over their own devices.
The program can not guarantee deletion, but in practice that is not necessary for it to be useful.
Protecting messages at rest at the source or destination is out of scope for perfect forward secrecy.
But if the attacker is a government or has otherwise compromised telco infrastructure, the attacker might already have copies of your old encrypted traffic -- which, without forward secrecy, it could use.
I think the context of the claim in the article is pretty much only for the "government physically seizes your phone and examines its contents" scenario: but even for that scenario, a user might choose to selectively delete specific messages without deleting all of them (e.g. Signal allows you to delete an entire "conversation" with a specific person).
So in this threat model, either way, we also need to look into whether Signal successfully overwrites the content and metadata of the messages it deletes on the mobile device storage, because the government attacker would use forensic tools to try to undelete that data. I don't know the answer to that.
Has anyone investigated the wear leveling of mobile device storage to see how bad/tractable this situation is at the moment?
>...they could then use the long-term key and traffic captures to decrypt the newer messages that weren't in the older backup.
I don't see how forward secrecy would change things for this situation.
The entire premise of encrypting the traffic passing over the network is that an attacker may have access to your traffic off the network.
> I don't see how forward secrecy would change things for this situation.
Suppose there is an attacker capturing all your network traffic, waiting for an opportunity to decrypt it. You backed up your phone in 2015. Then, today, the machine containing the 2015 backup of your phone is compromised, e.g. because you discarded it without sanitizing it. The attacker now has all of your messages from before 2015, because they're in the backup. But without forward secrecy, they also get all of your messages after 2015, because they could use the long-term key from the backup to decrypt all your captured network traffic. They would also get any messages from before 2015 that you had deleted prior to backing up your phone.
They would get all your messages after 2015 if they were willing and able to MITM the Diffie-Hellman handshake used in the forward secrecy scheme. Otherwise there would be no point in having long term identity keys in the first place.
Your example brings up an interesting point for me. Perhaps forward secrecy is more important in systems that trade off secrecy for convenience by failing to protect the private keys with a strong passphrase. In that case forward secrecy is more valuable due to the larger chance of a private key compromise. I guess the same point would apply to deniability as well.
So thanks for the discussion and generated insight.
If the master key was generated with a weak rng then the same would also be true for any ephemeral keys. That being said I doubt that any device capable of running signal is going to have a weak RNG.
Only the backup thing is possible but at this point the adversary can pretend to be you to your contacts anyway (and well, read your past messages). The easiest solution here is to not backup the signal directory.
Not all attackers are over the internet. Especially the ones who have had the opportunity to capture your past traffic, e.g. because they compromised your internet gateway, or have the ability to MITM you and may have used that ability to compromise other devices on your LAN or inject malicious javascript that could perform certain timing attacks from your own machine.
> But all of this does not matter because all modern protocols use algorithms that are safe from timing attacks.
New classes of timing attacks are discovered on a regular basis. Then existing implementations have to be hardened again. Moreover, it's generally not the algorithm itself that has to resist the attack. Sometimes it isn't even the cryptography -- Spectre can allow the attacker to read arbitrary memory from the address space of a vulnerable program, and the timing vulnerability doesn't have to be in the cryptography library, it could be in any part of the program.
> If the master key was generated with a weak rng then the same would also be true for any ephemeral keys. That being said I doubt that any device capable of running signal is going to have a weak RNG.
This is a thing that happened:
https://www.schneier.com/blog/archives/2008/05/random_number...
And even after they fixed it, so that ephemeral keys were no longer using the bad PRNG, the long-term keys generated with the bad PRNG were still in use by anyone not paying attention.
There are also degrees of brokenness. A bad PRNG may produce output that can be guessed but not inexpensively. The attacker may be willing to pay the high price once to crack the long-term key but not pay the same price for each of thousands of messages.
> The easiest solution here is to not backup the signal directory.
But then you don't have a backup of the signal directory when your phone falls into a wood chipper.
My personal view is that such a tradeoff comes down to the threat model of the individual user, and they should not be surprised by auto-deleting messages by default.
I mean, this is basically true of every feature in every product.
Consider the context in which Signal came of age - post Snowden mass surveillance. Signal has always prioritized fighting mass surveillance.
Getting individual devices hacked to recover its content is already outside of what I’d consider “mass surveillance”.
That is, even if you don’t use disappearing messages, you’re much less likely to have your conversations slurped up into some PRISM aggregator type machine by using an e2e communication channel like Signal, in part due to its forward secrecy capabilities.
That said - no harm in fighting targeted surveillance as well. Wether it be from a 3 letter agency, a phone thief, or an overzealous personal relationship.
I wonder if iMessage will feel compelled to up their game. They were early to the e2e game, for which they have my respect (they had their issues, I know), but will they put work into evolving their system? Or will they be happy being “second best” for default messaging privacy capabilities when privacy is so intricate to their marketing?
Anyway. This means moxie actually did a large part of what he set out to do. 2 billion users will use the signal protocol by default. No extra app install necessary. I have probably been the loudest "federate signal" whiner out there, but I feel rather stupid now.
One of the big innovations of the signal protocol, (called axolotl at the time) was that perfect forward secrecy, requires a handshake between participants before _each_ message, which is not compatible with the nature of async messaging, where the recipient might be (probably is) offline at the time of sending.
Instead Signal protocol does an eventual key ratcheting as soon as messages are round tripped between participants by essentially attaching half a handshake to each outgoing message.
edit: Signal protocol also has message deniability, future and forward secrecy. OpenPGP lacks these properties.
* A "double ratcheting" forward secrecy system, where message round-trips establish new DH keys, and message transmissions establish new symmetric keys.
* An authenticated key exchange --- "Triple Diffie Hellman" --- that provides deniability without having to publish spent keys, and works without needing a signature algorithm.
* A cryptosystem locked exclusively into modern misuse-resistant curves and AEAD cryptography.
By contrast, OpenPGP:
* Provides no forward secrecy (applications built on OpenPGP have to invent their own forward secrecy designs, which in practice nobody does).
* Relies on long-term keys.
* Uses a hodgepodge of algorithms, including outmoded cryptography from the 1990s; moreover, the compatible subset of PGP implementations depends on its nightmarish "MDC" hack, which was an attempt to retrofit message authentication into the standard.
Some of PGP's problems are due to the fact that Signal was designed at a time when we had far better understanding of cryptography, and, frankly, designed by better subject matter experts. But more of the problems are simply due to the fact that PGP isn't purpose-built for messaging; it's a general-purpose encryption tool, the "Awk" of cryptography, and one thing we're rapidly forming a consensus on is that you don't want Awk-like tools in cryptography engineering.
Signal rotates keys automatically; a good OpenPGP client would do the same (using the subkey support that the protocol has), but the UX for that is completely missing in most clients.
Signal has a much smaller protocol surface (fixed algorithms etc.) and has properly robust HMAC-style message authentication, whereas OpenPGP relies on a bolted-on MDC construction.
Downsides are that there's no web-of-trust support from the protocol (OpenPGP still requires you to agree what signing someone's key with a given trust level represents, but it gives you more tools to build your processes on), and that the (nominally untrusted) server's involvement is pretty complex (particularly in the first-message case) but tends to get left out of protocol analysis.
Later
I also dispute that subkeys are reasonably looked at as a forward secrecy feature. Most uses of subkeys, and virtually all of the tooling, are about having a hardware root of trust tied to shorter-term software keys.
A protocol where messages are both authenticated and repudiable is pretty confusing to ordinary people; in real life most forms of identity authentication (e.g. wet-ink signatures, government ID cards) are non-repuidable. In any case for ordinary people the whole question is moot, because actual in-practice repuidability relies on regularly publishing old session keys etc. in a way that ordinary people don't, because the UX is nowhere near good enough (and may never be).
> I also dispute that subkeys are reasonably looked at as a forward secrecy feature. Most uses of subkeys, and virtually all of the tooling, are about having a hardware root of trust tied to shorter-term software keys.
I don't see that there's any contradiction between that and the forward secrecy use case? A root of trust tied to shorter-term keys (that are destroyed in due course) is exactly what you need for forward secrecy.
Offline+subkey PGP is about enabling a root of trust that isn't exposed by exploits. Forward secrecy is about deliberately and frequently changing keys so that a point-in-time compromise can't be used to rewind all your previous communications. They are not the same thing. In particular: offline keys make it much harder to switch keys, which is exactly what you don't want. I don't think it's reasonable to suggest that the OpenPGP protocol contains the bones of a forward secrecy system --- it does not, it's just something people talk about grafting onto it.
Regarding deniable messages: the ability for an unrelated Mallory to confirm a message Alice sent to Bob is a vulnerability. It leaks a piece of information to the world that only Alice and Bob needed, and that both needed only for a brief moment in time. In the real world, nobody pays any attention to any of this stuff, which makes the vulnerability worse: non-repudiability is virtually always moot except in the circumstances where you need it not to exist.
Subkeys aren't exclusively about having your root be offline, that's just one use case. Yes, you can have a long-lived subkey and a super-long-lived root key, but you can also have short-lived subkeys and a regular-length root key; indeed to a computer there's very little difference between those timescales.
> Regarding deniable messages: the ability for an unrelated Mallory to confirm a message Alice sent to Bob is a vulnerability. It leaks a piece of information to the world that only Alice and Bob needed, and that both needed only for a brief moment in time.
That depends entirely on what Alice and Bob were doing and what their expectations were. If Bob received an authenticated message from Alice and expects to be able to prove as much, not being able to do so is every bit as big a vulnerability as any other.
What you're giving is a rationalization people use, to defend PGP and, recently, to argue that mail spool compromises are in the public interest, and should produce publicly verifiable logs. In reality, when Alice and Bob agree to produce verifiable, non-deniable messages to each other, they do so explicitly, not inadvertently, which is what is happening when your messaging system does that signing for you.
Wickr accounts are tied to nothing. And if you loose your phone you can just login again on any other phone to continue communicating.
That said, Signal plans to release non-phone identifiers, which I’m sure many are eagerly awaiting. I’m looking forward to it too, actually so I can use it to have my server message me instead of via Slack.
Sometimes it matters. Also, it doesn't always have to be some malicious thing. Could just be that there's a visionary executive with altruistic intents who convinced a higher-up that it's the right move.
But in the case of Signal, remember that it's a nonprofit. And in the case of whatsapp, it's looking more and more like the case above.
Also, besides marketing, reduced compliance costs. Once police etc. realize that you can't provide useful data, they stop asking.
Internally there was a lot of animosity towards the three letter agencies for tapping our lines, so part of the rational was sticking it to them.
Also, once you hire a security engineer for one thing they tend to be pretty vocal about other security issues. They can often stir up enough trouble that it's easier just to add the extra encryption.
Adding this encryption to Google's messenger was probably a couple person-years of effort. So, like, 0.00001% of the budget?
I guess I haven't been keeping up, but I did not know this.
Can you point me to a short documentary or document where I can learn more about what Google says it didn't know?
[1]: https://www.washingtonpost.com/business/technology/google-en...
And when dealing with proprietary software, we can't assume benevolence by default, ever. The most defenseless link in the chain, the end-user, needs do be defended.
At least until governments start implementing laws like Australia's Assistance and Access law, which compels companies to add back-doors on request.