24

As per PCI-DSS 3.4 requirement:

For storing Credit Card Data Strong Cryptography should be used.

I decided to use AES Encryption which is a strong and mostly recommended crypto for encrypting Credit Card Details.

I saw that AES has Cipher Mode and Padding Mode in it.

When I searched i found that according to NIST Special Publication 800-38A, it specifies five confidentiality modes of operation for symmetric key cipher algorithm.

So I'm totally confused whether can I use anyone of the five cipher modes or is there best one among the five as listed below:

Cipher Modes:

  1. ECB
  2. CBC
  3. OFB
  4. CFB
  5. CTR

Which is the best Cipher mode among the five?

Also which is the best Padding Mode for AES Ecryption?

closed as unclear what you're asking by Adi, TildalWave, Xander, Steve, Scott Pack Mar 5 '14 at 3:05

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

49

"Best" is rather subjective - it depends on your requirements. That said, I'll give you a general overview of each mode.

ECB - Electronic Code Book. This mode is the simplest, and transforms each block separately. It just needs a key and some data, with no added extras. Unfortunately it sucks - for a start, identical plaintext blocks get encrypted into identical ciphertext blocks when encrypted with the same key. Wikipedia's article has a great graphic representation of this failure.

Good points: Very simple, encryption and decryption can be run in parallel.

Bad points: Horribly insecure.

CBC - Cipher Block Chianing. This mode is very common, and is considered to be reasonably secure. Each block of plaintext is xor'ed with the previous block of ciphertext before being transformed, ensuring that identical plaintext blocks don't result in identical ciphertext blocks when in sequence. For the first block of plaintext (which doesn't have a preceding block) we use an initialisation vector instead. This value should be unique per message per key, to ensure that identical messages don't result in identical ciphertexts. CBC is used in many of the SSL/TLS cipher suites.

Unfortunately, there are attacks against CBC when it is not implemented alongside a set of strong integrity and authenticity checks. One property it has is block-level malleability, which means that an attacker can alter the plaintext of the message in a meaningful way without knowing the key, if he can mess with the ciphertext. As such, implementations usually include a HMAC-based authenticity record. This is a tricky subject though, because even the order in which you perform the HMAC and encryption can lead to problems - look up "MAC then encrypt" for gory details on the subject.

Good points: Secure when used properly, parallel decryption.

Bad points: No parallel encryption, susceptible to malleability attacks when authenticity checks are bad / missing. But when done right, it's very good.

OFB - Output Feedback. In this mode you essentially create a stream cipher. The IV (a unique, random value) is encrypted to form the first block of keystream, then that output is xor'ed with the plaintext to form the ciphertext. To get the next block of keystream the previous block of keystream is encrypted again, with the same key. This is repeated until enough keystream is generated for the entire length of the message. This is fine in theory, but in practice there are questions about its safety. Block transforms are designed to be secure when performed once, but there is no guarantee that E(E(m,k),k) is secure for every independently secure block cipher - there may be strange interactions between internal primitives that haven't been studied properly. If implemented in a way that provides partial block feedback (i.e. only part of the previous block is bought forward, with some static or weakly random value for the other half) then other problems emerge, such as a short key stream cycle. In general you should avoid OFB.

Good points: Keystream can be computed in advance, fast hardware implementations available

Bad points: Security model is questionable, some configurations lead to short keystream cycles

CFB - Cipher Feedback. Another stream cipher mode, quite similar to CBC performed backwards. Its major advantage is that you only need the encryption transform, not the decryption transform, which saves space when writing code for small devices. It's a bit of an oddball and I don't see it mentioned frequently.

Good points: Small footprint, parallel decryption.

Bad points: Not commonly implemented or used.

CTR - Counter Mode. This essentially involves encrypting a sequence of incrementing numbers prefixed with a nonce (number used once) to produce a keystream, and again is a stream cipher mode. This mode does away with the problems of repeatedly running transforms over each other, like we saw in OFB mode. It's generally considered a good mode.

Good points: Secure when done right, parallel encryption and decryption.

Bad points: Not many. Some question the security of the "related plaintext" model but it's generally considered to be safe.


Padding modes can be tricky, but in general I would always suggest PKCS#7 padding, which involves adding bytes that each represent the length of the padding, e.g. 04 04 04 04 for four padding bytes, or 03 03 03 for three. The benefit over some other padding mechanisms is that it's easy to tell if the padding is corrupted - the longer the padding, the higher the chance of random data corruption, but it also increases the number of copies of the padding length you have. It's also trivial to validate and remove, with no real chance of broken padding somehow validating as correct.


In general, stick with CBC or CTR, with PKCS#7 where necessary (you don't need padding on stream cipher modes) and use an authenticity check (HMAC-SHA256 for example) on the ciphertext. Both CBC and CTR come recommended by Niels Ferguson and Bruce Schneier, both of whom are respected cryptographers.

That being said, there are new modes! EAX and GCM have recently been given a lot of attention. GCM was put into the TLS 1.2 suite and fixes a lot of problems that existed in CBC and stream ciphers. The primary benefit is that both are authenticated modes, in that they build the authenticity checks into the cipher mode itself, rather than having to apply one separately. This fixes some problems with padding oracle attacks and various other trickery. These modes aren't quite as simple to explain (let alone implement) but they are considered to be very strong.

  • 6
    Almost three years later, has the situation changed? Have EAX and GCM (or yet other methods) moved up in the list of recommendations? (Also, are there references for the quality claims you make? Not that I don't want to believe you, but citeable evidence would easy my conscience.) – Raphael Jan 25 '17 at 14:18
  • 1
    GCM has definitely gained popularity, particularly in TLS. – Polynomial Jan 24 '18 at 17:26

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