| Package | Affected versions | Patched versions |
|---|---|---|
| com.google.crypto.tink:tink | < 1.5.0 | 1.5.0 |
| tink | < 1.5.0 | 1.5.0 |
| tink java | < 1.5.0 | 1.5.0 |
Tink's Java version before 1.5 under some circumstances allowed attackers to change the key ID part of the ciphertext, resulting in the attacker creating a second ciphertext that will decrypt to the same plaintext. This can be a problem in particular in the case of encrypting with a deterministic AEAD with a single key, and relying on the fact that there is only a single valid ciphertext per plaintext.
No loss of confidentiality or loss of plaintext integrity occurs due to this problem, only ciphertext integrity is compromised.
The issue was fixed in this pull request.
The only workaround is to backport the fixing pull request.
Tink uses the first five bytes of a ciphertext for a version byte and a four byte key ID. Since each key has a well defined prefix, this extends non-malleability properties (but technically not indistinguishability). However, in the Java version this prefix lookup used a hash map indexed by unicode strings instead of the byte array, which means that invalid Unicode characters would be replaced by U+FFFD by the Java API's default behavior. This means several different values for the five bytes would result in the same hash table key, which allows an attacker to exchange one invalid byte sequence for another, creating a mutated ciphertext that still decrypts (to the same plaintext).
We'd like to thank Peter Esbensen for finding this issue and raising it internally.
If you have any questions or comments about this advisory:
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free