6 ms·

>- PGP doesn’t give forward secrecy. Generally, the value of forward secrecy in end to end encrypted messaging is proportional to the chance that the secret ke

>- PGP doesn’t give forward secrecy. Generally, the value of forward secrecy in end to end encrypted messaging is proportional to the chance that the secret key material will be compromised. With an asynchronous, offline capable medium like encrypted email the secret key material can be protected very very well. A message archive accessible to the user for all practical purposes negates the value of forward secrecy. Most people like to keep their old emails around. Most people like to keep any form of messages around so that forward secrecy has little practical value in most forms of E2EE messaging. There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Encrypted email is more for the people that don't want their encrypted material compromised in the first place... More discussion: https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy https://articles.59.ca/doku.php?id=pgpfan:forward_secrecy

danShumway 5y ago
> This sort of attack could not reveal any messages archived off the network due to Signal's forward secrecy. Let's compare the end result to an encrypted email client running on the same phone using traditional passphrase protection [...] So the encrypted email actually ends up providing a better result for the user. That is because it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging. I have some issues: First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form, so you have no guarantee that anyone is actually required to input a passphrase every single time they want to look at their messages. In fact, I would wager that for many clients, this isn't the case, because I bet it makes functionality like local searching of messages a lot slower and more complicated. Second, this isn't an argument about forward secrecy at all, it's an argument about putting an extra passphrase in front of logging into the messenger/client. There's a reason why Signal doesn't do that, and it's that it's really annoying and ordinary users turn it off. We have a hard enough time getting people to put locks on their phones, your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email. Third, if they're not on a phone most people don't use local email clients, they use the browser and access email on many devices, so I don't really buy the idea that email is mostly accessed offline. In fact, this is arguably one of the strengths of a platform like Signal; the fact that it requires downloading a client forces you to do a lot of stuff locally on the device. Fourth, forward secrecy isn't necessarily about protecting the end-user's device anyway, it's about what happens when a key/archive gets compromised off-device. People sometimes try to dismiss that risk by saying that email gets sent over encrypted transports, but your email server can still be compromised or messages accessed using a warrant, and what forward secrecy can do is block an attacker from decrypting every message on the server or setting up a passive listener. This is a problem that's relevant to email because most users don't delete emails from the server after they're downloaded to a client -- most users rely on messages being stored in perpetuity on the server as well as on their clients. Just to make this point more clearly: > it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging. Very few people use email the way you're describing. In practice, most people use email in the form of an always available, instant messaging service. Any security model for email that relies on people changing their behavior so drastically is (in my mind) not a particularly realistic or useful plan for mass encryption. ---- > Encrypted email is more for the people that don't want their encrypted material compromised in the first place... Sure, but sometimes we do defense in depth, sometimes we think about what will happen if something gets compromised. The speed at which encrypted-email proponents jump to "just don't make any mistakes" is one of the reasons why I don't trust encrypted email. I don't think this is a conversation that acknowledges the ways that ordinary people use technology.
- upofadown 5y ago
  >First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form,... No, that's how it works. Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase. >...your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email. They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. That is the distinction that is being made here. Asynchronous is inherently more secure than synchronous. I think you have missed the points I made about forward secrecy and messaging. Neither depend on encryption of material on the network.
  - danShumway 5y ago
    > Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase. That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that. You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that. > They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever. ---- There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.
