Communicating signing algorithm and parameters

[secure-systems-lab]

Communicating signing algorithm and parameters

[MarkLodato]

I recommend against this. Such a feature has a history of security vulnerabilities, as @trishankatdatadog has said. The recommended solution is to make this a property of the public key so that only one algorithm can be used per key. If the public key / certificate does not indicate the hash algorithm (as is the case with x.509 certificates for ECDSA), then the application can hard-code a mapping as JWS does. For example, P-256 => SHA-256, P-384 => SHA-384, etc.

@laurentsimon can further expand if needed.

[trishankatdatadog]

This shouldn't be part of the signature, no. It should be part of the signed message. Otherwise you run into the same high-severity security issue CS-DRNT15-1 identified here.

[iamwillbar]

@trishankatdatadog thanks for sharing that, wasn't aware of that particular vulnerability. It can't be part of the payload because the envelope is agnostic of the payload but it could be in the envelope.

The specification does allow different signatures to use different algorithms (or at least doesn't appear to not allow that) so it could be in the signature block as long as it was incorporated into the PAE when generating the signature.

[trishankatdatadog]

The specification does allow different signatures to use different algorithms (or at least doesn't appear to not allow that) so it could be in the signature block as long as it was incorporated into the PAE when generating the signature.

The envelope alone cannot safely solve this issue. I think it is a lower-level issue.

[mnm678]

As @trishankatdatadog mentioned, the signing algorithm needs to be included in a trusted location. Another solution to the issue of determining the algorithm could be to define the algorithm when the key is delegated to or initially distributed

[dlorenc]

Yeah, including it on the key is the typical solution.

[trishankatdatadog]

For example, like so

[laurentsimon]

As others pointed out, the key type or other key metadata should never be taken from a parameter that is attacker-controlled or something that may be tampered with by an attacker. Having such a field is a source of vulnerabilities known as 'in-band key negotiations'.

It's a common problem in JWS (alg:none or mis-interpreting an RSA key as an HMAC key, see this example). This is still a source of vulnerabilities today, see here for a recent example. AWS cloud crypto library was also found vulnerable to this sort of attack last year - an attacker could change a ciphertext type from AES-GCM to AES-CBC and use the decrypter as a decryption oracle - see here and here.

We should think as keys not just as raw bytes, but as raw bytes + metadata. The metadata should contain all the parameters that are necessary to instantiate a signing or verification routine (signature type, hash type, etc). The TUF's format works, so long as the key is retrieved from a trusted location, for example signed by a trusted server/CA or communicated out-of-band - the latter does not scale well, though.

Theoretically, one can use x509 certificates as source of truth. There is a caveat Mark pointed out: algorithms defined using the Subject Public Key Info structure can describe all the necessary parameters for RSA signing keys, but not the hash algorithm for ECDSA. In the RSA case, the specification needs to be clear what the recipient should do if a cert does not define the hash: fail or default to, say, SHA512. In the ECDSA case, the specifications should define a mapping between ECDSA key sizes and hash algorithms. For example, P-256 => SHA-256, P-384 => SHA-384. An even simpler solution is to take the view that verification and signing operations will be performed on server machines (64bit arch) where SHA512 is faster. Ed25519 takes this approach and uses SHA512 even though it's a 265bit curve.

[iamwillbar]

Thanks for the education all! I'll concede this is a bad idea 😄.

[trishankatdatadog]

Thanks, Will, takes a lot to admit when incorrect.