[lamps] Re: [EXTERNAL] Re: Seed as private key for ML-DSA and ML-KEM

[Mike Ounsworth <[e-mail]>]

Sure, but also sometimes keys have a 30 year service lifetime, and you may need to replace the hardware (ie migrate the private keys) at some point in that interim, with the right level of admin access, you can migrate keys.

 

The point I’m making is that if we only standardize P12’s with the seed, then that’ll inevitably end up being one more barrier to migrating keys off old devices, in this case, when the device stored the expanded key and does not have the seed available anymore.

 

---

Mike Ounsworth

 

From: Phillip Hallam-Baker <[e-mail]> 
Sent: Thursday, August 22, 2024 5:32 PM
To: Mike Ounsworth <[e-mail]>
Cc: David Benjamin <[e-mail]>; Bas Westerbaan <[e-mail]>; LAMPS <[e-mail]>
Subject: Re: [lamps] Re: [EXTERNAL] Re: Seed as private key for ML-DSA and ML-KEM

 

Isn't the point of being an HSM to resist that type of reverse engineering in a 'don't even try that fuming nitric acid with me' sort of fashion? On Thu, Aug 22, 2024 at 4: 23 PM Mike Ounsworth <Mike. Ounsworth=40entrust. com@ dmarc. ietf. org>



Isn't the point of being an HSM to resist that type of reverse engineering in a 'don't even try that fuming nitric acid with me' sort of fashion?

 

On Thu, Aug 22, 2024 at 4:23 PM Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:[e-mail]> > wrote:

Observation: you can trivially go from seed -> full key, but not full key --> seed.  – at least I’m not seeing anything in FIPS 203 Algorithm 13 that the seed `d` is included in the decryption key `dk_pke`.

 

As the guy whose company gets called in when people have broken their on-prem PKIs, if we only allow seeds in P12’s, then I foresee problems where an HSM company goes out of business and we need to get keys out of that hardware, and they chose to only store the expanded private key and so can’t give us the seed even if we ask nicely: now we can’t use standard private key transports and will have to kludge something. The point of a standard is to be standard – to say that you’re allowed to store the key expanded internally, but then you’ll be up a creek without a paddle if you want to export it, feels wrong.

 

 

“2. Allow both seed and the expanded private key” ends up looking something like this: 

This would certainly not be the most complicated thing in RFC 5912.

 

ML-*-PrivateKey ::= CHOICE {

   seed               [0] SIZE 32 OCTET STRING,

   full                  [1] OCTET STRING,

   seedAndFull   [2] SeedAndFull

}

 

SeedAndFull ::= SEQUENCE {

   seed   SIZE 32 OCTET STRING,

   full      OCTET STRING

}

 

---

Mike Ounsworth

 

From: David Benjamin < <mailto:[e-mail]> [e-mail]> 
Sent: Wednesday, August 21, 2024 1:04 PM
To: Bas Westerbaan <bas= <mailto:[e-mail]> [e-mail]>
Cc: LAMPS < <mailto:[e-mail]> [e-mail]>
Subject: [EXTERNAL] [lamps] Re: Seed as private key for ML-DSA and ML-KEM

 

I'm also sold on option 4. On Wed, Aug 21, 2024, 11: 50 Bas Westerbaan <bas=40cloudflare. com@ dmarc. ietf. org> wrote: Hi all, NIST allows two formats in which private keys are stored ML-DSA and ML-KEM. 1. Seed. 32 bytes for ML-DSA; 64

I'm also sold on option 4.

On Wed, Aug 21, 2024, 11:50 Bas Westerbaan <bas=[e-mail] <mailto:[e-mail]> > wrote:

Hi all,

 

NIST allows two formats in which private keys are stored ML-DSA and ML-KEM.

 

1. Seed. 32 bytes for ML-DSA; 64 bytes for ML-KEM.

2. Expanded private key. Multiple kilobytes depending on instance.

 

An expanded private key is obtained from the seed by calling the KeyGen_internal function.

 

In contrast to RSA, key generation for these algorithms is very fast. In fact, if you use spinning disks, then using a seed is probably faster than the expanded private key.

 

Another advantage is that we do not need to worry about private key validation. NIST specified a few checks to perform, but there are more we could do (eg. whether the decoded coefficients of \hat{s} are bounded.)

 

Of course a big advantage is storage space: the seeds are much smaller.

 

Now, how do we want to proceed? I see a few options.

 

1. Ignore the seed as private key.

 

2. Allow both seed and the expanded private key.

 

3. Assign separate algorithm for seed-as-private-key.

 

4. Switch to seed as private key only.

 

I prefer 4, and would otherwise go for 1.

 

The downside of 2 is that it adds complexity without the gain of simplifying verification. If one only cares about size savings, then one can use seed-as-private-key without needing a portable format for it.

 

So I'd prefer 4 and 1 second.

 

Best,

 

 Bas

_______________________________________________
Spasm mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
Spasm mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>