md_ 5y ago
The other person replying already pointed out why this is an apples-to-oranges sort of argument, but for one specific point: > There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm? The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?
- upofadown 5y ago
  Forward secrecy is just forgetting the secret key material. The trick is the do it in a convenient way. In the case of something offline capable like OpenPGP over email, the inconvenience is in having to redistribute your keys before forgetting the secret key. You don't even have to reestablish any trust, that just works. I did a demonstration using GnuPG to provide a practical example: * https://articles.59.ca/doku.php?id=pgpfan:gpgburn https://articles.59.ca/doku.php?id=pgpfan:gpgburn
  - md_ 5y ago
    OMFG. This is the sort of thing that makes people not want to use PGP. "It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)
    - upofadown 5y ago
      Of course no one is actually going to do that. The point is that it is trivially possible. The question is: why do PGP users/developers not bother?
      - danShumway 5y ago
        I suspect the answer you're looking for is that it's not necessary, but the much more likely reason is that the UX is horrible and it's error-prone, and even out of the few people who use PGP for this kind of stuff, a fairly sizable chunk of users probably don't even know what forward secrecy is. I would say the expectation that PGP users need to be informed enough about encryption to make a personal decision for themselves when to change their keys is itself a somewhat damning indictment of the PGP ecosystem. You shouldn't have to be an expert in this stuff to have good encryption. Zooming out a bit, we could ask the same question that you've posed about email more broadly: why do most email users not bother with PGP encryption at all? Why do many client developers decide to not even add support to their apps? If you take the perspective that lack of mainstream adoption of a security technique is evidence that the security technique has no value, then it's hard not to conclude that SMS and Facebook Messenger are both fine and we're all wasting our time with encrypted messaging of any kind. But my perspective is that people use more secure tools (in part) only once they're at least as accessible and usable as the other tools/platforms that they already have. ---- From your linked article: > This process is very manual. There are no GnuPG --preburn and --burn commands to automate this. This suggests that this is not something that is commonly done. Most people don't fear the exposure of their keys enough to make this worthwhile for this sort of system. PGP does not have a generally accessible, vetted way to automatically create those subkeys and distribute them that any non-technical (or even reasonably technical) user can take advantage of: if it did then the blogpost wouldn't exist. So of course people don't do that stuff, it's not surprising that people don't manually edit keys. The problem is when developers and proponents then respond to that by saying, "we don't need a generally accessible, vetted way to automatically create and distribute subkeys because people don't do that." Then the whole conversation starts getting really circular. People use forward secrecy in Signal because it's on by default and works even if they don't know what forward secrecy is. Of course sometimes we can look at an ecosystem and we can take cues about user needs based on what they currently use. However, you have to be very careful about that. Don't fall into the same trap that (just as one example) Mozilla falls into, where they'll move an option into a buried preference menu and then say, "no one is clicking this anymore, guess we should remove it from the browser entirely." Sometimes users don't use features purely because they're not convenient, or accessible, or because they don't know the features exist. It's also worth noting that broadly, most E2EE messaging platforms are moving towards forward secrecy, and PGP encrypted email is somewhat of an outcast in saying that forward secrecy doesn't matter. So it's not really like forward secrecy is easy everywhere and people go and turn it off because they don't need it. Increasingly, it's just older systems like PGP where people have decided not to approach messaging this way. I would posit the reason for that split is because PGP has bad UX for forward secrecy and most people using it or building around it know that doing unconventional things in PGP is a recipe for accidentally shooting yourself in the foot.

danShumway 5y ago

> This sort of attack could not reveal any messages archived off the network due to Signal's forward secrecy. Let's compare the end result to an encrypted email client running on the same phone using traditional passphrase protection [...] So the encrypted email actually ends up providing a better result for the user. That is because it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging. I have some issues: First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form, so you have no guarantee that anyone is actually required to input a passphrase every single time they want to look at their messages. In fact, I would wager that for many clients, this isn't the case, because I bet it makes functionality like local searching of messages a lot slower and more complicated. Second, this isn't an argument about forward secrecy at all, it's an argument about putting an extra passphrase in front of logging into the messenger/client. There's a reason why Signal doesn't do that, and it's that it's really annoying and ordinary users turn it off. We have a hard enough time getting people to put locks on their phones, your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email. Third, if they're not on a phone most people don't use local email clients, they use the browser and access email on many devices, so I don't really buy the idea that email is mostly accessed offline. In fact, this is arguably one of the strengths of a platform like Signal; the fact that it requires downloading a client forces you to do a lot of stuff locally on the device. Fourth, forward secrecy isn't necessarily about protecting the end-user's device anyway, it's about what happens when a key/archive gets compromised off-device. People sometimes try to dismiss that risk by saying that email gets sent over encrypted transports, but your email server can still be compromised or messages accessed using a warrant, and what forward secrecy can do is block an attacker from decrypting every message on the server or setting up a passive listener. This is a problem that's relevant to email because most users don't delete emails from the server after they're downloaded to a client -- most users rely on messages being stored in perpetuity on the server as well as on their clients. Just to make this point more clearly: > it is possible to lock up the encryption key more securely in practice with an offline medium than it is with an online, always available, medium like instant messaging. Very few people use email the way you're describing. In practice, most people use email in the form of an always available, instant messaging service. Any security model for email that relies on people changing their behavior so drastically is (in my mind) not a particularly realistic or useful plan for mass encryption. ---- > Encrypted email is more for the people that don't want their encrypted material compromised in the first place... Sure, but sometimes we do defense in depth, sometimes we think about what will happen if something gets compromised. The speed at which encrypted-email proponents jump to "just don't make any mistakes" is one of the reasons why I don't trust encrypted email. I don't think this is a conversation that acknowledges the ways that ordinary people use technology.

