14 ms·

Sequoia PGP 1.0 Released: The Seedling Is a Sapling

156 points by dannyobrien 6y ago

rendx 6y ago
"The sequoia-openpgp crate (Rust’s terminology for a library) is a low-level, policy-free OpenPGP implementation. Our goal was to implement all of RFC 4880, and provide an API that can be used to access and modify pretty much everything, but is simultaneously secure by default." This is pretty exciting. Hope this gives the OpenPGP ecosystem a long needed push and more attention! "Sequoia was started 3.5 years ago by Justus Winter, Kai Michaelis and me, Neal Walfield. Prior to working on Sequoia, the three of us had worked together at g10code on GnuPG."
- seanieb 6y ago
  I’d recommend that people avoid PGP and use modern cryptography. Eg. AGE, It uses far less and simpler code, so it can be audited. PGP is a complicated old mess. https://age-encryption.org/ https://age-encryption.org/
  - rendx 6y ago
    OpenPGP is a standard, and a very flexible one. Not all implementations need to support all features. You cannot compare it to something like AGE, which is simply a single implementation without any effort to turn it into a standard about anything, nor the goal to support various use cases. We could go on talking about the differences of approach and the benefits and drawbacks of standardization, flexiblity, libraries vs. end-user applications etc, but that's been discussed times and times again here and elsewhere. There is simply no alternative to OpenPGP the standard and its efforts. Or can you point us at one? Have you looked at the OpenPGP spec? I find it pretty readable, and you will quickly see how it cannot be compared to any single application. I understand that AGE also has a "spec". It is limited to a single use case, encryption. No signatures, no certifications, no thoughts on key discovery or trust, etc etc.
    - pvg 6y ago
      OpenPGP is a standard, and a very flexible one. That's pretty much what makes it the opposite of 'modern cryptography'.
      - andrewstuart2 6y ago
        It certainly sounds like you're saying that cryptography needs to be brittle to be modern, which of course will find a lot of valid disagreement. There's no way that any non-flexible cryptography can ever stay modern if it doesn't accommodate for various key sizes and algorithms. If for no other reason, because we continue to see more and more compute power that makes brute forcing smaller or weaker keys more feasible. Perhaps you can elaborate a bit more.
        akerl_ 6y ago
        The way to accommodate a new key size or algorithm is to say “v2 of the protocol will use $key_size and $cipher, and will not use $old_key_size or $old_cipher. Upgrade to this version due to $reason_old_setup_is_obsolete”. A casual observation of history will find that attempting to build negotiation of security features into a protocol is akin to opting in to a fun, optional class of major security vulnerability. For reference: SSL/TLS, GPG.
        amluto 6y ago
        Not necessarily. You can also tie algorithms to keys. For example, if you want to verify a signature, it’s perfectly reasonable for the public key to actually be (algorithm, private key as defined by that algorithm). What you don’t want to do is put the algorithm in a message that is potentially controlled by an attacker.
        pvg 6y ago
        The things you mention are causes of catastrophic security failures, not mitigations. 'Algorithm agility' (and related) is the source downgrade attacks, software that relies on cryptography tends to get broken computationally only after years of warnings about unsafe algorithms that are ignored, more often than not, due to over-reliance on standards both formal and de-facto.
  - upofadown 6y ago
    Are you claiming that the Sequoia implementation of the OpenPGP standard is a "complicated old mess"? Because the OpenPGP standard (RFC 4880) isn't really all that complicated. A significant portion of is a bit by bit description of the key format. At any rate, age is hardly any sort of replacement for OpenPGP. It is really only suitable for the case where you want to encrypt something like a backup and not bother to sign it. I am not really sure that it is superior even for that niche case. Most people would want to know a backup is corrupt before they started the restore, not partway through it.
    - viraptor 6y ago
      In the out of scope section of the spec: > Any kind of signing (which is not a tooling problem, but a trust and key distribution problem, and to the extent that tools matter you should just use signify/minisign, and for keys we should probably use SSH ones) Yeah, they could implement it, but why not keep the utilities small and specific to a use case. You can shasum over the backup and sign it if that's what you want.
    - XMPPwocky 6y ago
      > Most people would want to know a backup is corrupt before they started the restore, not partway through it. Yes, which often makes OpenPGP a bad choice, because of how it has to authenticate things (requiring multiple passes). Many implementations of OpenPGP will happily release unauthenticated plaintext to the caller (and then fail at the end when the MAC fails- too late if you piped that to tar!) - there isn't an efficient way to do better than this with OpenPGP, because...well, it isn't very good.
  - joerandom 6y ago
    Pasting raw key material is so nice, Age is not even alpha featurewise. Stop recommending stuff that you don't use yourself. $ age-keygen -o key.txt Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p $ tar cvz ~/data | age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p > data.tar.gz.age $ age -d -i key.txt data.tar.gz.age > data.tar.gz
  - forgotmypw17 6y ago
    No.
  - Foxboron 6y ago
    Sadly age is only tackling one of the easier parts of gnupg, encrypting files. Implying age replaces gnupg is overselling it. We don't have any good alternatives for a web-of-trust (or something akin) where we can sign files or attest trust to some identity. Signify does parts of this, but lacks the trust aspects which makes you establish convoluted key distribution schemes to ensure you have future signing keys lined up. There isn't any good replacements for F/OSS developers that needs to have some from of signatures between them. Say replace linux distributions usage of signatures to form some network of developer trust.
    - SAI_Peregrinus 6y ago
      PGP keyservers don't support the web of trust any more either.
      - pabs3 6y ago
        There are some ideas for restoring support for the web of trust, not sure if they got implemented yet though: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-10 https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistan... https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/ https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystor... https://lwn.net/Articles/792674/ https://lwn.net/Articles/792674/
      - Foxboron 6y ago
        Which is why most distributions and other projects has moved to WKDs for key discovery. I don't think this is a good argument though as there are alternatives, even though they don't work super well at the moment.
        Leace 6y ago
        > Which is why most distributions and other projects has moved to WKDs for key discovery. Yeah, WKD is a first-class citizen in GnuPG. Creating signatures with "--sender $EMAIL" embeds e-mail in the signature and then gpg --auto-key-retrieve --verify will fetch the key via WKD without the need to touch keyservers.
