Les normes ML-KEM et ML-DSA vous permettent toutes deux de stocker la clé privée de deux manières. Il y a une petite graine, 64 octets pour ML-KEM et 32 octets pour ML-DSA, et il y a une forme élargie plus grande qui est dérivée de cette graine par le biais d'une ou plusieurs fonctions de hachage. Les deux sont mathématiquement équivalents et vous pouvez passer de la graine à la forme élargie quand vous le souhaitez, mais vous ne pouvez pas revenir en arrière. Si vous devez choisir ce que vous devez stocker comme clé privée, stockez la graine. C'est le véritable secret dont tout le reste est dérivé. Vous pouvez l'élargir en la clé complète chaque fois que vous en avez besoin, et cela prend environ 40 microsecondes, donc il n'y a pas vraiment de raison de stocker la version élargie sur disque. Si vous en avez besoin en mémoire pour des opérations répétées, élargissez-la simplement une fois au moment du chargement. La graine est juste des octets aléatoires, donc toute valeur est une clé valide. La forme élargie a une structure ; des coefficients qui doivent être dans une certaine plage, une clé publique intégrée, un hachage qui doit correspondre, et la norme exige que vous vérifiiez tout cela à l'importation. C'est beaucoup plus de surface pour que des choses se passent mal, ce que vous n'avez tout simplement pas avec une graine. Il y a aussi un problème de sérialisation en cours à l'IETF où le format de compromis actuel permet à la fois à la graine et à la clé élargie de se trouver dans la même structure de données. Cela signifie que deux implémentations conformes peuvent lire différents champs à partir de la même clé et se retrouver avec des matériaux de clé différents, ce qui n'est pas ce que vous voulez d'un format de clé. TL;DR : stockez la graine et élargissez-la à l'utilisation si nécessaire. Écriture complète ci-dessous.