Is there any advantage to populating random data in AES encryption?

Question

When using AES encryption, the plaintext must be supplemented by the size of the encryption block. Most libraries and standards use a pad where padding bytes can be determined from the unallocated length of the plaintext. Can random padding bytes be used if possible?

I implement a confidential data storage scheme for each user and each session. Data will typically be JSON-encoded key-value pairs and can be potentially short and duplicate. I am looking at PKCS # 5 for guidance, but I planned to use AES for the encryption algorithm, not DES3. I planned a random IV for each data item and a key defined by a user ID and a password or session ID, depending on the situation.

One thing that surprised me was the PKCS # 5 supplement scheme for clear text. To put the encrypted text in 8-byte blocks, 1 to 8 bytes are added at the end, and the contents of the byte complement fill the number of fill bytes (i.e. 01 , 0202 , 030303 , to 0808080808080808 ). My own padding scheme was to use random bytes at the beginning of plaintext, and the last character of the plaintext would be the number of bytes added.

My reasoning was that in AES-CBC mode, each block is a function of the ciphertext of the previous block. Thus, each plaintext will have an element of randomness, giving me another level of protection against known plaintext attacks, as well as IV and key issues. Since my plaintext is expected to be short, I do not mind keeping the entire decrypted string in memory, but cutting off the indentation in the front and back.

One of the drawbacks will be the same loose text, IV and key, which will lead to different ciphertext, which makes unit testing more difficult (and not impossible) - I can use the pseudo-random add-on generator for testing and cryptographically strong for production).

Another would be that to force random filling, I would need to add at least two bytes - an account and one random byte. For deterministic filling, the minimum size is one byte, either saved with clear text or in a shell of ciphertext.

Since a well-known standard, such as PKCS # 5, decided to use deterministic padding, I wonder if there is anything else that I missed, or I rate the benefits too high.

Answer 1

Both, I suspect. The benefit is pretty minimal.

You forgot about the time spent on acquiring or generating random numbers of cryptographic quality. on the one hand, when there is a limited margin of randomness (/ dev / random on some systems, for example), your code may take a long time for more random bytes.

On the other hand, when you get your random bytes from PRNG, you can expose yourself to problems if you use the same random source to generate keys. If you send encrypted data to several recipients one by one, you have provided the previous recipient with a whole bunch of information about the status of PRNG, which will be used to select a key for the next communication session. If your PRNG algorithm is ever broken, which is IMO more likely than a good plaintext attack on full AES, you are much worse than if you used a deliberately deterministic add-on.

In any case, however, you get padding, it is more computationally intensive than PKCS # 5 add-on.

As an aside, it’s pretty standard to compress potentially duplicate data, for example. deflate before encrypting it; this reduces data redundancy, which can make certain attacks difficult.

One last recommendation: getting a key with a mechanism in which only the username and password are changed is very dangerous. If you intend to use it, make sure that you use the Hash algorithm without any flaws (not SHA-1, not MD-5). cf this story is slashdot

Hope this helps.