Crypto library mainstreamed as version 1.2.0 lands on GitHub

Last year, a group of Google engineers emitted an “unofficial project,” a cryptographic library called Tink. Now, the Chocolate Factory has decided the software's good enough to carry its name.

One of Tink's developers, infosec engineer Thai Duong, made the library “official” in this blog post announcing version 1.2.0.

Duong wrote that the two-year coding effort has been boosted by its adoption within Mountain View as the basis of security for Google Pay, Google Assistant, the Firebase app developmen platform, Android search, and the AdMob advertising platform.

The new version allows developers to use Tink in Android and iOS applications, and in AWS cloud environments. C++ and Objective-C join Java as supported languages, and Android support is delivered via the Gradle build tool.

Its crypto algorithms include AES-EAX, AES-GCM, AES-CTR-HMAC-AEAD; HMAC-SHA2 for message authentication; ECDSA over NIST curves digital signatures; and ECIES over NIST curves with AEAD (AES-GCM and AES-CTR-HMAC-AEAD) and HKDF for hybrid encryption.

AWS support should arrive soon in Tink's C++ library, but getting it to work on Google's Cloud key management system is a tougher task “because of lack of Cloud KMS client library”

Here's a fab idea: Get crypto libs to warn devs when they screw up

Duong explained in a 2017 mailing list post that Tink is “based on the original K2 design from Daniel Bleichenbacher. Daniel is also one of the main contributors of the project.” Bleichenbacher is a familiar name in cryptography, as the discoverer of the eponymous attack against RSA encryption.

Duong wrote that Tink's APIs are designed to be “secure, easy to use correctly, and hard(er) to misuse”, and while it uses the BoringSSL and Java Cryptography Architecture, it “includes countermeasures to many weaknesses in these libraries, which were discovered by Project Wycheproof, another project from our team” (Project Wycheproof security-tests crypto libraries, and was launched in 2016).

As an example of Tink's protections, Duong wrote: "if the underlying encryption mode requires nonces and nonce reuse makes it insecure, then Tink does not allow the user to pass nonces”.

To make it easier to validate, Tink's security properties are exposed in the APIs, and the APIs are isolated for dangerous operations (Duong's example is loading keys from disk), so their usage can be discovered, restricted, monitored and logged. ®