5 ms·

GnuPG has a lot of legacy cruft like two key parsers and support for CAST5. The trend seems to be towards bespoke, tailored tools for specific purposes and away

by na85 6y ago

GnuPG has a lot of legacy cruft like two key parsers and support for CAST5. The trend seems to be towards bespoke, tailored tools for specific purposes and away from unified crypto tools that do many things. Mostly I feel like gpg is too broad for one guy to maintain and needs to drop support for stuff to keep the scope manageable.

signal11 6y ago
I’m looking forward to trying Sequoia PGP[1], a new OpenPGP implementation using Rust. Its opinionated high-level API and removal of MD5 and IDEA might just be the do-over OpenPGP needs. [1] https://sequoia-pgp.org/talks/2018-08-introduction/sequoia-introduction-deltax.pdf https://sequoia-pgp.org/talks/2018-08-introduction/sequoia-i...
- upofadown 6y ago
  Both IDEA and MD5 are depreciated in the published OpenPGP standard. So implementations don't have to implement them. If they do it doesn't make any difference other than a bit better backwards compatibility. Since everything these days prefers better algorithms there are no negative security aspects to supporting IDEA and MD5.
  - tialaramex 6y ago
    Aside: The word you wanted was "deprecated" not "depreciated" Supporting obsolete and perhaps insecure algorithms can give your user false confidence. Adversaries do not prefer the better algorithms, they get to choose whatever suits their purpose and so by supporting an obsolete algorithm you let your adversary choose that if it suits them. So don't. The diediedie draft (now more respectably named https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-... instead) deliberately tells people not just to support newer TLS versions but to stop supporting old ones, for exactly this reason.
    - upofadown 6y ago
      The protecting data at rest problem (PGP and the like) is fundamentally different from protecting data in flight (TLS and the like). In the PGP case adversaries can not affect the choice of algorithm without breaking the fundamental public key cryptography (which is fixed). Added: depreciated vs deprecated; Thanks. An error I have made before and hopefully will not make in the future. Added2: I wrote an article that covers this: https://articles.59.ca/doku.php?id=pgpfan:downgrade https://articles.59.ca/doku.php?id=pgpfan:downgrade
      - tialaramex 6y ago
        > In the PGP case adversaries can not affect the choice of algorithm without breaking the fundamental public key cryptography (which is fixed). Again, this is an error because you've not remembered that an adversary isn't obliged to do what a good actor should do. Your article explains how Alice gets to be quite sure that Bob would prefer she use a good algorithm, and doubtless as a result the conscientious Alice will use a good algorithm when sending messages to Bob. But alas an impostor sending messages to Bob purporting to be from Alice needn't care about this. For that impostor it only matters whether Bob's client will foolishly accept the bad algorithm they deliberately picked, not whether Alice might ever have chosen to use that algorithm. Even if it would be quite impossible for the attack to read or modify any messages Alice writes, in this way they may be able to send a message to Bob that seems to be from Alice. Perhaps the message should say "Hi Bob. Sorry, dreadful problems with PGP again. I had to create a new account, see next mail" followed shortly thereafter by a nice shiny PGP mail from... the impostor's account. Thus, to defeat such an impostor it is necessary to remove/ disable obsolete algorithms entirely. In principle we could imagine client software that securely separates messages received prior to some cut-off date and permits the use of an obsolete algorithm to read/ verify those messages only, but in practice you're asking far too much and this is likely just to add another exploitation avenue.
        upofadown 6y ago
        I am not sure I understand your scenario in enough detail to understand the actual attack. At any rate the identity is established on the basis of Alice's public key. That is the part that is fixed. If it is, say, 2048 bit RSA then that is what Bob uses to confirm that a particular message is from Alice.
GekkePrutser 6y ago
One great thing about gpg though is that if you have it, you have everything. And because it's so ubiquitous pretty much every distro has it by default. Not having to look for packages, being able to decrypt stuff even on a rescue image etc is great. On the mobile side there's also great clients like openkeychain. And most of its shortcoming are mainly academic, and not everyone has the heaviest actors in their threat model. One thing I really love about GPG is that you can use yubikeys and OpenPGP cards for your private keys and encrypt files to that. Any other tool would have to have at least that functionality. I use this all the time and it provides great protection against passphrase logging or key theft. Going back to private keys on disk is a huge step back IMO. I no longer use any such keys except for one backup key I have stored offline and which I throw in the mix in case all of my yubi's and cards break :)

