RedL0tus/VanityGPG

Add Cv25519 Key Generation Support

Opened this issue · 4 comments

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.

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?

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.

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.

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!