RB with random IV value for encryption

[kpcyrd]

On 12/23/24 12:06 PM, Shivanand.Kunijadar at toshiba-tsip.com wrote:
> Hi RB-Team,
> We are facing reproducibility issues with encrypted images. We use a random IV for encryption with AES CBC. The resulting artifact is not reproducible due to the random IV used.
> 
> Based on information from the RB website, the Random data will make builds unreproducible and must be avoided[1].
>  From a security perspective, it will be risky to use predictable IV values for the encryption.
> 
> Is there any other discussions related to the same in the mailing list or any guidelines related to handling random IV values for RB?

Disclaimer: I'm a self-taught cryptographer.

That being said, the IV in AES-CBC is used to achieve ciphertext 
indistinguishability[1]. If you use a static IV of e.g. all-0's, an 
adversary could, just from looking at the ciphertexts:

- detect if two ciphertexts decrypt to the same plaintext
- detect if two ciphertexts share a common prefix when decrypted

For a general-purpose encryption system this would usually be considered 
'very bad', which is why it's recommended to use a random nonce as IV.

For your specific use-case you may not care about 'these two encrypted 
images decrypt to the same image', but you may still care about the 
shared-prefix situation, because it may give away if some binary/config 
in the image has/has not been patched/modified between versions.

To prevent the later, you could use `hmac(aes_key, image_sha256)` to 
derive your IV in a deterministic way, making sure the IV is unique for 
each message, without accidentally giving away the sha256 of your 
decrypted image.

All of this is assuming the symmetric key is being reused, if the 
encryption key is unique to each message anyway, the IV doesn't matter much.

Hope this helps.

cheers,
kpcyrd

[1]: https://en.wikipedia.org/wiki/Ciphertext_indistinguishability