It seems to me like the developers have been earnestly trying to build and improve on Cryptocat and shore up any weaknesses only to be constantly shit on your typical internet crypto experts.
The release an insecure product.
People tell them it's insecure, and that they don't know what they're doing, and that they should stop.
They make a tweak, and release a new insecure version.
People tell them that it's insecure, and that they don't know what they're doing, and that they should stop.
They make another tweak, and release a new insecure version.
People tell them that it's insecure, and that they don't know what they're doing, and that they should stop.
They make another tweak, and release a new insecure version.
At this point, imagine no-one tells them about any bugs. Does that mean the product is secure? Does that mean people should be using it?
Here's one thread on HN where they get mostly polite advice (https://news.ycombinator.com/item?id=2855257) and the whack-a-mole game of "our software is secure", "here's a bug", tweak "Our software is secure" happens.
Here's a nice article about the hype surrounding cryptocat (which, admittedly, isn't the fault of cryptocat) (http://paranoia.dubfire.net/2012/07/tech-journalists-stop-hy...)
What more can you ask of them?
"You there. Stop. You shouldn't be building this because we the superior internet community think you're a terrible person who will never learn anything, so we're putting our foot down."
Screw that. What right do you have to tell these individuals to stop building something they might be actually enjoying building (and learning about crypto)?
You have absolutely no right to complain in much the same way I don't have any right to look at your Github repo, tell you you're a terrible developer and you should never touch a computer again.
Cryptographic software isn't something that you can improve by a process of gradual refinement.
Crypto can have small, subtle, bugs. Those bugs could mean that the product is worthless.
A skilled, knowledgeable researcher could audit the code closely, and report any bugs they find. Cryptocat could fix all of those bugs. Does that mean it's secure? No - because crypto is hard.
> What more can you ask of them?
I ask that they make the disclaimers much bolder and bigger. I ask that they emphasise the experimental, untested, unscrutinised nature of Cryptocat.
> "You there. Stop. You shouldn't be building this because we the superior internet community think you're a terrible person who will never learn anything, so we're putting our foot down."
That's a mischaracterisation of the criticism they've got.
"You there. Stop! Cryptography is very hard. Don't roll your own; or do but don't release it as a product for end users."
followed by
"You there. Stop! We suggested that you didn't release it for end users, but you did. Well, here's a list of bugs. Don't just fix these and think everything is good, there are probably other bugs and the whole thing is based on weird wrong ideas."
followed by
"You there. Stop! No, really, just stop. Here's a list of bugs. These are not subtle hard to find bugs. These are obvious bugs that anyone doing crypto really should have been aware of. The presence of these bugs demonstrates lack-of-clue. Please, stop hyping the product as secure, stop distributing as a tool for end users to use."
People get exasperated. It doesn't help that some of the responses from the developers were defensive and aggressive and dismissive.
tl;dr have fun with crypto and building stuff. Just don't think it's secure, and especially don't release it as secure. Especially don't release it as a browser plugin ready for naive end users.
How do you explain the fact that the majority/all of the crypto libraries we rely on today have been gradually improved over time, fixed as bugs have been found, etc?
I think you've severely mischaracterised the way crypto software is developed.
You fix the bugs and you move on. That's the only way to progress, and that's exactly what the developers have been doing. I can't fault them for that.
(In reality, it's not that bad because quite a lot of people distrust cryptocat. Still, "patch and move on" doesn't cut it for critical software, which almost all crypto software is.)
But not all software has the same sensitivity. In the weeks before Netscape Navigator shipped in the mid-90s, Jamie Zawinski slept under his desk at work trying to make it reliable. The builds from the night before launch crashed! Nobody thought they'd make it. That's a story anyone on a commercial dev team can probably tell you; it's the oldest story in product development.
That kind of incremental development works fine when you're shipping the first web browser, or even the first version of a new web browser.
It does not work when you are shipping cryptography. Nate Lawson is fond of saying, "plan to budget 10x for the validation of a new cryptosystem as you to implementation". You probably can't actually be doing that when your whole cryptosystem changes 4 times in 2 years.
The difference is between handling bugs and expecting bugs. Netscape expected bugs. Crypto software can't do that.
What we may be seeing is that we have roughly a decade now where "Agile" has been drummed into developers as the best way to write software. Perhaps it's the only approach they knew to take.
I dont know if I believe this. I have never had a software system that was completely bug-free (independent of whether or not it had anything to do with crypto). Furthermore, I would argue that one of the main ideas behind SSL was to expect there to be flaws in the underlying crypto that it used and therefore be able to deal with switching out one algorithm for another. You might argue that there exists a difference between a bug and an algorithmic flaw, but realistically they both have the same effect. Therefore, I argue that the superior method is not to write code expecting no flaws, but to write code which does expect them and has a way to deal with them.
That is not to say that you should release your code knowing that there exists a security flaw, but rather to acknowledge that you're not the smartest guy in the room and that the best way to harden a security system is by letting people attack it. Now, you cant force people who are good at crypto to attack your system in order to improve it. Hopefully though, security through obscurity will help. I.e. if your product is not well known it is not worth it for someone experienced to spend a lot of time to crack it. On the other hand, if it is, you then need to worry about the nature of the person attacking it. Is this person a researcher (in which case he will hopefully reveal his findings) or a threat? If you are a big product, you can hopefully afford to make this person a researcher who will give you his results. For the other case, I think that this is where auditing helps. Even if you have a broken system (which you can almost always safely assume you do), you can at least possibly detect a hack and then try to reverse engineer it. Lastly, to provide a solid example of 'bugs' which have been fixed in crypto code which everyone relied on, you need to look no further than unix's crypt.
Nobody does this with normal software.
If you find a bug in your crypto code through your testing and validation, that means your development process screwed up and allowed that bug to slip through. What you need to do is figure out how that bug got through your development process, change your development process so it wouldn't slip through next time, and then have a thorough audit of your already-written code to make sure no other bugs have slipped through the same way.
Developing must-not-fail critical software is the exact opposite of the traditional launch-fast-and-iterate model that most people use to produce web applications and such. This is a big reason that when web app developers try their hand at developing critical software like cryptography, they get it horribly wrong.
So who is building great crypto software that's built right from the ground up? OpenSSL AND OpenSSH struggle with this on a continual basis yet they seem to be the prime examples of doing it right. The problem, however seems to be unless every release is a complete rewrite eventually you will be working off of some foundational compromised base component.
Thoughts?
The way you deal with that is, you pick a credible crypto project with traction and build on top of it.
The world badly needs a GPG UX that ordinary people can use without thinking about it. Bonus: nobody knows what that UX is! It's an open problem! And you can tackle it without getting anyone killed, because the GPG/PGP team has spent decades getting the "might get someone killed" problems addressed.
On the other hand if you are including minor bugs, that have a low impact on security, then you are surely right but this doesn't mean much. Minor bugs get caught even in audits of the code for nuclear power plants.
A first amendment right.
> You have absolutely no right to complain
Freedom of speech includes freedom to complain.
> in much the same way I don't have any right to look at your Github repo
...per the fourth amendment for my private repros. I'll assume you're referring to my public repros instead of trying to compare as "the same" something that goes directly against someone's constitutional rights, with something that's explicitly protected by someone's constitutional rights.
> tell you you're a terrible developer and you should never touch a computer again.
...but this part is well within your first amendment rights as well. And if you think I've been undermining the pursuit of life and liberty as much as broken crypto can, repeatedly, despite fair warning, I'd dearly hope you'd exercise said rights. Rudeness and hurt egos are more survivable than broken crypto. Learning crypto is fine, but not at the expense of those who's lives may depend upon it. Whether or not they'll learn isn't the question: learning takes time, period, full stop. Time that cannot be afforded by those who would depend on said crypto.
And?
The same ideals and rights embodied within our constitution can be found as similarly protected rights well outside of the USA. Even ignoring that, the point would still stand: The blanket statement that "you" (generalizing to all those harshly critiquing the continued development of Cryptocat) "don't have the right" is incorrect.
If you suppose that freedom of speech isn't a universal human right, you could argue that not everybody has the right. But I would disagree with that assertion, as would the signatories of The Universal Declaration of Human Rights.
> Your amendments are utterly irrelevant to Europeans, for example.
They are utterly relevant not only in history, and how they affect those you may interact with, but also -- as is occurring here -- in the discussion of what rights one should (or shouldn't) have, by pointing out what rights were deemed worthy of enshrining in the highest laws of one of the largest countries of this world.
They may not be law in Europe, but that's a far cry from being irrelevant.
But if I package it up as a DIY package, ready for the real world, and lots of people start building/using my faulty car, I would consider it quite important to add a huge disclaimer.
"Here is our secure product for all" vs "Help us make our product secure for all"
If someone is learning crypto for fun and enjoyment they should seek advice of experts no matter how much of a jerk the expert may be. This isnt really the same level of a random github project 'convert your old php into haskell with 1 click!' I don't think anyone has expectations of that being 100% accurate.
People on HN flipped out over Linode, they made a mistake, they fessed up. People just want honesty.
Also, everyone has any right to complain, at least until prism comes a knockin
And his to tell you to fuck off and ignore you from then on if you did.
The complaints aren't posh "we disapprove" rants, they are legislate concerns. Imagine a Web server that didn't understand the Http from IE. You'd call them incompetent.
Learning to enjoy & build crypto? Awesome. Trying to improve your product? Awesome. Promoting your product as secure when the security experts say otherwise? Not awesome.
If these people were humble and would admit that this is just software for them to learn about cryptography. They would receive help and support.
What they are doing is promoting cryptocat as maintained secure system.
Moxie has been more than helpful to them in repeatedly showing that Gibberbot suffers from practical MITM attacks, yet they make tweaks and cause a dozen new vulnerabilities. It's only a matter of time until a huge blast of shit and twitter beat down explodes until they finally get it.