Native support for AWS Key Management System and its equivalent on other cloud platforms is a huge win; we should all be using more of these. But libsodium would have to start mandating a TLS library and an HTTP library and whatnot, interfering with people's existing setups; you can't really do that without C programmers getting angry at you.
It deals with not only key generation, but also key serialization. libsodium kind of strands you when it comes to the question how to actually store keys.
Deterministic nonces have also been something that libsodium appears to have rejected: https://github.com/jedisct1/libsodium/issues/392
If you're looking at it from a misuse-prevention perspective, Tink is probably a major step up that accounts for modern use cases. libsodium's kind of in a lower level niche and suffers from being held back by C and its notoriously anemic standard library.
Hmm. Is there really interesting work needed here? The keys are (should be treated as) an opaque blob and it'll probably generally be a mistake to do anything with them except load them back into (maybe a different language implementation of) Tink / libsodium.
If you're a cryptanalyst it can make sense to get a structure rather than a blob but I don't see a value in this for the intended users of Tink, and if it's just a blob -- who doesn't know how to serialize and de-serialize some bytes in their preferred language?
From a user's point of view, keys are still binary blob. Internally Tink serializes keys using protobuf, but in principle it supports arbitrary key formats via the KeysetReader/KeysetWriter interfaces. Admittedly, this aspect of our design is somewhat clumsy. We're working on a new design.
The key differences (pun intended) between Tink and other libraries are:
1/ Tink works with keysets instead of individual keys. This enables key rotation and crypto agility. This is very important at Google because there are systems that generate too much data to encrypt with a single key. We want to be able to rotate keys and still be able to decrypt old ciphertext.
Also most crypto schemes we're using today would be broken eventually. We want to make sure we can add new schemes and retire old ones over time without users having to change their code. For example, a lot of libraries have functions containing algorithm names, e.g., aes_gcm_encrypt. When GCM is no longer adequate, users of these libraries would have a hard time upgrading to alternatives.
Tink interfaces don't contain the algorithm name. We name our APIs after generic crypto primitives rather than famous cryptographers or algorithms. For example, we provide a generic AEAD interface for symmetric key encryption. With proper key management, users don't have to know anything about any particular algorithms and can easily rotate to new ones without changing a single line of code (rather than upgrading Tink).
2/ A key in Tink contains not only the raw key material, but also all necessary parameters. It is equivalent to the result of a handshake. Before any data encryption can take place, both sides have to reach an agreement not only on a raw key, but also how to use that key to encrypt data. Since a key in Tink contains all parameters, Tink does not require in-band ciphersuite negotiation. That is no ciphertext in Tink contains any other metadata aside from a key ID.
This design sounds so simple but I've seen people get this wrong all the time. For example, the root cause of many embarrassing vulnerabilities in JWT  is in-band ciphersuite negotiation. That is, a JWT contains an alg field that dictates how the receiver should process it. This alg field should rather be included as part of the key.
JWT is not the only standard making this mistake. Many crypto libraries only ask users for the raw key material. This means the parameters are either implicitly assumed or under specified. Aside from the aforementioned vulnerabilities, this can also lead to key confusion, cross-protocol key reuse and make it hard to rotate keys or change algorithms.
To the best of my knowledge, Tink is the only high-level library that gets this right.
If I was starting a new project today, I'd probably go a little bit out of my way to try to use Tink instead of libsodium.
Sure; I get that. There are C projects where that isn't acceptable, while libsodium is. It makes a lot of sense to use Tink if you're working in Go (which I know you're fond of) or Java or other high-level languages Tink supports. I tend to work with a lot of C (not C++) codebases, and I wouldn't choose or recommend C++ in a new project today.
We've added tons of new features since 2018, including support for two new languages Golang and Python.
The team has grown from 4 20% contributors to 5 full-time and countless contributors.
Please checkout the following release notes for a list of changes:
Is there a chance that a Dart port might be added in the foreseeable future? I totally understand that it's a ton of work to support another language and I really appreciate all the work that has already been put in, but I just have to ask since right now there is no high level cryptographic library for Dart mature enough that I would trust it for real use.
I'm not sure if NaCl itself is production ready, but I'm a great fan of libsodium. If I weren't working on Tink, I'd use libsodium for my personal projects. Did you know that Frank Denis  the creator of libsodium is not working full time on crypto or security? He's a professional photographer. I can't figure out how he manages to single-handedly maintain such a high-profile high-quality library as a side project. We have a team of full time cryptographers and engineers working on Tink, but we've struggled a lot.
We started Tink because all existing libraries that we had at Google didn't meet our requirements.
Business-wise, we need an open source library that can work on all major platforms that Google products run on including web, iOS, Android, Borg and GCP. There are many Google products that need crypto integration with external partners. While we can take care of the crypto implementation on our side, we found that many partners got it wrong. It'd be very nice if they can use the same library that we're using internally.
We learned very early that a single ciphersuite wouldn't work for everybody. Some would need short ciphertext. Some would need speed. Some would need FIPS certified. We want a library that can support a wide range of options. It should be easy to add new options and remove old ones.
Security-wise, we found that most libraries are either too high-level or too low.
The latter ask users for security-critical input such as nonces or randomness. In most crypto schemes, using a wrong kind of nonces can totally break an otherwise secure scheme. Based on our experience working with tens of thousands of engineers at Google, we found that most engineers can't tell why the IV must be non-repeated in some schemes but unpredictable in others. More importantly, we found that this level of control is not needed when using crypto to implement security/privacy features in most of our products. Tink aims to eliminate as many potential misuses as possible. For example, if the underlying encryption mode requires nonces and is insecure if nonces are reused, then Tink does not allow the passing of nonces by the user.
Why is too high-level also a bad idea? We found that many libraries provide a single API for different kinds of crypto primitive. For example, sign() is used for both MAC and digital signatures, and encrypt() for both AEAD and public key encryption. This reduces readability, making code review much harder because the crypto APIs can't provide accurate information on the security guarantees of the implementations.
Last but not least, Tink encourages the usage of key management system. Most libraries don't care where the keys come from, and as a result many users use hardcoded keys. Tink encourages developers to store keys encrypted or within a KMS. It provides security teams mechanisms to enforce this requirement. For example, at Google developers can't use Tink in production with keys stored outside our KMS, unless they got an explicit approval from us.
Further explanations of these design goals can be found in .
To wrap this up, IMHO libsodium and Tink are targeting different groups of audience. libsodium is great for personal projects, when you know what you're doing and can take care of yourself. Tink provides more bells and whistles which are useful when you want to do crypto in an enterprise setting.
I've reviewed projects that used Tink but never built one myself. So, grain of Nacl (haha i kill me). I've used libsodium in anger many times. Here's roughly my comparison:
* Both libsodium and Tink will do authenticated ("seal/unseal") cryptography using GCM (the deficient but de facto standard) or Chapoly (Bernstein's primitives). Tink will also do EAX, an AES AEAD that's less fragile in some ways than GCM, and, on the C++ platform, AES-GCM-SIV, which is both fast and misuse-resistant.
* Both libsodium and Tink will do streaming authenticated encryption (efficiently sealing and unsealing files and streams that are too large to buffer entirely in memory before transforming).
* Tink will do deterministic authenticated encryption with AES-SIV; Tink provides this feature for building things like encrypted search features but I think it's more commonly used as a safety feature for scenarios where nonce reuse is likely and revealing duplicate messages is not a major threat.
* Both libsodium and Tink will do ED25519 signatures. Tink will also do P-curve signatures and RSA.
* Both libsodium and Tink will do hybrid encryption (what libsodium would call "box"). libsodium uses Curve25519 and Chapoly; Tink uses P-curves and either GCM or CTR+HMAC (both of them AEAD modes).
* Tink has direct support for a bunch of platforms, notably including Java; unlike Tink, libsodium is, and thus has direct support for, C projects, and is provided for other languages through its C bindings. Tink has first-class C++ support (and its Python support is bindings to its C++ version), but not C.
* libsodium has much better documentation and a much bigger community. Tink is a Google project (it's the evolution of Keyczar, Google's first high-level cryptography library). On the other hand, Daniel Bleichenbacher is on the Tink team. I don't love P-curve crypto, but I'll use an implementation Bleichenbacher put his name on.
* Tink has better key management features and direct support for GCP and AWS KMS. It's not hard to build that feature for libsodium, but it's there already in Tink. Tink may get support for Android Strongbox (it already has support for the Android key storage API); it's probably a really strong choice for Android applications already.
They're both valid choices. If I was making a recommendation to a stranger without much context, I'd almost always recommend libsodium, unless you're doing Android. If it was me, on a new project, I might lean towards Tink at this point.
Happy to be corrected if I got any of this wrong.
I just don't get it: why can't I use `ed25519.sign` without being on secure origin.
The only reason I can think of is: don't allow people to create p2p networks without CA control and approval. I'm talking about this https://github.com/w3c/webcrypto/issues/28 . Because of that requirement, you can't use WebCrypto primitives on http sites.
So I can't implement my own security on network channel (in web app) without first getting approval from Big Guys, who can revoke it at their will.
WebCrypto only arguably skirts Mozilla's original (2015) definition of new features that shouldn't be enabled for insecure contexts.
(Mozilla says you might want to allow new features that could anyway be polyfilled, and though a polyfilled WebCrypto would be slow and under powered it could be built)
You can't bootstrap your "security on network channel (in web app)" without a secure origin because it's a house built on sand.
Some of the things people want to do in that issue are merely daft (e.g. people who are sad that they can't access a crypto-hash for their problem which would be much better suited to a fast non-crypto hash) but a bunch of them, like yours, involve hand-waving the real problem and then insisting you need "security" on a fundamentally insecure basis. If you actually trust that network then you don't need "security on network channel" and if (as is much more likely) you don't or shouldn't trust it then the exercise is hopeless because that network can trivially betray every element of your hoped-for WebCrypto feature set if you don't have a secure origin.
This wasn't hard – caddy2 makes it super easy. But I see it as a pretty weird requirement. I don't understand, why can't I sign some data with public key without being on secure origin.
> The only reason you can think of is a weird conspiracy?
I didn't mean to assume conspiracy theories, I agree that this is a pretty unprobable story. I'm just saying: "It's so weird that my only sound explanation is a weird conspiracy theory", meaning that I don't understand how this came to be, and motivation behind that :)
I'm guessing you mean sign with a private key.
In a secure context the Browser gets to promise the context that this private key stays private if it wants. For example, should the the private key be posted to Twitter?
In a secure context you get to decide, because only code your wrote runs in that context, if you don't add "post private key to Twitter" code then it doesn't happen.
But in insecure contexts any on-path attacker can substitute their own code for yours. Now your "private" key is in a Twitter post, hilarious.
Does ed25519.sign not work on origins with self signed certs?
I understand it might give people a false sense of security, or perhaps they trust the CA system and it's not false in their eyes, but if distrust of CAs is the reason to use plaintext connections instead, I'm not sure that's the best choice.
I agree it's not the same convenience as having an API built in though.
There's also an option to compile some e.g. Rust library to wasm, and use it, but it could hide some exotic security vulnerabilities that arise only in this narrowly-adopted use case, so it's a pretty high risk.
I’ve used a single Go module for AES key wrapping (RFC-5649) and I appreciated the native Go code
When using a library pushes you to use their build toolchain, I start to wonder what their motive is.
The biggest complicating factor here is that Tink, like many Google software projects, internally uses Protocol Buffers to serialize data (primarily keys) in a way that's compatible across all the different languages that it supports. Protocol Buffers work really nicely with Bazel and significantly less nicely with most other build systems. Again, though, Bazel won't be required in order to depend on the package, only to build it from source.
We have a test package for Linux with Python 3.7 or 3.8
pip3 install -i https://test.pypi.org/simple/ tink
The big difference between Tink and sodium is that the latter uses Bernstein's primitives (chaca, salsa, 25519) whereas Tink, from the slides, goes with AES-GCM.
> The big difference between Tink and sodium is that the latter uses Bernstein's primitives (chaca, salsa, 25519) whereas Tink, from the slides, goes with AES-GCM.
Tink has Bernstein's primitives as well.