5 ms·

Introducing the Tink cryptographic software library

96 points by helper 8y ago

tptacek 8y ago
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.
- pvg 8y ago
  Another difference seems to be KMS support.
- loeg 8y ago
  Notably (and unlike NaCl/libsodium), Tink is not portable to plain C.
  - dietr1ch 8y ago
    I hope that stops being a cons someday.
jeffreyrogers 8y ago
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 8y ago
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 8y ago
  Different notions of authenticity! Their hybrid encryption still uses an AEAD for the bulk encryption.
  - CiPHPerCoder 8y ago
    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 8y ago
      I would think you'd generally want to do it the other way around and sign the ciphertext instead.
      - CiPHPerCoder 8y ago
        "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 8y ago
        Crypto is confusing.
        CiPHPerCoder 8y ago
        It is, indeed.
vosper 8y ago
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 8y ago
  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
- wasx 8y ago
  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.
tatersolid 8y ago
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 8y ago
  If you don't bend like a willow, you'll break like an oak.
  - tatersolid 8y ago
    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 8y ago
      Disjoint versions would be good. Has it ever been tried? Also - would it have prevented, say, heartbleed?
      - tatersolid 8y ago
        > 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.
__john 8y ago
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
JensRantil 8y ago
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... :-)

96 points by helper 8y ago

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.

pvg 8y ago
Another difference seems to be KMS support.
loeg 8y ago
Notably (and unlike NaCl/libsodium), Tink is not portable to plain C.
- dietr1ch 8y ago
  I hope that stops being a cons someday.

jeffreyrogers 8y ago

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 8y ago

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 8y ago
Different notions of authenticity! Their hybrid encryption still uses an AEAD for the bulk encryption.
- CiPHPerCoder 8y ago
  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 8y ago
    I would think you'd generally want to do it the other way around and sign the ciphertext instead.
    - CiPHPerCoder 8y ago
      "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 8y ago
        Crypto is confusing.
        CiPHPerCoder 8y ago
        It is, indeed.

vosper 8y ago

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 8y ago
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
wasx 8y ago
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.

tatersolid 8y ago

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 8y ago
If you don't bend like a willow, you'll break like an oak.
- tatersolid 8y ago
  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 8y ago
    Disjoint versions would be good. Has it ever been tried? Also - would it have prevented, say, heartbleed?
    - tatersolid 8y ago
      > 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.

__john 8y ago

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

JensRantil 8y ago

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