dfabulich 6y ago
The GnuPG implementation was just one of the problems with PGP; Sequoia can't fix any of PGP's real problems while still being a "PGP" implementation. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html tl;dr: PGP is absurdly complex, mired in backwards compatibility with broken crypto algorithms, and relies on long-term secrets with no forward secrecy. In this very blog post, Sequoia PGP explains that they continue to support SHA-1, which was broken in 2005, for backwards compatibility reasons. They've added some code to mitigate the damage (introducing more complexity); they hope to turn off SHA-1 in 2023. Cool. In the meantime, don't use PGP, not even Sequoia PGP. Use Signal to transfer messages and files. Use full-disk encryption for encrypting backups. Use Minisign to sign packages. Use libsodium for encrypting app data. EDIT: This post is currently at -3 downvotes without comment, presumably from folks who think SHA-1 is just fine and that I'm overstating the case. I ask you to just read the link I posted and explain why you think PGP is good, actually, despite its terrible reputation among professional cryptographers and security professionals. "We can’t say this more clearly or often enough: you can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both."
- upofadown 6y ago
  It seems it is mandatory to post a link to "The PGP Problem" whenever anyone as much as mentions PGP. To save repetition, here is the link to my critique of that particular anti-PGP rant: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
  - dfabulich 6y ago
    You've misunderstood a lot of Latacora's critique, but I think the most important point you've misunderstood is "negotiation." > PGP does not do negotiation. It can't. PGP supports asynchronous store and forward applications. It works over a one way channel. Your cipher, digest, and compression preferences come along with your public key They are signed and so are protected by the base cryptographic system. An adversary would have to break the cryptography to modify your preferences. > I do not agree that compatibility is a bad thing. PGP is actually a good example of how to deal with backwards compatibility in a good way. "Negotiation" here doesn't mean a synchronous back-and-forth conversation. "Negotiation" in this case means, "if you're not sending me the most secure version, I'll just accept a somewhat less secure version." PGP encrypted messages are "take it or leave it," but that doesn't mean that PGP doesn't do negotiation. Instead, it means that the PGP implementations decide how much insecurity to accept in favor of backwards compatibility. Here, in the blog post linked at the top of this page, Sequoia moans that they can't bring themselves to turn off SHA-1 because Debian developers use it. They're accepting a less-secure implementation for backwards compatibility. It's right there in TFA. I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default." Today, in 2020, that means "don't use GPG, and don't use Sequoia PGP" and I'm confident that it means "don't use PGP ever again," but you and I don't have to agree on that. The fact that you can change the defaults to be more secure and less backwards compatible doesn't make PGP safe to use. It's dangerous by default. Don't use it, and don't advocate that others use it, until PGP is secure by default (in other words, never). The other thing you've misunderstood is the problem with long-term keys. > Most people prefer to keep their identity indefinitely. That is why, say, the Signal protocol also has a “practically-forever root key tied to their identity”. It is inherent to the problem. No. Long-term public identifiers are indeed, desirable, but PGP's public identifiers are paired with secret keys. Tying your identity to your public key means that you can't change your secret key unless you change your public identifier as well. (In Signal terms, that would be like saying that you can't rotate your secret key without changing your public phone number, which would be absurd.)
