13 comments

[ 4.0 ms ] story [ 43.0 ms ] thread
I like the idea is this useful for anyone outside of google?
Seems like anyone trying to build something from basics with crypto?
Pretty much anyone who wants to play with applications for cryptography. Cryptocurrency stuff immediately comes to mind, but also things like identity management, code signing, communications, password/secret management, voting, and I'm sure there's more.

I think the better way to say it is that if you are just building apps, then you probably don't need this. But, as an example, I was just thinking about hacking together a workflow for writing/deploying signed Javascript, so a Javascript version of this library would have been perfect.

Another way to say it: If you can delegate to HTTPS, filesystem encryption, or another higher-level construct, you probably don't need this.

If you're on your own (custom wire protocol, custom file format, oddball use case), maybe you want something like this (or libsodium).

How does this compare to BouncyCastle?
This sounds more comparable to NaCl/Sodium to me. Tink:

> Tink provides secure APIs that are easy to use correctly and hard(er) to misuse. It reduces common crypto pitfalls with user-centered design, careful implementation and code reviews, and extensive testing.

NaCl:

> NaCl (pronounced "salt") is a new easy-to-use high-speed software library for network communication, encryption, decryption, signatures, etc. NaCl's goal is to provide all of the core operations needed to build higher-level cryptographic tools. Of course, other libraries already exist for these core operations. NaCl advances the state of the art by improving security, by improving usability, and by improving speed.

One big difference is first-class Java support. NaCl/Sodium is in C, which makes it a pain to use with Java.

BouncyCastle is a low-level crypto library that aims to export to callers every primitive and every common (and many uncommon) ways of working with those primitives. Tink is a high-level crypto library that aims to expose only safe ways to use its primitives.
Python bindings "coming soon" -- from comment on issue 101 from July 2018.
Looks like their headers are all very C++, not the type of thing python can call into easily unless you want to mess with swig.

I'd use a python binding to libsodium instead of holding my breath for bindings to this code. But maybe I'm wrong and they're actively working on it.

When the easiest way to get started is to install Bazel, I'll re-calibrate the rest of the claims accordingly.