8 ms·

Ditching OpenPGP, a new approach to signing APT repositories

106 points by FiloSottile 5y ago

liveoneggs 5y ago
great news!
sohei 5y ago
Can anyone with more expertise comment on the use of cryptography.hazmat which is apparently (1) a frontend to openssl, (2) "full of land mines, dragons, and dinosaurs with laser guns"?
- tptacek 5y ago
  It's "hazmat" because cryptography is dangerous, and the library authors would strongly recommend you use an opinionated library that does the cryptography for you, like Nacl, where you don't think about which crypto primitives to use, but rather they're all set up for you. Here, they're working with an existing format and have specific requirements; they're doing the thing the "hazmat" library exists to facilitate.
dlor 5y ago
I took a look at the design and think there are a few issues with the format as proposed. # The public key is stored with the signature. This should be stored separately. A public key found here is too tempting to use, rendering the signature worthless. Authenticating it would be OK, but low value. This is unauthenticated. A "key ID" should be used instead if the intention is to support lookups among multiple keys. # The algorithm is stored with the signature. This is slightly less bad than above, but still bad. Attacker-controlled algorithms have been used repeatedly in "downgrade" attacks. Agility is bad, but if you must support multiple algorithms, store this with the public key (somewhere else). Some info here: https://github.com/secure-systems-lab/dsse/issues/35 https://github.com/secure-systems-lab/dsse/issues/35 I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself. Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/ https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for.
- trishankdatadog 5y ago
  > >The complexity designed into this system might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for. I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as, say, devising an in-toto root layout. Most open source projects should really just worry about subscribing to something like PEP 480 and signing with one-time Fulcio keys. But I think we are largely on the same page here: yes, please just minisign/signify if you want simplicity, but if you want resilience from nation-state attacks, you need something like TUF (coupled with in-toto and sigstore). We are happy to advise.
  - arkadiyt 5y ago
    > I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as ... I've heard great things about TUF but if you want people to adopt it then it seems like the documentation/tutorials/tooling should be a first class citizen
    - joshuagl 5y ago
      Thanks for your comment. I completely agree, and we are working on it. If you have any suggestions for documentation/tutorials/tooling you would like to see, I'd be happy to add them to the list. We are actively working to improve reference implementation, to make it easier to maintain (easier to read code, type annotations, generally more Pythonic, cleaner design) and use (cleaner documented API, easier to plug in your own implementation of things a content update system might already have an opinionated implementation of -- i.e. the network communication stack). We hope to build more tools on top of the cleaned up reference implementation once it is feature complete. For the specification itself, we recently switched to publishing a rich HTML document with cross-linking, syntax highlighting, ToC, etc. https://theupdateframework.github.io/specification/latest/ https://theupdateframework.github.io/specification/latest/ and added a new section covering some of the repository operations https://theupdateframework.github.io/specification/v1.0.19/#adding-updating-targets https://theupdateframework.github.io/specification/v1.0.19/#...
xvilka 5y ago
Why not use the Rust implementation[1] of the PGP instead? I feel that writing something new and complex like this in non-statically typed language (Python in this case) is a recipe for disaster. Someone suggested using TUF, but it's also in Python and prone to shifting compile-time errors to runtime. [1] https://sequoia-pgp.org/ https://sequoia-pgp.org/
- tptacek 5y ago
  Because even memory-safe implementations of PGP are saddled with the complexity and legacy cruft the the protocol itself, and the thing Debian projects are actually looking to do is exactly what the signify/minisign family of signature schemes does, using exclusively modern cryptography, with the simplest possible interface.
  - xvilka 5y ago
    Makes sense if they don't plan it to become more accommodating and complex over time.
    - tptacek 5y ago
      Ironically, by using a modern, stripped down signing system like this, they've probably increased their opportunities to do interesting things down the road, since they don't have all the possible weird interactions with the PGP system to consider.
      - julian-klode 5y ago
        Still have to trust 1k RSA keys because GPG does not allow us to say they're unsafe.
        deknos 5y ago
        i am pretty sure you can mark them yourself. but that they are generally still used, well that's called backwards compatibility. and that's needed.