deleted 6y ago
[deleted]
lifeisstillgood 6y ago
A good resource on why PGP is too complicated - definitely opened my eyes and seems pertinent to this discussion https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
nwjsmith 6y ago
Is it possible to use Sequoia to sign Git commits?
- lmm 6y ago
  You could try git config gpg.program=sq and see if it works. I don't know if the arguments are too different though.
- er4hn 6y ago
  It would be great if that were possible. Git commit signing is something that I would love to see be more commonplace, since it is a key part of a secured code supply chain. At my workplace I lead a project to make commit signing mandatory on our git repos, which I wrote about here: https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/ https://eos.arista.com/commit-signing-with-git-at-enterprise... . One of the painful aspects of this was using the gpg tools. They are products of an earlier age and don't display helpful error messages, nor do they display easy to parse messages. I realize that Sequoia doesn't currently have a JSON API, but it looks like one is planned for the future, so that it two thumbs up from me.
dpc_pw 6y ago
PGP is terrible. Avoid if you can. I wish people focused on building simpler and more modern tools. In particular: https://bitcoin.stackexchange.com/questions/100546/reusing-bitcoin-hw-wallet-infrastructure-as-a-pgp-replacement https://bitcoin.stackexchange.com/questions/100546/reusing-b... Having said that, if you need to use it, it's awesome that now it has a modern and saner implementation.
hda2 6y ago
Despite what the few naysayers in this thread would like to have you believe, there is a growing number of projects that rely on OpenPGP for security. Having a modern library for working with them is a giant plus no matter how you spin it. A big thank you to everyone who worked to get sequoia this far.
- cwyers 6y ago
  The naysayers don't believe that there aren't projects that rely on OpenPGP for security, they just think that it's not reliable.
  - hda2 6y ago
    Well, unfortunately for them, reality begs to differ.
aborsy 6y ago
I like keys.openpgp.org. It keeps the identity out of the key. If the user requires inclusion of the identity, it must be verified by confirming an email.

156 points by dannyobrien 6y ago

"The sequoia-openpgp crate (Rust’s terminology for a library) is a low-level, policy-free OpenPGP implementation. Our goal was to implement all of RFC 4880, and provide an API that can be used to access and modify pretty much everything, but is simultaneously secure by default." This is pretty exciting. Hope this gives the OpenPGP ecosystem a long needed push and more attention! "Sequoia was started 3.5 years ago by Justus Winter, Kai Michaelis and me, Neal Walfield. Prior to working on Sequoia, the three of us had worked together at g10code on GnuPG."

seanieb 6y ago
I’d recommend that people avoid PGP and use modern cryptography. Eg. AGE, It uses far less and simpler code, so it can be audited. PGP is a complicated old mess. https://age-encryption.org/ https://age-encryption.org/
- rendx 6y ago
  OpenPGP is a standard, and a very flexible one. Not all implementations need to support all features. You cannot compare it to something like AGE, which is simply a single implementation without any effort to turn it into a standard about anything, nor the goal to support various use cases. We could go on talking about the differences of approach and the benefits and drawbacks of standardization, flexiblity, libraries vs. end-user applications etc, but that's been discussed times and times again here and elsewhere. There is simply no alternative to OpenPGP the standard and its efforts. Or can you point us at one? Have you looked at the OpenPGP spec? I find it pretty readable, and you will quickly see how it cannot be compared to any single application. I understand that AGE also has a "spec". It is limited to a single use case, encryption. No signatures, no certifications, no thoughts on key discovery or trust, etc etc.
  - pvg 6y ago
    OpenPGP is a standard, and a very flexible one. That's pretty much what makes it the opposite of 'modern cryptography'.
    - andrewstuart2 6y ago
      It certainly sounds like you're saying that cryptography needs to be brittle to be modern, which of course will find a lot of valid disagreement. There's no way that any non-flexible cryptography can ever stay modern if it doesn't accommodate for various key sizes and algorithms. If for no other reason, because we continue to see more and more compute power that makes brute forcing smaller or weaker keys more feasible. Perhaps you can elaborate a bit more.
      - akerl_ 6y ago
        The way to accommodate a new key size or algorithm is to say “v2 of the protocol will use $key_size and $cipher, and will not use $old_key_size or $old_cipher. Upgrade to this version due to $reason_old_setup_is_obsolete”. A casual observation of history will find that attempting to build negotiation of security features into a protocol is akin to opting in to a fun, optional class of major security vulnerability. For reference: SSL/TLS, GPG.
        amluto 6y ago
        Not necessarily. You can also tie algorithms to keys. For example, if you want to verify a signature, it’s perfectly reasonable for the public key to actually be (algorithm, private key as defined by that algorithm). What you don’t want to do is put the algorithm in a message that is potentially controlled by an attacker.
      - pvg 6y ago
        The things you mention are causes of catastrophic security failures, not mitigations. 'Algorithm agility' (and related) is the source downgrade attacks, software that relies on cryptography tends to get broken computationally only after years of warnings about unsafe algorithms that are ignored, more often than not, due to over-reliance on standards both formal and de-facto.
