1
$\begingroup$

I'm aware that symmetric is faster than asymmetric.

I want to test this, but my (obviously incorrect) tests show the reverse.

Symmetric test:

#!/bin/bash

echo create random 100Mib binary file
head -c 100M /dev/urandom > blob

echo encrypt
time gpg --symmetric --batch --passphrase 123 --output blob.gpg blob

echo decrypt
time gpg --decrypt --batch --passphrase 123 --output blob blob.gpg

Asymmetric test (using fred's 4096 bit keypair, generated by gpg):

#!/bin/bash

echo create random 100Mib binary file
head -c 100M /dev/urandom > blob

echo encrypt using public key
time gpg --encrypt --recipient fred --output blob.gpg blob

echo decrypt using private key
time gpg --decrypt --batch --output blob blob.gpg

Results:

encryption : symmetric  : 6.2s
encryption : asymmetric : 5.8s         # I expected this to be > 6.2

decryption : symmetric  : 2.5s
decryption : asymmetric : 1.4s         # I expected this to be > 2.5

Can someone spot my error?

Improve this question
$\endgroup$
1
  • $\begingroup$ This is probably due to the fact that you specified a password / passphrase to be used and gpg will do some expensive operations on that to make it slower to brute-force. $\endgroup$
    – SEJPM
    Commented Apr 1, 2020 at 14:33

1 Answer 1

Reset to default
2
$\begingroup$

100 MiB is nothing nowadays. Still, it is likely that most time is spend because of I/O operations, rather than encryption / decryption. Once the file is buffered in RAM, the operations will proceed much more quickly. Worse than that, during encryption most of the time is spend during compression of the input - not encrypting it. Try -z 0 so compression of random data doesn't cost that much time:

maartenb@maartens-ryzen:~/Test$ time gpg --symmetric --batch --passphrase 123 --output blob.gpg -z 0 blob
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: handle plaintext failed: General error

real    0m0.686s
user    0m0.670s
sys     0m0.016s
maartenb@maartens-ryzen:~/Test$ rm blob
maartenb@maartens-ryzen:~/Test$ time gpg --decrypt --batch --passphrase 123 --output blob blob.gpg
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase

real    0m1.056s
user    0m0.965s
sys     0m0.088s

It seems that you are using password based encryption for "symmetric encryption" while you are using encryption / decryption with an unprotected private key (because the passphrase is cached).

For password based encryption you'd use a password based key derivation function or PBKDF, which has an explicit work factor (or iteration count) to slow down password guessing. More information here.

Now, if you look at the encrypted packet, you get this:

maartenb@maartens-ryzen:~/Test$ gpg --list-packets blob.gpg 
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
# off=0 ctb=8c tag=3 hlen=2 plen=13
:symkey enc packet: version 4, cipher 9, s2k 3, hash 2
    salt 4D975A3A5174CD4F, count 65011712 (255)
# off=15 ctb=d2 tag=18 hlen=6 plen=104857656 new-ctb
:encrypted data packet:
    length: 104857656
    mdc_method: 2

Note the s2k 3 and the pretty high value of count in there. Note that I'm using gpg (GnuPG) 2.2.12.

The public / private key operations do not have such a deliberate slow down - unless the private key is still protected by a password.

This is another advantage of public key encryption: during encryption you won't have any slow down to protect pass phrases sampled from a source with low entropy output (i.e. you).

Improve this answer
$\endgroup$
4
  • $\begingroup$ Yeah, OK, fast Linux system. I used to work on a sub 2 GHz laptop with SATA SSD if that's any consolation. $\endgroup$
    – Maarten Bodewes ♦
    Commented Apr 1, 2020 at 15:20
  • $\begingroup$ Thanks Maarten. I'm confused though by your second-last para - isn't symmetric crypto supposed to be faster? If you're using a pbkdf2 with high work factor, because this is considered to be the best practice, then why do people say that symmetric is faster? If done right (high interations), it will be slower. $\endgroup$
    – lonix
    Commented Apr 1, 2020 at 17:00
  • $\begingroup$ BTW nice catch on the compression, it lowers the numbers for both tests by a lot. $\endgroup$
    – lonix
    Commented Apr 1, 2020 at 17:01
  • 1
    $\begingroup$ I think they just focus on the encryption of the file itself, not the key derivation. Even if you use asymmetric crypto in PGP, the file itself is still encrypted with a symmetric cipher after all. The overhead of asymmetric RSA is just for encrypting the data key and is therefore not related to e.g. the file size; it is a constant overhead. $\endgroup$
    – Maarten Bodewes ♦
    Commented Apr 1, 2020 at 17:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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