upofadown 5y ago
>First off, you have no guarantee that anyone's client is storing PGP-encrypted mail only in its encrypted form,... No, that's how it works. Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase. >...your model for email security on a phone can not be that someone is going to enter a full passphrase every time they check their email. They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. That is the distinction that is being made here. Asynchronous is inherently more secure than synchronous. I think you have missed the points I made about forward secrecy and messaging. Neither depend on encryption of material on the network.
- danShumway 5y ago
  > Encrypted email stays encrypted until you decrypt it to look at it. I like to call this "encrypt once". People complain that they can't search their encrypted emails. You can make the user enter a passphrase to search (slow) or create an index and encrypt the index with the passphrase. That doesn't have anything to do with whether it stays encrypted once it's sitting on the client device. You don't know that an email client isn't fetching the encrypted email, decrypting it, and then storing it in plain-text on the device. And there's nothing in the protocol that forces them not to do that. You might want them to store contents encrypted on the client device, you might think it's best practice for them to do that, but you don't know that client will do that. > They are much more likely to do that than enter a passphrase to see if there is someone on instant messaging they would like to talk to. They're not going to do either of those things, it's like asking if I'm more likely to swim the Pacific or the Atlantic ocean. Neither scheme actually works in practice for a mass communication platform. People do not use email asynchronously, they treat it like long-form text in a messaging client, the same way they treat SMS or Signal or Element or whatever. ---- There's nothing special about email that means people are more likely to use a passphrase every time they want to access it on their phone. And even if they did (which they won't), there are risks other than client device access that forward-secrecy protects against. "On the network" in this case means that your encrypted emails are getting stored on a server that can be either compromised or accessed with a warrant. It is not true that the only way to gain access to E2EE archives is through the client device itself.

md_ 5y ago

The other person replying already pointed out why this is an apples-to-oranges sort of argument, but for one specific point: > There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it. Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm? The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?

upofadown 5y ago
Forward secrecy is just forgetting the secret key material. The trick is the do it in a convenient way. In the case of something offline capable like OpenPGP over email, the inconvenience is in having to redistribute your keys before forgetting the secret key. You don't even have to reestablish any trust, that just works. I did a demonstration using GnuPG to provide a practical example: * https://articles.59.ca/doku.php?id=pgpfan:gpgburn https://articles.59.ca/doku.php?id=pgpfan:gpgburn
- md_ 5y ago
  OMFG. This is the sort of thing that makes people not want to use PGP. "It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)
  - upofadown 5y ago
    Of course no one is actually going to do that. The point is that it is trivially possible. The question is: why do PGP users/developers not bother?
    - danShumway 5y ago
      I suspect the answer you're looking for is that it's not necessary, but the much more likely reason is that the UX is horrible and it's error-prone, and even out of the few people who use PGP for this kind of stuff, a fairly sizable chunk of users probably don't even know what forward secrecy is. I would say the expectation that PGP users need to be informed enough about encryption to make a personal decision for themselves when to change their keys is itself a somewhat damning indictment of the PGP ecosystem. You shouldn't have to be an expert in this stuff to have good encryption. Zooming out a bit, we could ask the same question that you've posed about email more broadly: why do most email users not bother with PGP encryption at all? Why do many client developers decide to not even add support to their apps? If you take the perspective that lack of mainstream adoption of a security technique is evidence that the security technique has no value, then it's hard not to conclude that SMS and Facebook Messenger are both fine and we're all wasting our time with encrypted messaging of any kind. But my perspective is that people use more secure tools (in part) only once they're at least as accessible and usable as the other tools/platforms that they already have. ---- From your linked article: > This process is very manual. There are no GnuPG --preburn and --burn commands to automate this. This suggests that this is not something that is commonly done. Most people don't fear the exposure of their keys enough to make this worthwhile for this sort of system. PGP does not have a generally accessible, vetted way to automatically create those subkeys and distribute them that any non-technical (or even reasonably technical) user can take advantage of: if it did then the blogpost wouldn't exist. So of course people don't do that stuff, it's not surprising that people don't manually edit keys. The problem is when developers and proponents then respond to that by saying, "we don't need a generally accessible, vetted way to automatically create and distribute subkeys because people don't do that." Then the whole conversation starts getting really circular. People use forward secrecy in Signal because it's on by default and works even if they don't know what forward secrecy is. Of course sometimes we can look at an ecosystem and we can take cues about user needs based on what they currently use. However, you have to be very careful about that. Don't fall into the same trap that (just as one example) Mozilla falls into, where they'll move an option into a buried preference menu and then say, "no one is clicking this anymore, guess we should remove it from the browser entirely." Sometimes users don't use features purely because they're not convenient, or accessible, or because they don't know the features exist. It's also worth noting that broadly, most E2EE messaging platforms are moving towards forward secrecy, and PGP encrypted email is somewhat of an outcast in saying that forward secrecy doesn't matter. So it's not really like forward secrecy is easy everywhere and people go and turn it off because they don't need it. Increasingly, it's just older systems like PGP where people have decided not to approach messaging this way. I would posit the reason for that split is because PGP has bad UX for forward secrecy and most people using it or building around it know that doing unconventional things in PGP is a recipe for accidentally shooting yourself in the foot.