I really do not get it. The defaults of OpenSSL are always set to the worst, not recommended and often broken things. Why?
As my CMS is down currently, I note it here.
Because pages like https://wiki.openssl.org/index.php/EVP leave you completely in the dark what is best for you. They often make it even harder to choose the right thing.
I noticed OpenSSL to be extremely slow on my hardware which supports several GB/s AES on hardware. Why? Because OpenSSL defaults to slow algorithms.
Probably because they do not trust the hardware acceleration of the CPU? Ehrm, WTF? You do not trust your CPU? Sorry, but this is insane. The only alternative of not trusting your CPU 100% is not use it at all. If you use it you trust it 100%. Period. Because else you are doing insane things. Well, there may be bugs. But then find these bugs, blame the manufacturer to have them repaired, and done. So there is no, I repeat, no excuse for not using hardware acceleration on encryption in any case.
http://www.cyberciti.biz/faq/how-to-find-out-aes-ni-advanced-encryption-enabled-on-linux-system/
openssl engine openssl speed aes-256-cbc openssl speed -evp aes-256-cbc
This means:
- OpenSSL - perhaps - has a fast mode, but this is not the default
- OpenSSL does not provide you a way to find out it is accelerated. (There once was a way, it is no more present.)
For more information about how to detect AES-NI see also
- http://www.cyberciti.biz/faq/how-to-find-out-aes-ni-advanced-encryption-enabled-on-linux-system/
- http://openssl.6102.n7.nabble.com/Verify-AES-NI-use-at-runtime-td47880.html
- http://stackoverflow.com/a/25284682
> `sort -u /proc/crypto | grep module`
# What algorithm to choose?
CTR, CCM, GCM, XTS, ECB, CBC, WTF?
To sum it up:
- XTS is the most general algorithm, specifically designed for disk drives, but can be applied to anything else, if you use an IV instead of the sector number. However it needs a key of the double bit size to only get a single bit size security margin.
- CBC is usable, but only with a carefully designed IV.
- GCM probably is the best algorithm if you need a MAC - this MAC must be transmitted, too, so data gets longer.
- If the data is intrinsically authenticated, you can use the "bad" algorithms, like CTR. But be aware, that an attacker then knows how to flip bits on your plaintext (even they do not know if it is 0 or 1, they know it is flipped).
- All algorithms depend on the Cipher chosen
See https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
- XEX **ok,but**: https://en.wikipedia.org/wiki/Disk_encryption_theory#Xor-encrypt-xor - KEY=2, BO
- XTS **ok,but**: https://en.wikipedia.org/wiki/Disk_encryption_theory#XEX-based_tweaked-codebook_mode_with_ciphertext_stealing KEY=2, Min=Blocksize (same as XEX, but mostly removes BO restriction)
- CTR **bad**: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter - IV, NA (calculates OTP out of KEY+IV+Counter)
- OFB **bad**: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Output_Feedback - SO, IV, NA (calculates OTP out of KEY+IV)
- CBC **ok,but**: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining - BO, IV (needs previous ciphertext to decrypt the next)
- PCBC **ok,but**: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Propagating_Cipher_Block_Chaining - FS, BO, IV (a bit more secure than CBC, algorithmically worse)
- CFB **bad**: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Feedback - IV, NA (algorithmically a bit faster than CBC)
- ECB **broken**: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook - BO, naive (if you ever use it you are probably doomed)
With MAC:
Note that the output data is longer than the input data due to the added MAC
- GCM **ok**: https://en.wikipedia.org/wiki/Galois/Counter_Mode - BO, AH, IV, Max=64GB-32B (like CTR)
- EAX **ok,slow**: https://en.wikipedia.org/wiki/EAX_mode CTR+OMAC
- CCM **???,slow**: https://en.wikipedia.org/wiki/CCM_mode BS=128 ??? (???)
- OCB **patented**: https://en.wikipedia.org/wiki/OCB_mode - ??? (deprecated, only included for completeness)
Notes:
- IV: security depends on IV
- NA: Needs Authentication (hence bare algorithm without MAC is bad). Small changes of ciphertext propagate predictably into the plaintext. This is bad, as this can be trivially used to attack the decrypted data. Only use with MAC or similar, else you are doomed.
- AH: Addititional Hardware needed for acceleration (available on Intel. AMD/others unknown to me)
- Min=len: Minimum length of data
- Max=len: Maximum length of data which can be encrypted/authenticated
- KEY=N needs a key N times the size of the encryption algorithm (without added security)
- BO: Only operates on full blocks
- BS=bits: Blocksize of algorithm
- FS: Full Stream only, cannot seek in the stream (not relevant to MAC type)
More on NA: https://www.youtube.com/watch?v=g_eY7JXOc8U
# Which IV? Or not?
You cannot leave IVs away. They are crucial.
- An IV is something which must not be reused for different messages.
- It is different to a KEY, as it meant to leave the machine.
- It is different to a NONCE, as it must be known to both sides, so it is not temporary.
- If the IV needs to be secret or not may depend on the algorithm.
- Like a NONCE an IV should not be predictable. But this may depend on the algorithm.