ML-KEM- og ML-DSA-standardene lar deg begge lagre den private nøkkelen på to måter. Det finnes et lite seed, 64 byte for ML-KEM og 32 byte for ML-DSA, og det finnes en større utvidet form som utledes fra det seed gjennom en hashfunksjon(er). De to er matematisk likeverdige, og du kan gå fra frøet til den utvidede formen når som helst, men du kan ikke gå tilbake. Hvis du skal velge mellom hva du skal lagre som privat nøkkel, oppbevar frøet. Det er den egentlige hemmeligheten som alt annet stammer fra. Du kan utvide den til full nøkkel når som helst, og det tar omtrent 40 mikrosekunder, så det er egentlig ingen grunn til å lagre den utvidede versjonen på disk. Hvis du trenger det i minnet for gjentatte operasjoner, kan du bare utvide én gang ved lastetid. Frøet er bare tilfeldige bytes, så enhver verdi er en gyldig nøkkel. Den utvidede formen har en struktur; koeffisienter som må være innenfor området, en innebygd offentlig nøkkel, en hash som må matche, og standarden krever at du sjekker alt dette ved import. Det er mye mer opplagt for at ting kan gå galt som du rett og slett ikke har med et frø. Det er også et pågående serialiseringsproblem ved IETF hvor det nåværende kompromissformatet tillater både frøet og den utvidede nøkkelen å ligge i samme datastruktur. Det betyr at to konforme implementasjoner kan lese forskjellige felt fra samme toneart og ende opp med forskjellig nøkkelmateriale, noe du ikke ønsker fra et nøkkelformat. TL; DR: oppbevar frøet og utvid det ved bruk etter behov. Fullstendig gjennomgang nedenfor.