by na85 6y ago

signal11 6y ago

I’m looking forward to trying Sequoia PGP[1], a new OpenPGP implementation using Rust. Its opinionated high-level API and removal of MD5 and IDEA might just be the do-over OpenPGP needs. [1] https://sequoia-pgp.org/talks/2018-08-introduction/sequoia-introduction-deltax.pdf https://sequoia-pgp.org/talks/2018-08-introduction/sequoia-i...

upofadown 6y ago
Both IDEA and MD5 are depreciated in the published OpenPGP standard. So implementations don't have to implement them. If they do it doesn't make any difference other than a bit better backwards compatibility. Since everything these days prefers better algorithms there are no negative security aspects to supporting IDEA and MD5.
- tialaramex 6y ago
  Aside: The word you wanted was "deprecated" not "depreciated" Supporting obsolete and perhaps insecure algorithms can give your user false confidence. Adversaries do not prefer the better algorithms, they get to choose whatever suits their purpose and so by supporting an obsolete algorithm you let your adversary choose that if it suits them. So don't. The diediedie draft (now more respectably named https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-... instead) deliberately tells people not just to support newer TLS versions but to stop supporting old ones, for exactly this reason.
  - upofadown 6y ago
    The protecting data at rest problem (PGP and the like) is fundamentally different from protecting data in flight (TLS and the like). In the PGP case adversaries can not affect the choice of algorithm without breaking the fundamental public key cryptography (which is fixed). Added: depreciated vs deprecated; Thanks. An error I have made before and hopefully will not make in the future. Added2: I wrote an article that covers this: https://articles.59.ca/doku.php?id=pgpfan:downgrade https://articles.59.ca/doku.php?id=pgpfan:downgrade
    - tialaramex 6y ago
      > In the PGP case adversaries can not affect the choice of algorithm without breaking the fundamental public key cryptography (which is fixed). Again, this is an error because you've not remembered that an adversary isn't obliged to do what a good actor should do. Your article explains how Alice gets to be quite sure that Bob would prefer she use a good algorithm, and doubtless as a result the conscientious Alice will use a good algorithm when sending messages to Bob. But alas an impostor sending messages to Bob purporting to be from Alice needn't care about this. For that impostor it only matters whether Bob's client will foolishly accept the bad algorithm they deliberately picked, not whether Alice might ever have chosen to use that algorithm. Even if it would be quite impossible for the attack to read or modify any messages Alice writes, in this way they may be able to send a message to Bob that seems to be from Alice. Perhaps the message should say "Hi Bob. Sorry, dreadful problems with PGP again. I had to create a new account, see next mail" followed shortly thereafter by a nice shiny PGP mail from... the impostor's account. Thus, to defeat such an impostor it is necessary to remove/ disable obsolete algorithms entirely. In principle we could imagine client software that securely separates messages received prior to some cut-off date and permits the use of an obsolete algorithm to read/ verify those messages only, but in practice you're asking far too much and this is likely just to add another exploitation avenue.
      - upofadown 6y ago
        I am not sure I understand your scenario in enough detail to understand the actual attack. At any rate the identity is established on the basis of Alice's public key. That is the part that is fixed. If it is, say, 2048 bit RSA then that is what Bob uses to confirm that a particular message is from Alice.

GekkePrutser 6y ago

One great thing about gpg though is that if you have it, you have everything. And because it's so ubiquitous pretty much every distro has it by default. Not having to look for packages, being able to decrypt stuff even on a rescue image etc is great. On the mobile side there's also great clients like openkeychain. And most of its shortcoming are mainly academic, and not everyone has the heaviest actors in their threat model. One thing I really love about GPG is that you can use yubikeys and OpenPGP cards for your private keys and encrypt files to that. Any other tool would have to have at least that functionality. I use this all the time and it provides great protection against passphrase logging or key theft. Going back to private keys on disk is a huge step back IMO. I no longer use any such keys except for one backup key I have stored offline and which I throw in the mix in case all of my yubi's and cards break :)