how strong is AES without salt

Question

The AES cryto library provided to us from company, does not generate a different encrypted value for plain text.

If text is "abcd" , it will generate the same encrypted value over multiple iterations.

So when we have to interact with other applications ( they redirecting it to our website and we redirecting back to their website), the scheme we use is to add a timestamp with a "#", and then encrypt.

Like in this case text becomes "abcd#32342534234232" , and then we encrypt it. The caller application decrypts it and discards the timestamp part.

I want to know the pros and cons of this scheme considering "abcd" is a user data but not a critical data like password.

Thanks !

Answer 1

Block Ciphers never incorporate a salt, this is usually used for hash functions. Block Ciphers like AES will use an Initialization Vector to ensure that two identical plaintext inputs will not produce the same cipher text output.

Also note that mode of operation that you choose for your block cipher is very important. Not all modes use an IV, for example ECB mode doesn't use an IV. ECB mode can be unsafe for multi-block data, here is an image encrypted with ECB mode:

Related: Why is using a Non-Random IV with CBC Mode a vulnerability?

Answer 2

I can see two main problems with the solution you have implemented:

• There may be several requests that have the same timestamp added, thus being easy to infer a relationship between them. If two encrypted values are identical, it means they have been generated in the same time and have the same value.
• The timestamp values is relatively easy to guess. This may help in building an attack. For example, if the attacker can choose the text to be encrypted, he would then try to guess the encryption key by submitting arbitrary values and analyzing the encrypted text. He would know what the plaintext value is (chosen value + timestamp).

Moreover, as Rook pointed out, it is very important to check what Block Ciphers you are using (if you are encrypting more than 128 bits at once). If you have no information about this, just encrypt a long text and save the value. After that, change the first letter of the plain text and encrypt it again. If the last part of the encrypted text is the same, then you are using ECB, which is not a good idea, as it has been described above.