Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When Do We Need to Provide Our Own Random Initialization Vector (IV) With Android?

Tags:

There are many published reports that on older versions of Android, we need to provide our own SecureRandom-based initialization vector (IV), as the default ones are not random:

  • Generating IV for AES in Java
  • https://medium.com/@tiensinodev/basic-android-encryption-dos-and-don-ts-7bc2cd3335ff
  • https://tozny.com/blog/encrypting-strings-in-android-lets-make-better-mistakes/
  • Android cryptography API not generating safe IV for AES

Conversely, as of API Level 23, if you try to provide your own IV, you also have to call setRandomizedEncryptionRequired(false) on the KeyGenParameterSpec.Builder, as otherwise you get a "Caller-provided IV not permitted when encrypting" exception.

Presumably, somewhere along the line, Android went from "awful" to "good enough" in terms of IV generation.

What is the cutoff, below which we should generate our own IV versus use Android's generated IV?

like image 915
CommonsWare Avatar asked Feb 01 '18 22:02

CommonsWare


People also ask

What is the purpose of the initialization vector IV?

Initialization vectors (IVs) are used to prevent a sequence of text that is identical to a previous sequence from producing the same exact ciphertext when encrypted.

Why IV should be random?

The IV should be random and only used once, otherwise it may allow people to decrypt other cipher texts which used the same key.

Is initialization vector needed for decryption?

Yes, you must provide the same IV for encryption and decryption.

How do you store a vector initialization?

Like a Salt value, an Initialization Vector can be stored in the public storage, along with encrypted data. And one of the possible ways to store it, is to add IV data to the encryption result : And parse it before decryption, from encrypted data: Full source code is available here.


1 Answers

From a security point of view, you should always provide your own IV, because you would have total control of its randomization quality, and eliminate one potential security weak point.

Regarding the exception, in your perspective, the IV is random and good. But in Android's perspective, your provided IV is fixed and thus not good, the API does not know if it is properly randomly generated or not. So the exception "Caller-provided IV not permitted when encrypting" is just a general warning trying to warn developers against using bad IV and encourage them to use the built-in IV.

However, note that the built-in IV is just one method to build the IV. As you can see, no one assures its quality as of API Level 23, so the best practice is still to assure your own IV quality yourself.

like image 132
THN Avatar answered Oct 03 '22 20:10

THN