Kleopatra not show ed/cv448 in advanced settings

Gpg4win help-en
1

HI. When I create a new OpenPGP key pair (File->New Key Pair OpenPGP), in Advanced Settings I can choose ed25519/brainpool/NIST, but there is no ed/cv448 option. Why?
If I do it from the command line (C:\Program Files (x86)\GnuPG\bin\gpg --expert --full-gen-key) I can do it, choosing (9) ECC → (2) Curve 448.

I read all the Kleopatra doc, the GnuPG doc, I also downloaded the source code of both Kleopatra and GPG to try to understand, I explored the “default-new-key-algo” option (which I tried to set as “ed448/cert,sign+cv448/encr”, but without result) and read many forums on the internet, in short, hours of testing and research but I didn’t understand why it doesn’t show the ed448/cv448 option but only 25519.

Yet 448 it is an algorithm that has been supported for at least 2 years.
Where is the problem? how do I activate it on Kleopatra, without needing to use the command line?
Thank you
where-is-cv448
where-is-ed448

2

Hello @anon27753184 and welcome to this forum :slight_smile:

In this issue you can read that the list of algorithms in Kleopatra is hard-coded so you can’t just add an option to the config file. You would have to build Kleopatra yourself.

Another issue describes that the implementation of X448 in GnuPG 2.3 was an experimental one. Maybe that state didn’t change yet.

I couldn’t find anything else on https://dev.gnupg.org/ what could give additional hints.

3

Yes, there is or at least was to our knowlege no other implementation which supported these curves. And IMO the selection of such curves is okay to do on the command line because you should really know what you want to do. It could be added to Kleopatra but it was just never done since the support for them was added. curve25519 is IMO the most compatible and overall best one which is why it is default. NIST is required for some applications and the US and brainpool is required for some mostly EU. So that is what speaks for these. In theory libgcrypt supports even more curves.

4

I understand. Thanks for the quick and precise replies.
For me the problem is solved, I just need to understand how I should interpret all this.

E.g., does “experimental” mean that it’s not very safe yet or perhaps that it doesn’t work very well?

That is, what if I use an experimental 448 key pair? will it be safer than ed25519? could it contain bugs and maybe I encrypt some files and after 3 months I can no longer decipher them? or could it be hacked in the future because it is experimental?

And then in the release notes:
https://files.gnupg.net/file/data/fhxuc4yjxzp2ermhbphu/PHID-FILE-3oiqrhrl63nrqgfbfxq4/NEWS
it says “gpg: Force version 5 key creation for ed448 and cv448 algorithms”

I had read from them that they want to move from “version 4” to “version 5”: what is it? a new key standard?

Also, I created a 448 key pair, which has a signature length of 64 instead of the standard 40. Like:
CE2BF48E7FA3B2B02CF1E340FCC9486ABC42CFE6C8C226D5567C30B23BB10BC3
Is this a new key format?

In short, is it currently safe to use 448, a “cutting-edge” algorithm, or is it still better to wait? but if they have already released it for 2 years and if they have not modified it for 2 years, I think it is already quite stable, in fact the last release note that talks about the 448 dates back to version 2.3.3 of 2021-10-12: “keyboxd: Fix “invalid object” error with cv448 keys. [#5609]”.

5

does “experimental” mean that it’s not very safe yet or perhaps that it doesn’t work very well?

It means you shall not use it, unless you can take the responsibility yourself. Usually this means you are a cryptographer and want to experiment with it.

That is, what if I use an experimental 448 key pair? will it be safer than ed25519?

No, using a 448 key pair would be less safe because the implementations have seen less testing and less scrutiny. I don’t know about the math and algorithms.

could it contain bugs

Yes, the chance of defects in the implementation is higher then with other algorithms.

and maybe I encrypt some files and after 3 months I can no longer decipher them?

This has a low risk as you can always go back and build an elder version of GnuPG to decrypt your files.

or could it be hacked in the future because it is experimental?

Assuming hacked means that a defect in the implementation is found and can be exploited, yes, there is a higher risk of this, because of the lesser testing (again).

I had read from them that they want to move from “version 4” to “version 5”: what is it? a new key standard?

Yes, a new format for public keys will be introduced into wider usage. The old standard is called v4 and the new one v5, see the website https://librepgp.org/ (which is in beta) for some more explanations.There is a proposed v6 a well, but it is to be seen which implementations will support it. GnuPG and Gpg4win are committed to v5.

CE2BF48E7FA3B2B02CF1E340FCC9486ABC42CFE6C8C226D5567C30B23BB10BC3
Is this a new key format?

This is probably the longer fingerprint. (I write “probably” because I did not check in detail.)

In short, is it currently safe to use 448, a “cutting-edge” algorithm, or is it still better to wait?

It is better to wait and use curve25519 for now.

1 Like
6

I have to disagree with bernhard a bit about the security implications of this. Using a different curve for ECC is not that special or in any way insecure.

But for the rest I agree with anything Bernhard said. curve 25519 is excellent and you will only run into interop problems with ed448.

Note that 2 years is nothing in the timelines we think. I think we deployed ECC support for about 10 years or so before we changed the default from RSA to ECC (cv25519)
Usually what we do is add support for new crypto algorithms pretty quickly. But then wait for years until versions with support for them are really widespread before we actually start to use them. I still use an RSA key as my primary (although I will change that pretty soon I guess).

7

I was taking a general and cautious approach. More common parameters are usually more tested. There are some ECC curve parameters which are more safe than others, but of course ed448 is seen as good as well. According to Elliptic curve ed25519 vs ed448 - Differences - Cryptography Stack Exchange there are some implementation differences in the details, though. So I sill believe it is okay to say that the ed25519 implementations have seen more testing.