7 ms·

If you approach it from "run these commands to do these things" it's not bad. Most wrappers are wrappers around a very limited set of functionality. It sticks

by R0b0t1 5y ago

If you approach it from "run these commands to do these things" it's not bad. Most wrappers are wrappers around a very limited set of functionality. It sticks around because it has some interface that users can use and is scriptable. Everyone saying GPG is bad usually has no general solution to replacing it.

tptacek 5y ago
The best-known problem with PGP is its poor usability, but that's not its biggest problem. It's biggest problem is an archaic design that literally predates much of modern cryptography; most egregiously, PGP is almost never forward-secret, and almost always relies on long-term keys, which is a deadly combination. A more fundamental design issue is simply that cryptography engineers long ago abandoned the idea of a single toolset or even a single standard design that handles multiple problems. Messaging cryptography is not the same as backup cryptography, which in turn isn't the same as secure transports, or package update security. More here: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
- rodgerd 5y ago
  > The best-known problem with PGP is its poor usability, but that's not its biggest problem. I don't know - if the design were more sounds from a crypto perspective, but it was still as easy to fuck up as the current interface, would it really be better?
- AlexCoventry 5y ago
  Is there a way to do forward security in a non-interactive protocol (which seems necessary, if you want to communicate over email?) I guess users could publish partial key exchanges out of band?
  - tptacek 5y ago
    Don't use encrypted email. Encrypted email is deeply problematic, for many reasons having little to do with PGP. https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
    - juliusmusseau 5y ago
      This reminds me of my father's advice to every client (he had a corporate litigation practice): "When you feel the urge to write an email, pick up the f*king phone instead. When in 5 years you're being cross-examined you can say 'I don't remember saying that' and you won't be lying, because we're too old to remember things, and I won't have to bill you for the time it takes to read all the f*king emails."
    - AlexCoventry 5y ago
      Thanks, interesting read.
- R0b0t1 5y ago
  I am aware of these arguments. Still, GPG exists, and no one has really proposed good solutions, or at least the solutions that have been proposed are not taking off for some reason. It is true that pointing out a problem does not need to be accompanied by a solution to be valid, but at this point, if you're going to complain please work towards solving the issue. It is too easy in this case to come off as someone who "knows things" while gesticulating at GPG in a derogatory manner while still accomplishing nothing.
  - akerl_ 5y ago
    Signal/WhatsApp/etc certainly seem to be taking off, and they seem to cover a broad swath of the use cases in messaging that people have historically tried to use GPG for.
    - tptacek 5y ago
      It's always funny to see people talk about how important it is that PGP has an installed base and then think about how many PGP users there are compared to Signal Protocol users.
  - njt 5y ago
    > GPG exists, and no one has really proposed good solutions [...] > if you're going to complain please work towards solving the issue Perhaps because you are asking the wrong question: "PGP/GPG is old, broken, and insecure, what is an exact drop-in replacement that I can substitute for it?" Instead, the question should be: "PGP/GPG is old, broken, and insecure, what is a replacement for [this specific thing I am trying to accomplish with it]?: So what are you trying to do with GPG? Sign a package? Encrypt a file? Store a backup? Transfer a file? Send a message? There are plenty of modern, secure solutions for these.
    - R0b0t1 5y ago
      I know. I am aware of the appropriate questions and some (most) of their answers. But these things still do not seem to get adopted. Best I've seen is a few projects pick up signify. Signal is OK I guess, but still does not solve a lot of things a decentralized system can. People always join these conversations to namedrop projects to sound smart and security conscious, apparently not having tried to integrate them into their existing workflows.
- lapinot 5y ago
  What's your opinion on recent sequoia implementation? I've heard your arguments numerous times and was quite convinced, but that project and their offsprings (openpgp-ca, hagrid, ..) and other stuff like wkd seem to drag the ecosystem to something nicer. I consider it promising.
  - tptacek 5y ago
    I think things written in Rust are better than things written in C. I think modern AEAD cryptography is better than the 90s cryptography that GPG uses. I think the PGP installed base mires the whole ecosystem in C code that accidentally goes quadratic just trying to parse keys, no matter what happens with Sequoia. It's a good project --- this TUI is probably a good project too --- but in a doomed ecosystem.
- reifyx 5y ago
  I don't think people want forward secrecy for their email. If they get a new computer, they probably want all their mail on there, right? Isn't porting over their email efficiently at odds with forward secrecy? Also, is forward secrecy compatible with any kind of encrypted search (I know most encrypted search schemes leak too much these days, but if the alternative is not encrypting email at all...)? Also, how would it work with multiple people in a thread that can be added/removed arbitrarily, or email addresses that resolve to multiple users? Messaging and email seem like different models to begin with.
  - AlbinoDrought 5y ago
    Adding to that, is there a forward secrecy solution to email? I believe this happens in TLS during negotiation, but a similar thing doesn't really exist in one-way communications.
    - reifyx 5y ago
      Assuming you don't want to keep any "chain state" in between messages (which seems reasonable), you can always consume a fresh one-time key of the recipient for every message. The first downside is how you know that the one-time key hasn't been reused, for this you can either trust the service provider or use blockchain or blockchain-like technologies. Second downside is that the user has to be online to generate a ton of one-time keys. I believe puncturable encryption helps with this so the recipient can "puncture" their key at the used-up key identifiers, and thus doesn't have to be online all the time. No idea how practical this is.
  - upofadown 5y ago
    Keeping old messages around for all practical purposes negates forward secrecy in any messaging system. It isn't just an email issue. If they can get your secret key they can pretty much for sure get your old messages. Most email users keep their messages in cloud storage (IMAP) so that changing computers is a non-issue. OpenPGP is an encrypt once scheme so that messages on an IMAP server are encrypted and stay encrypted.
