I plan to use GPG to encrypt a small file (32KB) for very many recipient public keys (few thousands).

I tested GPG with RSA and then ECDH public key encryptions. If RSA is very slow, with ECDH (nist 256 curve) I get (still bad -but) better results:

1K destinataries encrypt: 14sec
5K destinataries encrypt: 5m42sec

Now, my understanding was that all GPG does is to encrypt the file with a symmetric (session) key, and then encrypt the symmetric key with the public key of each recipient. Thinking that the ECDH is the bottleneck, I did an openssl speed ecdh on the machine and got:

256 bit ecdh (nistp256)   op=0.0001s  op/s=18934.7

My question is what can cause such a bad performance for 5K recipients if ECDH seems to be so quick with openssl? Is there anything else that GPG does (besides the symmetric and asymmetric encryptions) that can explain the 5m42s time?


closed as off-topic by Squeamish Ossifrage, Maeher, kelalaka, Maarten Bodewes Mar 12 at 10:13

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Programming questions are off-topic even if you are writing or debugging cryptographic code. Unless your question is specifically about how the cryptographic algorithm, protocol or side-channel (mitigation) works, you should look into asking on Stack Overflow instead." – Squeamish Ossifrage, Maeher, kelalaka, Maarten Bodewes
If this question can be reworded to fit the rules in the help center, please edit the question.

  • $\begingroup$ Just a side note: encrypt the file with a symmetric (session) key, and then encrypt the symmetric key with the public key of each recipient. is actually not how (EC)DH works. The symmetric key is the result of the key agreement (and derivation) process. The key is not selected explicitly and then encapsulated later. So you can't begin the actual encryption process until you complete the key agreement process. $\endgroup$ – Ella Rose Feb 9 at 22:51
  • $\begingroup$ Are these messages being signed in addition to being encrypted? $\endgroup$ – Ella Rose Feb 9 at 23:45
  • $\begingroup$ This sounds like a question for the gpg developers rather than crypto.se. $\endgroup$ – Squeamish Ossifrage Mar 11 at 23:38

You don't provide much information on your setup or. testing, but I'll take a stab at helping you improve the performance of your system.

Yes, ECDH is actually supposed to be less demanding than RSA in terms of demands it makes on the system, so I'm surprised at your situation and would equally love to know what caused it!

Here are some things to look at to help isolate the fault. Might not address ECDH specifically, but need a baseline of info to at least start with:

  1. Firstly, different version of GPG- GPG and GPG2- have different performance characteristics. So useful to know what version you're using:

    gpg --version

  2. GPG encrypts to binary format by default unless told to use ASCII with the --armor r -a switch. This can have performance implications. Try the following command with and without the -a switch to see how performance is affected. Also read the debug info which is output to see if it's puking any errors.

    time gpg --debug-all --batch --yes --trust-model always -r username@userdomain.com -a -e ./gpg-performance-test.txt

  3. Encryption is CPU intensive, so having a snappy processor improves performance. Also check your memory:
    free -m

  4. Myself, if I had a gazillion people I needed to encrypt a message to, I'd write a script that iterates through a list of email addresses with the above command and emails the message. And I would run top while the script was executing. But it's possible to run a single command with multiple recipients so any of them can read the message with their secret key. You're not clear on how you're doing the encryption.

Might be enough to help you identify the bottleneck, or if not, at least exclude what is *not causing it. If you've already identified the source of the problem, please post your findings.


Not the answer you're looking for? Browse other questions tagged or ask your own question.