5 ms·
That's not really what I'm talking about, though it is a manifestation. "Don't use the tool" is a cryptographically sound piece of advice, given what you know
by diminoten 12y ago
That's not really what I'm talking about, though it is a manifestation.
"Don't use the tool" is a cryptographically sound piece of advice, given what you know about the specific implementation, but it's utterly useless for Cryptocat, from a product standpoint. What's a developer supposed to do when a crypto expert just says, "no"? That's terrible feedback, it needs to be better, and it can be better (sometimes it actually is better, I think you've mentioned in the past that you've lent a hand to Cryptocat).
As with every other "theory vs. practice" discussion, the theorists need to tone down the rhetoric, and the practitioners need to actually listen to what the theorists are saying.
- tptacek 12y agoTo be clear: I've never done anything to help Cryptocat, nor will I. The right thing to happen with Cryptocat is for it to be scrapped. Its security issues pervade beyond bad cryptography. Its users are literally better off with Google Hangouts or iMessage. And, in fact, the same was true of Lavabit: there was no recommendation that would allow a mail service that worked (for users) the same way Google Mail to resist serious attacks. But that was the premise of the system! It needed to be scrapped.
- diminoten 12y agoAnd this is the nonuseful advice that the crypto experts need to stop giving. Joe Developer sees this advice and decides not to write crypto software. That's unambiguously bad, because the software industry thrives on failing a lot until a good solution is found. There needs to be a way to develop crypto software that falls in a land of, "Don't use this yet, but maybe someday after we're done testing it, you can start using it and be secure" rather than "nope, just scrap the whole thing".
- kasey_junk 12y agoI am not a crypto expert and don't have a position wrt this particular problem domain but: "the software industry thrives on failing a lot until a good solution is found" may be at the heart of the disagreement. It is true that some parts of the software industry are best served by this style of iterative failure based progress, but it is unfair to say that the entirety of software is best developed this way. There exist whole classes of problems where the failure modes of their solutions are quite simply worse than any potential value those solutions can provide. Those class of problems should NOT be iteratively developed, rather they should be rigorously engineered and formally verified. I suspect your disagreement stems from whether you think crypto systems exist inside or outside that problem set.
- wglb 12y agoWhere software industry thrives on failing a lot until a good solution is found. Except where it is important. Failing a lot in crypto can have deadly consequences that are not visible until it is too late.
- Nursie 12y ago>> Joe Developer sees this advice and decides not to write crypto software. He probably shouldn't. That's pretty much the point. (--edit-- or he should consult with people who have studied this, find out about best practice, use existing solutions where possible, etc etc)
- diminoten 12y agoWhy must he? Why can't he build whatever he likes? Who are you to tell Joe what he can and can't do with regards to software development? This is the problem -- you and others are trying to perpetuate the idea that software must always be "complete" the moment it's put on GitHub. Why must Joe Developer adhere to your rigorous definition of what a software product is? Joe Developer should be free to tinker, and if he wants to tinker with crypto, crypto experts should let him. Currently they don't, and that's why we don't have any good crypto software.
- Nursie 12y ago>> Joe Developer should be free to tinker, and if he wants to tinker with crypto, crypto experts should let him. Currently they don't, and that's why we don't have any good crypto software. He can tinker. He can learn. He can do any of the many excellent free courses, tutorials and challenges on the net. He can implement attacks against toy problems, and real problems. And eventually, he can get deeper into implementing it. What he will absolutely and rightly be shot down for is making unverifiable claims about the security or what he's tinkering with, and try to profit from his claims. I'm sorry if you have a problem with that.
- diminoten 12y agoWhen did he make unverifiable claims? When did he profit from his claims? It's a nice straw man, but not what I suggested at all.
- Nursie 12y ago>> When did he make unverifiable claims? When did he profit from his claims? When he launched an app that claimed to be the new safest thing ever, surely? Perhaps with an unbreakable One-Time-Pad. You know, the stuff we're commenting on here...
- crpatino 12y agoYou are wrong on practically every account: > Joe Developer sees this advice and decides not to write crypto software. False. Moe Manager stomps his foot and makes Joe Developer wire together "something good enough", regardless of Joe's qualifications. Since neither Joe nor Moe are able to tell how good a crypto system is, they invariably end up with something in the awful-to-kludge spectrum. Both Moe and Joe need to be repeatedly reminded that they don't know enough about this non trivial problem to make good enough calls. > That's unambiguously bad, because the software industry thrives on failing a lot until a good solution is found. "Unambiguosly bad" is a thought stopper, a rhetoric trick. This just means that since you don't like any of the options made available to you by reality (like... paying big bucks to a real expert), self deception is preferable. Now, the fact that our software industry thrives on failure... I am ashamed to say that this just means our industry is really good at externalizing the consequences of our own incompetence to the customers. This is all good and fun, until real lives are on the line. Crypto is one of those cases, so it is one of those lines you don't cross. > There needs to be a way to develop crypto software that falls in a land of, "Don't use this yet, but maybe someday after we're done testing it, you can start using it and be secure" rather than "nope, just scrap the whole thing". Are you familiar with the term "Security by Design"? It is one of those pesky realities I was talking about. It basically says that you cannot create a product giving no concern to security, sprinkle some crypto fairy dust on top of it, and magically turn it into a secure product. If you try to do that, you'll end up with a product with broken security. Which is not all that bad in practice. There are lots of useful products that we all are better of having in insecure form than not having at all. But if the whole point of product X is to be "Y, but done securely" there is no redeeming feature that can save X from the axe.
- diminoten 12y agoI'm not sure how to respond to this. On one hand you talk about "rhetorical show stoppers", and on the other hand you reply to a statement I've made with the one word sentence, "False.", and in another sentence you say I'm "wrong on practically every account". I guess I could point out that there lies, in a continuum of software, a place for experimental products which offer nothing other than the exploration of an idea and the opportunity to refine said idea through testing and discussion. I could also point out that your strawman of "sprinkle some crypto fairy dust" is entirely irrelevant to this conversation, and that your lack of understanding of how threat actors are modeled is evident in your inability to comprehend a tool that might protect against certain threats but can acceptably not protect against all threats. But I think those points would fall on the "ears" of someone who just wants to be combative. Maybe someone else will pick up where you left off and engage in a more honest and less antagonizing manner, but this deep in the comment tree, "here be dragons".