4 ms·

While I appreciate the links to actual learning material, and though it is said in the nicest possible way, I get the usual "Crypto is hard, back off" vibe, wit

While I appreciate the links to actual learning material, and though it is said in the nicest possible way, I get the usual "Crypto is hard, back off" vibe, without a clear path to victory. Sure it's hard, but it's not magic either. There are relatively few rules, that when followed give you a working, secure system. Those rules aren't easy to follow, but they are simple to know about. http://loup-vaillant.fr/articles/crypto-is-not-magic http://loup-vaillant.fr/articles/crypto-is-not-magic About not using your crypto until it's been vetted by professionals… How do you get those vaunted professionals to even look at your work? For instance, I've been working on Monocypher for over 3 years, and the only way I could get professionals to actually look at it was to pay $7.000 (out of the OTF's pocket, I don't have the money). That's an unrealistic bar to meet, people need other ways to vet their work. About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't waste your time. The penetration testing approach to secure systems does not work. You whack a mole, two more appear. We need ways to prevent whole classes of errors, like proofs. For instance, tools like https://verifpal.com/ https://verifpal.com/ can be a great help when designing a protocol. On crypto being deep and vast, it really depends what you're doing. While perhaps less than 50 people in the world are truly qualified to design a new cipher, that's not what people need when they "roll their own crypto". Most of the time they need a new implementation for an existing primitive (embedded programmers), or they need to invent a new protocol. Either is actually accessible to any professional programmer who actually follow the rules. Even side effect circumvention. programming without the "if" statement is not that hard, especially if you stick to constant-time friendly primitives.

tptacek 6y ago
It's easy to write this when the safety of your users is both an abstraction and an externality; it's a lot tougher when you have to own your mistakes.
- loup-vaillant 6y ago
  Please don't presume. I do care about my users. Their safety is not an abstraction. You personally made sure it wouldn't be an externality either. I can count on you to make me pay for any mistake I make (only one of any consequence so far, and it was over 2 years ago: https://monocypher.org/quality-assurance/disclosures https://monocypher.org/quality-assurance/disclosures). I know exactly how tough it is to own up to my mistakes.
  - tptacek 6y ago
    There's nothing I can say here that Thai Duong can't say better, or that I'd be more qualified than him to say. I yield my time!
    - loup-vaillant 6y ago
      He's someone I would really have liked to have around when I asked about the Edwards/Montgomery conversion for EdDSA all over the place. (Something I knew from the outset: when you deal with crypto, you don't do it alone. You seek advice and feedback.) No one at the time warned me this conversion was dangerous. Yet another hint that we don't have enough cryptographic engineers.
cryptbe 6y ago
I wrote this article to encourage people to study the field I love. If I wanted to tell people to back off, why would I bother providing advice, material and telling people to have fun? >Those rules aren't easy to follow, but they are simple to know about. If the rules were so simple, how come your library had a signature bypass vulnerability that you did NOT understand its root cause until I explained? The root cause looks deceptively simple, until you take your time to understand the underlying math. I didn't fully understand it until a professor at MIT explained it to me. Maybe it's just that I'm stupid, but it is never simple to me. >About not using your crypto until it's been vetted by professionals… How do you get those vaunted professionals to even look at your work? You can't expect people to pay attention to your work until you earn it. Why would anyone bother reviewing a random library from a random dude? Frank of libsodium fame didn't start by writing a brand new library from scratch, but built it on top of NaCl. If he did that, nobody would take him seriously either. >About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't waste your time. The penetration testing approach to secure systems does not work. You whack a mole, two more appear. We need ways to prevent whole classes of errors, like proofs. For instance, tools like https://verifpal.com/ https://verifpal.com/ can be a great help when designing a protocol. This was how my friends and I got started. Maybe you were right that it isn't worth it, but it helps get us to where we are, being paid to do security and crypto. There are two approaches to learning: top down or bottom up. The former is what you get at university. If you want to learn crypto, you have to learn abstract algebra, linear algebra, probability theory, complexity theory, and computer security. If you want to learn complexity theory, you want to learn automata theory, computability theory, and algorithms. If you want to learn computer security, you want to learn computer architecture, operating systems, networking, etc. The top down approach is systematic, but it might not prepare you for the real world. For that, you need internships and CTFs. They are reality checks with a fast feedback loop, showing you very quickly which skill or knowledge you are lacking or need improvement. They are also fun.
- tptacek 6y ago
  On the off chance that anyone here isn't familiar with 'cryptbe, he broke the Flickr URL signing scheme, he and Juliano Rizzo discovered and worked out the BEAST TLS attack (which, to hear Kenny Paterson describe it, more or less set the template for the next 10 years of applied TLS attack research), and then discovered CRIME, which is the first in a line of compression oracle attacks. He works on Daniel Bleichenbacher's team now doing Tink and and Wycheproof.