klodolph 5y ago
It's scriptable, but scripting GPG is full of footguns. You generally want to do everything through status-fd to avoid most of the footguns, which is a pain to work with through ordinary shell scripts.

by R0b0t1 5y ago

tptacek 5y ago

The best-known problem with PGP is its poor usability, but that's not its biggest problem. It's biggest problem is an archaic design that literally predates much of modern cryptography; most egregiously, PGP is almost never forward-secret, and almost always relies on long-term keys, which is a deadly combination. A more fundamental design issue is simply that cryptography engineers long ago abandoned the idea of a single toolset or even a single standard design that handles multiple problems. Messaging cryptography is not the same as backup cryptography, which in turn isn't the same as secure transports, or package update security. More here: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

rodgerd 5y ago
> The best-known problem with PGP is its poor usability, but that's not its biggest problem. I don't know - if the design were more sounds from a crypto perspective, but it was still as easy to fuck up as the current interface, would it really be better?
AlexCoventry 5y ago
Is there a way to do forward security in a non-interactive protocol (which seems necessary, if you want to communicate over email?) I guess users could publish partial key exchanges out of band?
- tptacek 5y ago
  Don't use encrypted email. Encrypted email is deeply problematic, for many reasons having little to do with PGP. https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
  - juliusmusseau 5y ago
    This reminds me of my father's advice to every client (he had a corporate litigation practice): "When you feel the urge to write an email, pick up the f*king phone instead. When in 5 years you're being cross-examined you can say 'I don't remember saying that' and you won't be lying, because we're too old to remember things, and I won't have to bill you for the time it takes to read all the f*king emails."
  - AlexCoventry 5y ago
    Thanks, interesting read.
R0b0t1 5y ago
I am aware of these arguments. Still, GPG exists, and no one has really proposed good solutions, or at least the solutions that have been proposed are not taking off for some reason. It is true that pointing out a problem does not need to be accompanied by a solution to be valid, but at this point, if you're going to complain please work towards solving the issue. It is too easy in this case to come off as someone who "knows things" while gesticulating at GPG in a derogatory manner while still accomplishing nothing.
- akerl_ 5y ago
  Signal/WhatsApp/etc certainly seem to be taking off, and they seem to cover a broad swath of the use cases in messaging that people have historically tried to use GPG for.
  - tptacek 5y ago
    It's always funny to see people talk about how important it is that PGP has an installed base and then think about how many PGP users there are compared to Signal Protocol users.
- njt 5y ago
  > GPG exists, and no one has really proposed good solutions [...] > if you're going to complain please work towards solving the issue Perhaps because you are asking the wrong question: "PGP/GPG is old, broken, and insecure, what is an exact drop-in replacement that I can substitute for it?" Instead, the question should be: "PGP/GPG is old, broken, and insecure, what is a replacement for [this specific thing I am trying to accomplish with it]?: So what are you trying to do with GPG? Sign a package? Encrypt a file? Store a backup? Transfer a file? Send a message? There are plenty of modern, secure solutions for these.
  - R0b0t1 5y ago
    I know. I am aware of the appropriate questions and some (most) of their answers. But these things still do not seem to get adopted. Best I've seen is a few projects pick up signify. Signal is OK I guess, but still does not solve a lot of things a decentralized system can. People always join these conversations to namedrop projects to sound smart and security conscious, apparently not having tried to integrate them into their existing workflows.
lapinot 5y ago
What's your opinion on recent sequoia implementation? I've heard your arguments numerous times and was quite convinced, but that project and their offsprings (openpgp-ca, hagrid, ..) and other stuff like wkd seem to drag the ecosystem to something nicer. I consider it promising.
- tptacek 5y ago
  I think things written in Rust are better than things written in C. I think modern AEAD cryptography is better than the 90s cryptography that GPG uses. I think the PGP installed base mires the whole ecosystem in C code that accidentally goes quadratic just trying to parse keys, no matter what happens with Sequoia. It's a good project --- this TUI is probably a good project too --- but in a doomed ecosystem.
reifyx 5y ago
I don't think people want forward secrecy for their email. If they get a new computer, they probably want all their mail on there, right? Isn't porting over their email efficiently at odds with forward secrecy? Also, is forward secrecy compatible with any kind of encrypted search (I know most encrypted search schemes leak too much these days, but if the alternative is not encrypting email at all...)? Also, how would it work with multiple people in a thread that can be added/removed arbitrarily, or email addresses that resolve to multiple users? Messaging and email seem like different models to begin with.
- AlbinoDrought 5y ago
  Adding to that, is there a forward secrecy solution to email? I believe this happens in TLS during negotiation, but a similar thing doesn't really exist in one-way communications.
  - reifyx 5y ago
    Assuming you don't want to keep any "chain state" in between messages (which seems reasonable), you can always consume a fresh one-time key of the recipient for every message. The first downside is how you know that the one-time key hasn't been reused, for this you can either trust the service provider or use blockchain or blockchain-like technologies. Second downside is that the user has to be online to generate a ton of one-time keys. I believe puncturable encryption helps with this so the recipient can "puncture" their key at the used-up key identifiers, and thus doesn't have to be online all the time. No idea how practical this is.
- upofadown 5y ago
  Keeping old messages around for all practical purposes negates forward secrecy in any messaging system. It isn't just an email issue. If they can get your secret key they can pretty much for sure get your old messages. Most email users keep their messages in cloud storage (IMAP) so that changing computers is a non-issue. OpenPGP is an encrypt once scheme so that messages on an IMAP server are encrypted and stay encrypted.

klodolph 5y ago

It's scriptable, but scripting GPG is full of footguns. You generally want to do everything through status-fd to avoid most of the footguns, which is a pain to work with through ordinary shell scripts.