4 ms·

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

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.
wcarss 8y ago
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.
tptacek 8y ago
What choices is Tink asking you to make that you feel are unreasonable for "the average developer"?
- tatersolid 8y ago
  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.

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.

wcarss 8y ago

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.

tptacek 8y ago

What choices is Tink asking you to make that you feel are unreasonable for "the average developer"?

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