Signal: The Pqxdh Key Agreement Protocol
signal.org
signal.org
- NIST pq candidates: https://blog.cloudflare.com/towards-post-quantum-cryptograph...
- Kyber in TLS: https://blog.cloudflare.com/post-quantum-for-all/
- Other candidates for TLS: https://blog.cloudflare.com/the-tls-post-quantum-experiment/
- For cert sigs (as opposed to kex): https://blog.cloudflare.com/sizing-up-post-quantum-signature...
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.
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*)
> 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
----------
- Crystal-Kyber: https://pq-crystals.org/kyber/data/kyber-specification-round... (pg 10 - 11; algorithms 8 & 9)
- NIST ML-KEM: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf (pg 30 - 32; algorithms 16 & 17)
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.
Note: not trying to start a discussion on how much one can trust facebook
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.
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.
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.
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.
That's quite a condition.
(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.
Good thing then that the Signal Protocol is repudiable? https://signal.org/docs/specifications/pqxdh/#deniability
When I switched to Signal, I stopped preserving my message history. I now have 4 week expirations on all chats by default.
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.
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.
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.
• relies on a centralized authentication server
• bans third party clients
• requires a phone number to create an account despite no longer supporting SMS
• marketing "Perfect Forward Secrecy" AKA "Forward Secrecy"[0].
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].
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.
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
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)!
Do you have a source for that? That has not been the case previously. Please see this thread: https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...
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.
The confusion surrounding this issue seems intentional (note https://old.reddit.com/r/signal/comments/htmzrr/psa_disablin...)
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
[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.
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.
> “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?
It's a bit of a mix of both!
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!
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.
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.
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.
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]
I push back when anyone recommends Signal because it is fundamentally not an open network.
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.
Third party clients really should be fully allowed too (even though they're not actually being banned so technically they're being condoned)
https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act
Sadly, they do get to choose what is considered "authorised" use of their service :(
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.
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.
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.
what do you mean by that?
Why wouldn't signal market a crypto property that is especially important in the context of a messenger app?
OTOH it's also probably read by most as meaningless hyperbole, so the actual damage from being misleading is probably minimal.