1

I'm using RNGCryptoServiceProvider.GetBytes(new byte[16]) to generate IV's to use in AES (256 bits) encryption. For every record I encrypt, I generate a new IV.

I'm also prepending each of these IV's to the encrypted text (to avoid storing them on a different column in the DB), as I guess is the standard.

However, to do that concatenation, I am using Convert.ToBase64String() to convert the IV byte array to a string first.

After a few tests I found a couple patterns that concern me:

  • every IV, as a string, ends with "=="
  • every encrypted text ends with a "="

One example of an output from my encryption: XbjwWH4ZA02KtH49/4IP9w==RxVDObmUzg3TJe0jWNuj8ZqDwK4zc8n0o4KCsXV1478=

Isn't this painfully obvious? I look at this and I know exactly where the IV ends and the encrypted string begins. If every record in the DB looks like this, then it's obvious that the first part is the IV, if you notice the fixed size and are aware of standard implementations.

Also, I'm not sure the ending with a "=" won't give away more.

Why does this happen? Is it my fault for converting the byte array? Shouldn't I be worried about these patterns being a possible security weakness?

9
  • 1
    Why do you think IV start/end position needs to be secret? Also why are you concatenating the b64 strings and not the bytes, and then converting to b64?
    – user
    Jun 9, 2021 at 13:02
  • I just assumed that an attacker would have an easier time by just knowing the IV. You are correct, I will change my implementation to concat the bytes first, makes a lot more sense! Beginner mistakes, I guess. Thank you for the help :) Jun 9, 2021 at 13:37
  • 1
    Err, which encryption mode are you using?
    – kelalaka
    Jun 9, 2021 at 20:10
  • I just assumed that an attacker would have an easier time by just knowing the IV Even if that were true, how were you going to stop them? Base64 is trivial to recognize and reverse; it doesn't hide anything. Also, seconding (and thirding!) the previous comment: WHAT ENCRYPTION MODE ARE YOU USING? AES by itself can only encrypt 128 bits at a time. You mention IVs, so that implies perhaps CBC mode, but CBC doesn't provide integrity and that matters. Your example doesn't include an authentication tag or MAC, so I'm guessing you made another beginner mistake and left out integrity.
    – CBHacking
    Jun 10, 2021 at 11:06
  • @CBHacking I am using cipher mode CBC, yes. And btw, the padding is PKCS7. I generated a key with 32 bytes, and the IVs with 16 bytes. I'm not sure what you mean by integrity, so you're probably right. Jun 15, 2021 at 22:18

1 Answer 1

1

Isn't this painfully obvious? I look at this and I know exactly where the IV ends and the encrypted string begins.

That's OK. The IV is not a secret, and an attacker does not gain any advantage by knowing which bytes in the payload contain the IV and which bytes contain the ciphertext. With other encryption tools, it is well-known how the IV is stored along with the ciphertext - especially if the encryption tool is open-source, and anyone can simply look at the code to see how its done. See https://crypto.stackexchange.com/questions/3298/is-there-a-standard-for-openssl-interoperable-aes-encryption for how openssl does it.

Also, I'm not sure the ending with a "=" won't give away more.

Remember, your IV and your ciphertext are raw bytes. You are base64-encoding these raw bytes, so that they can be represented as displayable text. Base64-encoded text must have a length that is a multiple of 4. The '=' symbols that you are seeing is padding, to pad the length to a multiple of 4 if needed. Again, this is not revealing anything useful to an attacker.

If you don't like having the '=' symbols between your IV and your ciphertext, just concatenate the raw bytes of your IV with the raw bytes of your ciphertext first, then base64-encode the result of that.

1
  • Thank you very much! I've seen a lot of stuff online mentioning that IV's can be public, but I wasn't understanding why. Your comment cleared that up for me, I believe. And the "=" symbols make sense as well. Thank you! Jun 9, 2021 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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