
Tink – Cryptographic APIs that are secure, easy to use correctly - todotask
https://github.com/google/tink
======
beefhash
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
And libsodium does things Tink doesn't do: provide a C API.

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

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

------
billme
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)

~~~
cryptbe
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
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?)

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

~~~
red_admiral
NaCl/sodium uses Bernstein-crypto by default, Tink uses NIST (e.g. AES-GCM)?

~~~
tptacek
Tink does EAX, SIV, and Chapoly as well as GCM.

------
voctor
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.m...](https://github.com/jedisct1/libhydrogen/blob/master/README.md)

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

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

------
todotask
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)

------
todotask
The following article:

[https://medium.com/asecuritysite-when-bob-met-alice/go-
and-d...](https://medium.com/asecuritysite-when-bob-met-alice/go-and-do-
crypto-1edd8da909ec)

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

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

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

~~~
VWWHFSfQ
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
I suppose that's a valid point, even if it seems far-fetched that this would
be the most effective way of killing someone's software.

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

------
ilaksh
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
Would anyone happen to know why Tink isn’t listed in PyPi.org?

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

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

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

------
phoe-krk
How does this compare to libsodium or Bouncy Castle?

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

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

