Is it safe to re-use a key with Fernet?

mic_e

5/22/23, 3:29 PM

Fernet is a supposedly idiot-proof, AES-based symmetric encryption scheme that was (again, supposedly) carefully designed to avoid any pitfalls that might compromise security.

I want to use the same key to encrypt multiple files, including modified versions of the same file.

I'm aware that many encryption schemes, especially home-brewn ones, become vulnerable to cryptoanalysis when keys are re-used (simplest example: XOR-based stream cipher), and I didn't find any explicit statement in the Fernet documentation that permits key reuse.

On the other hand,

Fernet is supposedly idiot-proof
Fernet uses a random IV each time it encrypts something
The documentation doesn't warn about reusing keys

So, what can go wrong if I reuse a key with Fernet?

My alternative approach, if key reuse is unsafe, would be to encrypt the files as follows:

Choose a random salt
Use a KDF to calculate the individual key from shared key and salt
Encrypt the file with the individual key, and append the salt

But this seems wrong (salt is only for use with passwords, not with random data...) and more importantly requires me to use low-level cryptography primitives which are explicitly not idiot-proof.

0 + 0

symmetric

key-reuse

Score:1

Crypto

kelalaka

5/22/23, 5:44 PM

The listed page talks about AES-128-CBC encryption with Encrypt-then-MAC Mac with HMAC.

The user's obligation is to provide the message, 256-bit uniform random key, and a time stamp.

The Fernet splits the 256 bits of the key into two equal-sized parts. First, part is used in the encryption of the message with AES-128-CBC, then the authentication tag $t$

$$ t = \operatorname{HMAC-SHA-256}( Version ‖ Timestamp ‖ IV ‖ Ciphertext)$$ is calculated with the other part of the key.

what can go wrong if I reuse a key with Fernet?

Encryption of too much message with the same key can cause IV collision under the same key.

This can leak that the beginning of the messages is the same. If you edit your file and don't encrypt it with a different IV then it will leak the same prefix of the files.

Well, one needs to encrypt $2^{64}$ messages to have IV collision under the same key. The 50% is too high for the advantage of the attacker one should consider lower probabilities.
Encryption of too much data block

Can cause ciphertext collision that uses Sweet32 attack. X-or of the mesage block can be obaineds if $c_i = c_j$ with $i \neq j$ $$m_i \oplus m_j = c_{1-1} \oplus c_{j-1}.$$

Again, the 50% is too high for the advantage of the attacker one should consider lower probabilities.

These two problems really depend on how many files you have and how much size they have.

Not totally safe, using different keys and IVs per file is better. Actually, Fernet's API enables this.

My alternative approach, if key reuse is unsafe, would be to encrypt the files as follows:

Choose a random salt

Use a KDF to calculate the individual key from shared key and salt

Encrypt the file with the individual key, and append the salt

But this seems wrong (salt is only for use with passwords, not with random data...) and more importantly requires me to use low-level cryptography primitives which are explicitly not idiot-proof.

This is what we do; have different keys and IV per file. You can use HKDF even only the expand part to derive key and IVs.

To be honest, I always ask why does someone needs complicated stuff while encrypted containers of the VeraCrypt handle this better than even experts. One doesn't need to consider encryption at all. Just learn to have a good password like dicewire typed and you are done.