nullc 5y ago
Doesn't appear to have any domain separation. This means that if a common private key is reused in another application you may be able to use that application as an oracle to produce signatures it doesn't intend to use. Say you later want to have packagers sign with the same keys for security announcements. Obviously not reusing keys is good but there are reasons people do that (e.g. to share the trust of an existing key). The lack of domain sep means stuff like a subkey itself is a valid payload signed by the master key. The modern advice is to personalize the hash function for each distinct application and use within the application. Signer is setup to have the whole input in memory at once. The protocol design makes it tricky to do otherwise without using two passes at best. This could be avoided if anyone cared, e.g. using a signing scheme with prehashing (which has its own obscure tradeoffs). This text says very little about validating trusted keys. A signature where you just take the pubkey from the input and don't validate it is essentially just a really computationally expensive hash and doesn't itself provide security. The text about validating all signatures regardless of trusted or not could be read as saying that you just accept stuff with valid signature regardless if they were being signed by the Evil League of Evil instead of an approved source. :) It uses ed25519 but doesn't do anything about inconsistent validation criteria ( https://hdevalence.ca/blog/2020-10-04-its-25519am https://hdevalence.ca/blog/2020-10-04-its-25519am ), different implementations consider non-overlapping sets of signatures valid. If you want to have automated klaxons on signature failures, this ought to be addressed for the same reason as "repositories do not fail for a subset of users". (though it's not fatal in this application as it is in consensus systems). The format will be a little clunky if used with post-quantum signatures, e.g. sphincs+ would have a couple kilobytes of signature data stuffed on a line. I don't have a real recommendation there other than saying you should probably have test vectors that have some couple-kilobyte-long examples. No obvious affordance for additional signed metadata, which is useful for forensics. So, for example, if a project has multiple parties with access to the keys they may want to tag which user(s) authorized the signature or included a timestamp. If their signing is performed by a HSM (e.g. something like USB armory that allows no user access) the consistency of their metadata could be preserved. This could probably be kludged on by requiring the metadata just be inside the payload somewhere. I like that there are subkeys with expiration. It's not entirely clear to me that it's supported to hand out multiple subkeys to different parties all with the same serial, and they stay all equally valid until a key is observed with a newer serial (at which point all subkeys need to be updated)? "Subkeys may reuse/share serial numbers provided" is confusing on this point. Good security practices suggest that if there are multiple places that can sign each should get its own subkey (so if there is a compromise you can isolate it), and this might mean that there are multiple subkeys in parallel all valid for a given trusted master. Personally, I'm a little disappointed to see a proposal for repository signing that doesn't include affordances for something like opentimestamps or a certificate-transparency like facility (e.g. to validate that parties aren't making backdoored alternative versions for private distribution). But I guess these could be overlaid as additional signature types and the idea is just to phase out pgp, not advance the security state of the art forward. Authors of this proposal should be aware the NSA has made a formal recommendation against the use of ECC with curves smaller than 384-bits. There are plenty of applications where compatibility, performance, or computational constraints make it attractive to stay with 256 bit options. But if I were doing something entirely greenfield where a double size key/signature would be a non-issue, I'd be really tempted to use ed448 instead: If nothing else, at least if there are problems in the future you at least didn't violate existing credible advice. :) (Really I'd want to use sphincs+ for something like this, but it's probably too premature). Considering how close to security theater package signing often is in practice, I'm not sure if it's worth worrying too much that the underlying cryptosystem might be stronger-- it's not the limiting factor.
julian-klode 5y ago
Please note that the spec is ahead of the implementation, and the project has been stale for 4 months. For spec and implementation to stay in sync, they'd have to be in the same repo I guess. For now, the spec is driving and the implementation catching up with it. For more background, see https://mastodon.social/@juliank/105679564085465156 https://mastodon.social/@juliank/105679564085465156
exabrial 5y ago
Do we ever learn anything from past security breaches? What is the compelling security reason to ditch pgp? The _one_ thing it is good at is long-term identity. There's ECDSA keys available now in PGP, and Ed25519 wouldn't be a stretch. This looks and smells like NIH syndrome. PGP has had a lot of time to bake. Let's make incremental improvements, not start all of over because you don't understand history. Oh and going all eggs in on one algorithm is stupid. Thinking there will never be problems with Ed25519 is naive. PGP was designed to be extended.
- tptacek 5y ago
  These ideas are pretty close to discredited in cryptography engineering. Diversity in signature algorithms doesn't help when everyone uses the same algorithm anyways, and, more importantly, a negotiated algorithm makes it harder to recover from an new attack on algorithms, not easier: with a non-negotiable algorithm, you version the entire repository, and can reliably rule out vulnerable signatures. Negotiation and downgrade attacks have been endemic in "ciphersuite" schemes. There's a reason the field is moving towards simple, modern schemes like this one, and Debian has more experience than most in trying to make broken, crufty old PGP work.
  - exabrial 5y ago
    So, no.
    - tptacek 5y ago
      It's OK to just say "I have no idea what you're talking about".

106 points by FiloSottile 5y ago

great news!

Can anyone with more expertise comment on the use of cryptography.hazmat which is apparently (1) a frontend to openssl, (2) "full of land mines, dragons, and dinosaurs with laser guns"?

