8 ms·

Tink – Cryptographic APIs that are secure, easy to use correctly

153 points by todotask 6y ago

ufo 6y ago
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.
- todotask 6y ago
  I think the first comment from 2018 might still answer your question. https://news.ycombinator.com/item?id=17877616 https://news.ycombinator.com/item?id=17877616
- red_admiral 6y ago
  NaCl/sodium uses Bernstein-crypto by default, Tink uses NIST (e.g. AES-GCM)?
  - tptacek 6y ago
    Tink does EAX, SIV, and Chapoly as well as GCM.
- loeg 6y ago
  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.
- cryptbe 6y ago
  Disclaimer: I'm one of the maintainers of Tink. 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/ https://00f.net/ [2] https://github.com/google/tink/blob/master/docs/SECURITY-USABILITY.md https://github.com/google/tink/blob/master/docs/SECURITY-USA...
folex 6y ago
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 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.
- thanksforfish 6y ago
  How do you implement your own security on a network channel if the first network request is over http and subject to man in the middle attack? Does ed25519.sign not work on origins with self signed certs?
- lucb1e 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - VWWHFSfQ 6y ago
    I think the issue is that your use of the crypto functions is dependent on permission from a CA. Depending on the nature of the application you're serving over HTTPS, a CA could be compelled under DMCA to revoke your certificate, and thus your permission to use the crypto APIs.
    - lucb1e 6y ago
antpls 6y ago
Previous discussion (2018) : https://news.ycombinator.com/item?id=17877616 https://news.ycombinator.com/item?id=17877616
todotask 6y ago
The following article: https://medium.com/asecuritysite-when-bob-met-alice/go-and-do-crypto-1edd8da909ec https://medium.com/asecuritysite-when-bob-met-alice/go-and-d...
- lucb1e 6y ago
  Hmm it seems you haven't finished your sentence? "The following article..." what about it?
billme 6y ago
Unless there’s significant clearly defined differences - in my opinion (2018) should be added to the title. https://news.ycombinator.com/item?id=17877616 https://news.ycombinator.com/item?id=17877616
- kyrra 6y ago
  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 https://github.com/google/tink/releases
  - psanford 6y ago
    I know they've added a Go port since that release.
- cryptbe 6y ago
  Disclaimer: I'm a maintainer of Tink. 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.3.0 https://github.com/google/tink/releases/tag/v1.4.0-rc1 https://github.com/google/tink/releases/tag/v1.4.0-rc1
  - skoodge 6y ago
    First of all, thank you for your work on Tink! 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. (Tink seems perfect for usage in mobile and web apps that Dart & Flutter target, and given that Dart is the only language heavily used by Google without Tink support it would make a great addition. If no native Dart implementation is planned, maybe a wrapper could be considered, using the Java/C++ bindings on mobile/native and the upcoming Javascript bindings for Dart/Flutter web support?)
phoe-krk 6y ago
How does this compare to libsodium or Bouncy Castle?
- red_admiral 6y ago
  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.
  - tptacek 6y ago
    Tink does EAX on most platforms, and Chapoly and I think SIV (deterministic, misuse-resistant) on all of them.
  - loeg 6y ago
    This comment was great up until: > 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.
ilaksh 6y ago
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.
jpp 6y ago
Would anyone happen to know why Tink isn’t listed in PyPi.org?
- mfer 6y ago
  I don’t see it on npm either. Their docs recommend people use bazel. When using a library pushes you to use their build toolchain, I start to wonder what their motive is.
  - taymonbeal 6y ago
    Hi, I'm currently working on Tink for JavaScript. (Formerly as part of a rotation on Google's cryptography team; that rotation has ended so I'm now doing this on weekends.) Tink for JavaScript is being used in production systems internally at Google, but the open source release isn't fully baked yet. npm compatibility is a big part of that; our internal codebase doesn't use npm, but we absolutely want open source users to be able to install and use Tink from npm without installing Bazel (though Bazel will most likely continue to be required in order to contribute to Tink). This is why JavaScript is not currently listed among the production-ready languages. Right now I'm fixing it by migrating the codebase to TypeScript so that it can use the TypeScript Bazel rules, which facilitate compatibility with npm. 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.
