Mailing List Archive

NIIBE Yutaka <gniibe@fsij.org> writes:

> Hello,
>
> In the task T6755, we introduced KEM API. ML-KEM is added.
>
> Today, I'd like to propose adding ECC KEM implementation in the API.
> The intention of mine is use in gpg-agent to support PQC (task T7014).
>
> Attached is a patch adding ECC KEM for X25519.

Nice! Is this intended to be compatible with HPKE ECC KEM?

https://www.rfc-editor.org/rfc/rfc9180.html#name-dh-based-kem-dhkem

Did you validate test vectors?

/Simon

Hi!

Thanks for working on this. I understand that you stared with X25519.
However we also need to support BrainpoolP384r1 and P512r1 because they
will likley be the default in GnuPG for Kyber (ML-KEM). There are also
request for other curves.

Thus I wondered whether we really want to have a whole bunch of
GCRY_KEM_* constants or whether it would be possible to define another
parameter which can be shared by similar algorithms/curves.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Hello,

Simon Josefsson <simon@josefsson.org> wrote:
> Nice! Is this intended to be compatible with HPKE ECC KEM?
>
> https://www.rfc-editor.org/rfc/rfc9180.html#name-dh-based-kem-dhkem

Yes. GCRY_KEM_DHKEM25519 is for DHKEM with X25519, HKDF, and SHA256
described in RFC 9180.

> Did you validate test vectors?

In my working branch of last year, I added test vectors from RFC 9180.

https://dev.gnupg.org/source/libgcrypt/browse/gniibe%252Fkem2/tests/t-kem.c;2f93e53f6525155b4c78419d55b35a35cde84907$349

It was tested at that time. I plan to merge this test into master.
(Currently, tests/t-kem only has generate-encap-decap tests.)

So, the answer is: yes, I did, but not yet with master.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hello,

Werner Koch <wk@gnupg.org> wrote:
> However we also need to support BrainpoolP384r1 and P512r1 because they
> will likley be the default in GnuPG for Kyber (ML-KEM). There are also
> request for other curves.

I will add other curves, too.

> Thus I wondered whether we really want to have a whole bunch of
> GCRY_KEM_* constants or whether it would be possible to define another
> parameter which can be shared by similar algorithms/curves.

Let's see by using the API.

While I added the ECC KEM API, I'm not sure if gpg-agent should use the
ECC KEM API for all of its uses of ECC.

Possibly, ECC KEM API will be only used for PQC. In this case,
gpg-agent uses gcry_kem_* API for PQC hybrid, and keeps using gcry_pk_*
API for existing non-hybrid use of ECC.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Fri, 29 Mar 2024 10:26, NIIBE Yutaka said:

> While I added the ECC KEM API, I'm not sure if gpg-agent should use the
> ECC KEM API for all of its uses of ECC.

Using that API would make FIPS certification easier, right?


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Hello,

I noticed that t-kem is currently failing with FIPS mode in master:

t-kem: gcry_kem_keypair 40: Not supported
t-kem: gcry_kem_keypair 41: Not supported
t-kem: gcry_kem_keypair 42: Not supported
t-kem: gcry_kem_keypair 43: Not supported
t-kem: gcry_kem_keypair 44: Not supported
t-kem: gcry_kem_keypair 45: Not supported
t-kem: gcry_kem_keypair 46: Not supported
t-kem: gcry_kem_keypair 47: Not supported
t-kem: gcry_kem_keypair 48: Not supported
t-kem: gcry_kem_keypair 49: Not supported
t-kem: gcry_kem_keypair 50: Not supported
t-kem: gcry_kem_keypair 51: Not supported
t-kem: gcry_kem_keypair 52: Not supported
t-kem: gcry_kem_keypair 53: Not supported
t-kem: gcry_kem_keypair 54: Not supported
t-kem: gcry_kem_keypair 55: Not supported
t-kem: gcry_kem_keypair 56: Not supported
t-kem: gcry_kem_keypair 57: Not supported
t-kem: gcry_kem_keypair 58: Not supported
t-kem: gcry_kem_keypair 59: Not supported
t-kem: gcry_kem_keypair 60: Not supported
t-kem: gcry_kem_keypair 61: Not supported
t-kem: gcry_kem_keypair 62: Not supported
t-kem: gcry_kem_keypair 63: Not supported
t-kem: gcry_kem_keypair 64: Not supported
t-kem: gcry_kem_keypair 65: Not supported
t-kem: gcry_kem_keypair 66: Not supported
t-kem: gcry_kem_keypair 67: Not supported
t-kem: gcry_kem_keypair 68: Not supported
t-kem: gcry_kem_keypair 69: Not supported
t-kem: gcry_kem_keypair 70: Not supported
t-kem: gcry_kem_keypair 71: Not supported
t-kem: gcry_kem_keypair 72: Not supported
t-kem: gcry_kem_keypair 73: Not supported
t-kem: gcry_kem_keypair 74: Not supported
t-kem: gcry_kem_keypair 75: Not supported
t-kem: gcry_kem_keypair 76: Not supported
t-kem: gcry_kem_keypair 77: Not supported
t-kem: gcry_kem_keypair 78: Not supported
t-kem: gcry_kem_keypair 79: Not supported
80 tests done
FAIL: t-kem

