3 ms·
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
by 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 agoSorry, 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.