search

tink-crypto / tink-go

Go implementation of Tink
https://developers.google.com/tink
Apache License 2.0
91 stars 4 forks source link

DEK in case of envelope encryption with AEAD is not authenticated with additional data #4

Closed beatrausch closed 9 months ago

beatrausch commented 10 months ago

Hi,

could please provide feedback about the following behavior, if it is intended or an bug.

Describe the issue: Remote Keys (DEKs) in case of envelope encryption with AEAD are not authenticated with additional data. See https://github.com/tink-crypto/tink-go/blob/2baf2591ca0eec082e754a2a3d2dd8bb948e70b3/aead/kms_envelope_aead.go#L90

What was the expected behavior? Remote Keys (DEKs) are authenticated with the same additional data as the plaintext.

What version of Tink are you using? v1.7.0 and main

Can you tell us more about your development environment? Golang 1.21

Regards,

beatrausch commented 10 months ago

Hi,

I checked the Java implementation and it does it in the same way. See

So probably no bug?

Regards, Daniel

kste commented 9 months ago

Hi Daniel,

This is indeed intentional and across all languages the associated data used for the remote part of the envelope encryption is the empty string.

In general, it would be desirable to bind the wrapped key to the ciphertext, however this would add quite some overhead here (e.g. you would have to either send the complete ciphertext or its hash to the remote AEAD to use as associated data; computing a hash over the ciphertext is costly compared to the actual costs of encrypting the plaintext). Considering that a unique key is generated each time you encrypt something with envelope encryption, there is an implicit binding though as this wrapped key will only be valid for this specific ciphertext.

Admittedly, this implicit binding can however lead to some subtle weakness if the AEAD and/or the remote AEAD are not committing to its inputs. In this case the assumption that the wrapped key will only be valid for a single specific ciphertext is violated (see e.g. https://eprint.iacr.org/2020/1456, https://www.usenix.org/conference/usenixsecurity23/presentation/cremers-protocols, https://eprint.iacr.org/2023/526 for some recent work on this topic). For most applications this won’t be an issue, but it’s something one should be aware of.

beatrausch commented 9 months ago

Hi, understood, so I will close the issue. Regards