5 ms·

>Do not let users use your product until it's been vetted. Its OK to let them use it so you can have a large user-base to test with, you just need to explain t

by phaus 13y ago

>Do not let users use your product until it's been vetted. Its OK to let them use it so you can have a large user-base to test with, you just need to explain to them that it isn't proven secure. As in, explicitly tell them that they are under no circumstances to use it with sensitive information. Playing around with cryptography is the only way to learn it, you just have to remember to tell people that playing is exactly what you are doing.

EpicEng 13y ago
But how many people are going to be interested in a crypto product which is unproven? Sure, perhaps a few technical types will give it a whirl, but most people just want something that works. If I'm in the market for something like this I'm certainly not going to use a product with a big disclaimer stating "Hey, we don't really know if this works yet, but help us test it out!" This is mission critical stuff, not some new URL routing framework.
- phaus 13y ago
  How many people would have been interested in a digital currency when it was worthless and not accepted as a form of payment anywhere? Perhaps the general population won't be interested, but techies are often willing to play around with unproven technologies.
  - EpicEng 13y ago
    I suppose that's fine as long as your target market is techies, but that is pretty limiting. Also, BTC is pretty unproven and, with massive volatility, unsustainable. If it doesn't improve it will never gain wide adoption.
tptacek 13y ago
Two things. First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are repeatedly broken. You can see that right now with TLS and the TLS working group, which still hasn't fixed MtE block ciphersuites because veteran implementors can't get it through their heads that MtE is a design flaw. Don't learn by building. You need to learn by breaking. Second, more than one project has done the tightrope walk of telling their users "this isn't really safe" but then misleading (innocently or not) non-savvy users into trusting them. One project made it clear that their system wasn't "ready" to defend against nation-state adversaries... but then suggested that maybe it would be good enough for journalists, and even promoted it at an event for teaching journalists cryptography. It was later comically broken. Be honest with yourself. Crypto doesn't get beta-tested into resiliency. Strong systems start out strong. If you're building something because its your dream to thwart the NSA, don't kid yourself into thinking that you'll get there by first protecting people's Warcraft clans.
- phaus 13y ago
  I get that you need to learn how to break software as a major part of the learning process. I also understand that a broken system often can't be fixed, and that if your system breaks you might have to start from scratch. But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed crypto systems, as the learning process continues? Maybe the process is just counterintuitive, but it seems that no matter how skilled someone might be at breaking systems, that building a sound system on the first try would still be incredibly difficult. I know that crypto systems aren't built iteratively, instead I'm talking about going back to the drawing board each time. Would there be value in that, or would it be a waste of time? I'm not yet an expert (and I am well aware that you are), though I aspire to be one day. Perhaps you would be kind enough to elaborate?
  - daeken 13y ago
    > But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed crypto systems, as the learning process continues? Both and neither. Once you get really good at breaking cryptosystems, designing them looks very similar. You start with best practices: use sane primitives (or thoroughly vetted components, preferably!) and put them together in known, simple (simple is key) ways. Then you put on your breaking hat and you attempt to violate every constraint. If you find a flaw, then you iterate or redesign. Once you are happy with it, you start showing it to other crypto breakers, until they're happy with it too. At this point, you have something that would withstand most basic attacks, and you might be ready to put it out into the world. It's still not battle-hardened and ready for uberconfidential data, but it's in a better state than most cryptosystems. As more and more people look at it without owning it, its trustworthiness goes up, and the risk goes down. Secure cryptosystems don't pop out of nothing; they're iterative, but not in the "I should do a Show HN" sense. It's iterative like writing a poem -- you don't release it one line at a time.
- sillysaurus2 13y ago
  Don't learn by building. You need to learn by breaking. The best way to do this is to do the Matasano crypto challenges. The challenges are designed to get progressively more difficult, and since the goal of most of them is to break something, that means you'll learn how to employ progressively more sophisticated attacks. They're also great for a newbie, because in one challenge you'll implement something that seems impervious to attack, then in the following challenge you'll attack and break it, often via an unexpected attack vector. (The padding oracle attack comes to mind.) You'll come away with an understanding of AES in ECB CBC and CTR modes; HMAC; timing attacks; attacks on RNGs; attacks on hashes; and a lot more. That's just off the top of my head. For me, there were a dozen "aha!" moments in the first 30 challenges. Each of those moments now live with me and inform my future decisions. They will also make you much less confident in your ability to design secure cryptosystems, which is good.

