Introducing the Tink cryptographic software library
security.googleblog.com
security.googleblog.com
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.
And, yes, I am aware of the common issues with doing crypto in the browser with JS libraries. And I'm aware of SubtleCrypto.
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. 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.
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.
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.
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.
Also - would it have prevented, say, heartbleed?
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.
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.