3

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

CBC PCBC CFB OFB CTR?

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

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

EDIT:

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.

| improve 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. Oct 13 '11 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 May 15 '18 at 7:31
4

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.

| improve this answer | |
  • 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. – Thomas Pornin Oct 13 '11 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 Oct 13 '11 at 18:20
2

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).

| 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.