gpg key size of 4096 and "the future is ECC"

Question

My boss wants to sign our binary. I need to tell him how he can create the signing key.

Most if not all sites I have seen about signing binaries suggest using GPG.

OK, so GPG per default has 2048. Their FAQ has several arguments why 3072 or even 4096 does not offer higher security but "costs a lot" (I assume they refer to computing resources).

Does this still apply in 2020? Can I safely recommend to my boss to use 2048 key size?

What puzzles me even more though, is that in their FAQ they say:

Probably not. The future is elliptical-curve cryptography, which will bring a level of safety comparable to RSA-16384. Every minute we spend arguing about whether we should change the defaults to RSA-3072 or more is one minute the shift to ECC is delayed. Frankly, we think ECC is a really good idea and we’d like to see it deployed as soon as humanly possible.

Is it possible to use ECC for signing binaries? Are there any tutorials for that? Or is the current state-of-the-art to still use GPG with 2048 key size?

Answer 1

Does this still apply 2020? Can I safely recommend to my boss to use 2048 key size?

This would be to a certain extent a matter of opinion and as such likely not suitable for discussion on StackExchange. For any practical purposes one should be safe with 2048-bit RSA for years to come. However, the cost of using 4096-bit RSA won't be practically noticeable when used for signing binaries.

ECC seem to offer more strength in smaller keys as well as faster computation for both signing and verification. Bitcoin employs ECDSA with 256-bit keys, for example.

Is it possible to use ECC for signing binaries? Are there any tutorials for that?

Currently, at least as of GPG v2.1, ECC key pairs are possible to be created in GPG. To check the version of GPG in your system and list available algorithms you can call gpg2 --version. If you can see ECDSA or EDDSA, you can also generate ECC key pairs using gpg2 --full-gen-key --expert and selecting the appropriate algorithm. As to differences between the two, see this question.

Answer 2

Even though this question is 3+ years old, I am answering just in case someone finds the answer useful.

You did NOT mention the platform on which the binaries will be used:

1. If you want to sign binaries for the Windows platform, it is best that you use a X.509 certificate, since Windows does not, by default, check PGP/GPG signatures (with some very specific exception, where it checks the PGP/GPG signature of packaged applications, but NOT for Microsoft Store apps). You have the choice of running your own CA, using a self-signed certificate, or buy a certificate from a publically-trusted CA. If you intend to distribute your application to the public, it is best to use a publically-trusted CA, because your certificate will be trusted by default. If you intend to use the application internally, it is better to use your private CA. If you don't have a private CA and don't need one, then use a self-signed certificate, which will have to be trusted by the clients.
2. If your platform is Linux, then your only viable option is PGP/GPG.
3. If your platform is Mac, then you will probably need a certificate from Apple's developer subscription.

Regarding RSA key-size:

1. The new guidelines of the CA/Browser Forum require a minimum key-size of 3072bit and that it also be generated in hardware cryptographic devices (i.e. not a .pfx/.p12 file on your computer). As far as compatibility goes, use 2028bit if your system can't handle more.
2. The "cost" of RSA3072 and higher is significant ONLY for constrained and/or embedded devices and/or older systems. Indeed, the increasing key-size for RSA has diminishing returns. Still, the minimum recommended AES key size is 128bit (symmetric encryption). The equivalent of AES128 in RSA is 3072bit, not 2048bit.

Regarding ECC:

1. ECC offers equivalent or better protection with smaller key-sizes. It is also faster, etc. If you can use ECC and your system supports it, then do it.
2. It is possible to use any signing and hashing algorithms you want, as long as your system supports it. Recent versions of PGP/GPG support ECC and multiple hashing algorithms. I am not sure about Windows 7 and Windows 8, but Windows 10 supports ECC and many hashing algorithms. I am not sure about Macs.
3. You don't need specific tutorials for signing with ECC. Just generate your ECC key and then use the standard commands to sign something.
4. As for the argument that arguing over RSA causes delays in the adoption of ECC, I believe that it only applies top novice users that use the defaults; an advanced user is knowledgeable, willing, and capable to change the defaults and use whatever settings they want.
5. If someone HAS to use RSA, then they should go for RSA4096, but they should use ECC256 (minimum), if they can.