Add Cv25519 Key Generation Support

[ElliotKillick]

VanityGPG's CLI doesn't support specifying Cv25519: [possible values: Ed25519, RSA2048, RSA3072, RSA4096, NISTP256, NISTP384, NISTP521]

The impact is that VanityGPG cannot be used to generate ECC vanity encryption subkeys. Looking at the code, I see VanityGPG already internally supports the functionality but it's not exposed to the user.

For ECC keys, I'm pretty sure encryption can only be used as a subkey (with a Ed25519 master key) so I'm not sure if it would be possible to export straight to an armored PGP key file in that format. Even saving directly to the key's binary private key material with fingerprint and key timestamp in its filename would be fine by me.

BTW: I've already figured out a way of attaching vanity subkeys to a vanity master key. It takes a bit of trickery primarily with GPG keygrips (a GPG implementation detail referring to the private key material) and the --faked-system-time option of gpg but it works.

[RedL0tus]

To be honest I didn't think of this problem before. However, I think adding the option to generate vanity subkeys would bring too much complexity to the program (not to the code itself, but to command line options).

Since you discovered a viable workaround, could you please help me to document it so that other people could follow?

[ElliotKillick]

To be honest I didn't think of this problem before. However, I think adding the option to generate vanity subkeys would bring too much complexity to the program (not to the code itself, but to command line options).

It should just be a matter of adding Cv25519 to the -c/--cipher-suite option. Other than that, -u/--user-id wouldn't work but that's probably to be expected for a subkey.

Since you discovered a viable workaround, could you please help me to document it so that other people could follow?

The workaround I discovered pertains to adding vanity subkeys to an arbitrary master key. I do have this working for Ed25519 subkeys and it should work the same for Cv25519 subkeys. However, a patch for VanityGPG is required to support generation of Cv25519 keys first.

[RedL0tus]

It should just be a matter of adding Cv25519 to the -c/--cipher-suite option. Other than that, -u/--user-id wouldn't work but that's probably to be expected for a subkey.

Sorry I misunderstood your suggestion. I thought you were talking about adding options to generate vanity subkeys together with the main one, and that IMO would be too complicated to let the user dial in all the parameters.

So, let me confirm that, making Cv25519 available for -c and allowing the user to disable UID generation would be enough? I'm thinking about making -u an optional parameter and don't generate it if it was left blank.

[ElliotKillick]

So, let me confirm that, making Cv25519 available for -c and allowing the user to disable UID generation would be enough? I'm thinking about making -u an optional parameter and don't generate it if it was left blank.

Yes, exactly. The only thing that makes a PGP master key different from a subkey is that the master key signs its subkeys as a proof and subkeys are usually distributed together with their master key. Other than that, master keys and subkeys are the same and my process essentially allows one to "convert" master keys to subkeys while maintaining all vanity key fingerprints.

I'll send a PR to document the process once Cv25519 is added!

[kjkent]

Hi there, jumping in with a similar use case to @ElliotKillick. It's not clear in what's said already, but there's a bit of nuance to primary/sub keys, i.e. the usage flags "Certify", "Authenticate", "Sign", and "Encrypt". The primary key needs the Certify flag at least, but can have others -- except, in the case of ed25519 keys, Encrypt (which instead can be generated as a cv25519 subkey).

If storing the keys on a hardware token, like a YubiKey, it can be beneficial to have a Certify-only primary key and separate Authenticate, Sign, and Encrypt subkeys.

Considering that the subkeys can be generated and attached after the fact, and that the primary key fingerprint is commonly used to reference its subkeys, perhaps a simple and flexible solution is to just add a --certify-only option to the CLI, and users can use another tool to add subkeys as they wish? The latter is as simple as:

gpg --quick-add-key <primary key fingerprint> <algo> <subkey flag> <expiration>