Return to Answer

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

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

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.

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

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. Remember, in CPA the attacker can obtain as many ciphertexts as he wants for any plaintext, so if you don't have enough random padding bytes he can easily 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 be 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.

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.