This page lists known issues in Tink. To report an issue or view recent reports from other users, go to our issues page on GitHub.
We recommend using Tink with the latest version of Conscrypt, Oracle JDK, OpenJDK or Bouncy Castle. If you cannot use the latest version, you might want to avoid using ECDSA (alternative: ED25519) or AES-GCM (alternatives: AES-EAX, AES-CTR-HMAC-AEAD or XChaCha20-Poly1305).
- The minimum API level that Tink supports is 19 (Android KitKat). This covers more than 90% of all Android phones. Tink hasn't been tested on older versions. Drop us a line if you really need to support ancient Android phones.
- On Android Marshmallow (API level 23) or older, the new
SeekableDecryptingChannel method in implementations of StreamingAead doesn't
work. It depends on
which is only available on API level 24 or newer. Users should use
- On Android Lollipop (API level 21) or older,
AndroidKeysetManagerdoes not support wrapping keysets with Android Keystore, but it would store keysets in cleartext in private preference. This is secure enough for most applications.
- On Android KitKat (API level 19) without
Google Play Services,
AES-GCMdoes not work properly because KitKat uses Bouncy Castle 1.48 which doesn't support updateAAD. If Google Play Services is present,
AES-GCMshould work well. If you want to support all Android versions without depending on Google Play Services, use
Envelope encryption: benign malleability
Envelope encryption uses a third-party provider (such as GCP or AWS) to encrypt the data encryption key (DEK). It is possible to modify certain parts of the encrypted DEK without detection when using KmsEnvelopeAead with AwsKmsAead or GcpKmsAead as the remote provider. This is due to the inclusion of some unauthenticated metadata (for instance version numbers), and modifications are not detected by the provider. Note that this violates the adaptive chosen-ciphertext attack property for this interface, although the ciphertext will still decrypt to the correct DEK. When using this interface do not presume that each DEK only corresponds to a single encrypted DEK.
Elliptic curve digital signature algorithm signatures (ECDSA), like the ECD-P256 key type recommended for use with Digital Signature are malleable. You can probably ignore this issue, unless you're working on Bitcoin or cryptocurrencies and have to worry about transaction malleability. In that case you want to use an ED25519 signature, such as EdDSA-Ed25591, which is non-malleable.
Streaming AEAD - potential integer overflow issues
Streaming AEAD implementations encrypt the plaintext in segments. Tink uses a 4-byte segment counter. When encrypting a stream consisting of more than 232 segments, the segment counter might overflow and lead to leakage of key material or plaintext. This problem was found in the Java and Go implementations of the AES-GCM-HKDF-Streaming key type, and has been fixed since 1.4.0.