- upofadown 6y ago
  Are you claiming that the Sequoia implementation of the OpenPGP standard is a "complicated old mess"? Because the OpenPGP standard (RFC 4880) isn't really all that complicated. A significant portion of is a bit by bit description of the key format. At any rate, age is hardly any sort of replacement for OpenPGP. It is really only suitable for the case where you want to encrypt something like a backup and not bother to sign it. I am not really sure that it is superior even for that niche case. Most people would want to know a backup is corrupt before they started the restore, not partway through it.
  - viraptor 6y ago
    In the out of scope section of the spec: > Any kind of signing (which is not a tooling problem, but a trust and key distribution problem, and to the extent that tools matter you should just use signify/minisign, and for keys we should probably use SSH ones) Yeah, they could implement it, but why not keep the utilities small and specific to a use case. You can shasum over the backup and sign it if that's what you want.
  - XMPPwocky 6y ago
    > Most people would want to know a backup is corrupt before they started the restore, not partway through it. Yes, which often makes OpenPGP a bad choice, because of how it has to authenticate things (requiring multiple passes). Many implementations of OpenPGP will happily release unauthenticated plaintext to the caller (and then fail at the end when the MAC fails- too late if you piped that to tar!) - there isn't an efficient way to do better than this with OpenPGP, because...well, it isn't very good.
- joerandom 6y ago
  Pasting raw key material is so nice, Age is not even alpha featurewise. Stop recommending stuff that you don't use yourself. $ age-keygen -o key.txt Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p $ tar cvz ~/data | age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p > data.tar.gz.age $ age -d -i key.txt data.tar.gz.age > data.tar.gz
- forgotmypw17 6y ago
  No.
- Foxboron 6y ago
  Sadly age is only tackling one of the easier parts of gnupg, encrypting files. Implying age replaces gnupg is overselling it. We don't have any good alternatives for a web-of-trust (or something akin) where we can sign files or attest trust to some identity. Signify does parts of this, but lacks the trust aspects which makes you establish convoluted key distribution schemes to ensure you have future signing keys lined up. There isn't any good replacements for F/OSS developers that needs to have some from of signatures between them. Say replace linux distributions usage of signatures to form some network of developer trust.
  - SAI_Peregrinus 6y ago
    PGP keyservers don't support the web of trust any more either.
    - pabs3 6y ago
      There are some ideas for restoring support for the web of trust, not sure if they got implemented yet though: https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-03#section-10 https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistan... https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystore/ https://gitlab.com/dkg/draft-openpgp-abuse-resistant-keystor... https://lwn.net/Articles/792674/ https://lwn.net/Articles/792674/
    - Foxboron 6y ago
      Which is why most distributions and other projects has moved to WKDs for key discovery. I don't think this is a good argument though as there are alternatives, even though they don't work super well at the moment.
      - Leace 6y ago
        > Which is why most distributions and other projects has moved to WKDs for key discovery. Yeah, WKD is a first-class citizen in GnuPG. Creating signatures with "--sender $EMAIL" embeds e-mail in the signature and then gpg --auto-key-retrieve --verify will fetch the key via WKD without the need to touch keyservers.

dfabulich 6y ago

The GnuPG implementation was just one of the problems with PGP; Sequoia can't fix any of PGP's real problems while still being a "PGP" implementation. https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html tl;dr: PGP is absurdly complex, mired in backwards compatibility with broken crypto algorithms, and relies on long-term secrets with no forward secrecy. In this very blog post, Sequoia PGP explains that they continue to support SHA-1, which was broken in 2005, for backwards compatibility reasons. They've added some code to mitigate the damage (introducing more complexity); they hope to turn off SHA-1 in 2023. Cool. In the meantime, don't use PGP, not even Sequoia PGP. Use Signal to transfer messages and files. Use full-disk encryption for encrypting backups. Use Minisign to sign packages. Use libsodium for encrypting app data. EDIT: This post is currently at -3 downvotes without comment, presumably from folks who think SHA-1 is just fine and that I'm overstating the case. I ask you to just read the link I posted and explain why you think PGP is good, actually, despite its terrible reputation among professional cryptographers and security professionals. "We can’t say this more clearly or often enough: you can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both."

