From a user's point of view, keys are still binary blob. Internally Tink serializes keys using protobuf, but in principle it supports arbitrary key formats via the KeysetReader/KeysetWriter interfaces. Admittedly, this aspect of our design is somewhat clumsy. We're working on a new design.
The key differences (pun intended) between Tink and other libraries are:
1/ Tink works with keysets instead of individual keys. This enables key rotation and crypto agility. This is very important at Google because there are systems that generate too much data to encrypt with a single key. We want to be able to rotate keys and still be able to decrypt old ciphertext.
Also most crypto schemes we're using today would be broken eventually. We want to make sure we can add new schemes and retire old ones over time without users having to change their code. For example, a lot of libraries have functions containing algorithm names, e.g., aes_gcm_encrypt. When GCM is no longer adequate, users of these libraries would have a hard time upgrading to alternatives.
Tink interfaces don't contain the algorithm name. We name our APIs after generic crypto primitives rather than famous cryptographers or algorithms. For example, we provide a generic AEAD interface for symmetric key encryption. With proper key management, users don't have to know anything about any particular algorithms and can easily rotate to new ones without changing a single line of code (rather than upgrading Tink).
2/ A key in Tink contains not only the raw key material, but also all necessary parameters. It is equivalent to the result of a handshake. Before any data encryption can take place, both sides have to reach an agreement not only on a raw key, but also how to use that key to encrypt data. Since a key in Tink contains all parameters, Tink does not require in-band ciphersuite negotiation. That is no ciphertext in Tink contains any other metadata aside from a key ID.
This design sounds so simple but I've seen people get this wrong all the time. For example, the root cause of many embarrassing vulnerabilities in JWT [1] is in-band ciphersuite negotiation. That is, a JWT contains an alg field that dictates how the receiver should process it. This alg field should rather be included as part of the key.
JWT is not the only standard making this mistake. Many crypto libraries only ask users for the raw key material. This means the parameters are either implicitly assumed or under specified. Aside from the aforementioned vulnerabilities, this can also lead to key confusion, cross-protocol key reuse and make it hard to rotate keys or change algorithms.
To the best of my knowledge, Tink is the only high-level library that gets this right.
I'm not sure if NaCl itself is production ready, but I'm a great fan of libsodium. If I weren't working on Tink, I'd use libsodium for my personal projects. Did you know that Frank Denis [1] the creator of libsodium is not working full time on crypto or security? He's a professional photographer. I can't figure out how he manages to single-handedly maintain such a high-profile high-quality library as a side project. We have a team of full time cryptographers and engineers working on Tink, but we've struggled a lot.
We started Tink because all existing libraries that we had at Google didn't meet our requirements.
Business-wise, we need an open source library that can work on all major platforms that Google products run on including web, iOS, Android, Borg and GCP. There are many Google products that need crypto integration with external partners. While we can take care of the crypto implementation on our side, we found that many partners got it wrong. It'd be very nice if they can use the same library that we're using internally.
We learned very early that a single ciphersuite wouldn't work for everybody. Some would need short ciphertext. Some would need speed. Some would need FIPS certified. We want a library that can support a wide range of options. It should be easy to add new options and remove old ones.
Security-wise, we found that most libraries are either too high-level or too low.
The latter ask users for security-critical input such as nonces or randomness. In most crypto schemes, using a wrong kind of nonces can totally break an otherwise secure scheme. Based on our experience working with tens of thousands of engineers at Google, we found that most engineers can't tell why the IV must be non-repeated in some schemes but unpredictable in others. More importantly, we found that this level of control is not needed when using crypto to implement security/privacy features in most of our products. Tink aims to eliminate as many potential misuses as possible. For example, if the underlying encryption mode requires nonces and is insecure if nonces are reused, then Tink does not allow the passing of nonces by the user.
Why is too high-level also a bad idea? We found that many libraries provide a single API for different kinds of crypto primitive. For example, sign() is used for both MAC and digital signatures, and encrypt() for both AEAD and public key encryption. This reduces readability, making code review much harder because the crypto APIs can't provide accurate information on the security guarantees of the implementations.
Last but not least, Tink encourages the usage of key management system. Most libraries don't care where the keys come from, and as a result many users use hardcoded keys. Tink encourages developers to store keys encrypted or within a KMS. It provides security teams mechanisms to enforce this requirement. For example, at Google developers can't use Tink in production with keys stored outside our KMS, unless they got an explicit approval from us.
Further explanations of these design goals can be found in [2].
To wrap this up, IMHO libsodium and Tink are targeting different groups of audience. libsodium is great for personal projects, when you know what you're doing and can take care of yourself. Tink provides more bells and whistles which are useful when you want to do crypto in an enterprise setting.
Is there a chance that a Dart port might be added in the foreseeable future? I totally understand that it's a ton of work to support another language and I really appreciate all the work that has already been put in, but I just have to ask since right now there is no high level cryptographic library for Dart mature enough that I would trust it for real use.
(Tink seems perfect for usage in mobile and web apps that Dart & Flutter target, and given that Dart is the only language heavily used by Google without Tink support it would make a great addition. If no native Dart implementation is planned, maybe a wrapper could be considered, using the Java/C++ bindings on mobile/native and the upcoming Javascript bindings for Dart/Flutter web support?)
Author here. One interesting aspect that I've learned is the tactics, techniques, and procedures (TTPs) of public opinion brigades, aka Force 47.
They tried hard to discrete me. My initial report had an error, that is I didn't know that Bluetooth on Android needs ACCESS_FINE_LOCATION permission. A person pointed this out in a comment -- he posted and rewrote it three times. I said thank you and thought that's that, but then he and a bunch of new people commented that since I made that basic mistake I'm immature and inexperienced, therefore the rest of my findings have no merit.
Someone then posted a super long comment, raising a lot of questions about my credibility and intention. The interesting thing is they claimed that they're a student, haven't installed the app, have no intention to do so, but care a lot about privacy. Essentially they want to show that they're merely an underdog bystander standing up against my wrongdoings. I thought this is a very subtle psychological trick, aiming to amplify their attacks.
Other attacks are more direct. For example, a person pointed out that since I don't have many followers on Twitter, I'm not a good engineer. They said I didn't really contribute anything to my public research, but I just took credit from my coauthors. That I am only cleaning toilet at Google, there's nothing proud about that.
After I posted a rebuttal to the developers' rebuttal, a guy [2] dropped this one-line comment:
>cái vụ này bắt đầu thấy nhảm rồi. Lập luận của anh Thái cũng không còn chặt chẽ như trước nữa.
Which translates to "This is getting nonsense. Thai's argument is not as strict as before".
The title of the guy's blog [3] is, I kid you not, "There's always only one truth: Communist Party of Vietnam.
If I remember rightly, requiring ACCESS_FINE_LOCATION for certain uses of Bluetooth on Android is a relatively new thing and the two used to be completely independent of each other, so it's not even that surprising a mistake to make.
Hi anh, be calm. Don't get triggered by their comments, it's a trap. Ignore the trolls. Keep your report succinct and professional. Stay safe and strong!
I have no strong evidence, but it seems that Force 47 is actively monitoring my blog [1]. I've never got so many personal attacks and smear comments like I did since I published my findings. I bet one of them will cite your comment as an evidence of my "immaturity".
This is hands down the best book on applied crypto, especially for people who want to self-learn crypto. I started reading it since version 0.1, but every time I pick it up I learn something new.The fun application section in each chapter is pure gold. The exercises are challenging but super rewarding. I can't do many of them, but reading the problem statements is usually enough to make me realize I don't understand something.
When I started learning crypto, I spent a lot of time reading A Computational Introduction to Number Theory and Algebra [1] another free, high-quality book by Shoup. I did a lot of exercises, even corrected some results in the book, and at one point thought that I wanted to publish a solution manual. I emailed professor Shoup, but he said it may not be a good idea because people would copy my solutions for their homework. It turns out he's right. The blog posts that I published still get hit from time to time, and the search keyword is always solutions for NTB [2] =).
Later on, I took CS255 [3] from Boneh. I had to pay for it myself. IIRC it was $4,000 or something. It was a huge amount of money where I'm from. I took an overdraft from my bank to pay for it, the best money I ever spent! I still remember in one of the classes when Boneh was talking about the Diffie-Hellman protocol he paused to ask us, "Do you know where this was invented?" Nobody knows, then he pointed to his left and said, "In a room a few yards from here". I felt like I was part of this amazing history. There's a stream of knowledge flowing through me and maybe one day I'd discover something cool.
Boneh is simply the best teacher. He knows everything. I like it when he poses an open problem, and ends with "if you can solve this, I'll be a friend forever". He doesn't just love teaching, but also knows how to inspire and apparently can't stop explaining things.
> I still remember in one of the classes when Boneh was talking about the Diffie-Hellman protocol he paused to ask us, "Do you know where this was invented?" Nobody knows, then he pointed to his left and said, "In a room a few yards from here".
>Ristretto is nice, terribly complex, and you don't actually need to care about the conceptual complexity. As an implementer, your only job is to execute the explicit formulas in section 5 of the Ristretto website. You do not have to be able to follow the hard math (just how you do not have to be able to follow the hard math involved in making the explicit formulas).
I don't think one should blindly follow an instruction without understanding why in any fields, let alone in crypto where a small, subtle difference can make or break it. Also, understanding crypto requires less math than inventing (and attacking) crypto, so it takes some effort, but it's doable even for hobbyists. If the math makes one uncomfortable, maybe one shouldn't try to roll their own crypto for production use in the first place.
Case in point: the author of this article that we're commenting on made a deadly mistake because they did not understand the math behind point conversion between Ed25519 and Curve25519 [1].
Below I also point out a mistake in their claim about malleability in EdDSA.
> Case in point: the author of this article that we're commenting on made a deadly mistake because they did not understand the math behind point conversion between Ed25519 and Curve25519
By the way, since you seem to work on Wycheproof: would you take a look at my pull request? The EdDSA test vectors would have saved me (and my users), but the front page didn't mention them, so I didn't know they even existed for over a year. I initially believed you were concentrating on other, even more error prone, primitives.
Others might be in my position: letting bugs through because they think Whycheproof is not relevant to their project. A pity, considering how amazing Whycheproof is (I'm now systematically integrating any new test vector I learn about).
It's difficult to assess one's "comfort" with the math. I've been working with crypto for more then 10 years and I wouldn't say that I'm perfectly "comfortable" (e.g. the Ristretto stuff). Should I stop working with it?
Maybe we should gatekeep it so much though. As long as there exist at least two people capable of implementation per programming language (one to implement, another to audit), there will only ever be one, single, canonical implementation and there's no way around it. It is not and should not be an inherent right to be allowed to implement cryptography (that is put into production or made publicly available). The gatekeeping is there for a reason and it's important that we uphold it. Fewer implementations means that more people will be focused on having to write and check less code overall. Patents could be used to help with this by only permitting one upstream implementation to exist, but that's now how they end up being used in practice, and that's ignoring the fact that patent expiry is impractically short (compared to copyright expiry especially so).
Gate keeping is a double edged, and somewhat blunt, sword.
First, some Maverick is going to ignore what everyone says and implement crypto for serious applications. Like yours truly.
Second, I've seen it go a bit too far when I implemented Argon2i: there was a discrepancy between the specs and the reference implementations, and the authors haven't corrected the specs. I figured this was because not enough independent implementers bugged them about that. (Now, 3 years later, the specs still aren't fixed, so maybe the authors are really really busy. At least but the issue is still open: https://github.com/P-H-C/phc-winner-argon2/issues/183 )
That simply does not work in the real world. Also, why does this only applies to crypto? A RCE vuln can have a much larger impact than mishandling cofactors. Should we have canonical implementations of every piece of software imaginable?
tl;dr: the conclusion of the EdDSA part of the article is wrong. EdDSA has its problems, but malleability is not one of them, if one is following RFC 8032.
>There are several ways to sign a document with EdDSA, and produce a valid signature. The three sources of malleability are:
>We can add a multiple of L (the order of the prime subgroup) to s. Recall that B has order L as well, so it will absorb any cofactor. Basically everything happens modulo L, so adding L won't change a thing.
This is prevented in RFC 8032 by checking that 0 <= s < L. Tink [1] does this check, and therefore is malleability free.
>We can sign the same message with a different nonce r. This requires knowledge of the secret key a.
This proves that the signature of a message is not unique -- that is the signer can product multiple signatures -- but I haven't seen anyone calling this a malleability issue. Malleability is about taking a triple (public key, signature message) and tweaking bits to produce another valid triple.
>We can add a low order point to A, and subtract it from R. That way we produce a valid signature, but from a public key nobody vouches for. If the verifier checks the weaker equation, we can add a low order point to just R, and produce a "valid" signature with the same public key.
This is the second time I saw this claim. When I first saw it [2], I thought, wait, this test is missing in Wycheproof [3], but Bleichenbacher does NOT miss anything. That's when I knew it's wrong.
Modifying A or R instantly makes the signature invalid. Using the article's notation, the signature is validated by checking that
B.s.8 == R.8 + A.h.8, where h = SHA-512(R, A, M) and M is the message
Multiplying the cofactor or not doesn't matter, doesn't introduce any weakness, as implied by the article. If R or A is changed, h will change.
> malleability is not one of them, if one is following RFC 8032
This is like claiming Weierstrass curves don't have any problems if you follow the NIST/SECG standards. The whole point of the "SafeCurves" it to be easier to get them right, but you can still get them wrong.
Daniel J. Bernstein et al's original paper (High-Speed High-Security Signatures), didn't feel the need to take as many precautions as RFC 8032. For instance, they didn't care about malleability.
You seem to think they should have. May I ask why?
I'm interested in Thai's response to this question too, as I would be in any comment anyone managed to solicit from him about this topic, but an easy point to make here is that Bernstein was himself involved in RFC 8032, at least as a reviewer and contributor to the process, as you can quickly learn by reading the CFRG mailing list.
Oh, so DJB changed his mind then? Makes sense considering the application of EdDSA beyond signatures (I've heard malleability is a problem with zero-knowledge proofs, but I haven't studied that subject).
> This is prevented in RFC 8032 by checking that 0 <= s < L
It is, but some libraries do not perform this check. Including TweetNaCl if I recall correctly.
> Modifying A or R instantly makes the signature invalid.
I was talking about modifying them together. Here's what I claim:
B.s = R + A.h
B.s = R + A.h + P - P
B.s =(R + P) + (A.h - P)
And now I'm realising this should work with any point, not just low order points. I'll correct this. Anyway, it's a commutative group we're talking about how could this not work?
> Multiplying the cofactor or not doesn't matter
Perhaps I went over this a bit to fast. Recall that for any low order point P, P.8 = zero. Once you accept this fact, the rest follows pretty smoothly:
And now you can see that the weaker equation will give the same result for R and R+P, if P has low order. Not a weakness if we're only doing signatures, but still a source of malleability.
I'll add this explanation in the article, thanks for the feedback.
>It is, but some libraries do not perform this check. Including TweetNaCl if I recall correctly.
I'm not sure why TweetNaCl is even considered a serious crypto library. I guess that it can fit in tweets, but this is an optimization that is at best irrelevant at worst a bad software engineering practice.
Re malleability: instead of just thinking about this issue in an abstract way, I recommend writing an exploit. For example, Tink doesn't check R or A at all, try to see if you can produce a new signature from an existing one by modifying R or A as you said.
> Re malleability: instead of just thinking about this issue in an abstract way, I recommend writing an exploit.
Challenge accepted! Hmm, doesn't work. Let me think a bit more abou— <facepalm>
Of course: I totally forgot that h is a hash of R and A, not just the message. So if I change them in any way, h's main factor will change unpredictably, and the signature will fail. Looks like the only malleability left is `s`, and that has nothing to do with the cofactor. Let's take the whole section down.
Lesson learned: I should test my writings like I test my code.
---
If I may, you should have lead with "If R or A is changed, h will change." I let myself get worked up by your first comment¹, and failed to notice the single most important sentence near the bottom. I ended up having to reach the same conclusion independently. I almost missed my error.
[1]: You didn't address me directly, and you didn't start with my error. Regardless of your intentions, that felt mildly confrontational. Being nicer would have been more effective.
From a user's point of view, keys are still binary blob. Internally Tink serializes keys using protobuf, but in principle it supports arbitrary key formats via the KeysetReader/KeysetWriter interfaces. Admittedly, this aspect of our design is somewhat clumsy. We're working on a new design.
The key differences (pun intended) between Tink and other libraries are:
1/ Tink works with keysets instead of individual keys. This enables key rotation and crypto agility. This is very important at Google because there are systems that generate too much data to encrypt with a single key. We want to be able to rotate keys and still be able to decrypt old ciphertext.
Also most crypto schemes we're using today would be broken eventually. We want to make sure we can add new schemes and retire old ones over time without users having to change their code. For example, a lot of libraries have functions containing algorithm names, e.g., aes_gcm_encrypt. When GCM is no longer adequate, users of these libraries would have a hard time upgrading to alternatives.
Tink interfaces don't contain the algorithm name. We name our APIs after generic crypto primitives rather than famous cryptographers or algorithms. For example, we provide a generic AEAD interface for symmetric key encryption. With proper key management, users don't have to know anything about any particular algorithms and can easily rotate to new ones without changing a single line of code (rather than upgrading Tink).
2/ A key in Tink contains not only the raw key material, but also all necessary parameters. It is equivalent to the result of a handshake. Before any data encryption can take place, both sides have to reach an agreement not only on a raw key, but also how to use that key to encrypt data. Since a key in Tink contains all parameters, Tink does not require in-band ciphersuite negotiation. That is no ciphertext in Tink contains any other metadata aside from a key ID.
This design sounds so simple but I've seen people get this wrong all the time. For example, the root cause of many embarrassing vulnerabilities in JWT [1] is in-band ciphersuite negotiation. That is, a JWT contains an alg field that dictates how the receiver should process it. This alg field should rather be included as part of the key.
JWT is not the only standard making this mistake. Many crypto libraries only ask users for the raw key material. This means the parameters are either implicitly assumed or under specified. Aside from the aforementioned vulnerabilities, this can also lead to key confusion, cross-protocol key reuse and make it hard to rotate keys or change algorithms.
To the best of my knowledge, Tink is the only high-level library that gets this right.
[1] https://auth0.com/blog/critical-vulnerabilities-in-json-web-...