Tink addresses things libsodium doesn't really do.
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.
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.
> but also key serialization. libsodium kind of strands you when it comes to the question how to actually store keys.
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?
That post was from when v1.2.0 came out, they are getting close to 1.4.0 (on RC2 right now). Nothing too big has been added, but there have been improvements across the library for all the languages they support. You can peak at the releases pages for differences. https://github.com/google/tink/releases
Does anyone know how this compares to other libraries such as NaCl and libsodium? Neither the readme nor the slides seem to mention other projects in this space.
Native-language reimplementations for each high-level language platform instead of wrapping a C library, for a start. In some respects they have similar objectives but different targets and scope.
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 [1] 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 [2].
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.
The obvious question about Tink is how it compares to libsodium. It's great that so many people ask, because it suggests that libsodium has successfully lodged itself into our collective consciousness. Both of these projects are forces for good in the world: they replace error-prone low-level crypto libraries with high-level interfaces designed for use by generalist developers.
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.
I hoped this one wouldn't depend on WebCrypto (in Javascript), but seems like it is dependent :( No cryptography without https, still.
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.
The only reason you can think of is a weird conspiracy?
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.
If you don't trust the CAs, then getting a certificate from one of them so that https is enabled and crypto works is no worse than no encryption at all, is it?
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 know it's going to be more effort, but is anything physically stopping you from running whatever crypto you like as a wasm module? I'm sure one could do NaCl-over-wasm?
I agree it's not the same convenience as having an API built in though.
Not to be confused with Tinc, an open-source, self-routing, mesh networking protocol and software implementation used for compressed and encrypted virtual private networks.
Bouncy Castle has an "old style" API where there's lots of switches to twiddle and some combinations produce insecure ciphers. Tink, like libsodium (the two are competitors, though in a friendly way), has a smaller API which exposes basically Mac and AEAD, and no way to accidentally set ECB mode or something like that.
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.
[+] [-] beefhash|5 years ago|reply
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.
[+] [-] tialaramex|5 years ago|reply
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?
[+] [-] loeg|5 years ago|reply
[+] [-] billme|5 years ago|reply
https://news.ycombinator.com/item?id=17877616
[+] [-] cryptbe|5 years ago|reply
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:
https://github.com/google/tink/releases/tag/v1.3.0
https://github.com/google/tink/releases/tag/v1.4.0-rc1
[+] [-] kyrra|5 years ago|reply
[+] [-] ufo|5 years ago|reply
[+] [-] todotask|5 years ago|reply
https://news.ycombinator.com/item?id=17877616
[+] [-] loeg|5 years ago|reply
[+] [-] cryptbe|5 years ago|reply
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 [1] 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 [2].
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.
[1] https://00f.net/
[2] https://github.com/google/tink/blob/master/docs/SECURITY-USA...
[+] [-] red_admiral|5 years ago|reply
[+] [-] voctor|5 years ago|reply
[1] https://github.com/jedisct1/libhydrogen/blob/master/README.m...
[+] [-] tptacek|5 years ago|reply
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.
[+] [-] antpls|5 years ago|reply
[+] [-] todotask|5 years ago|reply
https://github.com/google/tink/issues/133
[+] [-] todotask|5 years ago|reply
https://medium.com/asecuritysite-when-bob-met-alice/go-and-d...
[+] [-] lucb1e|5 years ago|reply
[+] [-] folex|5 years ago|reply
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.
[+] [-] tialaramex|5 years ago|reply
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.
[+] [-] thanksforfish|5 years ago|reply
Does ed25519.sign not work on origins with self signed certs?
[+] [-] lucb1e|5 years ago|reply
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.
[+] [-] red_admiral|5 years ago|reply
I agree it's not the same convenience as having an API built in though.
[+] [-] ItalyPaleAle|5 years ago|reply
I’ve used a single Go module for AES key wrapping (RFC-5649) and I appreciated the native Go code
[+] [-] ilaksh|5 years ago|reply
[+] [-] jpp|5 years ago|reply
[+] [-] mfer|5 years ago|reply
When using a library pushes you to use their build toolchain, I start to wonder what their motive is.
[+] [-] cryptbe|5 years ago|reply
We have a test package for Linux with Python 3.7 or 3.8
pip3 install -i https://test.pypi.org/simple/ tink
[+] [-] j88439h84|5 years ago|reply
[+] [-] niklaslogren|5 years ago|reply
[+] [-] dsun179|5 years ago|reply
[+] [-] phoe-krk|5 years ago|reply
[+] [-] red_admiral|5 years ago|reply
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.