Using SHA384 (or other) digests

[ctron]

Using Fulcio, it is possible to request different key (and digest) configuration. ECDSA256 with SHA256, but also ECDSA384 with SHA384 (among others).

However, in Rekor it seems that it is only possible to store SHA256 hashes:

rekor/pkg/types/hashedrekord/v0.0.1/hashedrekord_v0_0_1_schema.json

Lines 38 to 42 in 187df73

	"algorithm": {
	"description": "The hashing function used to compute the hash value",
	"type": "string",
	"enum": [ "sha256" ]
	},

So my understanding, this limits using Fulcio to an ECDSA256/SHA256 configuration?

How it is possible to user other digest algorithms with Rekor?

[bobcallaway]

If I understand your question, I think you might be confusing the digest algorithm used to digitally sign the code signing certificate, which can differ from the digest algorithm used to generate the detached signature over the artifact (which we only support SHA256 right now for uploads to Rekor using the hashedrekord type).

We could add other algorithms in the enum, and switch to using the requested algorithm during the validation on insert within Rekor.

[ctron]

I think there are two aspects on this:

a) If I choose SHA384 for the code signing certificate, why would I want to be limited to SHA256 for the blob?
b) To my understanding (and I might be wrong here), requesting an ECDSA-P384-SHA384 signing certificate, gives you a private key of the 384bits length. According to RFC6979 (https://www.rfc-editor.org/rfc/rfc6979#section-2.4) the length of the output of the hash function, should be roughly equal to the length of the private key component:

Normally, H is chosen such that its output length hlen is roughly equal to qlen, since the overall security of the signature scheme will depend on the smallest of hlen and qlen; however, the relevant standards support all combinations of hlen and qlen.

From what I understand, this means that signing a digest of SHA256 with a key for P384, would reduce the security to 256 bits.

And I guess this is why some implementations, like the ones from Rust Crypto, actually prevent you from doing this.

[haydentherapper]

This came up again - Someone was using ECDSA P-521 which requires sha512

[znewman01]

For the blob, that's a little bit awkward—we stick the blobs in a Merkle tree using SHA256, so "extra" security for hashing the blob doesn't make theoretical sense. We also sign the entries using the Rekor public key, which uses SHA256.

I guess the Rust Crypto philosophy (forbid you from accidentally doing something that reduces the security level) would say "you shouldn't be able to sign with anything stronger" and "you shouldn't be able to hash your blobs with anything stronger." However, I think in practice we do want to allow signatures using algorithms that use SHA384/SHA512; we had a request over at Cosign for this: sigstore/cosign#2907