Add an option to generate an X25519 keypair

Question

Add an option to generate an X25519 keypair

Closed this issue 5 months ago · 4 comments

I would like to be able to use KSE to test my code handling X25519 (Curve25519) DiffieHelman.
Could you please add an option to generate X25519 KeyPairs?

Currently, KSE offers an option to generate keypairs for Ed25519. It is my understanding that Ed25519 is using a different curve (although birationally equivalent), so the keys are not interchangeable, even if a manual (one way) conversion is possible.

Answer 1 · 2024-07-03T10:55:26.000Z

That won't work, because in the KeyStore API a key pair cannot exist on its own, there also has to be a certificate associated with it. So whenever a new key pair is generated, a self-signed certificate is generated alongside it. This works fine with Ed25519 keys as they are made for signing, but obviously you cannot use Curve25519/X25519 keys for that.

What KSE could do is to generate the X25519 key and then provide a save dialog, so it can be saved to a file. However, that is pretty awkward and does not fit into the concept of a keystore management tool at all.

I think your best option is to generate Ed25519 keys and convert them to X25519 for usage. For Ed25519 to X25519 the ambiguity issue does not exist, so this should be viable.

Answer 2 · 2024-07-03T20:33:17.000Z

Uh, forgive me my complete ignorance, I'm far from an expert, but that's only a limitation of JKS / JDK API, right? Shouldn't it be possible, at least in theory, to circumvent that and manually write the key pair to say a PKCS#12 store?

Answer 3 · 2024-07-04T17:00:33.000Z

You are completely right about this. This is in fact a restriction of the KeyStore API and the "native" Java keystore types like JKS and JCEKS. For PKCS#12 these restrictions do not apply - unless you access it through the KeyStore API.

Unfortunately that does not help much, as the whole KSE application is built around the KeyStore API. This is the reason why KSE can support all those different keystore formats and even crypto hardware with PKCS#11/MSCAPI. Building a second path along that for direct support of PKCS#12 (and thus enabling "standalone" X25519 keys) would make the code very complicated, because you basically have to add a special handling for X25519 keys everywhere. Also, KSE already suffers a bit from the magnitude of possible combinations of Java versions and keystore types and what is possible in any of these combinations and what not.

Anyway, if your code already handles DH with X25519 keys, then it should be no problem to create a little helper method for your tests that does the conversion from Ed25519 to X25519. Or am I missing something?

Answer 4 · 2024-07-04T17:55:59.000Z

Anyway, if your code already handles DH with X25519 keys, then it should be no problem to create a little helper method for your tests that does the conversion from Ed25519 to X25519. Or am I missing something?

I'm just starting the implementation now ;) But yeah, you are absolutely right.

Thanks for the clarification. I am closing this issue as not planned, as I understand it's not feasible to do in KSE without too much effort, while it's easy to generate or derive keys manually by myself.