Symmetric decryption slower than with private key

[fi4sk0]

Hey everybody,

I modified test/benchmarks/time.js to also include a test for symmetric decryption: First, I created an armored symmetrically encrypted message in getTestData:

      const armoredSymmetricEncryptedMessage = await openpgp.encrypt({ message: plaintextMessage, passwords: 'super secret!!' });

and then added the following case to the test suite:

  suite.add('openpgp.decrypt (symmetric)', wrapAsync(async () => {
    const message = await openpgp.readMessage({ armoredMessage: armoredSymmetricEncryptedMessage });
    await openpgp.decrypt({ message, passwords: 'super secret!!' });
  }));

Running the benchmarks yields the following results:

openpgp.readKey x 3,981 ops/sec ±4.40% (69 runs sampled)
openpgp.readMessage x 12,714 ops/sec ±1.83% (76 runs sampled)
openpgp.generateKey x 52.26 ops/sec ±4.14% (62 runs sampled)
openpgp.encrypt x 479 ops/sec ±0.82% (81 runs sampled)
openpgp.sign x 214 ops/sec ±4.32% (67 runs sampled)
--> openpgp.decrypt x 726 ops/sec ±1.27% (80 runs sampled)
--> openpgp.decrypt (symmetric) x 23.28 ops/sec ±0.88% (58 runs sampled)
openpgp.verify x 113 ops/sec ±3.63% (62 runs sampled)

It seems like there is factor ~30 between symmetric and asymmetric decrypt, where asymmetric is faster. I was under the impression that symmetric decryption should be faster than using a public/private key. Am I doing something wrong? Have I misunderstood
some basic principles?

I'm happy for any pointers!

[twiss]

Hello 👋 Password-based encryption has a step where the key is derived from the password, which is intentionally slow, in order to make it harder for attackers to guess the password via a brute-force attack. With asymmetric encryption, this concern doesn't apply as the entropy of the key itself should already be sufficient. If you're very confident that the password you're using has sufficient entropy as well (e.g. it's a randomly generated string of sufficient length, and not something provided by a user) then you can lower openpgp.config.s2kIterationCountByte to lower this protection and increase the performance.

[twiss]

(The keyword to learn more about this is "key derivation function", e.g. https://en.wikipedia.org/wiki/Key_derivation_function)

[steida]

@fi4sk0 I am using https://github.com/bitcoinjs/bip39 mnemonic. 12 words have good UX.

@twiss I plan OpenPGP public-private encryption but for user-only data, I am using symmetric encryption with bip39 mnemonic. For such a use case, browsers only, does it make sense to use OpenPGP? Isn't native subtle crypto good enough? How OpenPGP symmetric encryption with s2kIterationCountByte == 0 is different from native subtle crypto? Thank you.

[twiss]

12 words will give you 16 bytes / 128 bits of security, similar to the security of AES-128.

If you don't need interoperability with the existing OpenPGP (email) ecosystem, you don't necessarily need OpenPGP.js, no. I would only recommend using subtle crypto if you know what you're doing (hence the name "subtle"), but it's possible to use it securely, yeah.

[steida]

@twiss Thank you. Btw, are you watching Project Everest? Will it be used in OpenPGP?

[twiss]

Not very likely, unless it's via wasm - but the ideal way for us to end up using it is via the Web Crypto API. I believe Firefox is already using HACL* for some cryptographic algorithms, in which case we'd be using them indirectly if they're exposed in Web Crypto (which unfortunately isn't always the case - e.g. see w3c/webcrypto#196).