6 ms·

Nice writeup. It is a serious problem that the ecosystem is held back by wasting resources on personal disputes with immediate consequences for end users. Hat

Nice writeup. It is a serious problem that the ecosystem is held back by wasting resources on personal disputes with immediate consequences for end users. Hate on OpenPGP all you want, it still is an important technology with unrealized potential and growth.

femiagbabiaka 3y ago
It’s not actually clear from reading through this document or others, or the linked email threads, etc. that there is a personal dispute at play, or what that might be. I’m also not sure who the target of this document is, or who wrote it. It’s also not clear what the forcing function behind the strong recommendations at the end is — will the author fork GnuPG in the event a resolution can’t be reached?
freedomben 3y ago
It doesn't sound like a personal dispute to me, it sounds technical. One camp (Open) wants to move faster and break backward compatibility, the other (Libre) wants to move slower and maintain backwards compatibility
- daveguy 3y ago
  It seems like maintaining backwards compatibility would be important for something that otherwise irreversibly encrypts your data.
  - woodruffw 3y ago
    The correct way to maintain backwards compatibility in those contexts is to decrypt and re-encrypt, not support broken ciphers or weak modes of encryption indefinitely. The latter is security theater.
    - b112 3y ago
      No. There is 100% value in being able to decrypt a 20 year old email. It doesn't matter if it is a broken cypher. A 20 year old email has very little actionable in it, but can have value in other ways. It is absolutely vital that a project like this, supports some means for a modern machine/stack to access older data.
      - tptacek 3y ago
        This is silly. Nothing that happens with the standard or its implementation is going to prevent you from decrypting a 20 year old email. It shouldn't need saying, but one reason for that is that PGP's cryptography is schoolbook cryptography.
        b112 3y ago
        This is silly Upstream spoke of deprecated support for older emails. My response is aimed there. And there is loads of software that will not compile on modern hardware. End users don't often have that ability to re-write, or even to easily validate a random bit of code on github. A project like this, needs to maintain backwards operability. For decades.
        tptacek 3y ago
        Once again: this is silly, because whatever conversation we are having about the standard, your ability to decrypt old messages would not have been impacted. Standard revisions don't turn the previous standard into secret forbidden knowledge. What's really being asked for here is the capability to seamlessly continue sending messages with the previous, weak constructions, into the indefinite future, and have the installed base of the system continue seamlessly reading them. I think that is in fact a goal of PGP, and one of its great weaknesses.
        kazinator 3y ago
        When standards remove the requirements for something after a period of obsolescence, that tends to send a message to the implementors to remove that from the software. Users who still rely on that have to use the old software, against which there can be barriers: - old executables don't run on newer OS (particularly in the Unix world). - old source code won't build. - old code won't retrieve the old data from the newer server it has been migrated do. Things like that. The barriers could be significant that even someone skilled and motivated such as myself would be discouraged.
    - asveikau 3y ago
      A read-only operation should not cause an insane amount of writes. This is perilous for a great many reasons, one of which is the risk of data corruption should something go wrong.
      - woodruffw 3y ago
        You're thinking about this the wrong way: if your data needs to be secure, then it's already perilous to keep it around with with weak or broken encryption. Security models where data is too important to risk encryption upgrades but not important enough to encrypt correctly are internally incoherent. (This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes or why performing cryptographic upgrades is somehow uniquely, unacceptably risky from a data corruption perspective.)
        asveikau 3y ago
        No, I think you're thinking about it the the wrong way: write failures are common. The failure mode for a bad disk is often that reads will succeed and writes will lose data. Something that silently writes like this is increasing the risk of data loss. It probably depends a lot on the application, but I think it's often much better to have something that will warn the user about security risks and let them decide what to do with that risk. If you do design something with these silent writes, you absolutely need to think hard about failure cases and test them, and not handwave them away. Having the most "secure" data be corrupted is ultimately an unacceptable outcome. That's not even getting into the other problems, such as ... is it ok for the user to take a performance hit of writing X GB when all they want to do is read a file?
        woodruffw 3y ago
        Your cryptosystem is not responsible for the stability of your storage medium, and your storage medium is not responsible for the security of your cryptosystem. They are black boxes to each other; to confound their responsibilities is to ensure doom in your designs. Put another way: your cryptosystem isn't responsible for saving your ass from not making backups. If your data is valuable, treat it that way.
  - panarky 3y ago
    I read the article and couldn't find any hint that previously encrypted data would be undecryptable by either branch of the fork. Is there a real risk of this that I missed, or are you just free-associating off the term "backwards compatibility"?
    - daveguy 3y ago
      The article specifically refers to backward compatibility with RFC4880, RFC5581, and RFC6687. These specifications include encryption techniques. So no. I was not just "free associating". Please do not assume the worst, because it could be that you just haven't understood the implications of the article.
  - Nextgrid 3y ago
    On the other hand, as long as earlier versions or their sources remain available, it doesn't sound like a major problem to me. The sources would effectively be documentation for the previous format and can be reimplemented if needed.