tptacek 5y ago
It's "hazmat" because cryptography is dangerous, and the library authors would strongly recommend you use an opinionated library that does the cryptography for you, like Nacl, where you don't think about which crypto primitives to use, but rather they're all set up for you. Here, they're working with an existing format and have specific requirements; they're doing the thing the "hazmat" library exists to facilitate.

dlor 5y ago

I took a look at the design and think there are a few issues with the format as proposed. # The public key is stored with the signature. This should be stored separately. A public key found here is too tempting to use, rendering the signature worthless. Authenticating it would be OK, but low value. This is unauthenticated. A "key ID" should be used instead if the intention is to support lookups among multiple keys. # The algorithm is stored with the signature. This is slightly less bad than above, but still bad. Attacker-controlled algorithms have been used repeatedly in "downgrade" attacks. Agility is bad, but if you must support multiple algorithms, store this with the public key (somewhere else). Some info here: https://github.com/secure-systems-lab/dsse/issues/35 https://github.com/secure-systems-lab/dsse/issues/35 I didn't look at the sub-key protocol in detail. The ephemeral key for every release is an interesting choice. The root key is "offline". But if it must be brought online to sign a new ephemeral key for every release anyway, you might as well just use it to sign the release itself. Using minisign/signify like OpenBSD does and keeping things very simple makes sense to me. The complexity designed into this system (sub-keys, multiple algorithms and signatures) starts to stretch the bounds to where TUF (https://theupdateframework.io/ https://theupdateframework.io/) might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for.

trishankdatadog 5y ago
> >The complexity designed into this system might make sense. TUF is very complex and not worth it for most projects, but Debian is exactly what TUF is designed for. I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as, say, devising an in-toto root layout. Most open source projects should really just worry about subscribing to something like PEP 480 and signing with one-time Fulcio keys. But I think we are largely on the same page here: yes, please just minisign/signify if you want simplicity, but if you want resilience from nation-state attacks, you need something like TUF (coupled with in-toto and sigstore). We are happy to advise.
- arkadiyt 5y ago
  > I disagree that TUF is too complicated for most projects. While our documentation, tutorials, and tooling can be better, the setup is about just as complicated as ... I've heard great things about TUF but if you want people to adopt it then it seems like the documentation/tutorials/tooling should be a first class citizen
  - joshuagl 5y ago
    Thanks for your comment. I completely agree, and we are working on it. If you have any suggestions for documentation/tutorials/tooling you would like to see, I'd be happy to add them to the list. We are actively working to improve reference implementation, to make it easier to maintain (easier to read code, type annotations, generally more Pythonic, cleaner design) and use (cleaner documented API, easier to plug in your own implementation of things a content update system might already have an opinionated implementation of -- i.e. the network communication stack). We hope to build more tools on top of the cleaned up reference implementation once it is feature complete. For the specification itself, we recently switched to publishing a rich HTML document with cross-linking, syntax highlighting, ToC, etc. https://theupdateframework.github.io/specification/latest/ https://theupdateframework.github.io/specification/latest/ and added a new section covering some of the repository operations https://theupdateframework.github.io/specification/v1.0.19/#adding-updating-targets https://theupdateframework.github.io/specification/v1.0.19/#...

xvilka 5y ago

Why not use the Rust implementation[1] of the PGP instead? I feel that writing something new and complex like this in non-statically typed language (Python in this case) is a recipe for disaster. Someone suggested using TUF, but it's also in Python and prone to shifting compile-time errors to runtime. [1] https://sequoia-pgp.org/ https://sequoia-pgp.org/

tptacek 5y ago
Because even memory-safe implementations of PGP are saddled with the complexity and legacy cruft the the protocol itself, and the thing Debian projects are actually looking to do is exactly what the signify/minisign family of signature schemes does, using exclusively modern cryptography, with the simplest possible interface.
- xvilka 5y ago
  Makes sense if they don't plan it to become more accommodating and complex over time.
  - tptacek 5y ago
    Ironically, by using a modern, stripped down signing system like this, they've probably increased their opportunities to do interesting things down the road, since they don't have all the possible weird interactions with the PGP system to consider.
    - julian-klode 5y ago
      Still have to trust 1k RSA keys because GPG does not allow us to say they're unsafe.
      - deknos 5y ago
        i am pretty sure you can mark them yourself. but that they are generally still used, well that's called backwards compatibility. and that's needed.

nullc 5y ago

Doesn't appear to have any domain separation. This means that if a common private key is reused in another application you may be able to use that application as an oracle to produce signatures it doesn't intend to use. Say you later want to have packagers sign with the same keys for security announcements. Obviously not reusing keys is good but there are reasons people do that (e.g. to share the trust of an existing key). The lack of domain sep means stuff like a subkey itself is a valid payload signed by the master key. The modern advice is to personalize the hash function for each distinct application and use within the application. Signer is setup to have the whole input in memory at once. The protocol design makes it tricky to do otherwise without using two passes at best. This could be avoided if anyone cared, e.g. using a signing scheme with prehashing (which has its own obscure tradeoffs). This text says very little about validating trusted keys. A signature where you just take the pubkey from the input and don't validate it is essentially just a really computationally expensive hash and doesn't itself provide security. The text about validating all signatures regardless of trusted or not could be read as saying that you just accept stuff with valid signature regardless if they were being signed by the Evil League of Evil instead of an approved source. :) It uses ed25519 but doesn't do anything about inconsistent validation criteria ( https://hdevalence.ca/blog/2020-10-04-its-25519am https://hdevalence.ca/blog/2020-10-04-its-25519am ), different implementations consider non-overlapping sets of signatures valid. If you want to have automated klaxons on signature failures, this ought to be addressed for the same reason as "repositories do not fail for a subset of users". (though it's not fatal in this application as it is in consensus systems). The format will be a little clunky if used with post-quantum signatures, e.g. sphincs+ would have a couple kilobytes of signature data stuffed on a line. I don't have a real recommendation there other than saying you should probably have test vectors that have some couple-kilobyte-long examples. No obvious affordance for additional signed metadata, which is useful for forensics. So, for example, if a project has multiple parties with access to the keys they may want to tag which user(s) authorized the signature or included a timestamp. If their signing is performed by a HSM (e.g. something like USB armory that allows no user access) the consistency of their metadata could be preserved. This could probably be kludged on by requiring the metadata just be inside the payload somewhere. I like that there are subkeys with expiration. It's not entirely clear to me that it's supported to hand out multiple subkeys to different parties all with the same serial, and they stay all equally valid until a key is observed with a newer serial (at which point all subkeys need to be updated)? "Subkeys may reuse/share serial numbers provided" is confusing on this point. Good security practices suggest that if there are multiple places that can sign each should get its own subkey (so if there is a compromise you can isolate it), and this might mean that there are multiple subkeys in parallel all valid for a given trusted master. Personally, I'm a little disappointed to see a proposal for repository signing that doesn't include affordances for something like opentimestamps or a certificate-transparency like facility (e.g. to validate that parties aren't making backdoored alternative versions for private distribution). But I guess these could be overlaid as additional signature types and the idea is just to phase out pgp, not advance the security state of the art forward. Authors of this proposal should be aware the NSA has made a formal recommendation against the use of ECC with curves smaller than 384-bits. There are plenty of applications where compatibility, performance, or computational constraints make it attractive to stay with 256 bit options. But if I were doing something entirely greenfield where a double size key/signature would be a non-issue, I'd be really tempted to use ed448 instead: If nothing else, at least if there are problems in the future you at least didn't violate existing credible advice. :) (Really I'd want to use sphincs+ for something like this, but it's probably too premature). Considering how close to security theater package signing often is in practice, I'm not sure if it's worth worrying too much that the underlying cryptosystem might be stronger-- it's not the limiting factor.

julian-klode 5y ago

Please note that the spec is ahead of the implementation, and the project has been stale for 4 months. For spec and implementation to stay in sync, they'd have to be in the same repo I guess. For now, the spec is driving and the implementation catching up with it. For more background, see https://mastodon.social/@juliank/105679564085465156 https://mastodon.social/@juliank/105679564085465156

exabrial 5y ago

Do we ever learn anything from past security breaches? What is the compelling security reason to ditch pgp? The _one_ thing it is good at is long-term identity. There's ECDSA keys available now in PGP, and Ed25519 wouldn't be a stretch. This looks and smells like NIH syndrome. PGP has had a lot of time to bake. Let's make incremental improvements, not start all of over because you don't understand history. Oh and going all eggs in on one algorithm is stupid. Thinking there will never be problems with Ed25519 is naive. PGP was designed to be extended.

tptacek 5y ago
These ideas are pretty close to discredited in cryptography engineering. Diversity in signature algorithms doesn't help when everyone uses the same algorithm anyways, and, more importantly, a negotiated algorithm makes it harder to recover from an new attack on algorithms, not easier: with a non-negotiable algorithm, you version the entire repository, and can reliably rule out vulnerable signatures. Negotiation and downgrade attacks have been endemic in "ciphersuite" schemes. There's a reason the field is moving towards simple, modern schemes like this one, and Debian has more experience than most in trying to make broken, crufty old PGP work.
- exabrial 5y ago
  So, no.
  - tptacek 5y ago
    It's OK to just say "I have no idea what you're talking about".