search

google / conscrypt

Conscrypt is a Java Security Provider that implements parts of the Java Cryptography Extension and Java Secure Socket Extension.
Apache License 2.0
1.29k stars 275 forks source link

Poor design impacts Java AES-GCM encryption performance #697

Open james-k-polk opened 5 years ago

james-k-polk commented 5 years ago

AEAD ciphers like AES-GCM and AES-CCM must embargo plaintext during decryption until the tag is verified. This is understood. However conscrypt also embargoes ciphertext during encryption for AES-GCM. This is unnecessary and undesirable.

It appears that the reason this is happening is because both GCM and CCM modes are lumped together and use this class. CCM differs from GCM in that the length of the plaintext is a parameter to the scheme, so embargoing the ciphertext until doFinal makes some sense for CCM because the length is known for the first time. But this is completely unnecessary for GCM mode. Please create a separate class just for GCM mode and let CCM mode and it's limitations live alone in ignominy.

kruton commented 5 years ago

Conscrypt doesn't support CCM for Cipher instances. The reason it embargoes plaintext is the API in BoringSSL is simply EVP_AEAD_CTX_seal and EVP_AEAD_CTX_open which is defined in boringssl/include/aead.h.

Have you measured actual performance slowdowns? A description of your workload might help find inefficiencies. Typically AES operations goes a bit faster with larger records to work with since overhead is minimized (JNI call, etc).

james-k-polk commented 5 years ago

It's not for me, the question came up on stackoverflow here. Yes, one call does minimize overhead but in my opinion it's a poor match to the init, update, doFinal API of Java's Cipher method which creates the expectation of incremental progress. Still, you can't have incremental progress on the decrypt side so I suppose you might as well not have it on the encrypt side.