# Which hash is used when providing signature algorithm ED25519 or ED448?

From TLS 1.3 there are two signature algorithms using edDSA:

      /* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),


All the other signature-schemes provide hash information, for example:

ecdsa_secp256r1_sha256 => sha256

rsa_pkcs1_sha384 => sha384

How can I determine when receiving edDSA signature algorithm which hash to use?

Is there any default value for each one of them?

• It's already defined as a part of those signing algorithms, and any existing implementation will use the correct standardized one for each of those two – Natanael Feb 26 '19 at 13:52

If you follow the references in RFC 8446, you'll see that it cites RFC 8032 for the definition of the EdDSA-based algorithms. RFC 8032 in turn tells you all the details about the hash functions and other parametrization—field, curve equation, base point, encoding, signature equation, etc.—of EdDSA for Ed25519 and Ed448.

There are several roles for a hash function involved in RFC 8032: a prehash (peculiar to RFC 8032, added in order to placate users of shoddy designs that invite DoS attacks), a key-derivation hash, a per-signature pseudorandomization hash, and a message hash.

Ed25519 uses SHA-512 for all these purposes; Ed448 uses SHAKE256. But none of these choices concern you as a user of Ed25519 or Ed448: The choice of hash functions is a part of the signature scheme itself, not a parameter chosen or computed by a user.

The other signature methods in TLS are relics from days of yore when it was common to present users with a dizzying array of acronym soup options: Which mathematical magic do you want to use like RSA ($$s \equiv h^e \pmod n$$), ECDSA ($$r \equiv x([h s^{-1}]G + [r s^{-1}]A]) \pmod p$$), etc.; and separately, how do you want to be vulnerable to collisions in computing $$h$$ from a message $$m$$ like MD5, SHA-1, etc.? This era gave us delightfully nonsensical names like md5WithRSAEncryption (a.k.a. 1.2.840.113549.1.1.4) for signature schemes.

The modern approach is to use a short name Ed25519 for a complete signature scheme on messages providing 128-bit security against existential unforgeability under adaptive chosen message attack, with all knobs and parameters and bells and whistles decided for you. An implementation of Ed25519 or Ed448 operates on bit strings of arbitrary length and structure, and does all of this hashing internally—in fact, it's not even defined in terms of a fixed hash $$H(m)$$ of a message; instead it's defined in terms of a pseudorandom function $$H(k, m)$$ of the message where $$k$$ is part of the secret key.

• So if I understand it right, when verifying a signature of Ed25519 as a client, there's no need for computation of the hash in advance? Instead, the context together with the secret is sent to the function and it's internally computed with the signing itself? – Martin Feb 27 '19 at 7:50
• @SilentBash Correct. In fact, Ed25519 doesn't even involve $\operatorname{SHA512}(m)$ per se at all. Rather, it involves $\operatorname{SHA512}(k \mathbin\| m)$, where $k$ is part of the long-term secret key, and $\operatorname{SHA512}(R \mathbin\| A \mathbin\| m)$, where $R$ is half of the signature and $A$ is the public key. – Squeamish Ossifrage Feb 27 '19 at 7:52

Hash algorithms:

• Ed25519 uses SHA-512 (As referenced on wikipedia or on bearssl.org)
• Ed448 uses SHAKE-256$$^1$$ (As referenced on bearssl.org)

$$^1$$ SHAKE-256 is a SHA-3 algorithm, a subgroup of the "Keccak" family.