I realize that is a loaded question, but it is not an unreasonable one.

given a hex key/iv, what mode of operation is most secure from offline attacks.

I defaulted to aes-128-cbc. Partly because of schneier's 128 > 256 article. cbc because friends don't let friends use PBE or ECB



Use case: multi-client and platform support, which boils down to openssl in the end


Please focus on the question, and don't try to guess the use case. This is not for a government, PCI, etc environment. Key management is out of the scope of this question.

  • I didn't try to guess the use case. But: The best way to avoid people trying to guess your use case is to explicitly state what your use case actually is.... The use case is often relevant.
    – D.W.
    Commented Oct 13, 2011 at 19:43
  • The claim that AES-128 is more secure than AES-256 is a little silly. Because of the way the cipher works, if the key is truly random and uniformly distributed, it is impossible for AES-256 to be less secure. The only time it would be less secure is if related key attacks apply to your scheme (e.g. if attackers can choose or influence the keys). If each key is uniformly random, the weakness in the key schedule is entirely irrelevant and AES-256 will always be more secure than AES-128.
    – forest
    Commented May 15, 2018 at 7:31

2 Answers 2


They're all secure enough. The two standard choices are CBC and CTR. CBC is a bit more resilient to implementation errors. CTR can be parallelized more effectively. Pick either one.

Just make sure that you know what you are doing. The number-one most common mistake is to design your own cryptography. The number-one best way to avoid common mistakes is to reuse some existing high-level crypto software, like GPG or the OpenPGP format for securing data at rest, and TLS for securing communication channels.

Based upon your question, I would say that you are at high risk of introducing common mistakes into your software by attempting to build something yourself, rather than using standard mechanisms like GPG/TLS/etc.

  • 2
    I would like to add to this good answer that IV management is often a sore point. All modes require an Initialization Vector which is a publicly transmitted value, along the encrypted data (sometimes "implicitly"). A new IV must be regenerated for each message. The encryption modes have distinct requirements for the IV generation. Commented Oct 13, 2011 at 14:00
  • Thanks, but as I mention it all interfaces with OpenSSL in the end. It uses openssl to generate the key/iv and then uses the openssl library to encrypt and decrypt. Also, complex IV management is not overkill in this use case.
    – oreoshake
    Commented Oct 13, 2011 at 18:20

All the modes are not "secure enough". If you don't use authentication encryption, an attacker may be able to modify data (even though he can't read it) or to recover a plaintext using a side channel attack such as Vaudenay's padding oracle attack against CBC-PAD. This is what was used in the BEAST attack against SSL. Use GCM (Galois Counter Mode) if possible. For more options, check out Matthew Green's post on the subject: http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html

If you don't use an authenticated mode of encryption, you'll need to use HMAC (or some other MAC).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .