When I read the full two paragraphs around that sentence, I get the feeling it’s for educational purposes, not for real security use, which is why they encourage a security disclaimer.
I might be projecting my own views though because I think “rolling your own crypto” is a fantastic way of learning how the system works and how things can fall apart. I’ve learned how easy it is to make mistakes and I’ve never read papers and documentation more thoroughly than with cryptography and compression algorithms since both are so incredibly hard to debug. I’ve also learned a lot about tooling to mitigate these issues.
I’m a big fan of “rolling your own crypto” and here I’m talking about implementing known algorithms. I do it myself. I even think making it available on GitHub or similar, to ask for feedback, is good (if users are warned that no security can be expected).
However, a problem arises when projects that don’t even uphold the bare minimum of testing test vectors, are published with no warnings at all. Had there been used test vectors in this case, it wouldn’t have left IdentityModel completely broken.
When I read the full two paragraphs around that sentence, I get the feeling it’s for educational purposes, not for real security use, which is why they encourage a security disclaimer.
Yes, this is exactly what I mean. And I totally agree with your benefits, that come from exploring it for educational purposes.
One reason it’s not a good idea: After showing a snippet of code that calls some XChaCha20-Poly1305 crypto functions, the author notes:
This is not a XChaCha20-Poly1305 construction.
In other words, the APIs exposed by low-level libraries are like bags of loose components. They have to be wired up correctly in order to work right, and it’s not always obvious how to do so. Even if you know about padding and nonces, a specific cipher can have its own limitations you also need to be aware of.
That’s why I’m a fan of the higher-level libraries stemming from and inspired by Daniel Bernstein’s NaCl (libSodium, Monocypher, CryptoKit, etc) which give you bigger building blocks like “cryptoBox” that do a specific thing and do it right, and choose appropriate algorithms under the hood. That makes it a lot easier to successfully implement a crypto construction, and in a way that’s compatible with other programs that use the same construction.
That’s why I’m a fan of the higher-level libraries stemming from and inspired by Daniel Bernstein’s NaCl (libSodium, Monocypher, CryptoKit, etc) which give you bigger building blocks like “cryptoBox” that do a specific thing and do it right, and choose appropriate algorithms under the hood.
Thanks for citing my work, appreciated. :-)
Working on Monocypher had me realise that the NaCl family ((Tweet)NaCl, Libsodium, Monocypher) is actually fairly low level. Yes, providing authenticated encryption and clean key exchange out of the box was a huge improvement. But my work on authenticated key exchange told me that high-level protocols are often fairly delicate, and require significant effort for untrained people to get them right. (Implementing an existing protocol like Noise isn’t too bad, though.) That’s in my opinion a big reason why Latacora’s Cryptographic Right Answers still recommends freaking TLS for client/server security.
I’d say the NaCl family of APIs is a good start. More work is needed to provide even higher-level facilities: full authenticated key exchange, PAKE, encrypted file formats (I’m leering at PURB), certificates… On top of those, we should then provide fully fledged network libraries, that actually handle the I/O (so far I’ve limited myself to manipulating buffers, to minimise dependencies and maximise portability). My, I’m afraid I still have a couple years of work ahead of me…
Isn’t this article a great example of why NOT to roll your own crypto?
When I read the full two paragraphs around that sentence, I get the feeling it’s for educational purposes, not for real security use, which is why they encourage a security disclaimer.
I might be projecting my own views though because I think “rolling your own crypto” is a fantastic way of learning how the system works and how things can fall apart. I’ve learned how easy it is to make mistakes and I’ve never read papers and documentation more thoroughly than with cryptography and compression algorithms since both are so incredibly hard to debug. I’ve also learned a lot about tooling to mitigate these issues.
Yes, this is exactly what I mean. And I totally agree with your benefits, that come from exploring it for educational purposes.
Not why. How. Avoiding most mistakes only requires following a few rules. Those rules aren’t easy to follow, but they are pretty easy to know about.
Exactly, I was going to post the same thing.
One reason it’s not a good idea: After showing a snippet of code that calls some XChaCha20-Poly1305 crypto functions, the author notes:
In other words, the APIs exposed by low-level libraries are like bags of loose components. They have to be wired up correctly in order to work right, and it’s not always obvious how to do so. Even if you know about padding and nonces, a specific cipher can have its own limitations you also need to be aware of.
That’s why I’m a fan of the higher-level libraries stemming from and inspired by Daniel Bernstein’s NaCl (libSodium, Monocypher, CryptoKit, etc) which give you bigger building blocks like “cryptoBox” that do a specific thing and do it right, and choose appropriate algorithms under the hood. That makes it a lot easier to successfully implement a crypto construction, and in a way that’s compatible with other programs that use the same construction.
Thanks for citing my work, appreciated. :-)
Working on Monocypher had me realise that the NaCl family ((Tweet)NaCl, Libsodium, Monocypher) is actually fairly low level. Yes, providing authenticated encryption and clean key exchange out of the box was a huge improvement. But my work on authenticated key exchange told me that high-level protocols are often fairly delicate, and require significant effort for untrained people to get them right. (Implementing an existing protocol like Noise isn’t too bad, though.) That’s in my opinion a big reason why Latacora’s Cryptographic Right Answers still recommends freaking TLS for client/server security.
I’d say the NaCl family of APIs is a good start. More work is needed to provide even higher-level facilities: full authenticated key exchange, PAKE, encrypted file formats (I’m leering at PURB), certificates… On top of those, we should then provide fully fledged network libraries, that actually handle the I/O (so far I’ve limited myself to manipulating buffers, to minimise dependencies and maximise portability). My, I’m afraid I still have a couple years of work ahead of me…
(cliche warning) two kinds of people roll their own crypto: geniuses and idiots.
(i’m not a genius)