RB with random IV value for encryption

[Shivanand.Kunijadar at toshiba-tsip.com]

Hi, 

Thank you for the reply.

> 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. 

Yes correct. 

>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.

Sounds good, will check and try to adapt it. 

>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.

Right, IV doesn't matter if key is different each time, however we use same key each time so will generate IV using hmac as you suggested. 

Thanks & Regards
Shivanand K





-----Original Message-----
From: rb-general <rb-general-bounces at lists.reproducible-builds.org> On Behalf Of kpcyrd
Sent: Monday, December 23, 2024 9:15 PM
To: rb-general at lists.reproducible-builds.org
Subject: Re: RB with random IV value for encryption

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