Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F71C1D52EF for ; Mon, 9 Sep 2024 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzHArVeQkRob for ; Mon, 9 Sep 2024 09:22:04 -0700 (PDT) Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC3FC1D52FB for ; Mon, 9 Sep 2024 09:22:04 -0700 (PDT) Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-5e1c65eb5bbso1030379eaf.1 for ; Mon, 09 Sep 2024 09:22:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725898923; x=1726503723; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CVPuKJY5wA6jGuJNlTHO+woxOM+iizY7eMT755/uA4c=; b=aEY2V3MXHpMWyVItRAtGKAuAdYi2QDDDcjHwbkFGS4Vprzx1hKW6+ZfZ3tU4tM7Bz2 0d064dJx7kTqSugkH3k1jrBu43KPm5Vdd/6jZj6VnYWDIwYptwFiAGwxoncoqLw8/PF9 qLrmYGNoMr/gdDZhZaoD+Q0ljpMZeqyAH9e1tm3NR+kYrHgbCkWV04fonI3ozxIaEEMC g6bGf5s6kNSJrhyesdfKHjxYEFFIZ0YrUx1EFvlGxeZv67lYSmoB6Qf3eHDetYpfqhqr k5pqhU9zm8IaIbcFj3IvBPwUxCfVQh6Dv2+K/I14FD3G8xX58PrAz2eMU+wTwnDNFmbG 90ig== X-Gm-Message-State: AOJu0Yy/q9v1VaOavMWnQCzebILgpTZi3Ue/RbI7lJiBQFfgIk1hiPFr SxqGjeFGTNj820EZT7WQHT6oaj/sPoP8ry+2rYRZcD54XRoBqjjOFKqRgMGR0gQCWHdNX+WjgxL KZmDumDcRQvWijdbpUOyWjHnp3xXi+g== X-Google-Smtp-Source: AGHT+IHtJsbNso05qsFEUc1VCttxiPDYNFmandqesaoOQ8znhg0/KM/1dF2fbeI1uKqWgIoO6ggVE3mfiH17p3GuGsE= X-Received: by 2002:a05:6820:4b0e:b0:5dc:a733:d988 with SMTP id 006d021491bc7-5e1a9bf2d3fmr8802276eaf.1.1725898923350; Mon, 09 Sep 2024 09:22:03 -0700 (PDT) MIME-Version: 1.0 References: <172538719711.1420249.4393971363081609427@dt-datatracker-68b7b78cf9-q8rsp> <02e9a51e-b938-49f2-b832-de4d3ec575ee@redhat.com> In-Reply-To: From: Phillip Hallam-Baker Date: Mon, 9 Sep 2024 12:21:51 -0400 Message-ID: To: Orie Steele Content-Type: multipart/alternative; boundary="0000000000003ea7b60621b22892" Message-ID-Hash: 7X37N5LAYPOXLFLG5EKDFGQYFTH5POHD X-Message-ID-Hash: 7X37N5LAYPOXLFLG5EKDFGQYFTH5POHD X-MailFrom: hallam@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_Rigid_generation_of_RSA_from_a_seed=2E?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003ea7b60621b22892 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Orie Steele wrote: > I did something similar for DIDs... by extending BIP32 / BIP39 / BIP44 > beyond secp256k1 to ed25519 and bls12381 (I didn't cover secp256r1, or th= e > other P curves) > > > https://did.key.transmute.industries/generate/ed25519?seed=3D824c576ef63e= a1e37a8820236acf37a97cb8c4432afd7172ee682f95b4b38725 ( > 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 ma= de > 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 us= ed > 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=E2=80=AFPM Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > >> I have implemented a scheme to perform rigid generation of RSA keys base= d >> 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. Th= is >> 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. Fo= r >> example, the following UDF key generation string has a 128 bit work fact= or: >> >> 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 an= d >> 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 squirt= s >> 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 -- cfrg@irtf.org >> To unsubscribe send an email to cfrg-leave@irtf.org >> > > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > > --0000000000003ea7b60621b22892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Interesting,

The reason I went down this path was to allow for key recovery. Imagine y= ou are a refuge. Your house etc. are all destroyed. Your entire digital ges= talt=C2=A0is 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 yo= u 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 w= hich 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 max= imize cryptographic hygiene. So I have separate keys for transport encrypti= on/authentication and for stored data encryption allowing me to only escrow= the stored data keys.

Wh= y 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.<= /div>




On Mon, Sep 9, 2024 at 10= :21=E2=80=AFAM Orie Steele <orie@transmute.industries> wrote:
I did = something similar for DIDs... by extending BIP32 / BIP39 / BIP44 beyond sec= p256k1 to ed25519 and bls12381 (I didn't cover secp256r1, or the other = P curves)

https://did.key.transmute.industries/generate/ed2551= 9?seed=3D824c576ef63ea1e37a8820236acf37a97cb8c4432afd7172ee682f95b4b38725=C2=A0( a smarter strategy would be to put the seed in the fragment of th= e URL ).

did key is basically a URN for public keys... when the publ= ic key can be converted to a blockchain / asset network address, you can al= so think of the did key as a URN for receiving / sending payments.

T= his was just an experiment, obviously the same=C2=A0seed should not be used= for multiple key types at the same time, etc... (lots of mistakes were mad= e here, feel free to point them out.).

There is some related work he= re:

-=C2=A0https://eprint.iacr.org/2014/998.pdf
-=C2=A0https://ieee= xplore.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=C2=A0+ ML-DSA keys from a single seed= ... With Ed25519 and X25519 there is point conversion which=C2=A0can be use= d to produce similar (not the same) results:=C2=A0https://l= ibsodium.gitbook.io/doc/advanced/ed25519-curve25519

In a constra= ined environment, it can be nice to generate keys deterministically, and no= t need a separate=C2=A0deterministic 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 i= nteraction that can support both signing and key establishment.

OS

On Sat, Sep 7, 2024 at 12:53=E2=80=AFPM Phillip Hallam-Baker &l= t;phill@hallamba= ker.com> wrote:
=
I have implemented a scheme to per= form rigid generation of RSA keys based on FIPS 185-5=C2=A0

The basic ide= a is that starting with a seed with a particular work factor, we can genera= te the public keypair in a deterministic manner. This approach=C2=A0provide= s a verifiable means of key generation. The application that is accepting t= he private key can check that it has been correctly constructed in accordan= ce with best practice.

The seeds could be encoded in a private key info s= tructure 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:

ZAA= A-Q4DQ-QCO4-7TEG-WJYB-QD5B-YAXL-EMY

It generates a 2048 bit key in ab= out 2 seconds on my machine using the FIPS 185-5 scheme generating two auxi= liary primes used to construct p an q.
=
Or you can generate the=C2=A0same = key in a fraction of a second by adding a hint string:

FGCA-GSAS-IYIQ-GAY

<= div>This specifies the number of rounds needed to derive=C2=A0p and q, the = auxiliary primes and a qualified seed for p and q in that order using a sim= ple 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-DED= U-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 ke= ys to devices. The idea of the Mesh being that Alice has 100 devices rangin= g 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 pur= poses.

Having a consistent, rigid means of generating the keys allows the= degree=C2=A0of trust to be minimized.
=
_______________________________________________
CFRG mailing list -- cfr= g@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org


--
--0000000000003ea7b60621b22892--