ML-KEM och ML-DSA-standarderna låter dig båda lagra den privata nyckeln på två sätt. Det finns ett litet seed, 64 byte för ML-KEM och 32 byte för ML-DSA, och det finns en större expanderad form som härleds från det seed via en hashfunktion(er). De två är matematiskt likvärdiga och du kan gå från fröet till den utökade formen när du vill, men du kan inte gå tillbaka. Om du väljer mellan vad du ska lagra som privat nyckel, förvara fröet. Det är den faktiska hemligheten som allt annat härstammar från. Du kan utöka den till full nyckel när du behöver, och det tar ungefär 40 mikrosekunder, så det finns egentligen ingen anledning att lagra den utökade versionen på disk. Om du behöver det i minnet för upprepade operationer, expandera bara en gång vid laddningstid. Seeden är bara slumpmässiga bytes så vilket värde som helst är en giltig nyckel. Den utvidgade formen har en struktur; koefficienter som måste vara inom intervall, en inbäddad publik nyckel, en hash som måste matcha, och standarden kräver att du kontrollerar allt detta vid import. Det är mycket mer ytlig för saker att gå fel som du helt enkelt inte har med ett frö. Det finns också ett pågående serialiseringsproblem vid IETF där det nuvarande kompromissformatet tillåter både seed och expanderad nyckel att ligga i samma datastruktur. Det betyder att två konforma implementationer kan läsa olika fält från samma tonart och sluta med olika nyckelmaterial, vilket inte är något du vill ha i ett nyckelformat. TL; DR: förvara fröet och utöka det vid användning vid behov. Fullständig sammanfattning nedan.