by phaus 13y ago

EpicEng 13y ago

But how many people are going to be interested in a crypto product which is unproven? Sure, perhaps a few technical types will give it a whirl, but most people just want something that works. If I'm in the market for something like this I'm certainly not going to use a product with a big disclaimer stating "Hey, we don't really know if this works yet, but help us test it out!" This is mission critical stuff, not some new URL routing framework.

phaus 13y ago
How many people would have been interested in a digital currency when it was worthless and not accepted as a form of payment anywhere? Perhaps the general population won't be interested, but techies are often willing to play around with unproven technologies.
- EpicEng 13y ago
  I suppose that's fine as long as your target market is techies, but that is pretty limiting. Also, BTC is pretty unproven and, with massive volatility, unsustainable. If it doesn't improve it will never gain wide adoption.

tptacek 13y ago

Two things. First, while "playing around with cryptography" may be the only way to learn it, building cryptographic systems is just about the worst way to learn. Professional cryptographers start by cryptanalyzing targets and use that experience to inform their future designs. On the other hand, veteran implementors who have never taken the time to learn how to break crypto turn out protocols and designs that are repeatedly broken. You can see that right now with TLS and the TLS working group, which still hasn't fixed MtE block ciphersuites because veteran implementors can't get it through their heads that MtE is a design flaw. Don't learn by building. You need to learn by breaking. Second, more than one project has done the tightrope walk of telling their users "this isn't really safe" but then misleading (innocently or not) non-savvy users into trusting them. One project made it clear that their system wasn't "ready" to defend against nation-state adversaries... but then suggested that maybe it would be good enough for journalists, and even promoted it at an event for teaching journalists cryptography. It was later comically broken. Be honest with yourself. Crypto doesn't get beta-tested into resiliency. Strong systems start out strong. If you're building something because its your dream to thwart the NSA, don't kid yourself into thinking that you'll get there by first protecting people's Warcraft clans.

phaus 13y ago
I get that you need to learn how to break software as a major part of the learning process. I also understand that a broken system often can't be fixed, and that if your system breaks you might have to start from scratch. But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed crypto systems, as the learning process continues? Maybe the process is just counterintuitive, but it seems that no matter how skilled someone might be at breaking systems, that building a sound system on the first try would still be incredibly difficult. I know that crypto systems aren't built iteratively, instead I'm talking about going back to the drawing board each time. Would there be value in that, or would it be a waste of time? I'm not yet an expert (and I am well aware that you are), though I aspire to be one day. Perhaps you would be kind enough to elaborate?
- daeken 13y ago
  > But does one go from becoming an expert at breaking systems to automatically churning out a secure cryptographic system? Or does one become an expert at breaking and then build a bunch of flawed crypto systems, as the learning process continues? Both and neither. Once you get really good at breaking cryptosystems, designing them looks very similar. You start with best practices: use sane primitives (or thoroughly vetted components, preferably!) and put them together in known, simple (simple is key) ways. Then you put on your breaking hat and you attempt to violate every constraint. If you find a flaw, then you iterate or redesign. Once you are happy with it, you start showing it to other crypto breakers, until they're happy with it too. At this point, you have something that would withstand most basic attacks, and you might be ready to put it out into the world. It's still not battle-hardened and ready for uberconfidential data, but it's in a better state than most cryptosystems. As more and more people look at it without owning it, its trustworthiness goes up, and the risk goes down. Secure cryptosystems don't pop out of nothing; they're iterative, but not in the "I should do a Show HN" sense. It's iterative like writing a poem -- you don't release it one line at a time.
sillysaurus2 13y ago
Don't learn by building. You need to learn by breaking. The best way to do this is to do the Matasano crypto challenges. The challenges are designed to get progressively more difficult, and since the goal of most of them is to break something, that means you'll learn how to employ progressively more sophisticated attacks. They're also great for a newbie, because in one challenge you'll implement something that seems impervious to attack, then in the following challenge you'll attack and break it, often via an unexpected attack vector. (The padding oracle attack comes to mind.) You'll come away with an understanding of AES in ECB CBC and CTR modes; HMAC; timing attacks; attacks on RNGs; attacks on hashes; and a lot more. That's just off the top of my head. For me, there were a dozen "aha!" moments in the first 30 challenges. Each of those moments now live with me and inform my future decisions. They will also make you much less confident in your ability to design secure cryptosystems, which is good.