cosign icon indicating copy to clipboard operation
cosign copied to clipboard

Allow configurable signing algorithms

Open tetsuo-cpp opened this issue 2 years ago • 3 comments

Description

I've filed similar issues under Cosign and Rekor. I realise there's a lot of overlap in maintainers, but wanted to make sure that we discuss each project that we plan to touch. Apologies if this feels a bit spammy.

Hi there! At Trail of Bits, we're looking at potentially implementing part of the Configurable Crypto Algorithms proposal (specifically Phase 1). I wanted to float this idea to each of the relevant Sigstore sub-projects so we can hash out the details in a more concrete way.

Across the Sigstore stack, we default to using ECDSA for signatures and SHA256 for hashing. There's more detail in the linked proposal but there are a number of motivations for wanting to customise the signatures that are generated, including paving the way for post-quantum signatures. The proposed design includes having a "supported algorithm" registry (perhaps this can go in the Protobuf specs) that outlines enumerates the approved signature/hash algorithm combinations. We specifically don't want to allow arbitrary mixing and matching of signature and hash algorithm to avoid some of the security pitfalls listed in the proposal.

For Cosign, we want to support this set of approved signing algorithms. This can be as simple as a --signing-algorithm flag. As a first pass, we'd like to support ECDSA with SHA256 and SHA384 as well as EdDSA, with ECDSA-SHA256 remaining as the default.

I believe that in order to change this, we may have to make changes to the sigstore-go and sigstore libs, but I figured that I'd make the issue here since cosign is going to be entrypoint for this functionality.

tetsuo-cpp avatar Oct 02 '23 09:10 tetsuo-cpp

Some notes. ECDSA is assumed in the following places:

  • cosign.GeneratePrivateKey, used from GenerateKeyPair(called when doing cosign generate-key-pair) and from signerFromNewKey (called when doing cosign sign-blob and generating an ephemeral key for getting the certificate)
  • cosign.ImportKeyPair handles only RSA, ECDSA, and ED25519 keys. This function is used in the cosign import-key-pair command
  • cosign.LoadPrivateKey
  • signer/verifier objects: https://github.com/sigstore/sigstore/tree/main/pkg/signature here ECDSA is assumed.
  • LoadVerifier, used on the verify side (e.g. cosign verify-blob) to load a verifier for the right algo.

ret2libc avatar Oct 09 '23 13:10 ret2libc

This is awesome!

dlorenc avatar Oct 09 '23 14:10 dlorenc

For the public instance, the TUF root keys will need to be rotated to PQ keys and the metadata will also need to be re-signed. We also have online KMS keys that sign the snapshot and target metadata that will either need to be rotated to PQ KMS keys (once that's supported). Note that the TUF reference implementation only mentions RSA, ECDSA and ed25519 (https://theupdateframework.github.io/specification/latest/#keytype) so that should be updated too.

Hayden-IO avatar Oct 23 '23 19:10 Hayden-IO

Has there been any updates since? Supporting post-quantum signatures would be a major push in the right direction.

caretak3r avatar Apr 30 '25 20:04 caretak3r

@caretak3r yes, see https://github.com/sigstore/cosign/pull/4050 and https://github.com/sigstore/cosign/pull/3497 .

ret2libc avatar May 06 '25 07:05 ret2libc

#4050 has been merged!

Hayden-IO avatar Sep 02 '25 22:09 Hayden-IO

Going to call this wrapped up now. We've got one open PR for fixing an issue with ed25519 keys, but otherwise this is done.

Hayden-IO avatar Nov 03 '25 04:11 Hayden-IO