- throw0101b 3y ago
  > One camp (Open) wants to move faster and break backward compatibility, the other (Libre) wants to move slower and maintain backwards compatibility There is no breaking of backward compatibility. The crypto-refresh draft and the LibrePGP draft are equally backward-compatible. See 'A Critique on “A Critique on the OpenPGP Updates”': * https://blog.pgpkeys.eu/critique-critique https://blog.pgpkeys.eu/critique-critique Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format. The Proton folks are choosing to support both v5 and v6: * https://github.com/ProtonMail/go-crypto/pull/182 https://github.com/ProtonMail/go-crypto/pull/182 As is the Thunderbird/RNP team: * https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855678b175105470e09 https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855...
nvy 3y ago
I think the common refrain against PGP is that it shouldn't be important, because it suffers from a myriad of technical and sociological shortcomings. The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire.
- 0xDEAFBEAD 3y ago
  >The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire. Can you explain why? People elsewhere in this thread are saying that PGP sucks because it tries to do too many things at once, but it seems to me that the one big advantage of a tool which does everything at once is that you only need to solve authenticity one time for everything you do. For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
  - nvy 3y ago
    >Can you explain why? Well, the key servers are useless because they are susceptible to that poisoning attack from a few years ago, and they happily send you fraudulent or revoked keys. And the web of trust doesn't scale. The trust ratings mean different things to different people, the propagation of revocation certs and signatures is slow, and rotating keys is onerous. >For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this? How often do you check the fingerprints of that key? Do you verify out of band when the developer rotates their key? (Haha just kidding, PGP users essentially never rotate keys) If you care enough to encrypt your emails, then what is the virtue of verifying less frequently that you're talking to the correct persons? Why wouldn't you want separate keys for all those things? Why would you want an adversary to be able to compromise a single key and have the ability to forge commits, emails, and whatever else?

femiagbabiaka 3y ago

It’s not actually clear from reading through this document or others, or the linked email threads, etc. that there is a personal dispute at play, or what that might be. I’m also not sure who the target of this document is, or who wrote it. It’s also not clear what the forcing function behind the strong recommendations at the end is — will the author fork GnuPG in the event a resolution can’t be reached?

freedomben 3y ago

It doesn't sound like a personal dispute to me, it sounds technical. One camp (Open) wants to move faster and break backward compatibility, the other (Libre) wants to move slower and maintain backwards compatibility

