4 ms·

Other than the UX for trust on first use, are there other things that make Signal's protocol better than OpenPGP?

captn3m0 6y ago
Your permanent key in PGP can be used to decrypt any intercepted communications down the line? Key compromise has drastic consequences in a sense?
- rpdillon 6y ago
  Usability and perfect forward secrecy. Usability is observable empirically: I was able to easily onboard everyone I text with to Signal, but getting them to use PGP has been completely intractable for years, even with tools like mailvelope.
blueplanet200 6y ago
Well, people tend to actually use it in real life. edit: Signal protocol also has message deniability, future and forward secrecy. OpenPGP lacks these properties.
tptacek 6y ago
They're barely even comparable. Signal Protocol has: * 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.
- psanford 6y ago
  Whoa whoa whoa. No need to besmirch Awk's good name here.
  - tptacek 6y ago
    I was going to say something about how I like Awk, just for the things Awk is good at and meant for, but in fact I really hate Awk and avoid it religiously.
lmm 6y ago
Signal messages are repudiable which is not "better" but different, and probably more appropriate to a chat-like use cases. 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.
- tptacek 6y ago
  Lack of deniability is strictly a downside in a messaging protocol. Applications built on top of messaging protocols that want non-repudiability can provide it directly, using signatures. You almost never want non-repudiable messages between ordinary people. 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.
  - lmm 6y ago
    > Lack of deniability is strictly a downside in a messaging protocol. Applications built on top of messaging protocols that want non-repudiability can provide it directly, using signatures. You almost never want non-repudiable messages between ordinary people. 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.

Your permanent key in PGP can be used to decrypt any intercepted communications down the line? Key compromise has drastic consequences in a sense?

rpdillon 6y ago
Usability and perfect forward secrecy. Usability is observable empirically: I was able to easily onboard everyone I text with to Signal, but getting them to use PGP has been completely intractable for years, even with tools like mailvelope.

blueplanet200 6y ago

Well, people tend to actually use it in real life. edit: Signal protocol also has message deniability, future and forward secrecy. OpenPGP lacks these properties.

tptacek 6y ago

They're barely even comparable. Signal Protocol has: * 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.

psanford 6y ago
Whoa whoa whoa. No need to besmirch Awk's good name here.
- tptacek 6y ago
  I was going to say something about how I like Awk, just for the things Awk is good at and meant for, but in fact I really hate Awk and avoid it religiously.

lmm 6y ago

Signal messages are repudiable which is not "better" but different, and probably more appropriate to a chat-like use cases. 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.

tptacek 6y ago
Lack of deniability is strictly a downside in a messaging protocol. Applications built on top of messaging protocols that want non-repudiability can provide it directly, using signatures. You almost never want non-repudiable messages between ordinary people. 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.
- lmm 6y ago
  > Lack of deniability is strictly a downside in a messaging protocol. Applications built on top of messaging protocols that want non-repudiability can provide it directly, using signatures. You almost never want non-repudiable messages between ordinary people. 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.