tptacek 6y ago

It's easy to write this when the safety of your users is both an abstraction and an externality; it's a lot tougher when you have to own your mistakes.

loup-vaillant 6y ago
Please don't presume. I do care about my users. Their safety is not an abstraction. You personally made sure it wouldn't be an externality either. I can count on you to make me pay for any mistake I make (only one of any consequence so far, and it was over 2 years ago: https://monocypher.org/quality-assurance/disclosures https://monocypher.org/quality-assurance/disclosures). I know exactly how tough it is to own up to my mistakes.
- tptacek 6y ago
  There's nothing I can say here that Thai Duong can't say better, or that I'd be more qualified than him to say. I yield my time!
  - loup-vaillant 6y ago
    He's someone I would really have liked to have around when I asked about the Edwards/Montgomery conversion for EdDSA all over the place. (Something I knew from the outset: when you deal with crypto, you don't do it alone. You seek advice and feedback.) No one at the time warned me this conversion was dangerous. Yet another hint that we don't have enough cryptographic engineers.

cryptbe 6y ago

I wrote this article to encourage people to study the field I love. If I wanted to tell people to back off, why would I bother providing advice, material and telling people to have fun? >Those rules aren't easy to follow, but they are simple to know about. If the rules were so simple, how come your library had a signature bypass vulnerability that you did NOT understand its root cause until I explained? The root cause looks deceptively simple, until you take your time to understand the underlying math. I didn't fully understand it until a professor at MIT explained it to me. Maybe it's just that I'm stupid, but it is never simple to me. >About not using your crypto until it's been vetted by professionals… How do you get those vaunted professionals to even look at your work? You can't expect people to pay attention to your work until you earn it. Why would anyone bother reviewing a random library from a random dude? Frank of libsodium fame didn't start by writing a brand new library from scratch, but built it on top of NaCl. If he did that, nobody would take him seriously either. >About CTF (Capture The Flag), and cryptopal challenges, my advice is: don't waste your time. The penetration testing approach to secure systems does not work. You whack a mole, two more appear. We need ways to prevent whole classes of errors, like proofs. For instance, tools like https://verifpal.com/ https://verifpal.com/ can be a great help when designing a protocol. This was how my friends and I got started. Maybe you were right that it isn't worth it, but it helps get us to where we are, being paid to do security and crypto. There are two approaches to learning: top down or bottom up. The former is what you get at university. If you want to learn crypto, you have to learn abstract algebra, linear algebra, probability theory, complexity theory, and computer security. If you want to learn complexity theory, you want to learn automata theory, computability theory, and algorithms. If you want to learn computer security, you want to learn computer architecture, operating systems, networking, etc. The top down approach is systematic, but it might not prepare you for the real world. For that, you need internships and CTFs. They are reality checks with a fast feedback loop, showing you very quickly which skill or knowledge you are lacking or need improvement. They are also fun.

tptacek 6y ago
On the off chance that anyone here isn't familiar with 'cryptbe, he broke the Flickr URL signing scheme, he and Juliano Rizzo discovered and worked out the BEAST TLS attack (which, to hear Kenny Paterson describe it, more or less set the template for the next 10 years of applied TLS attack research), and then discovered CRIME, which is the first in a line of compression oracle attacks. He works on Daniel Bleichenbacher's team now doing Tink and and Wycheproof.