Tink competes with Nacl/libsodium.<p>Tink is really great and more people should look at it. It's (I think?) the successor to Keyczar, which was one of the first misuse-resistant crypto libraries.<p>Some ways in which Tink differs from Nacl:<p>* Its interfaces are in some ways better; for instance, it doesn't punt nonces to the developer (a source of security issues with Nacl software).<p>* It has a coherent design based on security objectives, so that extensions to it make sense. For instance, instead of exposing random block cipher modes in a low-level interface, Tink maintains a notion of AEAD, streaming AEAD, and deterministic AEAD, and then has interfaces to add primitives that fulfill those objectives.<p>* Tink is natively (rather than through bindings) portable to Java, C++, and ObjC.<p>* Tink has a team of cryptographers maintaining it; that team includes Daniel Bleichenbacher, which is crazy and awesome.<p>Nacl is great, but more people should look at Tink.
Ouch, my employer is named Tink (<a href="https://business.tink.se" rel="nofollow">https://business.tink.se</a>). We're a Swedish/European based fintech company offering data-driven banking APIs. This is bad for our SEO... :-)
Could/should this be cross-compiled to JS? I've been looking for something recently that lets me encrypt from a command-line tool and decrypt in the browser, preferably in a way that's not too likely I'll f- it up as a non-crypto-expert.<p>And, yes, I am aware of the common issues with doing crypto in the browser with JS libraries. And I'm aware of SubtleCrypto.
This looks interesting. I like that it doesn't expose nonces when reuse is a vulnerability. That seems like a smart idea. Unfortunately, the C++ implementation doesn't appear to support Windows yet. I'd be interested in using this for a cross-platform app I've been working on but that rules it out.
As a non-crypto guy, I find it bit curious that "Hybrid encryption" primitive does not offer authentication. With the talk of being misuse resistant, that seems like bit of a sharp edge still.
For those who didn't know what AEAD is, it stands for Authenticated Encryption with Associated Data.<p><a href="https://en.wikipedia.org/wiki/Authenticated_encryption" rel="nofollow">https://en.wikipedia.org/wiki/Authenticated_encryption</a>
So... another crypto library with way too many choices for the average developer.<p>How about standardizing (RFC I guess) a single primitive of each type, and a strongly versioned set of serialization formats (including key storage).<p>That’s something a developer can’t misuse. Standardizing serialization formats and parsers are critical for developers to use this stuff correctly.<p>We can’t get rid of PKCS, X.509, and PGP and all their “algorithm agility” nonsense and insecurity until _somebody_ with industry clout replaces them with something secure and much simpler.<p>Google could do this... but instead we get Tink, a “choose your own adventure” just like the monthly alphabet soup produced by the IETF.<p>If GOOG/MSFT/Mozilla/etc can build and standardize AV1 together they could do the same for crypto. It’s way easier.