If you squint enough, what Signal's doing is similar to Kyber in TLS, which takes us back to KEM (like with RSA-OAEP in TLS v1.2 removed from v1.3) for key exchange (kex) with ECDH, in a pq safe way of course.
The link is a specification of the protocol, not a tutorial. It is intended to unambiguously state the operations, and requires significant background knowledge to be able to read correctly.
I guess if you're not already familiar with the Signal protocol specs, the current documentation might feel a little incomplete.
TLDR is, SS (shared secret) derived rom Kyber is mixed in to make the handshake, which outputs SessionKey (SK), pq safe. Note though, offline authentication (of identities) itself isn't pq safe (the authors plan to address this in the near future, however).
// CipherText (CT) and SharedSecret (SS) as outputs from Kyber
(CT, SS) = Kyber(PostQuantumOneTimePublicPreKeyBob)
// DH1, DH2, DH3, and optionally DH4 are Diffie-Hellman-Merkel outputs
SecretKey = HKDF-Signal(DH1 || DH2 || DH3 || *SS*)
// or
StrongSecretKey = HKDF-Signal(DH1 || DH2 || DH3 || DH4 || *SS*)
From Signal's PQ-XDH spec (section 4.11):
> Kyber hashes Bob's public (pre)key with Alice's random bits to generate the shared secret, making Bob's key contributory, as it is with a Diffie-Hellman key exchange. This does not reduce the dependence on Alice's entropy source but it does limit Alice's ability to control the post-quantum shared secret (SS). Not all KEMs make Bob's key contributory and this is a property to consider when selecting pqkem.
The pqkem (Kyber) happens 2 phases (1a & 1b below):
----------
Alice:
xx. recv(publickey)
0a. msg <- prng(256bits)
0b. random1, random2 = sha3-512(msg || sha3-256(publickey))
1a. ct = encrypt(publickey, msg, random2)
1b. ss = shake256(random1 || sha3-256(ct))
xx. send(ct); store(ss)
----------
Bob:
yy. recv(ct)
0a. msg' = decrypt(ct, privatekey)
0b. random1', random2' = sha3-512(msg' || sha3-256(publickey))
1a. ct' = encrypt(publickey, msg', random2')
yy. assert(ct == ct')
1b. ss = shake256(random1' || sha3-256(ct))
yy. store(ss)
----------
Both:
zz. sk = ss mixed with X3DH
zz. AEAD verify sk
----------
Has Matrix / Element had anything to say about this yet? How does their security compare? I don't trust Signal organizationally nearly as much now that Moxie has left, but I do trust their software and crypto design quite a bit more than most open alternatives.
I'm not a fan of moxie especially because of his hatred of federation (but luckily the EU is now enforcing this) but I don't think it's fair to say he cashed out.
The cryptocoin crap in signal was indeed a misstep but moxie didn't get rich from it. Signal is still paid for by donations and nobody even uses the payment stuff.
I'm not using it much because I want something open on both the software and network side, so I'm in favor of matrix all the way. Even if their E2E isn't quite as good yet.
My understanding of all DH based encrypted communication protocols is that they rely on some external authentication mechanism to ensure the public key of your counterparty is actually the right person. Is that correct?
In other words, if my friend is on the other side of the world and we can only communicate digitally, I need to bootstrap trust in a public key somehow and that is always outside these protocols. This is specifically called out here in section 4.1 and I'm pretty sure this is just a fundamental reality but I wanted to see if anyone had pointers to either a general proof of this or some kind of alternative.
I believe this is true not only for DH based protocols, but more generally for all protocols without any pre-shared data over an insecure transport.
Even quantum key distribution (QKD) is vulnerable to an active man-in-the-middle attacker.
With no pre shared data, and a protocol which doesn't give (trustworthy) guarantees about who you are communicating with, it seems impossible to actually know if you are establishing a key with the intended recipient or not. I'm not aware of any formal proof of this however.
Yeah, the core issue is really that you can't cryptographically prove which human being is holding the cell phone you're talking to. You can't tell if you're talking to Bob, or someone named Charlie who is pretending to be Bob. Charlie could then hire an accomplice to call Bob and pretend to be you so you'd both think you were talking to each other.
The threat model here assumes Charlie controls whatever mechanism you used to learn about Bob's phone number / public key / whatever, and that he can convincingly alter anything you say to Bob that involves checking whether you have the correct phone number / public key / whatever.
Certificate Transparency type solutions make it easier to compare notes about whose phone number / public key / whatever is whose, but Charlie can still (with enough effort and resources) defeat them by impersonating everyone you try to talk to about Certificate Transparency.
This attack has already happened in the wild apparently. I was speaking with a big company CISO a week ago who has just updated the runbook for their helpdesk to specifically introduce steps to mitigate it.
Apparently the state of the hack right now is attackers are only generally able to convincingly fake a short section of video (because they will have limited source material of the person they are spoofing) so will call say a helpdesk on zoom with the faked video playing and say they are experiencing connection issues so are turning the video off. From then onwards they just fake audio which is a lot easier.
The workaround/mitigation is for the service desk employee to insist at one or more random points in the call that the video has to go back on in order to do various additional authentication steps with video live. If the attacker has only built a short/shallow fake it will be very difficult for them to pass this.
If an attacker can perform discrete logs over EC, and a collision attack is found on SHA-3, then an attacker can encapsulate a malicious secret in Kyber, which when hashed with the 3 ECDH values force the session keys for communications with that attacker to be attacker-chosen values.
In the context of Signal, this means that in a case where an attacker would know the session keys anyway (being one of the parties to the handshake), if ECDH and SHA-3 are both broken, then the attacker could force the session keys to values of their choice.
Certainly there would be cases where this could be a problem, but in the case of Signal, the most disastrous attack I can think of would be maybe some kind of backward MitM attack where two users think they're both talking with the attacker, but they're actually talking with each other. C.H.A.O.S. gets the NSA and GCHQ on a chat where they both think they're trying to exploit C.H.A.O.S., and then when they accidentally exploit each other and establish a persistent compromise, C.H.A.O.S. goes in through the backdoors that the NSA and GCHQ have set up, quickly before either the NSA or GCHQ realizes they've exploited the wrong target?
Maybe an attacker colludes with a third party where they arrange encryption keys ahead of time, and then the third party could more easily eavesdrop on communications between the innocent user and the attacker. However, in that case, why doesn't the attacker just leak the session keys to the third party after the fact rather than agreeing beforehand? I could contrive some situation where you've got malware infiltrated into a very locked-down environment where Signal is the only communications channel back out of the environment, preventing two-way communication with the malware, but I feel we're getting pretty far into contrived situations there.
What am I missing? Yes, the proposed key derivation function ads negligible overhead and looks sound. All else being equal, it's strictly better to not allow the attacker to force the session keys to a attacker-determined values if both ECDH and SHA-3 are broken. However, in this context, the risks associated with a larger code change seem to outweigh the risks of an attacker being able to choose session keys, particularly as it seems a security proof of the proposed key derivation function still seems to be a work in progress.
If an attacker needs your specific signal messages, they wouldn't bother with trying to break encryption as the messages you type and receive are right there in plain text on your device.
(The software that captures your input and the software that writes to your display driver are typically not under your control)
As for large scale surveillance: Definitely an improvement that makes it much more expensive for attackers.
> If an attacker needs your specific signal messages, they wouldn't bother with trying to break encryption as the messages you type and receive are right there in plain text on your device.
They definitely can and do scrape Signal logs and use them in court. The protocol doesn’t help them prove the validity of the log, but they don’t need it to: it’s already not plausible to claim that you and your contact falsified your logs, something few people know how to do, in sync, in order to frame yourselves. I think Signal’s approach to deniability is just not making it even more hopeless, while the real protection against future compromise of a currently trusted contact or your own device lies in a different strategy that does work, ephemerality.
It's the use case that prevents me from recommending Signal to anyone I know.
Some people may not value that data, and may choose to deliberately throw it away; that's their choice. But it shouldn't get lost because of a lost or broken phone.
You can restore from Android to Android, and from iOS to iOS.
I don't think it's very often that people switch phone platforms, given the enormous switching costs engineered by Apple and Google to avoid competition on merit.
We are talking about restoring chat history in-app from one phone to another phone. The Signal app allows you to transfer its state (which you correctly note is not stored in backups) from Signal running on one phone to Signal running on a second phone on the same LAN.
The serialization (I guess) is different on iOS and Android so it only works between phones running the same OS.
A lost or broken phone does indeed render the chat history toast, however.
I value ma data, that's why I don't keep important information in random chats. But I digress. If you care about losing your history, the proper solution is backing it up, right? Signal does support that.
I favor Session Private Messenger[1] because it is decentralized and allows third party clients, but Signal enthusiasts warn me that the Session client may, hypothetically, at some future date, integrate a cryptocurrency, as the Signal client already does[2].
I feel like at this point, we can consider Signal the Mozilla of messaging: They deliver a desperately needed high-quality, open-source alternative to an oligopoly of sometimes secure but always closed-source competitors, yet we hold them to much higher standards than any of these.
Yes, Signal is (intentionally, i.e. as a stated design goal!) not federated, and I'm not super happy about it.
Yes, it includes a cryptocurrency nobody asked for, and I'm definitely not happy about that.
Yes, they've dared to dabble with trusted computing, and Intel SGX at that! (Although only in a purely-additive way, which I find really hard to disagree with, personally.)
But they have done so much for giving users a reasonable chance at evading the warrant-less wiretapping that is dragnet data collection.
Signal has pushed WhatsApp to become end-to-end encrypted by default, and that might have very well set the most important precedent for encryption-by-default in the recent past (see the UK's current legislation, and the EU's attempts of doing the same).
They're continuously pushing the envelope and are collaborating with academic cryptgraphic researchers on pq-safety, which will trickle down into all non-Signal users of the Signal protocol before too long (which includes WhatsApp and Facebook Messenger, making up for multiple billion daily users).
Yes, we should continue to hold them to a high standard, but I'd love if we could sometimes also keep things in perspective.
They also refuse to update their privacy policy, which lies when they say that signal is designed to "never collect and store any sensitive information". They're collecting and forever storing a list of all your contacts in the cloud, along with your name, phone number, and photo.
Considering too their very sketchy communication about that data collection and the confusion it's caused, I suspect that lie to be a canary warning people away from Signal.
If it isn't, and they're just misleading people about the risks of using their service while also advertising it to vulnerable people like activists and whistleblowers, I guess they failed to live up to my "high standard" of having ethics. In either case, all I can do is recommend that people stay the hell away from Signal.
If you want a Mozilla of secure messaging, try Jitsi or Jami
> They're collecting and forever storing a list of all your contacts in the cloud, along with your name, phone number, and photo.
The photo is part of your profile, which is only available to bidirectional contacts, as far as I know?
And getting visibility into everybody's phonebooks is really hard to avoid in a service like Signal. Yes, theoretically they don't have to automatically scan your entire phone book for Signal membership and could do that just in time when you are about to message somebody (and I believe you can actually use it like that if you just don't grant it phone book access).
But many users do actually like being able to see which of their contacts are reachable on Signal, rather than going by trial-and-error essentially forever, just in case one of their existing contacts did finally sign up in the end. Adoption also matters to keep a project alive.
As far as storing your contact list online goes, you can always opt out of that by not creating a PIN, or alternatively use a high-entropy one, which takes SGX out of the equation entirely if you don't trust it.
And for actual contact sync, Signal has been doing extensive non-SGX research on the topic (and used a bloom filter based solution for Redphone in the past!), and it's apparently just a really hard problem to solve trustlessly in a scalable way [1].
> I suspect that lie to be a canary warning people away from Signal [...] they're just misleading people about the risks of using their service while also advertising it to vulnerable people like activists and whistleblowers, I guess they failed to live up to my "high standard" of having ethics [...]
This is exactly what I mean. From what I can see, Signal sometimes takes non-conservative bets, but ultimately acts in good faith. That's a style not everybody has to agree with, but calling the entire effort harmful is just ridiculous to me.
I'm all in favor of having these discussions, but to some extent, I'm also concerned that when they bleed over into mainstream tech news (usually in a very lossy way thanks to shoddy reporting), it will confuse people even more or drive them towards less secure alternatives such as Telegram.
> If you want a Mozilla of secure messaging, try Jitsi or Jami
These are nice projects, but no. We're talking about a Mozilla-equivalent to Facebook (WhatsApp, Messenger) here, not Zoom (which Jitsi actually does quite nicely)!
> As far as storing your contact list online goes, you can always opt out of that by not creating a PIN, or alternatively use a high-entropy one, which takes SGX out of the equation entirely if you don't trust it.
Unless they've changed something recently, if you don't set a pin, one is created for you and all of your data is still uploaded and stored in the cloud. If you do set one, no matter what it's set to, your data is uploaded and forever stored in the cloud.
What's harmful is misleading vulnerable users about the risks they take by using Signal. Signal has a responsibility to make it very clear to everyone using their product what data is being uploaded to their servers and stored, and when that takes place. Signal promotes their app to people whose freedom, and lives may be at stake, so it's critical that those people are allowed to evaluate what using Signal could mean for them. They can't do that while Signal outright lies to them and provides misleading answers to direct questions.
> These are nice projects, but no. We're talking about a Mozilla-equivalent to Facebook (WhatsApp, Messenger) here, not Zoom (which Jitsi actually does quite nicely)!
What does facebook messenger do those those apps don't? They support voice and video calls, but also instant messaging, file sharing, screen sharing, group chat, etc
I might be out of the loop a little bit, but wasn't Telegram the first that offered E2E encryption[1] for the "general public" (at least it was very popular in Europe)? So, I feel attributing WhatsApp etc implementing E2E because of Signal is overselling it a bit.
[1] I know there was some controversy because someone (Signal, maybe?) accused them of using a custom encryption scheme that was poorly designed. I didn't follow that drama very closely, but given Telegram is still around and there hasn't been any outrageous news claiming its encryption getting cracked, I assume it was a mistaken claim.
No, Telegram was neither the first to offer end-to-end encryption (Signal started out as TextSecure in 2010), nor do they make end-to-end encryption the default.
Defaults matter.
> given Telegram is still around and there hasn't been any outrageous news claiming its encryption getting cracked, I assume it was a mistaken claim.
“Innocent until proven guilty” is for criminal systems, not security analysis.
And the controversy you are referring to, regarding unusual (to put it mildly) design choices in their E2E protocol is indeed very concerning, but the fact that Telegram by default is not end-to-end encrypted and stores all chat history server-side in a way that is accessible to its operators is undisputed.
Oh, you're right about it not being the default. I could've sworn it was the default way back when, but I might be misremembering. Also wasn't aware Signal rebranded.
> “Innocent until proven guilty” is for criminal systems, not security analysis.
Sorry if this sounds ignorant; I'm not a cryptanalyst/security researcher. Isn't this kind of the norm in the industry?
A few examples come to mind like hashing algorithms or encryption methods becoming obsolete over the years.
Was that due to the innocent-until-guilty mindset, or because computational power just overtook those standards?
At the low level, we unfortunately can't do much more than hope that certain fundamental mathematical/computational complexity assumptions hold. For RSA, that's the assumption that factoring prime numbers is hard; for AES, it's the assumption that it's really hard to invert the pseudorandom permutation a given AES key and the algorithm description represents. We don't have formal proof for these assumptions (or really hopes) being true; some even suspect that these proofs are fundamentally impossible.
In that sense, these really are assumed secure until proven otherwise (by counterexample). And one such counterexample to RSA, Diffie-Hellman and its elliptic curve variants are certain quantum computing algorithms!
However, at the high level, there is the concept of security proofs. These are formal, and in a nutshell they (often) work by mapping a new/unknown problem or solution onto a known one we've already proven some property of.
An example of that would be "if the decisional Diffie-Hellman assumption holds, running protocol x is a secure way of deriving a session key, and a passive observer can't derive the key themselves with non-negligible probability/without improbable resource expenditure" (obviously the actual formalism is much more involved).
In that sense, at the high level, there are positive security proofs, and this is the kind of work that the researchers working on Signal do. It's much harder than clobbering together a few low-level cryptographic primitives and hoping that they'll stick securely, but it's the best approach we have!
> includes a cryptocurrency nobody asked for, and I'm definitely not happy about that.
They created a centralized SGX based "cryptocurrency" and some not-publicly-identified person with a phenomenal amount of this entirely premined cryptocurency used the signal integration as a pump to steal a billion dollars from FTX's customers.
This isn't even equivalent to Mozilla integrating something widely used like Bitcoin at all... and Mozilla hasn't done that.
Even if you're utilitarian-consequentialist enough to see enabling/participating in a scam as a justifiable means to fund charitable efforts (like SBF) then you should still see that an encrypted messager with remote update ability really shouldn't be putting itself in a potentially exploitable position. "Ship this backdoor to these targets, or you get prosecuted for your cryptocurrency stunts".
The "Don't Break the Law When You're Breaking The Law" adage doesn't just apply to doing crimes, it also applies when you're doing stuff that powerful entities wished were crimes.
> (Although only in a purely-additive way,
I don't agree. Signal now uploads your contacts and other privacy relevant data to their servers, protected by nothing other than a trivial-to-bruteforce pin and SGX. They used varrious dark patterns to prevent any opt-out from the functionality. Their excuse for the acceptability of protection by trivially weak pins is SGX.
If they were streaming all session keys to the Chinese government protected by ROT13 would we say that it's okay that rot13's dubiousness is okay because its purely additive? No. Signal depends on SGX is a material way, and compromises user confidentiality with it even for users that have no interest in the marginal functionality provided by backing up that data to their servers.
The grandparent poster also missed many other problems with signal. For example, they actively block users from protecting themselves from rogue updates by timebombing every version. They undermined the ability for users to validate identities via other channels by making the comparison fingerprint process functionally pairwise unique (something which originally worked in signal). They've at various times made it extremely difficult to tell when a MITM has replaced your counterparty, e.g. by reencrypting and automatically resending when messages when the key changes (though I'm not sure if they backed off on that) and by noting a key change with a small grey message which the other side can scroll off by sending multiple times.
All that said I think signals weaknesses are kind of moot now in any case, because it no longer acts as an SMS app on android anymore it will likely fade out as more and more people fail to discover that the people they're communicating with have it installed. Signal is dead but it'll take a decade for the body to cool off.
Signal does not ban third party clients. I use a private fork of Signal Desktop every day and it works fine.
I know several others who operate Signal bots using API clients (in Java, IIRC).
They don't like it, but the ToS doesn't prohibit it.
We would consider it ridiculous if Google updated their ToS to say you must use Chrome to access google.com. I consider HTTP APIs of which I am a legitimate user to be the same; I will use whatever client I wish.
Well, they threatened LibreSignal with legal action, both for accessing their service and for using the Signal name, demanding that any third party client runs their own entire separate server network. Sounds pretty much like a ban.
That's a trademark (or perhaps trade dress) issue because it had "Signal" in the name.
They (the forkers) were stupid to induce brand confusion like that.
Signal is GPL free software; you can fork it and release it with any API URLs you like in the source or binary. It is perfectly legal to fork Signal and remove the user-hostile expiration timer, the image scaling enshittifier that happens on upload, and leave the signal.org API URLs completely unchanged. You just can't call it Signal (or LibreSignal, or BetterSignal, or ExtraSignal, or whatever) when distributing it.
The API ToS is what applies to end users who connect to the API. It says nothing about what software you are allowed to use to do so.
Signal would prefer to pretend that they get to choose what tools their users get to use to consume their service. Unfortunately for them (but good for us), they don't. It's the web and such a restriction would be insane.
Don't confuse software and services. They aren't the same.
This is so wrong. Signal is absolutely against third-party clients. Here's a quote from Moxie himself:
I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me. [0]
This is not saying anything about being open. This is talking about federation and stable protocols.
Both absolutly do hamper fast evolution of a product because they require a LOT of coordination and consensus, both of which are incredibly expensive and time consuming.
With a non-federated and unstable protocol, they are free to update and deprecated whatever they like and on a fast timescale. That is impossible with a federated stable protocol.
This has nothing to do with FOSS.
XMPP is a good example of a protocol that got fragmented to death by many many different and incompatible extensions, ultimately making it too fragmented and too slow to adopt to new requirements.
> Signal would prefer to pretend that they get to choose what tools their users get to use to consume their service. Unfortunately for them (but good for us), they don't. It's the web and such a restriction would be insane.
The reality is that most of Signal's popularity stems from them using phone numbers for initial authentication. Obviously there are people who can work without phone number, but the general population cannot. Or perhaps more correctly, will not. They'll just continue using a system that does.
>Obviously there are people who can work without phone number, but the general population cannot.
I think you're wrong in multiple ways. First, you are asserting a false dichotomy. Using phone numbers as one option for authentication in absolutely no way requires using them exclusively. To take a fairly large scale example, Apple's iMessage does not require any phone number. People can transparently use it with their phone numbers easily, but it will also work fine and always has with any email-based Apple ID. No telephone is required at all.
Second and more foundationally, we can objectively observe given the popularity of a range of online accounts using email or just user names (Facebook, Google, etc) that the general population is perfectly capable of working without a phone number. The UX might require more effort, and onboarding in some countries might be easier of course with phone numbers.
> but Signal enthusiasts warn me that the Session client may, hypothetically, at some future date, integrate a cryptocurrency
Session actually already does. It's just not exposed to the user because the OPTF foots the bill for it. But theoretically if the OPFT was to completely fold and Oxen & Session were to keep chugging along, you'd need to pay some minuscule per message fee for the service you are getting from the network.
The OPTF intends on footing the bill for basic messaging as long as they continue to exist but they probably will need to add some degree of user facing fees for video chat, etc in the long run if it ever seriously takes off.
Because lay users misunderstand "Perfect forward secrecy" as "perfect security". It's actively misleading when included in marketing material targeted at a lay audience.
OTOH it's also probably read by most as meaningless hyperbole, so the actual damage from being misleading is probably minimal.
I also hate the name, but its not like signal was the one who came up with the term. I somewhat think most marketing discussions of cryptography are highly misleading, although i suppose its reasonable to want signal to be better.
This is coming from Signal, who are more than qualified to do this kind of work. You shouldn't roll your own crypto. But crypto experts can do what they want.
it's good. think of it like adding a different kind of lock that requires a different key (method) to open up first. at worst it's no less secure than before. If it works as intended it's a huge disincentive for anyone collecting encrypted data with the hopes that a quantum computer may break encryption the "old" method in the future.
Just like the efficient market hypothesis presents a paradox of who actually makes the market, "don't roll your own crypto" keeps this question unanswered :)
Not sure if you're joking, but "your own" usually means "in isolation of both academic and applied cryptography" – and Signal has some of the world's finest of both working on their protocol, as evidenced by the multiple quoted academic papers.
