5

I'm attempting to encrypt some information into our database to be later pulled back out and displayed to the user. Searching and reading up on different methods I found a post over at stack exchanged with example code for doing AES Encryption.

https://stackoverflow.com/questions/165808/simple-2-way-encryption-for-c-sharp

Reading through the comments and some different articles I've come to realize that using a static IV for your encryption is generally poor form. That using a random IV is better. This would make sense, but to my understanding I need a way to find that IV again in order to be able to decrypt the information.

I would believe that I can't store the IV in my DB as well, since that would defeat the whole purpose of this. The only thing I can think of is to use something in the row (e.g. a Datetime) as a seed for a random number generator. Which would generate the same IV every time, but that doesn't seem that secure to me either if anyone figured that out.

What are the best practices for situations like this?

Community
  • 1
Derek
  • 53
  • 3

1 Answers1

7

Using a static IV isn't simply "poor form" — it introduces crippling weaknesses to the security of your ciphertexts. Likewise, using correctly-generated IVs (the requirements differ from mode-to-mode, but cryptographically random IVs almost always meet those requirements) isn't "better"; it's absolutely necessary.

That said, there is absolutely no requirement of security for IVs. They can be stored safely alongside your ciphertexts.

However, I would strongly caution against using the implementation in the linked post. It uses CBC mode without authenticating the validity of the ciphertext (e.g., with an HMAC), and so will likely (depending on your particular use) make you susceptible to padding oracle attacks.

You should use something like KeyCzar or NaCl if at all possible. As a non-cryptographer, trying to use cryptographic primitives yourself is a bit like trying to build a car engine from parts. You're overwhelmingly likely to miss an important but crucial detail, and have the whole thing blow up in your face.

Stephen Touset
  • 11,002
  • 1
  • 38
  • 53