[HN Gopher] Signal: The Pqxdh Key Agreement Protocol
___________________________________________________________________
Signal: The Pqxdh Key Agreement Protocol
Author : thunderbong
Score : 211 points
Date : 2023-09-22 11:02 UTC (11 hours ago)
(HTM) web link (signal.org)
(TXT) w3m dump (signal.org)
| RunSet wrote:
| Still:
|
| * 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].
|
| [0] https://en.wikipedia.org/wiki/Forward_secrecy
|
| [1] https://getsession.org
|
| [2] https://www.stephendiehl.com/blog/signal.html
| tcfhgj wrote:
| > * marketing "Perfect Forward Secrecy" AKA "Forward
| Secrecy"[0].
|
| what do you mean by that?
| bawolff wrote:
| Indeed this is a bizarre criticism.
|
| Why wouldn't signal market a crypto property that is
| especially important in the context of a messenger app?
| jacoblambda wrote:
| > 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.
| nebulous1 wrote:
| > * relies on a centralized authentication server
|
| 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.
| xoa wrote:
| > _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.
| sneak wrote:
| 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.
| kuschku wrote:
| 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.
| sneak wrote:
| 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.
| Evidlo wrote:
| 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]
|
| 0: https://github.com/libresignal/libresignal/issues/37
|
| I push back when anyone recommends Signal because it is
| fundamentally not an open network.
| exitheone wrote:
| 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.
| greyface- wrote:
| Moxie isn't CEO anymore. Has Meredith made any statements
| on third party clients since taking the reins?
| kuschku wrote:
| > 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.
|
| https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Ac
| t
|
| Sadly, they do get to choose what is considered
| "authorised" use of their service :(
| [deleted]
| [deleted]
| ComodoHacker wrote:
| Please can we refrain from arguments like "this is from the
| same people I don't like because ..."?
| lxgr wrote:
| 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.
| spoiler wrote:
| 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.
| lxgr wrote:
| 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.
| exfil wrote:
| "Don't roll your own crypto..."
| minroot wrote:
| [dead]
| josephg wrote:
| 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.
| inp wrote:
| Yes, and moreover, they just add a shared secret in the
| computation of the initial root key, it cannot be worse in
| this case.
| zx8080 wrote:
| What could go wrong
| flangola7 wrote:
| Is that good or bad?
| 7v3x3n3sem9vv wrote:
| 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.
| HumanOstrich wrote:
| If this is always true, then where does crypto come from?
| omginternets wrote:
| I believe a stork installs the crypto package for your
| favorite language.
| lxgr wrote:
| 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 :)
| lxgr wrote:
| 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.
| niel wrote:
| Previous discussion about the blog post announcement, including
| speculation about timelines:
| https://news.ycombinator.com/item?id=37571919
| popol12 wrote:
| And yet I still can't back up or transfer my message history out
| of my iPhone/to Android. Priorities.
| sneak wrote:
| I don't think this is a very common use case.
|
| When I switched to Signal, I stopped preserving my message
| history. I now have 4 week expirations on all chats by default.
| JoshTriplett wrote:
| > I don't think this is a very common use case.
|
| 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.
| taway1237 wrote:
| 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.
| sneak wrote:
| It does not, at least not on iOS.
| sneak wrote:
| 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.
| adastra22 wrote:
| Message history isn't saved in backups. Restoring your
| phone does not preserve message history.
| sneak wrote:
| 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.
| aftbit wrote:
| 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.
| WC3w6pXxgGd wrote:
| [dead]
| horseblanket wrote:
| Moxie cashed out and split, didn't he? Secret crypto scheme,
| ICO, money, then out?
| h0p3 wrote:
| Do you have any other criticisms of the design of Signal?
| inp wrote:
| What about this "Concatenating Secrets May Be Dangerous"?
| https://mailarchive.ietf.org/arch/msg/tls/F4SVeL2xbGPaPB2GW_...
| baby wrote:
| that's interesting, I'm wondering how it compares with the way I
| drafted it a while back
| (https://gist.github.com/mimoo/356fd8c32216307d4f4f8b79659637...
| &
| https://gist.github.com/mimoo/4e90d030b4e927be29459f0ef92e62...)
| beders wrote:
| 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.
| ignoramous wrote:
| > _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._
|
| Good thing then that the Signal Protocol is repudiable?
| https://signal.org/docs/specifications/pqxdh/#deniability
| rokob wrote:
| 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.
| ylk wrote:
| WhatsApp is working on improving this situation:
| https://engineering.fb.com/2023/04/13/security/whatsapp-key-...
|
| Note: not trying to start a discussion on how much one can
| trust facebook
| filleokus wrote:
| 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.
| csande17 wrote:
| 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.
| maxloh wrote:
| Maybe you can just video call him to make sure that the key is
| correct?
| [deleted]
| janekm wrote:
| It seems we'll have convincing AI video impersonation before
| practical quantum cryptanalysis, unfortunately...
| piuvas wrote:
| loving it!!!
| ignoramous wrote:
| Cloudflare did a (phenomenal) series on _pq safe_ (public key)
| cryptography; here are some posts:
|
| - 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.
| drcongo wrote:
| That's really useful, thanks. I barely understood a word of the
| OP.
| ignoramous wrote:
| 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 ----------
|
| Refs:
|
| - 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)
| couchand wrote:
| 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.
| drcongo wrote:
| I know, that's why I thanked this poster for adding some
| links that are easier to understand.
| ylk wrote:
| Signal also created an easier to understand blog post in
| case you haven't seen it, yet:
| https://signal.org/blog/pqxdh/
___________________________________________________________________
(page generated 2023-09-22 23:02 UTC)