2

I was going to encrypt with AES, But I noticed ECB mode is not safe for CPA. So I thought about preventing CPA by padding input text to a multiple of 16 bytes.

First, perform custom padding system: pad input text and secret text for 16bytes "each" like this, so input text will be a multiple of 16 bytes.

For example pad for 8 bytes, pad text is part of "12345678" in ASCII:

AAAAA   -> AAAAA123
A       -> A1234567
AAAAAAAA-> AAAAAAAA12345678

After that, pad with PKCS#7 compatible padding on this padded input + padded secret text.

Last, encrypt the padded text with AES128/ECB.

Then, secret text will be encrypted separately with input text. So.. maybe this prevents CPA.

I think it is not safe still on something other attack. But It seems like perfectly prevent to get secret text with CPA is.

Is there any way to get secret text? Or is it safe?

In other words, Is there any possible attack or CPA in other way on this upgraded ECB mode?

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
kakacar
  • 23
  • 3
  • Note that padding - at least for block cipher modes such as CBC / ECB - is always performed on the plaintext (i.e. not on the ciphertext). If you'd add your own padding up to the block size then one additional block with just encrypted padding will be added. So basically you'd have replaced PKCS#7 compatible padding, and added a useless block of ciphertext that always has the same value (16 bytes of PKCS#7 padding). – Maarten Bodewes Feb 12 '23 at 22:19

2 Answers2

5

Padding only affects the last part of the ciphertext. So, by definition, the other blocks before the last one are still ECB encoded without any particular alteration. So - almost by definition - it does absolutely nothing when it comes to getting ECB to be IND-CPA. All the blocks are still clearly distinguishable if they contain a previously encountered plaintext / ciphertext combination.

The scheme you mention is nothing more than an additional deterministic padding. It won't make the algorithm more or less secure.

Most other modes are invulnerable against the CPA attacks that ECB suffers from, so if you just choose about any other, you should be fine. Nowadays we generally go for an authenticated scheme such as AES-GCM.

Notes:

  • secure ciphers always require a unique IV / key combination to be CPA secure (I'll assume that a nonce is a type of IV here);
  • IND-CPA security means indistinguishability (of the ciphertext) against chosen plaintext.
  • To be able to confirm a block of plaintext the attacker must be able to either have an oracle encrypt the plaintext or the attacker must know the encryption of a block for that specific plaintext in advance; if the cipher is not IND-CPA secure then attacker may just gain information that some blocks are identical (or not).
  • Your scheme is not secure against padding oracle attacks; you'd have to use a scheme without padding or one that authenticates the ciphertext to achieve security against padding oracles (where such an oracle can be constructed).
Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
1

If for some reason you want to "force" AES-ECB to become CPA resistant, I guess the best option would be to insert one plaintext byte to each 16-bytes block, and fill the other 15 bytes with Cryptographically strong random bytes.

Of course, it would probably be ok to insert 2 or 3 plaintext bytes per block, but we need to keep in mind that in CPA the attacker can query the encryption oracle as many times as he chooses (within some computational boundary of course), so if we don't ensure a sufficiently large random padding length, it will be easy to exhaust the pad combinations and reveal whether a certain message was encrypted under the relevant key. (Even if the attacker can't control the padding bytes, probability of a collision may become non negligible).

This would be a highly wasteful scheme (and also clearly not CCA secure for example), so I wouldn't recommend using it, apart from academic purposes, but I think it can be shown to be CPA secure. If your goals are practical rather than academic, as @MaartenBodewes already mentioned you are better off using a secure mode of operation like GCM.

Edit: After writing the above, I also found a question asking exactly about the kind of scheme I've "proposed"* here: Does AES-ECB with random padding added to each block satisfy IND-CPA?

*(I don't literally propose that anyone should use this! Please don't. Hence the quotation marks.)

Amit
  • 432
  • 3
  • 12