CVE-2020-8929

A mis-handling of invalid unicode characters in the Java implementation of Tink versions prior to 1.5 allows an attacker to change the ID part of a ciphertext, which result in the creation of a second ciphertext that can decrypt to the same plaintext. This can be a problem with encrypting deterministic AEAD with a single key, and rely on a unique ciphertext-per-plaintext.

A mis-handling of invalid unicode characters in the Java implementation of Tink versions prior to 1.5 allows an attacker to change the ID part of a ciphertext, which result in the creation of a second ciphertext that can decrypt to the same plaintext. This can be a problem with encrypting deterministic AEAD with a single key, and rely on a unique ciphertext-per-plaintext.

Impact

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.

Patches

The issue was fixed in this pull request.

Workarounds

The only workaround is to backport the fixing pull request.

Details

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

Acknowledgements

We'd like to thank Peter Esbensen for finding this issue and raising it internally.

For more information

If you have any questions or comments about this advisory:

• Open an issue in Tink

A mis-handling of invalid unicode characters in the Java implementation of Tink versions prior to 1.5 allows an attacker to change the ID part of a ciphertext, which result in the creation of a second ciphertext that can decrypt to the same plaintext. This can be a problem with encrypting deterministic AEAD with a single key, and rely on a unique ciphertext-per-plaintext.

A mis-handling of invalid unicode characters in the Java implementation of Tink versions prior to 1.5 allows an attacker to change the ID part of a ciphertext, which result in the creation of a second ciphertext that can decrypt to the same plaintext. This can be a problem with encrypting deterministic AEAD with a single key, and rely on a unique ciphertext-per-plaintext.

Impact

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.

Patches

The issue was fixed in this pull request.

Workarounds

The only workaround is to backport the fixing pull request.

Details

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

Acknowledgements

We'd like to thank Peter Esbensen for finding this issue and raising it internally.

For more information

If you have any questions or comments about this advisory:

• Open an issue in Tink

A mis-handling of invalid unicode characters in the Java implementation of Tink versions prior to 1.5 allows an attacker to change the ID part of a ciphertext, which result in the creation of a second ciphertext that can decrypt to the same plaintext. This can be a problem with encrypting deterministic AEAD with a single key, and rely on a unique ciphertext-per-plaintext.