Introducing the Tink cryptographic software library(security.googleblog.com)
security.googleblog.com
Introducing the Tink cryptographic software library
https://security.googleblog.com/2018/08/introducing-tink-cryptographic-software.html
28 comments
Ouch, my employer is named Tink (https://business.tink.se). 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.
And, yes, I am aware of the common issues with doing crypto in the browser with JS libraries. And I'm aware of SubtleCrypto.
And, yes, I am aware of the common issues with doing crypto in the browser with JS libraries. And I'm aware of SubtleCrypto.
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
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
The tool doesn't matter so much, if something is encrypted with, say, AES and a specific mode of operation with one tool, it can be decrypted with a separate tool given the same key and mode. Assuming the implementations of the encryption and decryption are done properly.
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.
Different notions of authenticity! Their hybrid encryption still uses an AEAD for the bulk encryption.
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.
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.
I would think you'd generally want to do it the other way around and sign the ciphertext instead.
"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.
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.
Then I'm even more confused. What are the different authenticities here, what guarantees do I get and not get?
Tink's provided Hybrid primitive allows Alice to send messages to Bob if Alice knows Bob's public key.
No third party can understand Alice's messages even if they intercept them, and if a third party tampers with the message Bob doesn't get that message at all, just an error. So in this sense the messages are promised to be authentic.
However, Bob is not provided with assurance that the messages really came from Alice - there's no authentication, and so Bob should treat all the messages as anonymous. If Alice wants to authenticate as Alice to Bob, the two will need to agree some mechanism they can layer on top of Tink's hybrid primitive.
This is not dissimilar to how HTTPS is used from web browsers. When you visit Hacker News your browser is able to completely ensure that it's really talking to Hacker News using cryptography, but when it comes to reassuring Hacker News that you're really "zokier" you end up using a simple username + password login form.
No third party can understand Alice's messages even if they intercept them, and if a third party tampers with the message Bob doesn't get that message at all, just an error. So in this sense the messages are promised to be authentic.
However, Bob is not provided with assurance that the messages really came from Alice - there's no authentication, and so Bob should treat all the messages as anonymous. If Alice wants to authenticate as Alice to Bob, the two will need to agree some mechanism they can layer on top of Tink's hybrid primitive.
This is not dissimilar to how HTTPS is used from web browsers. When you visit Hacker News your browser is able to completely ensure that it's really talking to Hacker News using cryptography, but when it comes to reassuring Hacker News that you're really "zokier" you end up using a simple username + password login form.
Sounds like what we are getting could be better described as integrity rather than authenticity. Makes kinda sense
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
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.
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.
If you don't bend like a willow, you'll break like an oak.
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.
Disjoint versions would be good. Has it ever been tried?
Also - would it have prevented, say, heartbleed?
Also - would it have prevented, say, heartbleed?
> 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.
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.
What choices is Tink asking you to make that you feel are unreasonable for "the average developer"?
1) Which primitives to use (there are intentionally multiple AEAD in Tink for example)
2) How to encode/signal those primitives to the other endpoint or decrypting program.
3) How to manage keys
4) How to signal which keys should be used to the other endpoint/decryptor
5) how to serialize messages for the network or filesystem, and how to parse them without making catostrophic mistakes.
Yes, I know most of those are “not in Tink’s scope”. They are also unaddressed by libsodium. But it’s what the “average” application developer needs to use crypto securely.
2) How to encode/signal those primitives to the other endpoint or decrypting program.
3) How to manage keys
4) How to signal which keys should be used to the other endpoint/decryptor
5) how to serialize messages for the network or filesystem, and how to parse them without making catostrophic mistakes.
Yes, I know most of those are “not in Tink’s scope”. They are also unaddressed by libsodium. But it’s what the “average” application developer needs to use crypto securely.
There's a difference in the objective here that may reward us for avoiding a monoculture. One way to do all crypto means one way to defeat it.
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.