Tink Roadmap

Stay organized with collections Save and categorize content based on your preferences.

(Last updated August 2022)

This document details the high level goals our team has prioritized for the open source distribution of Tink. It will be periodically updated as the goals are achieved or changed.

We would love to hear about how you use Tink or which features would be most useful for your implementation. Let us know by taking our survey.

Splitting Tink into multiple GitHub repositories

We plan to split the project into multiple GitHub repositories. They will be separated by language. Some of the integrations will also be separate.

This will provide the following benefits:

  • Decouple the releases for each language (meaning an issue in language X won't prevent performing a release for language Y)
  • More frequent releases
  • A reduced set of dependencies to download for each library (for example, SDKs for several cloud providers)

Improving documentation

More of our internal documentation will be made public, as well as adding documentation tailored to external users. This will make it easier for new users to use the library.

We also plan to make more of our design considerations public. By doing so, we aim to make Tink easier for people to use and allow for more contribution opportunities. We also want to give cryptographers insight into our thought process and allow for peer review of hard-to-misuse cryptographic APIs.

Overhauling key management

We want to give users a better way to manage the keys within a key set. This will make it easier to implement things like key management systems. It will also enable us to add more comprehensive support for importing and exporting keys to different formats like PEM or JWK, while ensuring the API prevents common mistakes that could result in security vulnerabilities like in-band protocol negotiation.

Monitoring support

While Tink prevents many common cryptographic mistakes, there are still some blind spots that cannot be addressed with API design alone. To shed more light on these issues, we are adding monitoring hooks to Tink. Users can employ these hooks to collect and analyze non-sensitive data about their cryptographic operations. For example:

  • Noting the upper bounds on the number of encrypt calls made with a specific key across a distributed system
  • Collecting data on which key types are currently in use

To carry the example further, organizations can then use this information to ensure their key rotation is working as expected (independently from monitoring attached to the key management system), or to create a list of keys that are vulnerable to quantum computers in preparation for a PQC migration.

Post-quantum cryptography (PQC)

On July 5th, 2022, NIST announced the PQC algorithms they plan to standardize first:

  • Key Encapsulation Mechanism (KEM)
    • Kyber
    • NTRU-HRSS (only if IP questions related to Kyber remain1)
  • Digital Signature
    • Dilithium
    • Falcon
    • SPHINCS+

In 2021, we enabled C++ support for all of the above digital signature algorithms as well as NTRU-HRSS-KEM.

Tink already provides a solid PQC cipher suite for teams interested in experimenting with PQC that mostly matches the NIST PQC selection. We note that the current Tink implementations may still differ from the NIST PQC final specs, which NIST expects to publish by 2024.

Moving forward, we plan to continue to enable relevant PQC algorithms in Tink. Among them, Kyber is a good candidate as long as the IP questions mentioned above are clarified. Another good candidate is the LMS signing algorithm, which is a stateful algorithm already standardized by NIST in SP 800-208 suitable for certain applications such as code signing and secure boot. In addition, enabling experimental implementations of alternate KEMs not based on lattices (such as BIKE, HQC or Classic McEliece) may also be pursued to avoid full reliance on a single PQC family for KEMs.

  1. The Kyber IP questions refer to the NIST IR 8413 report statement: ↩

    NIST negotiated with several third parties to enter into various agreements to overcome potential adoption challenges posed by third-party patents. NIST expects to execute the various agreements prior to publishing the standard. If the agreements are not executed by the end of 2022, NIST may consider selecting NTRU instead of KYBER. NTRU was proposed in 1996, and U.S. patents were dedicated to the public in 2007.