
Introducing the Tink cryptographic software library - helper
https://security.googleblog.com/2018/08/introducing-tink-cryptographic-software.html
======
tptacek
Tink competes with Nacl/libsodium.

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.

Some ways in which Tink differs from Nacl:

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

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

* Tink is natively (rather than through bindings) portable to Java, C++, and ObjC.

* Tink has a team of cryptographers maintaining it; that team includes Daniel Bleichenbacher, which is crazy and awesome.

Nacl is great, but more people should look at Tink.

~~~
loeg
Notably (and unlike NaCl/libsodium), Tink is _not_ portable to plain C.

~~~
dietr1ch
I hope that stops being a cons someday.

------
JensRantil
Ouch, my employer is named Tink
([https://business.tink.se](https://business.tink.se)). We're a
Swedish/European based fintech company offering data-driven banking APIs. This
is bad for our SEO... :-)

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

And, yes, I am aware of the common issues with doing crypto in the browser
with JS libraries. And I'm aware of SubtleCrypto.

~~~
josephg
If you want to make a JS version, WebAssembly might be a great way to package
the code up. WASM is fully supported in nodejs now, and its available in all
modern browsers[1]. You'd need to write bindings for the C++ API methods, but
once you do that you could throw the result up on npm and it should work in
both node and web projects, with no compilation step.

To your library's users the end result will be indistinguishable from a native
JS library.

 _Edit:_ I just had a play to see how feasible this would be. Even a stripped,
optimized build of tink compiles into a 2.5MB binary. This would be fine from
nodejs, but its way too big for a web library. It would need to be heavily cut
down to be useful in a browser. It might be easier to simply wrap the modern
browser crypto API.

[1] [https://caniuse.com/#feat=wasm](https://caniuse.com/#feat=wasm)

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

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

~~~
tptacek
Different notions of authenticity! Their hybrid encryption still uses an AEAD
for the bulk encryption.

~~~
CiPHPerCoder
Also, this limitation is easily worked around.

1\. Use a digital signature.

2\. Encrypt your signed message using Hybrid Encryption.

After your recipient decrypts your message (which, as Thomas notes, has AEAD),
they can then verify your signature.

~~~
zokier
I would think you'd generally want to do it the other way around and sign the
ciphertext instead.

~~~
CiPHPerCoder
"Just sign this opaque blob"?

Digital signatures aren't in the scope of the cryptographic doom principle.
Generally, if you're signing a document, you want it to be really clear that
you signed what it says.

~~~
zokier
Crypto is confusing.

~~~
CiPHPerCoder
It is, indeed.

------
__john
For those who didn't know what AEAD is, it stands for Authenticated Encryption
with Associated Data.

[https://en.wikipedia.org/wiki/Authenticated_encryption](https://en.wikipedia.org/wiki/Authenticated_encryption)

------
tatersolid
So... another crypto library with way too many choices for the average
developer.

How about standardizing (RFC I guess) a single primitive of each type, and a
strongly versioned set of serialization formats (including key storage).

That’s something a developer can’t misuse. Standardizing serialization formats
and parsers are critical for developers to use this stuff correctly.

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.

Google could do this... but instead we get Tink, a “choose your own adventure”
just like the monthly alphabet soup produced by the IETF.

If GOOG/MSFT/Mozilla/etc can build and standardize AV1 together they could do
the same for crypto. It’s way easier.

~~~
emmelaich
If you don't bend like a willow, you'll break like an oak.

~~~
tatersolid
No, you simply version the format if required, picking a new (disjoint)
primitive set. Algorithm agility has _caused_ many of the security defects in
TLS, PGP, and SSH. It has remedied exactly zero flaws that a simpler versioned
scheme would not also have addressed.

~~~
emmelaich
Disjoint versions would be good. Has it ever been tried?

Also - would it have prevented, say, heartbleed?

~~~
tatersolid
> Disjoint versions would be good. Has it ever been tried?

I believe Signal does this based on the papers I’ve read; I’m sure many
private or lesser-known protocols do as well.

>would it have prevented, say, heart bleed?

Probably, because in a strictly versioned scheme with no options, the buggy
DTLS keepalive mechanism _would not even have been in the same library_.
OpenSSL’s position of “we’ve got nine of everything including the kitchen
sink” was the true cause of Heartbleed. Simpler code is easier to get right,
debug, and perhaps formally verify as correct.

