4 ms·

This article completely misses the forest for the trees. Of course someone can roll their own crypto, if they've a willingness to study and internalize the con

This article completely misses the forest for the trees. Of course someone can roll their own crypto, if they've a willingness to study and internalize the concepts, have a commitment to doing it right, and spend time doing things like "Make it bug free. Test, test, test. Prove what you can. Be extra-rigorous". The whole point of that common advice is that the overwhelming majority of developers have none of those things and it would behoove them to lean on a library instead.

loup-vaillant 6y ago
One of my hopes is that my article gives an idea of what one would be getting into. That someone without the dedication or rigour to do this would notice right away and back off, with no hard feelings. My other hopes is that it would help newcomers focus their learning. Had I read this article 4 years ago, it would have taken me less time to design a reliable enough test suite.
- anticristi 6y ago
  @loup-vaillant This is an excellent write-up! But I would say that the net benefit is that it teaches developers why they should not roll their own crypto, instead of telling them off. Small tangent, I feel the same way about car servicing: I watch YouTube videos on how to do it, then I pay a mechanic to do it. Besides not needling to invest time in learning a non-core competence -- most devs need to deliver a user experience and features -- not rolling your own crypto also transfers risks. I doubt you would like to hear your bank using a custom IV, because they thought it would be cool. :) In a follow-up, it would be cool if you wrote about SRP authentication.
  - loup-vaillant 6y ago
    > In a follow-up, it would be cool if you wrote about SRP authentication. First time I hear of this. Looks interesting, but as PAKE goes I know B-SPEKE, AuCPACE, and OPAQUE better. I'm trying to determine which one I want right now, possibly even design my own, but I found those protocols are significantly harder to get right than authenticated key exchange. I also don't know them well enough to competently write about them just yet.
    - anticristi 6y ago
      Sorry, I should have written PAKE (the general concept) and not SRP (one particular protocol that implements PAKE). If you are interested in my 2 cents, choose one that you understand and you can explain best. Feels most aligned with your goal of making crypto less magic.
readams 6y ago
I think part of what the article conveys and I think lacking in many of the messages that just say "don't roll your own crypto" is that testing and proving things is nowhere near sufficient to write a secure crypto library. The hard part is all the invisible things like the side channels. These are the pitfalls that you will fall into because you must know about them to avoid them.
kls 6y ago
I agree that the saying misses the mark a little bit, and the real meaning behind don't roll your own cryto is, to not write some crypto library that you only use internally and that you are protecting important information with. If you are going to try to create a new crypto library, release it to the world and let them beat the crap out of it, until it is battle hardened then have at it. I think that is the major point, of saying don't roll your own. Is that, someones hack it together in a weekend for logins is going to get broken if someone really wants to get in. But if we did not have people trying out new ideas in cryptography we would have never seen blowfish or ECDSA. I think people should absolutely try writing a crypto library, I don't think they should use it to try to secure anything of importance. I remember back in the BBS days people would actually play a cryto war game where they would write a library, encrypt a message, put it up on the BBS and get people to try to hack it. The message usually contained contact info, with a request to please contact the author and explain how they broke it, so the author could learn from their mistakes.

loup-vaillant 6y ago

One of my hopes is that my article gives an idea of what one would be getting into. That someone without the dedication or rigour to do this would notice right away and back off, with no hard feelings. My other hopes is that it would help newcomers focus their learning. Had I read this article 4 years ago, it would have taken me less time to design a reliable enough test suite.

anticristi 6y ago
@loup-vaillant This is an excellent write-up! But I would say that the net benefit is that it teaches developers why they should not roll their own crypto, instead of telling them off. Small tangent, I feel the same way about car servicing: I watch YouTube videos on how to do it, then I pay a mechanic to do it. Besides not needling to invest time in learning a non-core competence -- most devs need to deliver a user experience and features -- not rolling your own crypto also transfers risks. I doubt you would like to hear your bank using a custom IV, because they thought it would be cool. :) In a follow-up, it would be cool if you wrote about SRP authentication.
- loup-vaillant 6y ago
  > In a follow-up, it would be cool if you wrote about SRP authentication. First time I hear of this. Looks interesting, but as PAKE goes I know B-SPEKE, AuCPACE, and OPAQUE better. I'm trying to determine which one I want right now, possibly even design my own, but I found those protocols are significantly harder to get right than authenticated key exchange. I also don't know them well enough to competently write about them just yet.
  - anticristi 6y ago
    Sorry, I should have written PAKE (the general concept) and not SRP (one particular protocol that implements PAKE). If you are interested in my 2 cents, choose one that you understand and you can explain best. Feels most aligned with your goal of making crypto less magic.

readams 6y ago

I think part of what the article conveys and I think lacking in many of the messages that just say "don't roll your own crypto" is that testing and proving things is nowhere near sufficient to write a secure crypto library. The hard part is all the invisible things like the side channels. These are the pitfalls that you will fall into because you must know about them to avoid them.

kls 6y ago

I agree that the saying misses the mark a little bit, and the real meaning behind don't roll your own cryto is, to not write some crypto library that you only use internally and that you are protecting important information with. If you are going to try to create a new crypto library, release it to the world and let them beat the crap out of it, until it is battle hardened then have at it. I think that is the major point, of saying don't roll your own. Is that, someones hack it together in a weekend for logins is going to get broken if someone really wants to get in. But if we did not have people trying out new ideas in cryptography we would have never seen blowfish or ECDSA. I think people should absolutely try writing a crypto library, I don't think they should use it to try to secure anything of importance. I remember back in the BBS days people would actually play a cryto war game where they would write a library, encrypt a message, put it up on the BBS and get people to try to hack it. The message usually contained contact info, with a request to please contact the author and explain how they broke it, so the author could learn from their mistakes.