Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 !

share|improve this question

2 Answers 2

up vote 5 down vote accepted

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:

enter image description here

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

share|improve this answer
    
Thanks ... last link explains quite a lot ! –  Novice User Jan 5 '13 at 4:26
    
Though you have explained quite a bit .. but can you emphasize on the downside of the process I am following of using a timestamp for making the cipher different everytime, instead of using an IV ? –  Novice User Jan 5 '13 at 7:45
    
@Novice User It sounds horribly insecure, but I'm not sure that follow. you.. what mode are you using? –  Rook Jan 5 '13 at 17:00
2  
@NoviceUser Adding data to the plaintext is a type of cryptographic padding. However, if you're using ECB, you'll still run into the problem that statistical patterns are transferred into the ciphertext, as demonstrated by the above image. Cryptography is hard to get right - you should always use properly tested configurations (i.e. cipher mode, proper IV use, proper key generation, etc.) with a modern cryptographic cipher. –  Polynomial Jan 5 '13 at 19:15

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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