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

[Orie Steele <[e-mail]>]

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>