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?

2 Answers 2


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.

  • 2
    For compatibility with older systems you should stick with RSA. If unsure about the key size, IMHO just pick the largest as you won't notice the difference. For ECC I would at least recommend waiting for the RFC's to be published, see: wiki.gnupg.org/ECC. This opens up a whole lot of new questions though, with ECC there's some mistrust in curves like the NIST ones with no rationale behind some of the chosen parameters. GnuPG plans on using Curve25519 by default, and although SSH requires support for NIST curves it prefers Curve25519 or its close variant, Ed25519, when possible. Commented Jul 8, 2021 at 4:28
  • @ThomasGuyot-Sionnest What does the fact that the RFC4880bis is still a draft and not approved mean, based on your take on it? GnuPG already uses those curves and RFC4880bis can be enabled. Commented Jul 3, 2023 at 4:56
  • @ARGYROUMINAS So what is your question exactly? ECC is still not supported by older tools, not officially standardized (subject to changes) and is still a new technology that hasn't been tested as much as classic crypto. You can use it if you want but for best compatibility RSA is still a very well trusted crypto. Commented Jul 4, 2023 at 11:17

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.
  • You can actually use X.509 to sign elf binaries - the only difference is that Linux has no standard way of securely checking file signatures before loading executable code. There has been various options over the years, and there are now frameworks making it possible to implement these checks with some levels of automation, but there are no standards just yet. PGP has been mainly used in Linux as a convenience (easier/cheaper to build chain of trusts than get X.509 code signing certs) and because there's no run-time verification anyway. Commented Jul 4, 2023 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .