Skip to main content

2. Signature Algorithms

  1. Signature Algorithms

Section 8.1 of [RFC9052] contains a generic description of signature algorithms. This document defines signature algorithm identifiers for two signature algorithms.

2.1. ECDSA

The Elliptic Curve Digital Signature Algorithm (ECDSA) [DSS] defines a signature algorithm using Elliptic Curve Cryptography (ECC). Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithm allows systems to avoid relying on random number generators in order to avoid generating the same value of "k" (the per-message random value). Biased generation of the value "k" can be attacked, and collisions of this value lead to leaked keys. It additionally allows performing deterministic tests for the signature algorithm. The use of deterministic ECDSA does not lessen the need to have good random number generation when creating the private key.

The ECDSA signature algorithm is parameterized with a hash function (h). In the event that the length of the hash function output is greater than the group of the key, the leftmost bytes of the hash output are used.

The algorithms defined in this document can be found in Table 1.

          +=======+=======+=========+==================+
          | Name  | Value | Hash    | Description      |
          +=======+=======+=========+==================+
          | ES256 |   -7  | SHA-256 | ECDSA w/ SHA-256 |
          +-------+-------+---------+------------------+
          | ES384 |  -35  | SHA-384 | ECDSA w/ SHA-384 |
          +-------+-------+---------+------------------+
          | ES512 |  -36  | SHA-512 | ECDSA w/ SHA-512 |
          +-------+-------+---------+------------------+

                 Table 1: ECDSA Algorithm Values

This document defines ECDSA as working only with the curves P-256, P-384, and P-521. This document requires that the curves be encoded using the "EC2" (two coordinate elliptic curve) key type. Implementations need to check that the key type and curve are correct when creating and verifying a signature. Future documents may define it to work with other curves and key types in the future.

In order to promote interoperability, it is suggested that SHA-256 be used only with curve P-256, SHA-384 be used only with curve P-384, and SHA-512 be used only with curve P-521. This is aligned with the recommendation in Section 4 of [RFC5480].

The signature algorithm results in a pair of integers (R, S). These integers will be the same length as the length of the key used for the signature process. The signature is encoded by converting the integers into byte strings of the same length as the key size. The length is rounded up to the nearest byte and is left padded with zero bits to get to the correct length. The two integers are then concatenated together to form a byte string that is the resulting signature.

Using the function defined in [RFC8017], the signature is:

Signature = I2OSP(R, n) | I2OSP(S, n)

where n = ceiling(key_length / 8)

When using a COSE key for this algorithm, the following checks are made:

  • The "kty" field MUST be present, and it MUST be "EC2".

  • If the "alg" field is present, it MUST match the ECDSA signature algorithm being used.

  • If the "key_ops" field is present, it MUST include "sign" when creating an ECDSA signature.

  • If the "key_ops" field is present, it MUST include "verify" when verifying an ECDSA signature.

2.1.1. Security Considerations for ECDSA

The security strength of the signature is no greater than the minimum of the security strength associated with the bit length of the key and the security strength of the hash function.

Note: Use of a deterministic signature technique is a good idea even when good random number generation exists. Doing so both reduces the possibility of having the same value of "k" in two signature operations and allows for reproducible signature values, which helps testing. There have been recent attacks involving faulting the device in order to extract the key. This can be addressed by combining both randomness and determinism [CFRG-DET-SIGS].

There are two substitution attacks that can theoretically be mounted against the ECDSA signature algorithm.

  • Changing the curve used to validate the signature: If one changes the curve used to validate the signature, then potentially one could have two messages with the same signature, each computed under a different curve. The only requirements on the new curve are that its order be the same as the old one and that it be acceptable to the client. An example would be to change from using the curve secp256r1 (aka P-256) to using secp256k1. (Both are 256-bit curves.) We currently do not have any way to deal with this version of the attack except to restrict the overall set of curves that can be used.

  • Changing the hash function used to validate the signature: If one either has two different hash functions of the same length or can truncate a hash function, then one could potentially find collisions between the hash functions rather than within a single hash function. For example, truncating SHA-512 to 256 bits might collide with a SHA-256 bit hash value. As the hash algorithm is part of the signature algorithm identifier, this attack is mitigated by including a signature algorithm identifier in the protected-header bucket.

2.2. Edwards-Curve Digital Signature Algorithm (EdDSA)

[RFC8032] describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for the edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing, and HashEdDSA, where a hash function is applied to the content before signing and the result of that hash function is signed. For EdDSA, the content to be signed (either the message or the prehash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. Therefore, there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE object (with the hash value) and the content as separate items.

The algorithm defined in this document can be found in Table 2. A single signature algorithm is defined, which can be used for multiple curves.

                  +=======+=======+=============+
                  | Name  | Value | Description |
                  +=======+=======+=============+
                  | EdDSA |   -8  | EdDSA       |
                  +-------+-------+-------------+

                   Table 2: EdDSA Algorithm Value

[RFC8032] describes the method of encoding the signature value.

When using a COSE key for this algorithm, the following checks are made:

  • The "kty" field MUST be present, and it MUST be "OKP" (Octet Key Pair).

  • The "crv" field MUST be present, and it MUST be a curve defined for this signature algorithm.

  • If the "alg" field is present, it MUST match "EdDSA".

  • If the "key_ops" field is present, it MUST include "sign" when creating an EdDSA signature.

  • If the "key_ops" field is present, it MUST include "verify" when verifying an EdDSA signature.

2.2.1. Security Considerations for EdDSA

Public values are computed differently in EdDSA and Elliptic Curve Diffie-Hellman (ECDH); for this reason, the public key from one should not be used with the other algorithm.

If batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED (Section 8.2 of [RFC8032]). Signing and nonbatch signature verification are deterministic operations and do not need random numbers of any kind.

Last updated on