- j88439h84 6y ago
  They're working on it
- cryptbe 6y ago
  It's coming and will be part of 1.4.0: https://github.com/google/tink/issues/358 https://github.com/google/tink/issues/358. We have a test package for Linux with Python 3.7 or 3.8 pip3 install -i https://test.pypi.org/simple/ https://test.pypi.org/simple/ tink
niklaslogren 6y ago
Not to be confused with Tink, an open-banking fintech from Stockholm. https://tink.com/ https://tink.com/
- dsun179 6y ago
  Or tink.de a smart home store. I do not think there are any 4 letter words that do not clash with a company.
ItalyPaleAle 6y ago
It’s a neat library but features across languages aren’t exactly the same. Also, documentation could be improved. I’ve used a single Go module for AES key wrapping (RFC-5649) and I appreciated the native Go code
beefhash 6y ago
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. Deterministic nonces have also been something that libsodium appears to have rejected: https://github.com/jedisct1/libsodium/issues/392 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.
- loeg 6y ago
  And libsodium does things Tink doesn't do: provide a C API.
  - tptacek 6y ago
    It doesn't, but it provides a first-class C++ API. 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.
    - beefhash 6y ago
      Can't really argue with the makers of proprietary microcontrollers about what tooling they provide though.
    - loeg 6y ago
      > It doesn't, but it provides a first-class C++ API. 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.
tptacek 6y ago
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. Happy to be corrected if I got any of this wrong.
voctor 6y ago
There is also libhydrogen [1] which is a "small, easy-to-use, hard-to-misuse cryptographic library". [1] https://github.com/jedisct1/libhydrogen/blob/master/README.md https://github.com/jedisct1/libhydrogen/blob/master/README.m...
todotask 6y ago
There is an open issue for adding Tink information into Wikipedia, if anyone who is knowledgable to take this task will be appreciated. https://github.com/google/tink/issues/133 https://github.com/google/tink/issues/133

153 points by todotask 6y ago

ufo 6y ago

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.

todotask 6y ago
I think the first comment from 2018 might still answer your question. https://news.ycombinator.com/item?id=17877616 https://news.ycombinator.com/item?id=17877616
red_admiral 6y ago
NaCl/sodium uses Bernstein-crypto by default, Tink uses NIST (e.g. AES-GCM)?
- tptacek 6y ago
  Tink does EAX, SIV, and Chapoly as well as GCM.
loeg 6y ago
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.
cryptbe 6y ago
Disclaimer: I'm one of the maintainers of Tink. 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/ https://00f.net/ [2] https://github.com/google/tink/blob/master/docs/SECURITY-USABILITY.md https://github.com/google/tink/blob/master/docs/SECURITY-USA...

folex 6y ago

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 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.

thanksforfish 6y ago
How do you implement your own security on a network channel if the first network request is over http and subject to man in the middle attack? Does ed25519.sign not work on origins with self signed certs?
lucb1e 6y ago
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.
- deleted 6y ago
  [deleted]
- VWWHFSfQ 6y ago
  I think the issue is that your use of the crypto functions is dependent on permission from a CA. Depending on the nature of the application you're serving over HTTPS, a CA could be compelled under DMCA to revoke your certificate, and thus your permission to use the crypto APIs.
  - lucb1e 6y ago

antpls 6y ago

Previous discussion (2018) : https://news.ycombinator.com/item?id=17877616 https://news.ycombinator.com/item?id=17877616

todotask 6y ago

The following article: https://medium.com/asecuritysite-when-bob-met-alice/go-and-do-crypto-1edd8da909ec https://medium.com/asecuritysite-when-bob-met-alice/go-and-d...

lucb1e 6y ago
Hmm it seems you haven't finished your sentence? "The following article..." what about it?

billme 6y ago

Unless there’s significant clearly defined differences - in my opinion (2018) should be added to the title. https://news.ycombinator.com/item?id=17877616 https://news.ycombinator.com/item?id=17877616