daveguy 3y ago
It seems like maintaining backwards compatibility would be important for something that otherwise irreversibly encrypts your data.
- woodruffw 3y ago
  The correct way to maintain backwards compatibility in those contexts is to decrypt and re-encrypt, not support broken ciphers or weak modes of encryption indefinitely. The latter is security theater.
  - b112 3y ago
    No. There is 100% value in being able to decrypt a 20 year old email. It doesn't matter if it is a broken cypher. A 20 year old email has very little actionable in it, but can have value in other ways. It is absolutely vital that a project like this, supports some means for a modern machine/stack to access older data.
    - tptacek 3y ago
      This is silly. Nothing that happens with the standard or its implementation is going to prevent you from decrypting a 20 year old email. It shouldn't need saying, but one reason for that is that PGP's cryptography is schoolbook cryptography.
      - b112 3y ago
        This is silly Upstream spoke of deprecated support for older emails. My response is aimed there. And there is loads of software that will not compile on modern hardware. End users don't often have that ability to re-write, or even to easily validate a random bit of code on github. A project like this, needs to maintain backwards operability. For decades.
        tptacek 3y ago
        Once again: this is silly, because whatever conversation we are having about the standard, your ability to decrypt old messages would not have been impacted. Standard revisions don't turn the previous standard into secret forbidden knowledge. What's really being asked for here is the capability to seamlessly continue sending messages with the previous, weak constructions, into the indefinite future, and have the installed base of the system continue seamlessly reading them. I think that is in fact a goal of PGP, and one of its great weaknesses.
        kazinator 3y ago
        When standards remove the requirements for something after a period of obsolescence, that tends to send a message to the implementors to remove that from the software. Users who still rely on that have to use the old software, against which there can be barriers: - old executables don't run on newer OS (particularly in the Unix world). - old source code won't build. - old code won't retrieve the old data from the newer server it has been migrated do. Things like that. The barriers could be significant that even someone skilled and motivated such as myself would be discouraged.
  - asveikau 3y ago
    A read-only operation should not cause an insane amount of writes. This is perilous for a great many reasons, one of which is the risk of data corruption should something go wrong.
    - woodruffw 3y ago
      You're thinking about this the wrong way: if your data needs to be secure, then it's already perilous to keep it around with with weak or broken encryption. Security models where data is too important to risk encryption upgrades but not important enough to encrypt correctly are internally incoherent. (This is sidestepping the other parts of the comment that don't make sense, like why a single read implies multiple writes or why performing cryptographic upgrades is somehow uniquely, unacceptably risky from a data corruption perspective.)
      - asveikau 3y ago
        No, I think you're thinking about it the the wrong way: write failures are common. The failure mode for a bad disk is often that reads will succeed and writes will lose data. Something that silently writes like this is increasing the risk of data loss. It probably depends a lot on the application, but I think it's often much better to have something that will warn the user about security risks and let them decide what to do with that risk. If you do design something with these silent writes, you absolutely need to think hard about failure cases and test them, and not handwave them away. Having the most "secure" data be corrupted is ultimately an unacceptable outcome. That's not even getting into the other problems, such as ... is it ok for the user to take a performance hit of writing X GB when all they want to do is read a file?
        woodruffw 3y ago
        Your cryptosystem is not responsible for the stability of your storage medium, and your storage medium is not responsible for the security of your cryptosystem. They are black boxes to each other; to confound their responsibilities is to ensure doom in your designs. Put another way: your cryptosystem isn't responsible for saving your ass from not making backups. If your data is valuable, treat it that way.
- panarky 3y ago
  I read the article and couldn't find any hint that previously encrypted data would be undecryptable by either branch of the fork. Is there a real risk of this that I missed, or are you just free-associating off the term "backwards compatibility"?
  - daveguy 3y ago
    The article specifically refers to backward compatibility with RFC4880, RFC5581, and RFC6687. These specifications include encryption techniques. So no. I was not just "free associating". Please do not assume the worst, because it could be that you just haven't understood the implications of the article.
- Nextgrid 3y ago
  On the other hand, as long as earlier versions or their sources remain available, it doesn't sound like a major problem to me. The sources would effectively be documentation for the previous format and can be reimplemented if needed.
throw0101b 3y ago
> One camp (Open) wants to move faster and break backward compatibility, the other (Libre) wants to move slower and maintain backwards compatibility There is no breaking of backward compatibility. The crypto-refresh draft and the LibrePGP draft are equally backward-compatible. See 'A Critique on “A Critique on the OpenPGP Updates”': * https://blog.pgpkeys.eu/critique-critique https://blog.pgpkeys.eu/critique-critique Both groups would create a new format (Libre = v5; crypto-refresh = v6). v4-only wouldn't be able to handle either new format, and newer software could presumably be told to create files in the older format. The Proton folks are choosing to support both v5 and v6: * https://github.com/ProtonMail/go-crypto/pull/182 https://github.com/ProtonMail/go-crypto/pull/182 As is the Thunderbird/RNP team: * https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855678b175105470e09 https://github.com/rnpgp/rnp/commit/fdfc1f5bb11d439e35f3c855...

nvy 3y ago

I think the common refrain against PGP is that it shouldn't be important, because it suffers from a myriad of technical and sociological shortcomings. The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire.

0xDEAFBEAD 3y ago
>The whole situation regarding key servers, key rotation, and the web of trust is a complete dumpster fire. Can you explain why? People elsewhere in this thread are saying that PGP sucks because it tries to do too many things at once, but it seems to me that the one big advantage of a tool which does everything at once is that you only need to solve authenticity one time for everything you do. For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this?
- nvy 3y ago
  >Can you explain why? Well, the key servers are useless because they are susceptible to that poisoning attack from a few years ago, and they happily send you fraudulent or revoked keys. And the web of trust doesn't scale. The trust ratings mean different things to different people, the propagation of revocation certs and signatures is slow, and rotating keys is onerous. >For example, if I'm communicating with an open source dev, having their known-authentic PGP key allows me to simultaneously verify the authenticity of their software updates, verify the authenticity of the email they send me, and encrypt my emails to them. Is there anything outside of PGP that accomplishes this? How often do you check the fingerprints of that key? Do you verify out of band when the developer rotates their key? (Haha just kidding, PGP users essentially never rotate keys) If you care enough to encrypt your emails, then what is the virtue of verifying less frequently that you're talking to the correct persons? Why wouldn't you want separate keys for all those things? Why would you want an adversary to be able to compromise a single key and have the ability to forge commits, emails, and whatever else?