CODEWITHSUNDEEP
c#encryptioncryptography
PC Luddite
PC Luddite

Reputation: 6098

Security of AES encryption with constant salt

I have an encoding application written in C# where users can optionally encrypt messages. I had been using the class in this answer, and it turns out I'm in good company because I found several places online that use the exact same code (one of which is Netflix's Open Source Platform).

However, comments to that answer (as well as later edits to that answer) led me to believe that this method was insecure. I opted to use the class in this answer to the same question instead.

How secure is AES encryption if you use a constant salt? How easily can this method be broken? I admit that I have very little experience in this area.

Upvotes: 1

Views: 1664

Answers (2)

Maarten Bodewes
Maarten Bodewes

Reputation: 94018

AES is a block cipher. A block cipher's input is a key and a block of plaintext. A block cipher is usually used in a block cipher mode of operation. All secure modes of operation use an Initialization Vector or IV. Otherwise identical plaintext would encrypt to identical ciphertext (for the same key), and this is leaking information.

Salt is not used by AES or modes of operation. It's usually used as input for Key Derivation Functions (KDFs), especially Password Based Key Derivation Functions (PBKDFs). Dot NET's Rfc2898DeriveBytes implements the PBKDF2 function as defined in - you'd guess it - RFC 2898: "PKCS #5: Password-Based Cryptography Specification Version 2.0".

If you use a static salt in a PBKDF2 then you would get the same key as output (for the same number of iterations). Now if you would ever leak the resulting key then all your ciphertext would be vulnerable. And if you would use multiple passwords then an attacker would be able to build a rainbow table; the PBKDF2 work factor would become less important; the attacker can simply build one table and then try all the resulting keys on all possible ciphertexts.

So, as the salt is not actually used for AES it doesn't make much of a difference for the security. It is however still a horrible sin, even worse than using the default iteration count for PBKDF2 / Rfc2898DeriveBytes.

Note that horrible security sins are committed by a large number of people on a daily basis. That there are many many many persons that get it wrong doesn't tell you that you are in "good company". That there are 289 upvotes just tells you that SO answers about cryptography should not be trusted based on vote count.

Upvotes: 2

Amir Sasson
Amir Sasson

Reputation: 11513

Salt is there for a reason. This enables same input to be encrypted differently. If an attacker would really insist, he can find some patterns that repeat themselves in encryption without salt, and eventually can get to your key more easily. Still the attcker would have to work very hard. Using constant salt equals to not using salt at all. And it is highly recommended to use it, as it has no effect on the decryption process.

Upvotes: 0

Related Questions