-Jussi

On 28.3.2024 6.30, NIIBE Yutaka wrote:
> Hello,
>
> In the task T6755, we introduced KEM API. ML-KEM is added.
>
> Today, I'd like to propose adding ECC KEM implementation in the API.
> The intention of mine is use in gpg-agent to support PQC (task T7014).
>
> Attached is a patch adding ECC KEM for X25519.
>
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel@gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gcrypt-devel


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hello,

Let me answer two messages by this reply.

Werner Koch <wk@gnupg.org> wrote:
> Using that API would make FIPS certification easier, right?

Yes. That's my intention.

I think that KEM API will be added in FIPS 140-* when FIPS 203 (for
ML-KEM) is finalized.


Jussi Kivilinna <jussi.kivilinna@iki.fi> wrote:
> I noticed that t-kem is currently failing with FIPS mode in master:
>
> t-kem: gcry_kem_keypair 40: Not supported

Thank you for your report.

The test program t-kem is not good yet for FIPS support. Since KEM API
is not included in FIPS 140-* yet, all tests should be failed and the
tests should handle the failure as expected. Currently, ECC KEM with
X25519 fails because Curve25519 is defined with "fips" field = 0 (in
libgcrypt/cipher/ecc-curves.c).

In (near) future, KEM API itself should have check for FIPS.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Hi!

I recently introduced the GCRY_PK_KEM algo which I marked as pseudo
algorithms. Right now we use a 3 Kyber variants and sntrup761 under
this label. This would we similar to GCRY_PK_ECC and hthe use of named
curves to identify which algorithm is actually used. Shall we take this
path and if so, what shall we do with ECDH? ECDH is a pure ECC
algorithm and does not really fit as a KEM algorithm because we would
need to list all supported curves also there. Or should we add some
common curves also under the KEM label and thus provide a second
interface for tehse curves?

On Fri, 29 Mar 2024 10:26, NIIBE Yutaka said:

> Possibly, ECC KEM API will be only used for PQC. In this case,
> gpg-agent uses gcry_kem_* API for PQC hybrid, and keeps using gcry_pk_*
> API for existing non-hybrid use of ECC.

Okay for GnuPG. But is this also good for other applications?


Shalom-Salam,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Werner Koch <wk@gnupg.org> wrote:
> I recently introduced the GCRY_PK_KEM algo which I marked as pseudo
> algorithms. Right now we use a 3 Kyber variants and sntrup761 under
> this label.

I observed that. My understanding is that it's needed to support
keygrip for those keys.

> This would we similar to GCRY_PK_ECC and hthe use of named
> curves to identify which algorithm is actually used. Shall we take this
> path and if so, what shall we do with ECDH? ECDH is a pure ECC
> algorithm and does not really fit as a KEM algorithm because we would
> need to list all supported curves also there. Or should we add some
> common curves also under the KEM label and thus provide a second
> interface for tehse curves?

# For the term, I use "composite" KEM (instead of "hybrid"), because of
# avoiding confusion of terms in "hybrid" in DHKEM.

AFAIK, in other areas (than GnuPG), I don't see any changes of practice
for existing ECC computation yet (for example, migration of API). It
seems for me that (except DHKEM) it's only in the context of composite
KEM where ECC KEM is used.

So, I think that GCRY_KEM_RAW_X25519 for composite KEM is actually
useful for now.

GCRY_KEM_DHKEM25519 is worth to have in libgcrypt, possibly, if there
will be use cases.

These are experimental, mainly for GnuPG experiment of mine:

GCRY_KEM_OPENPGP_X25519
GCRY_KEM_CMS_X25519_X963_SHA256
GCRY_KEM_CMS_X25519_HKDF_SHA256

Current approach of mine (for T7014) is that: let us keep using existing
ECC (as long as it works well) with existing key format. Here, keygrip
for the ECC key is computed by the existing public key API
(gcy_pk_get_keygrip with name of the curve in SEXP), not introducing new
ones.

In other words, an ECC key can be used for both of:

gcry_pk_encrypt and gcry_pk_decrypt API (with _gcry_pubkey_spec_ecc)
gcry_kem_* API

while keygrip is computed by gcy_pk_get_keygrip.

Firstly, let us extend the KEM API by adding GCRY_KEM_RAW_<CURVENAME>.
This is for API for pure ECDH, and it is intended for composite KEM.
KDF should be implemented by application code.
--

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel