6 ms·

Quite the opposite: keys are generated once per signing event, and the private key never leaves memory.

• remram 4y ago
  I'm not sure I understand this, why generate a key pair and sign, rather than simply using a hashing function?
  • kapilvt 4y ago
    verification of not just payload, but who/what signed, ie trust on who produced the artifact.
  • woodruffw 4y ago
    Hashing provides integrity, not authenticity. The idea behind sigstore is to enable an end user (which, for CPython, might be someone who intends to build it from source for inclusion in a package manager) to verify that the artifact is the same one produced by a trusted entity, not just the same one downloaded from a server. A strong cryptographic hash only provides the latter.
    • remram 4y ago
      Signing with a keypair you just generated doesn't provide any authenticity either...
      • woodruffw 4y ago
        The keypair is bound to a public identity via OIDC. That’s where the authenticity comes from; modulo a breach in GitHub’s IdP, you can be confident that the keypair corresponds to a signing action performed by the GitHub identity (either username or repository).
        • remram 4y ago
          > The keypair is bound to a public identity via OIDC It is not "bound" to anything cryptographically. Sigstore checks that you own the OIDC account, and if yes, it signs your public key and puts it in the log. Why not just sign your software's hash and put it in the log, "binding" it as you say?
          • woodruffw 4y ago
            This is true, but only because a cryptographic binding to the OIDC JWT would be meaningless. Fulcio could conceivably hash the JWT and add it as another certificate extension, but I don't see why it would (since nobody is expected to "burn" the JWT by publishing it after expiry). > Why not just sign your software's hash and put it in the log, "binding" it as you say? That's exactly what it's doing. Is the objection you have solely to the fact that it can be done with short-lived keys?
            • remram 4y ago
              See the sibling thread: https://news.ycombinator.com/item?id=33334598 https://news.ycombinator.com/item?id=33334598
  • di 4y ago
    Anyone can generate a hash. Signing with a private key means that only the owner of that private key was able to generate a given signature. Singing with a private key which was bound to a known identity via a signing certificate proves that only that identity was in possession of the signing key, during a very short window. In this specific case, we can say that the artifacts in question were verifiably signed by owner of the <release-manager>@python.org identity.
    • remram 4y ago
      But the key pair is not known, you have to put the public key in the trusted registry. Every time you sign, because you get a new key pair. Why not put a hash in that trusted registry instead?
      • di 4y ago
        That's the point of the certificate authority and transparency log: it makes the public key known by publicly binding it to a verifiable identity. A hash verifies integrity, but has no way to demonstrate any relationship to a signing identity. Signing is not just about integrity, but also being able to say _who_ generated the signature.
        • remram 4y ago
          I have no idea what you are saying concretely. The way it seems to me that it works: * You generate a keypair and use it to sign your Python installer (SP) * Authority creates a signature of your public key (SA) and puts the whole thing in transparency logs (SP + SA) * End users can check SA because they trust authority, can check SA is in transparency logs, therefore can trust your signature SP, therefore can trust your software Why not just use a hash instead: * You generate a hash of your Python installer (HP) * Authority creates a signature of your hash (SA) and puts it in transparency logs (H + SA) * End users can check SA because they trust authority, can check SA is in transparency logs, therefore can trust your hash, therefore can trust your software What matters is that ultimately the contents of your software are signed by the Authority and a commitment of that is in logs. Why add this level of keys, that can't possibly be trusted since they are ephemeral?
• LtWorf 4y ago
  How do I verify the file I download is the one that got signed?
  • di 4y ago
    Not sure if you're asking how to specifically do this for CPython, or how this works generally with Sigstore. For how this works specifically with CPython, see https://www.python.org/download/sigstore/ https://www.python.org/download/sigstore/ for details. For how this works generally: it's the same public/private key cryptography you're used to elsewhere, and https://docs.sigstore.dev/ https://docs.sigstore.dev/ has more details.
    • LtWorf 4y ago
      But so, basically, it's a root certificate that signs the key…
      • woodruffw 4y ago
        It’s very close to the existing PKI ecosystem for TLS: the CA is presented a possession proof for the locally held private key, and mints a signing certificate for it. There is no singular “root certificate”: there’s a trust root for the CA, a separate root for the transparency log, etc.
      • di 4y ago
        Nope. The private key is generated within the client each time a signing event occurs, and that's what is used to sign the artifact. It doesn't come from the certificate. The certificate just binds the public key to the identity at a given point in time, in a public way. This certificate is generated every time you sign something, and is put in the transparency log. There's a walkthrough of the process here that might be helpful: https://www.youtube.com/watch?v=jdf-gNYg0fw&t=494s https://www.youtube.com/watch?v=jdf-gNYg0fw&t=494s