3 ms·

Isn't there that new thing called Sequoia which is supposed to have all advantages of PGP while having none of its drawbacks?

dale_glass 3y ago
Yup, but it's a new thing. It's something like 2-3 years old, I think? I'm not sure, maybe that'll revive things some? But something of this sort has been needed for decades.
- WesolyKubeczek 3y ago
  I'm given to understand that OpenPGP as such is not vile per se; it is a standard on which you can build a secure and flexible system that can evolve as ciphers evolve, etc. It's GnuPG that gave it all bad fame. It's also where I tend to agree with he-who-shouldn't-be-named-on-hn-lest-a-shitfest-begins: "never ever roll your own cryptography" stigmatized the field such that anyone who would like to actually try to do something is first discouraged by their peer crabs in the bucket repeating "never ever roll your own cryptography" mantra, and those who get past that are discouraged by the old boys' club of Those Doing Cryptography for Decades who seem to imply that you need to have at least a Nobel Prize in Mathematics to join the club — even though those are the same folks who also gave us a plethora of cutely named OpenSSL vulnerabilities and made GnuPG an unscalable cabinet of morbid curiosities (where the curiosities are all those wonderful workarounds that put GUIs on GPG, integrate it with other systems, etc). I wish People Doing Cryptography for Decades had enough humility to admit that they don't know everything, and that maybe while they may be algorithm demigods (although all those sweet named vulnerabilities would make some question that status), there also exist folks who do API and UX design better. If only people could talk to one another...
  - dale_glass 3y ago
    OpenPGP is kind of crap too. It's a devilishly complex format with all sorts of footguns and backwards compatibility going back decades, and badly chosen defaults. Really I think it should be killed too. Right now if you want to talk to everything you'll end up implementing stuff like CAST5, SHA1, compression (seemed like a good idea back in the day, turns out it's not!), and the NSA's backdoored elliptic curve algorithm. This will be a huge undertaking, and a lot of it is frankly crap that shouldn't be used if not actively dangerous. Or you could stick to modern crypto and follow the latest security practices, and save yourself a whole bunch of work. But then why suffer implementing the packet format? You won't be able to interoperate with software that for some reason in 2023 uses SHA1 anyway.
    - WesolyKubeczek 3y ago
      Is there a thing that has modes of work akin to OpenPGP but without its baggage? I mean this: decentralised/web of trust (there exist cases when not having to have a CA is a feature), can work in offline mode, uses asymmetric encryption, can use hardware keys, is suitable for email.
  - woodruffw 3y ago
    > I'm given to understand that OpenPGP as such is not vile per se; it is a standard on which you can build a secure and flexible system that can evolve as ciphers evolve, etc. It's GnuPG that gave it all bad fame. No, OpenPGP is pretty bad as well. The RFC contains all kinds of things that wouldn't be allowed anywhere near a modern design, including: * Encouraging compression before encryption (Ss. 2.3) * A pointlessly malleable packet and certificate format, one that allows certificate bindings to be stripped off without invalidating the certificate itself (Ss. 5.5.1.1) * All kinds of dangerous primitives: DSA, MD5 and SHA-1, etc. * A brittle not-HMAC for message tampering detection (Ss. 5.14) And so on; those were just the ones from the top of my head. OpenPGP's decisions were understandable in the early-to-mid 1990s, and justifiable (for compatibility purposes) through the early-to-mid 2000s. But that ship has long since sailed.
    - bscphil 3y ago
      > compression before encryption What's the matter with that? It should be secure with any modern cryptography primitives. (I mean, it's obviously no less secure to do `age -e myfile.7z` than it is to do `age -e myfile`.)
      - Avamander 3y ago
        It creates a compression oracle, potentially leaking parts of plaintext.
        SpaghettiCthulu 3y ago
        The compression oracle (a lookup table if I'm not mistaken) would still be encrypted, right?
      - dale_glass 3y ago
        Sometimes you can interrogate the compression. CRIME attack: if you can provide something to the target system, then it will compress differently depending on what's provided. If you guess right, then the compressed version will be smaller. VOIP statistics: You can make very good guesses about encrypted voice communication by knowing how it compresses speech, figuring out how long different phonemes are, and statistically trying to reconstruct the conversation.
woodruffw 3y ago
Sequoia is an implementation of OpenPGP, i.e. RFC 4880. It also supports a few non-standard extensions to OpenPGP, e.g. ECDSA and EdDSA signatures, better stream ciphers than CAST5, etc. I think a legitimate selling point of Sequoia is simplicity: it's a new implementation, written in a memory-safe language[1], and it can make better (but still not optimal) default decisions. At the same time, I don't think Sequoia succeeds in avoiding PGP's baggage or drawbacks: PGP is defined by its baggage, and any greenfield implementation that avoids that baggage is intentionally breaking compatibility with the thing it's meant to be compatible with. It's unclear to me (personally) what the value proposition for Sequoia is meant to be, given that it's shackled to the past and can't do better on basic things like certificate malleability. If the goal is for it to be something better, I think it'd be best to cut the losses and start from stronger (and more modern) foundations. [1]: Except that they've chosen to use Nettle for the cryptographic components, meaning that there's still a good chunk of C under the hood.
- WesolyKubeczek 3y ago
  > PGP is defined by its baggage, and any greenfield implementation that avoids that baggage is intentionally breaking compatibility with the thing it's meant to be compatible with. Is there a way in PGP to say "I won't talk to you if you have a weak key, or use ciphers that are not one of <some reasonable list of modern ciphers>"? Like you have in TLS, SSH, and IKE handshakes?
  - SAI_Peregrinus 3y ago
    Not and be compatible with the OpenPGP spec. You can define a safe subset of OpenPGP with some additional restrictions (like no weak keys) but that won't be PGP any more, it'll be a new protocol.
    - Avamander 3y ago
      Technically true and it would certainly avoid a bunch of confusion if the new subset carries a new name. However there are a bunch of "OpenPGP" implementations out there but when you start comparing them, it's obvious that they differ quite a bit.

dale_glass 3y ago

Yup, but it's a new thing. It's something like 2-3 years old, I think? I'm not sure, maybe that'll revive things some? But something of this sort has been needed for decades.

WesolyKubeczek 3y ago
I'm given to understand that OpenPGP as such is not vile per se; it is a standard on which you can build a secure and flexible system that can evolve as ciphers evolve, etc. It's GnuPG that gave it all bad fame. It's also where I tend to agree with he-who-shouldn't-be-named-on-hn-lest-a-shitfest-begins: "never ever roll your own cryptography" stigmatized the field such that anyone who would like to actually try to do something is first discouraged by their peer crabs in the bucket repeating "never ever roll your own cryptography" mantra, and those who get past that are discouraged by the old boys' club of Those Doing Cryptography for Decades who seem to imply that you need to have at least a Nobel Prize in Mathematics to join the club — even though those are the same folks who also gave us a plethora of cutely named OpenSSL vulnerabilities and made GnuPG an unscalable cabinet of morbid curiosities (where the curiosities are all those wonderful workarounds that put GUIs on GPG, integrate it with other systems, etc). I wish People Doing Cryptography for Decades had enough humility to admit that they don't know everything, and that maybe while they may be algorithm demigods (although all those sweet named vulnerabilities would make some question that status), there also exist folks who do API and UX design better. If only people could talk to one another...
- dale_glass 3y ago
  OpenPGP is kind of crap too. It's a devilishly complex format with all sorts of footguns and backwards compatibility going back decades, and badly chosen defaults. Really I think it should be killed too. Right now if you want to talk to everything you'll end up implementing stuff like CAST5, SHA1, compression (seemed like a good idea back in the day, turns out it's not!), and the NSA's backdoored elliptic curve algorithm. This will be a huge undertaking, and a lot of it is frankly crap that shouldn't be used if not actively dangerous. Or you could stick to modern crypto and follow the latest security practices, and save yourself a whole bunch of work. But then why suffer implementing the packet format? You won't be able to interoperate with software that for some reason in 2023 uses SHA1 anyway.
  - WesolyKubeczek 3y ago
    Is there a thing that has modes of work akin to OpenPGP but without its baggage? I mean this: decentralised/web of trust (there exist cases when not having to have a CA is a feature), can work in offline mode, uses asymmetric encryption, can use hardware keys, is suitable for email.
- woodruffw 3y ago
  > I'm given to understand that OpenPGP as such is not vile per se; it is a standard on which you can build a secure and flexible system that can evolve as ciphers evolve, etc. It's GnuPG that gave it all bad fame. No, OpenPGP is pretty bad as well. The RFC contains all kinds of things that wouldn't be allowed anywhere near a modern design, including: * Encouraging compression before encryption (Ss. 2.3) * A pointlessly malleable packet and certificate format, one that allows certificate bindings to be stripped off without invalidating the certificate itself (Ss. 5.5.1.1) * All kinds of dangerous primitives: DSA, MD5 and SHA-1, etc. * A brittle not-HMAC for message tampering detection (Ss. 5.14) And so on; those were just the ones from the top of my head. OpenPGP's decisions were understandable in the early-to-mid 1990s, and justifiable (for compatibility purposes) through the early-to-mid 2000s. But that ship has long since sailed.
  - bscphil 3y ago
    > compression before encryption What's the matter with that? It should be secure with any modern cryptography primitives. (I mean, it's obviously no less secure to do `age -e myfile.7z` than it is to do `age -e myfile`.)
    - Avamander 3y ago
      It creates a compression oracle, potentially leaking parts of plaintext.
      - SpaghettiCthulu 3y ago
        The compression oracle (a lookup table if I'm not mistaken) would still be encrypted, right?
    - dale_glass 3y ago
      Sometimes you can interrogate the compression. CRIME attack: if you can provide something to the target system, then it will compress differently depending on what's provided. If you guess right, then the compressed version will be smaller. VOIP statistics: You can make very good guesses about encrypted voice communication by knowing how it compresses speech, figuring out how long different phonemes are, and statistically trying to reconstruct the conversation.

woodruffw 3y ago

Sequoia is an implementation of OpenPGP, i.e. RFC 4880. It also supports a few non-standard extensions to OpenPGP, e.g. ECDSA and EdDSA signatures, better stream ciphers than CAST5, etc. I think a legitimate selling point of Sequoia is simplicity: it's a new implementation, written in a memory-safe language[1], and it can make better (but still not optimal) default decisions. At the same time, I don't think Sequoia succeeds in avoiding PGP's baggage or drawbacks: PGP is defined by its baggage, and any greenfield implementation that avoids that baggage is intentionally breaking compatibility with the thing it's meant to be compatible with. It's unclear to me (personally) what the value proposition for Sequoia is meant to be, given that it's shackled to the past and can't do better on basic things like certificate malleability. If the goal is for it to be something better, I think it'd be best to cut the losses and start from stronger (and more modern) foundations. [1]: Except that they've chosen to use Nettle for the cryptographic components, meaning that there's still a good chunk of C under the hood.

WesolyKubeczek 3y ago
> PGP is defined by its baggage, and any greenfield implementation that avoids that baggage is intentionally breaking compatibility with the thing it's meant to be compatible with. Is there a way in PGP to say "I won't talk to you if you have a weak key, or use ciphers that are not one of <some reasonable list of modern ciphers>"? Like you have in TLS, SSH, and IKE handshakes?
- SAI_Peregrinus 3y ago
  Not and be compatible with the OpenPGP spec. You can define a safe subset of OpenPGP with some additional restrictions (like no weak keys) but that won't be PGP any more, it'll be a new protocol.
  - Avamander 3y ago
    Technically true and it would certainly avoid a bunch of confusion if the new subset carries a new name. However there are a bunch of "OpenPGP" implementations out there but when you start comparing them, it's obvious that they differ quite a bit.