upofadown 6y ago
It seems it is mandatory to post a link to "The PGP Problem" whenever anyone as much as mentions PGP. To save repetition, here is the link to my critique of that particular anti-PGP rant: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
- dfabulich 6y ago
  You've misunderstood a lot of Latacora's critique, but I think the most important point you've misunderstood is "negotiation." > PGP does not do negotiation. It can't. PGP supports asynchronous store and forward applications. It works over a one way channel. Your cipher, digest, and compression preferences come along with your public key They are signed and so are protected by the base cryptographic system. An adversary would have to break the cryptography to modify your preferences. > I do not agree that compatibility is a bad thing. PGP is actually a good example of how to deal with backwards compatibility in a good way. "Negotiation" here doesn't mean a synchronous back-and-forth conversation. "Negotiation" in this case means, "if you're not sending me the most secure version, I'll just accept a somewhat less secure version." PGP encrypted messages are "take it or leave it," but that doesn't mean that PGP doesn't do negotiation. Instead, it means that the PGP implementations decide how much insecurity to accept in favor of backwards compatibility. Here, in the blog post linked at the top of this page, Sequoia moans that they can't bring themselves to turn off SHA-1 because Debian developers use it. They're accepting a less-secure implementation for backwards compatibility. It's right there in TFA. I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default." Today, in 2020, that means "don't use GPG, and don't use Sequoia PGP" and I'm confident that it means "don't use PGP ever again," but you and I don't have to agree on that. The fact that you can change the defaults to be more secure and less backwards compatible doesn't make PGP safe to use. It's dangerous by default. Don't use it, and don't advocate that others use it, until PGP is secure by default (in other words, never). The other thing you've misunderstood is the problem with long-term keys. > Most people prefer to keep their identity indefinitely. That is why, say, the Signal protocol also has a “practically-forever root key tied to their identity”. It is inherent to the problem. No. Long-term public identifiers are indeed, desirable, but PGP's public identifiers are paired with secret keys. Tying your identity to your public key means that you can't change your secret key unless you change your public identifier as well. (In Signal terms, that would be like saying that you can't rotate your secret key without changing your public phone number, which would be absurd.)

deleted 6y ago

[deleted]

lifeisstillgood 6y ago

A good resource on why PGP is too complicated - definitely opened my eyes and seems pertinent to this discussion https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

nwjsmith 6y ago

Is it possible to use Sequoia to sign Git commits?

lmm 6y ago
You could try git config gpg.program=sq and see if it works. I don't know if the arguments are too different though.
er4hn 6y ago
It would be great if that were possible. Git commit signing is something that I would love to see be more commonplace, since it is a key part of a secured code supply chain. At my workplace I lead a project to make commit signing mandatory on our git repos, which I wrote about here: https://eos.arista.com/commit-signing-with-git-at-enterprise-scale/ https://eos.arista.com/commit-signing-with-git-at-enterprise... . One of the painful aspects of this was using the gpg tools. They are products of an earlier age and don't display helpful error messages, nor do they display easy to parse messages. I realize that Sequoia doesn't currently have a JSON API, but it looks like one is planned for the future, so that it two thumbs up from me.

dpc_pw 6y ago

PGP is terrible. Avoid if you can. I wish people focused on building simpler and more modern tools. In particular: https://bitcoin.stackexchange.com/questions/100546/reusing-bitcoin-hw-wallet-infrastructure-as-a-pgp-replacement https://bitcoin.stackexchange.com/questions/100546/reusing-b... Having said that, if you need to use it, it's awesome that now it has a modern and saner implementation.

hda2 6y ago

Despite what the few naysayers in this thread would like to have you believe, there is a growing number of projects that rely on OpenPGP for security. Having a modern library for working with them is a giant plus no matter how you spin it. A big thank you to everyone who worked to get sequoia this far.

cwyers 6y ago
The naysayers don't believe that there aren't projects that rely on OpenPGP for security, they just think that it's not reliable.
- hda2 6y ago
  Well, unfortunately for them, reality begs to differ.

aborsy 6y ago

I like keys.openpgp.org. It keeps the identity out of the key. If the user requires inclusion of the identity, it must be verified by confirming an email.