[CFRG] Re: Rigid generation of RSA from a seed.

[Phillip Hallam-Baker <[e-mail]>]

Interesting,

The reason I went down this path was to allow for key recovery. Imagine you
are a refuge. Your house etc. are all destroyed. Your entire digital
gestalt is encrypted in the cloud. How can you reclaim it?

The Mesh allows you to create recovery shares for your primary seed using
Shamir/LaGrange secret sharing. So if you can get to 2 out of your three
shares, you can get everything back.

I use the same seed to create the root signature key for the personal PKI
and the primary escrow key to which all escrowed encryption keys are
encrypted. The KDF has different info mixins for different key types.

This approach allows me to easily split off additional keys and maximize
cryptographic hygiene. So I have separate keys for transport
encryption/authentication and for stored data encryption allowing me to
only escrow the stored data keys.

Why those particular curves? I am doing NIST P256/P384/P521 and
Ed25519/Ed448/X25519/X448 for ECC because that is what I see used in SSH,
Open PGP etc.




On Mon, Sep 9, 2024 at 10:21 AM Orie Steele <[e-mail]>
wrote:

> I did something similar for DIDs... by extending BIP32 / BIP39 / BIP44
> beyond secp256k1 to ed25519 and bls12381 (I didn't cover secp256r1, or the
> other P curves)
>
>
> https://did.key.transmute.industries/generate/ed25519?seed=824c576ef63ea1e37a8820236acf37a97cb8c4432afd7172ee682f95b4b38725 (
> a smarter strategy would be to put the seed in the fragment of the URL ).
>
> did key is basically a URN for public keys... when the public key can be
> converted to a blockchain / asset network address, you can also think of
> the did key as a URN for receiving / sending payments.
>
> This was just an experiment, obviously the same seed should not be used
> for multiple key types at the same time, etc... (lots of mistakes were made
> here, feel free to point them out.).
>
> There is some related work here:
>
> - https://eprint.iacr.org/2014/998.pdf
> - https://ieeexplore.ieee.org/document/7966967
>
> The recent discussion of using KDFs to expand z and d in ML-KEM reminded
> me of this design.
>
> ... I was wondering about generating ML-KEM + ML-DSA keys from a single
> seed... With Ed25519 and X25519 there is point conversion which can be used
> to produce similar (not the same) results:
> https://libsodium.gitbook.io/doc/advanced/ed25519-curve25519
>
> In a constrained environment, it can be nice to generate keys
> deterministically, and not need a separate deterministic key generation
> algorithm per key type.
>
> If you start with an Ed25519 seed, you can convert any Ed25519 key to an
> X25519 key, and use some algorithm to generate unique key pairs per
> interaction that can support both signing and key establishment.
>
> OS
>
>
> On Sat, Sep 7, 2024 at 12:53 PM Phillip Hallam-Baker <
> [e-mail]> wrote:
>
>> I have implemented a scheme to perform rigid generation of RSA keys based
>> on FIPS 185-5
>>
>> The basic idea is that starting with a seed with a particular work
>> factor, we can generate the public keypair in a deterministic manner. This
>> approach provides a verifiable means of key generation. The application
>> that is accepting the private key can check that it has been correctly
>> constructed in accordance with best practice.
>>
>> The seeds could be encoded in a private key info structure same as for
>> ML-KEM, Ed448 etc. Or they can be specified in a human readable form. For
>> example, the following UDF key generation string has a 128 bit work factor:
>>
>> ZAAA-Q4DQ-QCO4-7TEG-WJYB-QD5B-YAXL-EMY
>>
>> It generates a 2048 bit key in about 2 seconds on my machine using the
>> FIPS 185-5 scheme generating two auxiliary primes used to construct p an q.
>>
>> Or you can generate the same key in a fraction of a second by adding a
>> hint string:
>>
>> FGCA-GSAS-IYIQ-GAY
>>
>> This specifies the number of rounds needed to derive p and q, the
>> auxiliary primes and a qualified seed for p and q in that order using a
>> simple run encoding scheme.
>>
>> And of course this can be expressed as a URI:
>>
>> udf:ZAAA-Q4DQ-QCO4-7TEG-WJYB-QD5B-YAXL-EMY:FGCA-GSAS-IYIQ-GAY
>>
>>
>> At this point, the main use I have for the scheme is in testing. I can
>> set up a test vector really easily:
>>
>> udf:ZAAA-Q-MY-SSH-TEST-KEY:SICM-CBAP-DEDU-UAQL
>>
>> And of course, I have the same scheme for Ed448, X448, ML-KEM, ML-DSA and
>> I am about to add P256, P384 and P521.
>>
>>
>> I make use of the scheme in the Mesh to provision keys to devices. The
>> idea of the Mesh being that Alice has 100 devices ranging from laptops
>> where she does coding to coffee pots and light switches. The Mesh squirts
>> the set of keys each device needs to perform its assigned purposes.
>>
>> Having a consistent, rigid means of generating the keys allows the
>> degree of trust to be minimized.
>>
>> _______________________________________________
>> CFRG mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>