kyrra 6y ago
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 https://github.com/google/tink/releases
- psanford 6y ago
  I know they've added a Go port since that release.
cryptbe 6y ago
Disclaimer: I'm a maintainer of Tink. 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.3.0 https://github.com/google/tink/releases/tag/v1.4.0-rc1 https://github.com/google/tink/releases/tag/v1.4.0-rc1
- skoodge 6y ago
  First of all, thank you for your work on Tink! 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. (Tink seems perfect for usage in mobile and web apps that Dart & Flutter target, and given that Dart is the only language heavily used by Google without Tink support it would make a great addition. If no native Dart implementation is planned, maybe a wrapper could be considered, using the Java/C++ bindings on mobile/native and the upcoming Javascript bindings for Dart/Flutter web support?)

phoe-krk 6y ago

How does this compare to libsodium or Bouncy Castle?

red_admiral 6y ago
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.
- tptacek 6y ago
  Tink does EAX on most platforms, and Chapoly and I think SIV (deterministic, misuse-resistant) on all of them.
- loeg 6y ago
  This comment was great up until: > 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.

ilaksh 6y ago

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.

jpp 6y ago

Would anyone happen to know why Tink isn’t listed in PyPi.org?

mfer 6y ago
I don’t see it on npm either. Their docs recommend people use bazel. When using a library pushes you to use their build toolchain, I start to wonder what their motive is.
- taymonbeal 6y ago
  Hi, I'm currently working on Tink for JavaScript. (Formerly as part of a rotation on Google's cryptography team; that rotation has ended so I'm now doing this on weekends.) Tink for JavaScript is being used in production systems internally at Google, but the open source release isn't fully baked yet. npm compatibility is a big part of that; our internal codebase doesn't use npm, but we absolutely want open source users to be able to install and use Tink from npm without installing Bazel (though Bazel will most likely continue to be required in order to contribute to Tink). This is why JavaScript is not currently listed among the production-ready languages. Right now I'm fixing it by migrating the codebase to TypeScript so that it can use the TypeScript Bazel rules, which facilitate compatibility with npm. 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.
j88439h84 6y ago
They're working on it
cryptbe 6y ago
It's coming and will be part of 1.4.0: https://github.com/google/tink/issues/358 https://github.com/google/tink/issues/358. We have a test package for Linux with Python 3.7 or 3.8 pip3 install -i https://test.pypi.org/simple/ https://test.pypi.org/simple/ tink

niklaslogren 6y ago

Not to be confused with Tink, an open-banking fintech from Stockholm. https://tink.com/ https://tink.com/

dsun179 6y ago
Or tink.de a smart home store. I do not think there are any 4 letter words that do not clash with a company.

ItalyPaleAle 6y ago

It’s a neat library but features across languages aren’t exactly the same. Also, documentation could be improved. I’ve used a single Go module for AES key wrapping (RFC-5649) and I appreciated the native Go code

beefhash 6y ago

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. Deterministic nonces have also been something that libsodium appears to have rejected: https://github.com/jedisct1/libsodium/issues/392 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.

loeg 6y ago
And libsodium does things Tink doesn't do: provide a C API.
- tptacek 6y ago
  It doesn't, but it provides a first-class C++ API. 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.
  - beefhash 6y ago
    Can't really argue with the makers of proprietary microcontrollers about what tooling they provide though.
  - loeg 6y ago
    > It doesn't, but it provides a first-class C++ API. 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.

tptacek 6y ago

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. Happy to be corrected if I got any of this wrong.

voctor 6y ago

There is also libhydrogen [1] which is a "small, easy-to-use, hard-to-misuse cryptographic library". [1] https://github.com/jedisct1/libhydrogen/blob/master/README.md https://github.com/jedisct1/libhydrogen/blob/master/README.m...

todotask 6y ago

There is an open issue for adding Tink information into Wikipedia, if anyone who is knowledgable to take this task will be appreciated. https://github.com/google/tink/issues/133 https://github.com/google/tink/issues/133