https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 14:57:41 +0000 https://cve.radiocsirt.org/vuln/cnvd-2020-57870 cnvd-2020-57870 https://cve.radiocsirt.org/vuln/cnvd-2020-57870 https://cve.radiocsirt.org/vuln/euvd-2026-38797 EUVD-2026-38797 https://cve.radiocsirt.org/vuln/euvd-2026-38797 https://cve.radiocsirt.org/vuln/fkie_cve-2020-8929 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2020-8929 https://cve.radiocsirt.org/vuln/ghsa-g5vf-v6wf-7w2r <p><strong>Affected:</strong> Maven: com.google.crypto.tink:tink</p> <p>### Impact Tink&#39;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.</p> <p>No loss of confidentiality or loss of plaintext integrity occurs due to this problem, only ciphertext integrity is compromised.</p> <p>### Patches The issue was fixed in this [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).</p> <p>### Workarounds The only workaround is to backport the fixing [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).</p> <p>### 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](https://en.wikipedia.org/wiki/UTF-8#Invalid_sequences_and_error_handling) by the [Java API&#39;s default behavior](https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#String(byte[],%20java.nio.charset.Charset)). This means seve…</p> <p><strong>Affected:</strong> Maven: com.google.crypto.tink:tink</p> <p>### Impact Tink&#39;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.</p> <p>No loss of confidentiality or loss of plaintext integrity occurs due to this problem, only ciphertext integrity is compromised.</p> <p>### Patches The issue was fixed in this [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).</p> <p>### Workarounds The only workaround is to backport the fixing [pull request](https://github.com/google/tink/commit/93d839a5865b9d950dffdc9d0bc99b71280a8899).</p> <p>### 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](https://en.wikipedia.org/wiki/UTF-8#Invalid_sequences_and_error_handling) by the [Java API&#39;s default behavior](https://docs.oracle.com/javase/7/docs/api/java/lang/String.html#String(byte[],%20java.nio.charset.Charset)). This means seve…</p> https://cve.radiocsirt.org/vuln/ghsa-g5vf-v6wf-7w2r https://cve.radiocsirt.org/vuln/gsd-2020-8929 gsd-2020-8929 https://cve.radiocsirt.org/vuln/gsd-2020-8929 https://cve.radiocsirt.org/vuln/pysec-2020-142 <p><strong>Affected:</strong> PyPI: tink</p> <p>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.</p> <p><strong>Affected:</strong> PyPI: tink</p> <p>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.</p> https://cve.radiocsirt.org/vuln/pysec-2020-142