If I understood correctly, some symmetric ciphers such as AES, Camellia, ChaCha are implemented in OpenSSL (along with several older ones) but some other commonly used and proven ciphers such as Serpent, Twofish and Threefish are not.

Any way or chance of these being supported by OpenSSL as well?

Or is there another de facto encryption tooling (with comparable solid reputation as OpenSSL) that implements these ciphers?

  • 3
    $\begingroup$ Please see the list of topics for cryptography.se. Your second question might be better on softwarerecs (but check how to ask there). The first is for the openssl devs, but check the existing issues first. $\endgroup$ – Marc Sep 14 at 13:50
  • $\begingroup$ > commonly used and proven ciphers such as Serpent, Twofish and Threefish are not. I'd not really call those "commonly used". Nor are they as well proven as AES or ChaCha20, though they're probably about as trustworthy as Camellia they're not standardized by any country. There's no real benefit to using them, and some major downsides. $\endgroup$ – SAI Peregrinus Sep 14 at 15:25
  • 2
    $\begingroup$ openssl is for ssl/tls communication and primarily implements ciphers used in the standards required for this communication $\endgroup$ – Richie Frame Sep 14 at 19:43

AES is the main block cipher in use today, standardized by NIST. Camellia is a Japanese standardized cipher. ChaCha is a fast stream cipher specified by Bernstein and incorporated into TLS with support from Google.

Serpent and Twofish were AES last round candidates that didn't make it. Serpent is not that fast, and Twofish is relatively fast but not compared to AES when hardware acceleration is used. Both are block ciphers that are really not needed as long as we deem AES to be secure.

Threefish was mainly designed for the Skein hash function. This tweakable block cipher is not used much. It Skein had been chosen as SHA-3 then it would have stood a better chance. For now an authenticated form of Keccak would make more sense.

So yeah, two standardized ciphers and a fast stream ciphers are supported, none of which are broken. There is no reason to include the also-ran's and a cipher made specifically for a hash function which was also not standardized.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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