ECDSA et RSA signent toujours un condensat : les données peuvent donc être hachées en flux ou sur une autre machine, et un HSM ne voit jamais que 32 à 64 octets. PureEdDSA et ML-DSA traitent au contraire le message entier avec des valeurs qui dépendent de la clé (le nonce et le challenge d’EdDSA hachent tous deux le message ; ML-DSA lie un condensat de la clé publique à son représentant de message μ) : le message complet doit donc parvenir au signataire.
Des variantes avec pré-hachage existent pour ce cas : Ed25519ph et Ed448ph (RFC 8032 ; HashEdDSA dans FIPS 186-5 §7.8), HashML-DSA (FIPS 204 §5.4) et HashSLH-DSA (FIPS 205 §10.2.2), ces deux dernières intégrant l’OID de la fonction de hachage dans ce qui est signé. Ce sont des algorithmes distincts aux signatures distinctes : un vérificateur de la variante pure les rejette. FIPS 204 permet aussi d’exécuter hors du module de signature toutes les étapes de ML-DSA sauf la génération de l’aléa de signature, ce dont se servent les interfaces de HSM pour accepter un μ précalculé.
Le pré-hachage fait dépendre la sécurité de la résistance aux collisions de la fonction de hachage, alors qu’EdDSA pur tolère les collisions de hachage. Utilisez les variantes pures sauf si le traitement en flux ou un signataire distant impose le contraire, et ne mélangez jamais les deux variantes sous une même clé sans séparation de domaine (RFC 8032 §8.6 ; FIPS 204 recommande une seule variante par clé).