does TLS 1.3 use ECDSA-Sig-Value encoded signatures for Ed25519 / Ed448?

Question

Quoting The Transport Layer Security (TLS) Protocol Version 1.3:

ECDSA algorithms Indicates a signature algorithm using ECDSA [ECDSA], the corresponding curve as defined in ANSI X9.62 [X962] and FIPS 186-4 [DSS], and the corresponding hash algorithm as defined in [SHS]. The signature is represented as a DER-encoded [X690] ECDSA-Sig-Value structure.

...

EdDSA algorithms Indicates a signature algorithm using EdDSA as defined in [RFC8032] or its successors. Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants.

ECDSA-Sig-Value is defined thusly:

ECDSA-Sig-Value ::= SEQUENCE {
  r  INTEGER,
  s  INTEGER
}

RFC8032: Edwards-Curve Digital Signature Algorithm (EdDSA) says the following about the signature format:

6. Form the signature of the concatenation of R (32 octets) and the little-endian encoding of S (32 octets; the three most significant bits of the final octet are always zero).

I don't see why ECDSA-Sig-Value couldn't be used with EdDSA in TLS 1.3 but that doesn't mean that it is. Indeed, I'm guessing that it isn't and that you're supposed to use the RFC8032 construction?

Answer 1

EdDSA is a family of signature schemes defined precisely on strings of bytes, including its extension to more curves like edwards448. This generally avoids failures of security theorems in the real world arising from a mismatch between powers of an adversary on a system of strings of bytes and powers of an adversary on a system of idealized mathematical objects. The choice was motivated by failures of exactly that type in HMQV observed by Menezes.

Any software implementing Ed25519 will generally be byte-for-byte compatible. The TLS stack need not know anything about its mathematical structure. It is enough to know that a secret signing key has a standard 32-byte representation, that a public verification key has a standard 32-byte representation, that a signature has a standard 64-byte representation, and that the definition of Ed25519 entails the precise relations between these byte strings. In contrast, ECDSA leaves needlessly complicated details to the caller to sort out—or to botch with additional ASN.1 attack surface and logic to interpret the mathematical structure in ECDSA.

In this specific case, although the parts of a signature may be named by the letters ‘r’ and ‘s’ in both ECDSA and EdDSA, and although they may be represented by integers, they actually represent different types of object with different rôles in the signature verification equation. For an elliptic curve $E/k$ over the field $k = \mathbb Z/q\mathbb Z$ for some prime power $q$, with $k$-rational group $E(k)$ of order $h\ell$:

• An ECDSA signature is some representation, with whose details the caller must be concerned, a field element $r \in \mathbb Z/q\mathbb Z$ and a scalar $s \in \mathbb Z/\ell\mathbb Z$. It is valid on a message $m$ under a public key that is a curve point $A \in E(k)$ if and only if $$r \equiv x([H(m)\cdot s^{-1}]B + [r s^{-1}]A) \pmod p,$$ where $B$ is the standard base point.

• An EdDSA signature is a standard byte string representing of a curve point $R \in E(k)$ and a scalar $s \in \mathbb Z/hl\mathbb Z$. It is valid on a message $m$ under a public key that is the standard encoding of a curve point $A \in E(k)$ if $$[8 s]B = [8]R + [8 H(R\mathbin\|A\mathbin\|m)] A,$$ where $B$ is the standard base point.