> is it possible for you to give constructive criticism for a project without calling people "incompetent"?

Cryptocat had many such bits of constructive criticism. They chose to ignore it. They continued to promote their broken product as secure.

You're making statements like that in a very matter of fact way. Can you please give references?

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.

> earnestly trying to build and improve on Cryptocat and shore up any weaknesses

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...)

Like I said, the developers seem to be earnestly trying to improve their product based on the feedback they are getting.

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.

> Like I said, the developers seem to be earnestly trying to improve their product based on the feedback they are getting.

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.

I think I do understand what you're saying Dan, but do you really believe that cryptographic software isn't something you can gradually improve on?

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.

There is a difference between starting with a reasonably well written core and fixing issues that are discovered, and starting with a product that demonstrates essentially no understanding of cryptography beyond the bare minimum and trying to debug a working cryptosystem into existence. It's bad enough to try that with regular software, but doing it with crypto is insane.

Note that, assuming the security model proposed by cryptocat, every time it's broken a few hundred peaceful protesters against a brutal regime end up against the wall. The brutal regime obviously doesn't bother to tell the world to stop using the software in question.

(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.)

He's not mischaracterizing the way crypto software is developed. You are.

Please characterize the proper way for us of the uninformed...

All software has bugs. There's no piece of real-world general-purpose software that you can't look at and say "this was improved incrementally as bugs were found".

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.

So what you're saying is, for cryptography software, "Agile" development doesn't work. For cryptography software you need very careful, deliberate, up-front design. You need careful, deliberate implementation that does not deviate from the design. You need careful deliberate validation.

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.

That a much better way to put it than mine.

> The difference is between handling bugs and expecting bugs. Netscape expected bugs. Crypto software can't do that.

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.

You haven't explained anything about how crypto software is developed. You have told us how other software is developed and then told us that it isn't okay for crypto software.

Spend 10x the resources on verification as on implementation. Spend 10x the resources on design as on implementation.

Nobody does this with normal software.

And ultimately the biggest thing to do is that when you find a bug, don't just fix that one bug and call it a day.

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.

This seems similar to way the people who developed the software for the space shuttle worked. Finding a bug was a huge deal, as it meant something was wrong in their process. It wasn't just fix the bug, but fix what caused the bug, and look to see where that faulty process may have caused other bugs. Google 'they write the right stuff' for a good article on it.

Another domain where you have things like this is embedded systems related to safety, ie, the micro-controller managing pressure equipment.

Reading that it seems as if this space is almost, positively, stacked against any solo or small group dev. Thanks for the insight, but if crypto is hard and there's issues on both ends of the spectrum (commercial space generally ships for monetary reasons, small groups ship for notoriety / political discourse rationale / tinfoil hat.

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?

This space is positively stacked against any solo or small group dev.

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.

If the user is placing their trust in the UX's ability to validate that PGP/GPG is working correctly and has not been tampered with, that sounds exactly like something that could get someone killed.

You can say the same thing about any piece of software; if Excel forgets how to multiply numbers, think of the horrible things that could happen! The difference is that multiplying two numbers isn't hard compared to getting a cryptosystem right, and neither is accurately displaying a key fingerprint.

My knowledge of this topic is limited but I believe if you are saying that the majority of crypto libraries have had major bugs, in the sense that they are made trivial to break, that you are overreaching.

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.

> What right do you have

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.

Not everyone lives in the USA. Your amendments are utterly irrelevant to Europeans, for example.

> Not everyone lives in the USA.

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.

Jeez dude. Stop oppressing Europeans by discussing speech rights.

I'd say it's akin to me building a high-speed car that randomly stops braking, severely endangering whoever uses it. As long as it's just me and other high-speed car enthusiasts playing around with it, that's fine.

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.

I think all you should ask of them is honesty, if their track record has truly been this bad.

"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

The idea is that they should, instead of continuing to write that software and endanger the public, go and study crypto in deep detail. Just how you don't build a production-ready nuclear reactor by "learning while doing", and instead go and study many fields of engineering first and actively run prototype designs by many peers before publishing, should the cryptocat dev have done the same.

Actually, I'd entirely support your right to do that.

And his to tell you to fuck off and ignore you from then on if you did.

No one's saying they aren't earnest, people are saying they aren't competent.

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.

Because people's lives could/are at stake.

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.

Everyone has right to their personal opinion. Not everyone has right to professional opinion.

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.

I noticed similar behaviour with the devs at Guardianproject (supposedly secure android apps). Noble project indeed, but some serious sloppy development.

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.

Can we please separate criticism of (1) the technical internals of Cryptocat from (2) the core idea behind Cryptocat and, especially, (3) Nadim himself, personally?

My own take on this is that Nadim ought to be encouraged, and we ought to help him engage additional people who are experienced crypto experts to help implement the Cryptocat internals.

If you think the core idea behind Cryptocat is crap, then fine, make a technical argument. If you think the idea is good, then let's encourage and help Nadim make it better.

If you want to criticize Nadim's judgment from afar (I assume you are not on the core Cryptocat team) then that's your choice, but trust me, it does not help him, or you, or anyone. We all have our flaws and we all make bad decisions. I for one would bet that Nadim is absolutely interested in making Cryptocat better, not sweeping problems under the rug. Let's help make that happen and let's do it without the personal attacks.

> If you think the core idea behind Cryptocat is crap, then fine, make a technical argument.

People keep making these technical arguments. They are ignored. It is frustrating to have to keep pushing warnings and to have those warnings ignored.

> (1) the technical internals of Cryptocat from (2) the core idea behind Cryptocat and, especially, (3) Nadim himself, personally?

That sounds reasonable, except it's hard to do.

The internals of Cryptocat are closely tied to the core idea. People point out the flaws in the core ideas, and cryptocat team just say "point out an actual attack". So then people are forced to find bugs in the internals. And when they do CryptoCat patch, and say "See! Nothing to worry about!" Except that the core idea is still flawed.

People get exasperated playing this game of Whack-a-mole.

I get that Nadim is proud of his product, but his choices of promotion have caused friction, and his reaction to some of the criticism has made it worse.

Some people have mentioned that the crypto community is toxic. They're right, but there's also a high barrier to entry. When someone releases a product as secure, but has made very many obvious flaws that ruin the security of that product, they're going to attract a lot of flak. Don't forget that many people are not sincerely trying to learn about crypto and make it accessible. Many people are bodging together terrible software and selling it. There's a long history of debunking snake-oil.

It's unfortunate that Nadim has been subject to attack, but he should have known it was coming and presented the product differently.

> making Cryptocat better

It can never be made "good enough". That's the fundamental point.

I think someone could probably make a relatively lightweight chat client which used OTR and ran as a mobile app or browser extension (although I'm not totally sure of the security model for extensions, they do seem to be a lot better than website-delivered js). I mean, we have pretty good examples of other people doing this (on mobile) with chatsecure, etc.

Not to be snide, but, you mean like Adium?

Adium is a local mac-specific app, and multi protocol, and pretty complicated. Far bigger and more complicated than I would want to trust. Doesn't ship with OTR out of the box (iirc).

Something either browser-extension or mobile app would be a lot better. IMO, also not supporting legacy stuff like aim/yahoo/etc, and supporting OTR out of the box.

Nadim did a decent job on the simple UI front. I don't know about the lack of persistent identity (pluses and minuses to that).

Adium has had OTR out of the box for as long as I've known about it, and you don't have to do anything special to make it work; just talk to someone else that wants to do OTR, and it'll pop up at you.

(I use adium too...) I was confusing it with Pidgin for needing the OTR plugin. Adium (and Pidgin) have had security issues in the past due to libpurple; a lightweight app would solve that. I want something where you can just tell someone who starts talking recklessly on FB messenger or SMS or whatever to go to a single URL or download a single app and have pretty high confidence it will work.

Mobile is probably more important in the long run, especially for the kind of activist users CryptoCat seems to target.

(Another obvious thing is just i18n/l10n for arabic/pashto/etc., of existing tools.)

Another feature which would be nice is Grugqian "anti-forensics"; Adium for a while logged OTR chats by default, and even retaining OTR keys could be used against you (even if it doesn't allow decryption of past messages, it is enough outside of a court of law to link you to activity...). A browser extension or mobile app which didn't save local state (doing key derivation from a passphrase?) would probably be great for that. Add in SnapChat-style "no logging in the application", and honest-but-stupid counterparties wouldn't log chats.

The only weakness I see is no great way to do message-encryption for multiparty right now in a standard way. I'm not sure how you can do multiparty key agreement with PFS using anything outside academic papers.

It's hard to think of a well-regarded widely-used multiparty encryption system, which is a good reason generalists shouldn't try to implement them.

It's fairly straightforward (conceptually, if not in actual implementation) for a system without PFS, since you can reduce the problem to N interoperating conventional public key systems (e.g. how PGP works for multiple recipients). (and, obviously, just use OpenPGP for it...). But PFS is probably highly desirable in the "Syrian protest" scenario.

Or with a trusted third party (at the limit, just do irc-over-SSL.) This is probably fairly safe if you pick your TTP correctly -- I'd trust the NYT or USG even if I were a Syrian protester with the FSA.

I agree overall -- and am not trying to defend CryptoCat, just the CryptoCat market niche.

On mobile, there's something called Gibberbot for Android but it's XMPP-based and fairly fiddly to get working.

Because, well, while a bug in your task-planer rails app is not cool it most likely won't endanger people's lives. While with crypto many people around the world depend on it with their lives.

Sometimes you just have to hit the thing with a bat to get attention.

Nonsense - the article comes across more weakly by taking a personal tone.

It's a technical article. You can like it more or less because of its tone, but if you're an engineer, you should be persuaded (or not) by the content, not the persuasiveness of the writing.

One shouldn't have to filter personal bullshit to be able to read technical content.

And? Perhaps one does in this case. If you're technically competent, you should be able to evaluate the claims in the article regardless.

I think the unfortunate side of this is it "feels" like there is an agenda, regardless of if that's the case or not. Technical basis aside, one generally wouldn't write a white paper on this format.

I'm not technically competent. At least as far as crypto goes. But I can understand things like "shortens the time needed for a brute force attack" quite fine. And many non technical people can do the same. By littering this article with petty personal bullshit, he commits the same sin as cryptocat: failing to inform users.

So what? He's not providing an encryption tool for LGBTQ activists, like Cryptocat claims to do. The bar he needs to meet is lower. Unlike the Cryptocat team, he is not actually obligated to inform Cryptocat's user base; regardless, he's done them a huge service by donating his time to finding vulnerabilities.

I agree.

They say you should write to your audience and this feels like the author did and it’s targeted at an audience - that, well, is not HN.

I wish it had been targeted at HN - as then I would have read it. But after the first couple of sentences I gave up - and waited for people with more fortitude, to read the doc and report back here. (Thanks to everyone who did that.)

It is difficult, to say the least, to conceive of some Platonic ideal of "the content" of a written work without being influenced, positively or negatively, by the style of the writing. Your profession does not make you immune to this.

This is a software engineering discussion. The "content" is links to diffs, plus sentences describing the diffs. If you can code, you can read the diffs and the sentences and reconcile them. If you can't, I concede, you probably can't do much more than talk about the "tone".

While I can't say I've ever looked at the source wouldn't most be able to imply that, even if CryptoCat has issues it's likely better, and easier to use, than other competing projects in this space based on its popularity?

I get there are many others ways to skin this... However the author is at least trying and providing. As a prior comment stated, there are a lot of very good people in the security/crypto/dev realm in this very thread that have provided some awesomely D-bagish feedback.

>> even if CryptoCat has issues it's likely better, and easier to use, than other competing projects in this space based on its popularity?

Easier to use does not imply better in this space. In fact it may be worse than not providing a product at all because it encourages people to think they have a secure channel when in fact it's trivially breakable.

> wouldn't most be able to imply that, even if CryptoCat has issues it's likely better, and easier to use, than other competing projects in this space based on its popularity?

But in this case it's popular because it's easy to use than other systems and not because it's more secure than other systems.

Years of linux kernel, theo de raadt/bsd, and grsec mailing list total rage and various IRC hacker/dev channel slamming of idiocy has hardened my skin and actually makes me thankful they are clear, concise and direct with their criticism instead of phony hand holding and passive aggressiveness. It's a rite of passage to get your ass handed to you by other devs. Some people just don't get it, you have to pummel them with a blast of anger on the mailing list or they'll continue to waste everybody's time with their idiocy.

It's not the end of the world if somebody calls your insecure program a pile of shit and you a nerf herding waste of skin for inflicting said shit upon the world. That's like standard behaviour since the days of Stallman at MIT labs

This. Every time someone gets flamed, you get the same crowd of people going "what an asshole". Except, oh wait, the person got flamed for breaking userspace and not fessing up to it, or providing a false sense of security to people whose lives depend upon it. And in each case, these weren't newbies - they had been warned before and should have known better. It's not just ignorance, it's willful, practically malicious ignorance.

Wake up. This isn't some social media photo-sharing app. This is the literal definition of mission critical software. Being an asshole is the cost to pay to either a) convince incompetent people to stop wasting everyone else's time or b) convince them to become competent.

You know why I don't write and release crypto software? Because I know I'm not qualified to.

This is a really gross attitude, and it's even grosser that you dress it up like some macho rite-of-passage. Call it what it is: A bunch of bitter nerds taking their pent-up anger out on random newbies. It's the fraternity hazing of the tech world, it's bullshit, and it needs to stop. It doesn't need other bitter nerds treating it like it's normal.

Instead of expecting newbies to know they're going to be met with a storm of putrid shit should they speak a syllable out of line, how about we expect our moderators and leaders have some degree of social skill?

I think there's something wrong with you if you get all uppity and bent out of shape over a senior developer calling you out. I actually laugh when Theo De Raadt calls my device driver a flaming bag of of shit, and says my head must be so far up my ass I'm unable to understand the interfaces I'm coding to.

I rewrite it then submit it to somebody else to review before submission, then get a message saying thanks for doing it the proper way, thanks for using the proper channels, and hey you seem OK do you want to come to the invite only hackathon in Germany this year? If I cried about it instead, I'd still be a shitty programmer, and I wouldn't be drinking gigantic beers in Hamburg learning invaluable methods from Henning Brauer how to properly design a program from the ground up with security in mind so you don't have to dispose of everything half way through a major project, wasting everybody else's time because you didn't carefully design. If you think mailing list comments are bad, wait until a room full of developers has to delete six days worth of coding because you screwed up the design with a simple mistake. Wait until your boss finds out you wasted company resources and money for months and had to scrap a project. You will get worse than hurt feelings, you will be fired.

Almost all security/crypto projects are open source. There's no money involved, therefore no corporate sensitivity training or social skills needed. What's needed is secure code to stop governments from rounding up Syrian and Bahraini dissidents and drilling holes into their knees during interrogation because they were duped into trusting cryptocat while planning their democracy protests.

There's something wrong with someone who doesn't want to get treated like shit? You're not helping your case.

> What's needed is secure code to stop governments from rounding up Syrian and Bahraini dissidents and drilling holes into their knees during interrogation because they were duped into trusting cryptocat while planning their democracy protests.

Oh, get over yourself. We all know the vast majority of online cryptographic transmissions are for child pornography and drug purchases. Don't act like Syrian rebels actually use these technologies when most of them don't even have access to a computer, let alone the knowledge of how to use one.

This is seriously the problem. You sit there and think modern cryptography is something other than a rich white guy's game, as though it's nothing but a Righteous Endeavor, so you get to treat other people like shit. The fact that the paragraph before that one is all about how you're getting drunk at some invite-only German hackathon is proof enough.

If Syrian rebels aren't using computers, why would pro-government forces bother to send them malware? See: https://www.eff.org/deeplinks/2012/12/iinternet-back-in-syri...

Your unsupported claim that the "majority of cryptographic transmissions are for child pornography and drug purchases" is insanely wrong.

Given the default use of HTTPS by Google, Hotmail (Live.com), Twitter and most recently Facebook, it is almost certain that the legitimate traffic to/from those sites vastly outnumbers, by several orders of magnitude, whatever encrypted data is sent by folks exchanging child pornography images or buying drugs via silk road.

You don't know what you're talking about.

You are exactly the kind of self absorbed, reckless person crypto projects want to weed out, so it's great you take criticism personally and run off crying. No amount of hand holding or spoon feeding will make you understand it's importance so the tried and true method of removing clueless, poisonous (and in your case dangerous due to your prejudice) time wasters via deflating their ego has been vindicated and you are the proof why it still works. The farther a fragile basketcase like you is kept away from critical protocols the better off humanity is.

I've taken some time away from this discussion, had something to eat, cooled down a bit, and I'd like to say that I'm sorry if I offended you. I didn't realize how abrasive I was being.

You are exactly the kind of programmer I hope I never become. But I would like to thank you for this content! I'm saving this series of comments from you - when I become a CS professor at some small community college, I want to warn my students what they can become if they aren't careful.

I guess you failed to read the part where I was responding to somebody who basically said Syrians are too inferior to use computers, and that cryptography was only used by criminals.

You are exactly the kind of CS professor I'm glad I never had. You failed to read everything and care more about politics than quality of code and safety of users (k now im just trolling, sorry but read the actual replies)

From the guidelines:

> Be civil. Don't say things you wouldn't say in a face to face conversation.

This was uncivil. I doubt you would say that to his face. Comments like this are likely to get flagged, and if it happens enough, your account will get banned. It doesn't matter how good of a programmer you are, or how impolite RMS and Theo are.

https://news.ycombinator.com/item?id=5991882 is the comment I was responding to. Before you freak out realize HN does not show linear comments so the orig was downvoted and it looks like I'm blasting somebody harmless

Please, comments like this are not welcome on HN. Your comment is needlessly derisive and personal.

I understand your need to argue against a certain opinion, but I find it ironic that in a post where you use the term 'a rich white guy's game' you state that most people in Syria don't have access to a computer yet alone the knowledge how to use one. Yet a quick search shows Syria as 55th in the world with regards to Internet users - 5.4 million Internet users, or just over 24% of the population. Couple this with the fact that the government took Syria off of the global Internet, I think that maybe there is a solid use case for Syrians using strong crypto.

In context, Syria has the third lowest internet penetration in the entire Middle East at 22.5%.[0] Considering there are only ~195 countries in the world, being #55 is pretty low. 5.4m is nothing to forget about, of course, but my original point was that most don't have access. The United States, on the other hand, has 78.1% penetration.[1]

Obviously I'm not arguing that Syrians who have access to computers shouldn't get to use crypto, or that there has never been a Syrian who used crypto to aid in protest. But let's not act like crypto's main usage is as righteous as helping a rebellion against an oppressive regime.

[0]: http://www.internetworldstats.com/stats5.htm

[1]: http://www.internetworldstats.com/stats14.htm

> But let's not act like crypto's main usage is as righteous as helping a rebellion against an oppressive regime.

You realise that cryptocat isn't marketing itself as a chat client for paedophiles and drug users, but for activists in oppressive regimes, right?

Here's one example from their blog:

> In working with young and middle-aged professionals in the Middle East region, we have discovered that desktop OTR clients suffer from serious usability issues which are sometimes further exacerbated due to language differences and lack of cultural integration (the technology was frequently described as “foreign”). In one case, an activist who was fully trained to use Pidgin-OTR neglected to do so citing usability difficulties, and as a direct consequence encountered a life-threatening situation at the hands of a national military in the Middle East and North Africa region.

That's why people keep talking about the risk from foreign governments - because the cryptocat hype keeps mentioning governments.

dobbsbob's post was not concentrating on Cryptocat. It was talking about all crypto projects. This is the entire block:

> Almost all security/crypto projects are open source. There's no money involved, therefore no corporate sensitivity training or social skills needed. What's needed is secure code to stop governments from rounding up Syrian and Bahraini dissidents and drilling holes into their knees during interrogation because they were duped into trusting cryptocat while planning their democracy protests.

Ooooo, yea, you lost me when you attacked cryptography instead of sticking to the "spade is a spade" argument against being a dick online.

No, I think people should be treated roughly in the same way they'd expect to be treated in meatspace. I know I don't always configure a server correctly the first time, but if my lead called me a fucking dipshit and a waste of time, I'd go find another job real damned quick.

There's a certain level of banter and sarcasm allowed between friends and known colleagues, but strangers don't have that luxury, or shouldn't.

Releasing an untested crypto product to the general public, and calling it "secure", is incompetent, period.

I would suggest that the author's description of the developer(s) as "incompetent" is somewhat more reasonable than your (implied) description of him/her as a "complete and utter jerk".

Perhaps the author should have narrowed the description to incompetence in crypto and not generalized to "everyone involved", but I don't think it's entirely unreasonable given the apparent magnitude of the problems and the history of the product.

Crypto software that doesn't work potentially puts people at risk.

If a car mechanic only used half the wheel nuts to fasten the rims on your car, would you stay calm and give constructive criticism?

That's a silly argument. There is a great deal of software out there in the world that operates in incredibly important roles. The software running your car, your electricity grid, your bank, your nearest nuclear power plant. Does everyone get free license to be an asshole?

Crypto does not occupy some special branch of importance above and beyond a great deal of software many of us create in our jobs.

I used to work on software in the defence industry on things that could put people at risk. I can't recall any of my colleagues behaving the way people in the crypto community do.

Software in the industries you name is not marketable to the general public. It is written by employees or contractors of the relevant organization and extensively evaluated, tested, and certified (in some cases including by government regulators) before it is permitted to go into production.

The public is not at risk from an amateur who whips up what they think is some great nuclear reactor control code and starts distributing it to everybody.

An amateur marketing cryptographic software to the masses is different and akin to a snake oil salesman. He is dangerous, and no one has the legal authority to stop him.

Do you really think these developers of this are actively trying to sell snake oil?

You know what it looks more like to me? A couple of people are earnestly trying to build a secure communication product. They're not perfect, so they've made mistakes. And for every mistake they've made, there is a legion of toxic people from the crypto community who would rather demonstrate how much smarter they are by pointing out those mistakes in a condescending and unhelpful manner rather than simply being friendly, constructive, and helpful.

Shit, think of the chilling effect this even has on anyone out there who wants to try to build some security/crypto stuff. Myself I wouldn't even dare try - the hysteria of some of the people in this community is just without equal. It's toxic. Pure toxic.

The developers do not know what they are doing. They are not qualified for the task they have taken on. In other words, they are not competent.

They have been told this, both politely and less so. It is no longer about them, it is about helping the public by warning that Cryptocat is dangerous snake oil being actively peddled as secure by incompetent developers who are not to be trusted with people's lives.

This will not be accomplished by merely providing the developers technical critiques. It will only be accomplished by informing the public in terms the public will understand. "Incompetent" is a suitable English word for that purpose.

> Shit, think of the chilling effect this even has on anyone out there who wants to try to build some security/crypto stuff.

Good!

> Myself I wouldn't even dare try

Very good!

I absolutely do hear what you are saying, and I understand your point.

I think where we disagree is in our assessment of the developers. You think that they are incompetent and unqualified for the task. Whereas I think they are likely qualified for the task (I give them the benefit of the doubt) and the crypto community is overreacting in their criticisms of the issues, making minor mistakes seem much graver than they actually are.

I've seen cryptosystems written by brilliant people and thought solid for many years later to be shown to be vulnerable. We still today continue to find issues in critical crypto libraries used around the world. Should we just throw them all out? Declare the authors incompetent? Anybody can make mistakes. And I don't think this making of mistakes invalidates anyones right to fix their mistake and keep pushing forward, as you evidently do.

> I understand your point.

No, you don't, because you continue to make worthless tautological statements like "anyone can make mistakes".

I've designed an airplane. I have no experience in doing so. I have no more than a layman's understanding of aerodynamics. I know nothing of materials science. I've hardly even looked inside any kind of engine. I have heard some fancy words before, though, and I'm sure my quick read of various Wikipedia articles has prepared me.

I'm going to start building these planes and selling them to the public as a great way to travel.

Do you think it is overreacting for an aviation engineer to tell people that my plane is dangerous, just because Boeing sometimes makes mistakes?

If you don't, then you shouldn't have a problem with the public being told that Cryptocat is dangerous.

If you do think it's overreacting, well, as it happens I'm no more competent to deal with insanity than with aeronautics.

His "jerks" point still stands though. You just called him insane because he made a couple of careful wrong assumptions and tried to verify them.

Yes, crypto is serious stuff. Yes, people should be warned about insecure security products. No, you don't have to be a jerk while doing that. See for example jdiez17's reply for what I think would be an effective and persuasive approach.

> You just called him insane

No, I didn't. I called a hypothetical and clearly homicidal person who I doubt was ever participating in this thread insane.

You can try to weasel out of it, but for all intents and purposes you did. Here is how you did it:

1. You compared the situation A to a hypothetical situation B, claiming it to be equivalent or comparable - A <=> B

2. You claim that someone describing the hypothetical situation as an overreacting description of the hypothetical situation - Describe (P, O (B)) => Insane (P)

3. By extension you imply that the person considering the first situation overreacting is also insane - Describe (P, O (A)) => I (P)

    (A <=> B, Describe (P, O (B)) => Insane (P))
      => (Describe (P, O (A)) => Insane (P)

Its probably unintentional as you did attempt to soothe it out (but that didn't help)

Personally I find that using the "understanding" method works much better than the "sootheing" method i.e.

"I understand why you think this way - <explanation of your understanding of the thought process of the other person> but you're wrong because <explanation where thought process goes wrong>"

You're insane. I say that not because you disagree with me, but because you have tried to turn an informal discussion into a math problem, apparently thinking it would be in any way persuasive.

For the record, the final line of my comment was intended to mean, basically, "If you don't think airplanes built my amateurs are dangerous, then we're not going to get anywhere, because I would consider you insane."

Whatever else you got out of it is your own invention.

You're an asshole.

The problem is that your argument is based on false equivalence.

The counterpoint is the classic trade-off between usability and security. I would (as would many) argue that charges against the Cryptocat team of poor cryptographic implementation or indeed knowledge are rational, appropriate and correct.

Charges of unbounded incompetence are irrational, inappropriate and incorrect. The cryptocat team understand usability, UX, general architecture and programming. That does not chime with sweeping statements of incompetence. Where they fail (and you may see this as a fatal flaw, it may surprise you to see that others may not but it appears that others do) is at crypto.

When it comes to real world attacks so far, it seems that Cryptocat is dangerous, but as dangerous as using any other TLS website. I totally accept that there is substantial evidence pointing to a lack of understanding of cryptography, but unbounded claims of incompetence only undermine a cryptographer's position.

There is no trade-off. A product is either secure for its intended purpose, or it is not. CryptoCat is not. An insecure crypto product is a useless crypto product, and no amount of user-friendliness will make it useful.

There is no "charge of unbounded incompetence". The charge of incompetence is concerned with cryptography (though there is evidence of surprisingly basic programming incompetence, too). Their competence at UX or anything else is totally irrelevant.

> A product is either secure for its intended purpose, or it is not.

I'm going to have to respectfully disagree here. All products have bugs and a proportion of those bugs will be security-related. Crypto buys you temporary secrecy, based on the class of crypto used and the technology available to break it. DES was considered fine decades ago because even though it had weaknesses it was considered to provide sufficient protection of assets carrying certain classifications of data for a certain period of time.

AES256 is good for a period of time dependent on the projected capabilities of your perceived adversary and the sensitivity of the data.

> There is no "charge of unbounded incompetence". The charge of incompetence is concerned with cryptography (though there is evidence of surprisingly basic programming incompetence, too). Their competence at UX or anything else is totally irrelevant.

Where do I start with this? First you say there's no unbounded charge then go off charging Cryptocat in two areas. The UK "or anything else" is not totally irrelevant. The whole purpose of Cryptocat is to provide an easy to use chat system that encrypts conversations. Note that easy to use comes before encrypt in the description on the front page of the website. Nowhere on the front page does Cryptocat say that they're secure, because they know they're not.

The point is that writing software that uses cryptography is unlike writing software that, say, uses a Twitter API library. In the latter case you can detect errors quite easily because functionality will be compromised if you make a mistake. This is not so in programs that use cryptography; they tend to work without noticeable problems, but they may be shooting themselves in the foot.

It's all about preventing known mistakes. For example, say a developer uses a One Time Pad encryption scheme in their application and calls it "secure". Surely if we've had any contact with cryptography we know that a OTP with a reused pad is broken and leaks key bytes, and vulnerable to many other types of attack.

These mistakes can be avoided by having proper education in cryptography. I understand cryptocat's developers urge to write it in the same way they've written software the rest of their lives, through trial and error. And that is okay for most software, but not cryptography.

> And that is okay for most software, but not cryptography.

I'd be fine with it if they just slapped big red letters across the top saying "WARNING - EXPERIMENTAL". Why? Because people do need to experiment with topics and that doesn't hurt.

What's upsetting is they're basically claiming their product is on the same level as lots of products that have been heavily tested and verified by groups of people when it's an amateur experiment in the topic.

That might be fine for most kinds of software, but is irresponsible in crypto, embedded safety systems, etc.

I'm not terribly familiar with this, so I don't what know the average toxicity of the feedback they have received is. Maybe it's unhelpful. But there is a reason that their critics are like that. If they are just learning and want nice and supportive criticism, then they need to present their project in that way, not as serious software. If it were a paint program then no one would care. With something like this, the stakes are too high to just give them a pass.

Yes, that's exactly the problem. It's not even relevant that it's crypto software vs paint software, what matters is that it's crypto software being presented as something that should be used by the public.

Nobody cares if you tinker with crypto in your bedroom. You can even toss it on github and ask for feedback on it if you want. Hell, if you want to put the security of your own data at the mercy of the software you write, go right ahead. What you can't get away with is claiming to build a useful crypto product when you don't even have the first clue what that entails.

> Shit, think of the chilling effect this even has on anyone out there who wants to try to build some security/crypto stuff.

As someone who is currently in the process of building some security/crypto stuff it has certainly made me think a lot about releasing it.

Having said that, while I wish the crypto community got out more and interacted with people more often in order to learn how to be less douchey about it, the fact is that I'm now unsure whether releasing my code will be safe. I'm not a pro-cryptographer, just a lowly pentester. Not sure what I'll do now.

> I'm not a pro-cryptographer, just a lowly pentester. Not sure what I'll do now.f

Release it with a big "WARNING - EXPERIMENTAL" at the top and don't claim it's a secure solution for end-users?

That seems to be what the complaint is about, not that people are experimenting in crypto.

>is it possible for you to give constructive criticism for a project without calling people "incompetent"?

You're too focused on the fact that it's an insult. Even though it's rude, there are circumstances where literal incompetence should be pointed out, like software that can be life-or-death. This commit right here https://github.com/cryptocat/cryptocat/commit/7fe56f0ad6a1b4... is either someone coding without paying attention / severely sleep deprived / drunk, or it's someone who is incompetent. And the first option is only a polite way of saying they were 'temporarily incompetent at coding while working on this project'. And that provides no solace to someone who gets hurt.

In short, it is a fact that the cryptography system here was handled in an incompetent way, beyond that of normal implementation errors. Blatantly stating this fact is an effective way of getting people away from the danger.

These "serious cryptographers" really never seem to deliver usable solutions themselves - and therefore the average users use software like cryptocat, or they don't use software at all. Cryptocat managed to bring cryptography to the masses, and usually no "serious cryptographers" have managed with the same thing.

> These "serious cryptographers" really never seem to deliver usable solutions

When people say a crypto product is "broken" they have several different meanings.

Ignoring one-time-pads every crypto system can be, in theory, broken by brute force. The time taken to do the brute forcing might be billions of years, but in theory it's possible. This is the edge of what we currently know about math.

Anything that can be cracked quicker than brute forcing is regarded as broken, even if that attack is still not feasible. A crypto-system that takes 100 billion billion years to brute force, but 10 billion billion years with some other attack is still regarded as broken. At that point people would tend to stop working on that algorithm and move onto something else, or they'd try to improve that crack and see if it can be combined to make something feasible. Don't forget that the bad guys keep their secrets secret. You will not know if they can break your product.

This can be frustrating for people developing software. "But wait, no-one can actually use that flaw to break the crypto, so it's still secure, right?" Well, not really.

And then that algorithm, the math, has to be turned into code. This is hard because you need to know what the language is doing, what the compiler is doing, what the hardware is doing. Any flaws in the algorithm could be magnified by implementation as software.

Just as an example of people keeping secrets: Diffie and Hellman invented a practical key exchange in 1976; it had been independently invented -and kept secret- in 1974 by Ellis, Cocks, and Williamson at GCHQ. GCHQ made this public in 1997. Even though key exchange was in use by very many people all over the world it was kept secret for about 25 years.

Clifford Cocks invented RSA a few years before Rivest Shamir and Adelman did. (Not only did he do it before them, but because he wasn't in the building he did it in his head. (He wasn't allowed to write anything down.) He had to go to sleep and hope that he still remembered it in the morning.) And, again, even though RSA was in use daily by very many people GCHQ still kept it secret until 1997, about 25 years.

> Cryptocat managed to bring cryptography to the masses

No, it really didn't. CryptoCat gave people a false sense of security. CryptoCat gave people the illusion of secrecy. Cryptocat didn't give people a usable safe product.

> usually no "serious cryptographers" have managed with the same thing.

The cryptocat developers would do far more good by using their knowledge to make existing tested products easier to use.

You appear to be ignoring PGP / GPG; SSL, etc, which are used by many people.

On the one hand, you're understating the case: Cryptocat has often been breakable within days to attackers with very modest resources.

On the other hand, you're missing the point. If crypto software is going to be used, it has to be usable --- and if the setup instructions are obscure, it won't get installed. If the procedures for using it are arcane, it won't get used.

That's what CryptoCat is getting right: the UX. The unsafe internals make that dangerous, but it's still worth studying.

> If crypto software is going to be used, it has to be usable

If crypto software is going to be labeled crypto software, it has to be secure. Otherwise it's just software.

Yes, I agree with you. Crypto software must be usable, otherwise it will never catch on. The average person doesn't care about their security, and thus the smallest compromise in UX for improved security will lose you large amounts of users. However, if you design something fantastically usable and pretty and call it "secure software" doesn't make it so.

I think that this whole argument stems from people misunderstanding the term "secure". Cryptographers, when talking about "security", consider it more or less binary: "Secure" is something for which no attack (even theoretical) exists. Laymen mean "my spouse/neighbour/boss/ISP/government can't read my messages".

In the former meaning, CryptoCat is entirely broken and useless. In the latter meaning, CryptoCat is on the low end of the "security" scale. It can be used for hiding things from your neighbour, assuming your neighbour doesn't have lots of technical knowledge. If it were advertised as such, I don't think anyone would be lambasting them now, but it was advertised as "cryptographer" secure when it's probably not even "layman" secure.

Having "cryptographer" security means you have to make UX concessions. You just can't have both. Saying "but CryptoCat has both great UX and great security" is false, because it doesn't. It has great UX at the expense of security, and they should probably make people aware of this more.

All this having been said, I do recognize that sometimes you need to sacrifice security to get better UX (see iMessage), and that is perfectly reasonable, and probably necessary. I would love to see more semi-secure software with great UX that people will use more than the completely insecure software now, and I really hope CryptoCat achieves its goal of security and ease of use and becomes more popular.

If you're not willing to deal with "obscure" setup instructions, you probably don't need strong crypto.

If you do need strong crypto, i.e. your life and/or autonomy depend on it, you will hopefully be willing to take ten minutes of your time to install a properly written piece of software.

Cryptocat is cargo-cult cryptography. People think cryptography is cool, so they use cryptocat. They don't actually need the strong encryption it would [yet has never actually been able to] provide, but they think their two-bit marijuana transaction or liquor-soaked 19th birthday celebration is worthy of strong encryption, but not of the actual effort required to use it. So they use cryptocat.

These people who use cryptocat are stupid. The popularity of cryptocat just increases the risk that someone who actually needs security will use it, and could very likely experience severe injury as a result. That's not okay; it's not relevant whether someone is "being nice" or "learning" or whatever, it needs to not happen. Cryptocat is bad through and through, from conception to implementation.

Maybe if the tagline was "Cryptocat provides encrypted communication that probably isn't secure", people wouldn't pull out their hair.

From a recent interview with Brewster Kahle[1]:

  Q: Do you encrypt all your own email, as a result
     of this stuff?

  A: No, that's really hard.

Brewster is the founder of the Internet Archive; the subject of the interview was an NSL that he fought off in court. He's also a pretty smart techie in his own right. But I suppose you could still argue that he's lazy, stupid, or not in need of strong crypto.

Or maybe, just maybe, the available tools for the purpose take a lot more than ten minutes to install and configure well enough for even an intelligent and technically skilled user to have any confidence that they've done it correctly.

People can't install good crypto tools in ten minutes. Not even people like Brewster. And if you're making one of those tools, and you want it to be anything more than a research toy, that's your problem, not theirs.

[1] http://www.newyorker.com/online/blogs/elements/2013/06/what-... (If you want to see the part I quoted, scroll right to the end.)

People don't need cryptography everywhere. Where they need it, they should be willing to spend ten minutes. Where they don't need it, such as coupon mailing lists, they go with the flow.

The only way to have 100% encrypted email is to avoid a massive number of services. This is something to be done only when it actually provides safety.

Basically you're arguing a point (100% crypto) that is completely different from the post you're replying to (crypto on critical conversations).

People need cryptography everywhere. Otherwise the fact that cryptography is being used leaks information.

Wow, the amount of bullshit in this comment is mind blowing.

So only a hardcore developer who can setup mutt in 2 minutes, customizes Emacs in his sleep, write code in Assembler needs cryptography? Anyone who wants an easier UI to handle crypto doesn't deserve to use it, right? The rest of the people are just riding the bandwagon because they think it's cool and don't really have any secrets?

You go so far as to call all of them stupid.

Just who in the world do you think you are?

I don't know what you're replying to but it's certainly not the comment you posted this on.

> You appear to be ignoring PGP / GPG; SSL, etc, which are used by many people.

PGP / GPG is a joke in terms of usability - no average Joe uses it. Even my techy friends find it too complicated to use. I myself prefer signing messages with bitcoin addresses instead of GPG, jsut because it is so much simpler.

SSL works, that's true.

PGP is widely used enough that the GPGMail team keeps up with Apple Mail.app development; Apple breaks Mail.app compatibility with every release. PGP is also a standard tool in my field; we use it every day.

I suspect that most of the people who say PGP is too hard to use simply don't encrypt messages that often (or, when they first learned PGP, weren't routinely encrypting messages). They're complaining in essence that PGP isn't automatic and frictionless.

I'm in agreement here. I've set up PGP email, and S/MIME, and it isn't really that hard to use once it's in place. Mail clients that support it offer easily-invokable "sign" and "encrypt and sign" options. But when few people you email use it, you yourself end up using it rarely, and then you get a new computer, lose your keys, and you can't even revoke them because you didn't keep a backup. So you have to do it all over again. Then it seems "difficult to use" because you have to stop and read some man pages again.

> They're complaining in essence that PGP isn't automatic and frictionless.

Exactly. That was cryptocat was, UX-wise. Automatic and frictionless. I believe if crypto can be built in that fashion, then it will really effect the world. In expert fields, GPG is used, but no average Joe uses it.

One of the main reasons that Cryptocat is able to celebrate their high usability is because they didn't even attempt to tackle the most difficult usability problems in a system for secure communication. There is no such thing in Cryptocat as persistently stored private identity keys, so every time you use Cryptocat new identity keys are generated which you are then expected to manually verify in some out-of-band way (i.e. make a phone call to every other person in a Cryptocat chat room and swap hex encoded fingerprints). If you don't manually verify the keys of every other person you talk to every single time you use Cryptocat then you might judge Cryptocat to be 'usable' and maybe even more usable than other similar software, but the usability trade off is that you and even other people you communicate with who have otherwise verified keys correctly will be vulnerable to having your conversations intercepted and decrypted by an active attacker.

As far as I can tell without installing it, they don't even support the Socialist Millionaire's Protocol - a mutual authentication technique that OTR uses by default exactly because the developers discovered verifying keys out-of-band isn't practical and most people won't bother. Using Cryptocat in a way that's actually secure is harder than doing the same thing with OTR.

This is better off not done than done improperly.

"I managed to produce shit while you refused to produce shit!" is not something to be proud of.

I somewhat disagree. Even some protection is better than no protection at all. Then if cryptocat was actually harmful to the users or less secure than traditional IM (which I fail to see), it would be different case.

There seems to be strong "do not do" culture in these circles. I dislike this. Doing is always good. Then again, criticism is also important.

I disagree vehemently. It is much better _not_ to create software that gives you the false impression of privacy, than to create it. If I am aware that my IM client is insecure, I'll behave differently than if I mistakenly think my IM client is secure. Specifically with crypto, I may be endangering myself if I mistakenly hold this belief.

In essentially everywhere else in CS, people are encouraged to go nuts and experiment. The barrier for entry is null. Anyone with access to a computer can make whatever he wants. Not here. In crypto, it becomes more serious, because people easily depend on it. If it is a toy, _clearly mark it as such_, and never give the false impression of security. Toys are fine. Endangering people is not.

Isn't the argument more that the people doing the software for end users shouldn't be implementing the cryptography for that software themselves and should instead built it on top of libraries that make all of the difficult decisions? Libraries like NACL are good for this, you don't specify cipher modes or anything like that you just say something closer to encrypt(data,key);

Of course you can still fuck up with just that, but it reduces the requirements for the programmer to understand deep cryptography and focus on designing their application for their users.

Also the advertised level of security will alter how the users use the software.

Say for example you have a bunch of confidential documents, you are currently storing them in a bomb proof safe and you never digitize them because you are concerned about security even though digital copies would be useful.

Along comes software that promises to be just as secure as your safe (or more secure). So you jump on it and start using it. Now if that software is not as secure as advertised then you are probably in a worse position security wise than you were before, and you don't even know until somebody steals your documents.

> Doing is always good.

Until the government cracks the crypto used for your messages and locks you up for life.

And look what happened. People thought they had a secure channel but they didn't.

>> Cryptocat managed to bring cryptography to the masses

Not really! Obfuscation perhaps.

It's a matter of consequences. Badly built crypto endangers the people who can least afford it (ROT13 is probably enough to secure your comms, but you aren't in Syria).

I've being using double ROT13 for most of my transmissions, but I'm paranoid.

> Question for those in this space: is it possible for you to give constructive criticism for a project without calling people "incompetent"?

Sometimes 'you're incompetent at X' is constructive criticism.

Someone who doesn't know how to accelerate a car is an incompetent driver. That doesn't make him a bad person; it doesn't make him worthless (as an example, neither Newton nor Plato knew how to accelerate a car); it does, however, make him incompetent at driving.

One should understand one's weaknesses. I know lots about some things, a bit about others and nothing about yet others. As an example, I know absolutely nothing about assembly line engineering; I am an incompetent assembly line engineer—and thus I do not produce assembly-line-engineering products.

Some people build things, other people break things. The people that break things don't understand what it's like to build something, so tend to come across as jerks to people that build things for a living.

This builders/breakers thing drives me nuts.

I've done both throughout my career. I've lead and shipped very large projects, and I've spent years breaking. To be a good breaker, you have to be a good builder; you need to be able to intuit what someone building the target was trying to do, then think a step ahead of them and predict their mistakes. To do the job professionally, you need to be capable of doing that in a wide variety of environments, too. Most "builders" are Rails devs, or Java devs, or C devs. Good breakers have to be all of those.

There are a lot of "breakers" out there who repeat a cookbook of well-known techniques to find lots of instances of the same bug. But if you look at the very best in the field, to a one, they're all top-caliber builders as well.

I also think that to be a good builder, you have to be a good breaker — which is most especially the case with crypto. Of course, you already know this, thus your competition, but you didn't bother to say it.

To be a good crypto-builder, I think you need to be a good breaker. I don't think that holds for other kinds of building.

I meant for software in general; I guess you don't agree? My reasoning is that you have to think systematically about what can go wrong in order to be a good programmer, which is a skill that you can only acquire by finding bugs in programs.

No, I don't agree. I think in many cases it's possible to code defensively without having what my partner Dave calls "killer instinct", the X-factor for being good at finding vulnerabilities in systems. Also, good breakers have to deal with arbitrary technologies; a good developer can specialize, substituting experience and depth of knowledge for intuitive feel.

I agree there are more jerks in the crypto community than elsewhere, but in this instance it is justified, crypto is serious and if you are gonna claim to be secure and all that - peoples lives can hang on it - then make sure you get the basics right.

I mean come on, Im not a crypto-programmer, but this, Cryptocat.random()*123456789 !?

Actually it's 1234567890. Which is even worse.

Cryptocat is written by people who don't fully understand how their program works. They don't fully understand how the platform on which their program is built works. They may be smart, but they need to sit down and learn things.

This is the most important take-away. They're not just incompetent at crypto, they're incompetent at programming.

And they don't understand that they don't understand programming.

Fascinating. For those of us not versed in cryptography, can anyone elaborate on why

  foo.random() * 123456789

is insecure, and why it is made moreso with the added zero?

Is this what the author describes, using floating point to generate random numbers (where he cites this code)? I am wondering about the theory behind this.

I'm not a crypto guy, so this is just my interpretation of part of the issue. Anything that should be random that introduces easily predictable could be a problem.

With that in mind, what we've got is a sixteen digit floating point number (their random number generator works in decimal, not binary) multiplied by a very specific number.

This is then turned back into a string, so I'm going to assume it's ascii (I'm sure a similar problem would be if this was in utf-8).

Now, ascii representations of numbers means that each digit is converted to hex 30 to 39

So, what we're passing into the MD5 sum is 3-3-3-3-3-3-3-3... with one of them 2E because of the decimal place.

The first digit cannot be a 0 or the decimal place, so it's going to be 31-39 to start with. This first digit is also significantly more likely to be a 1 than anything else, here's a random sample of the first digit counts:

    Counter(str(get_uniform()*1234567890)[0] for i in range(100000))

Counter({'1': 28042, '2': 9208, '5': 9068, '3': 9053, '7': 9045, '9': 8987, '8': 8972, '4': 8829, '6': 8796})

How about the second digit? Still biased:

Counter({'0': 16368, '1': 16227, '2': 10942, '6': 8141, '5': 8124, '3': 8118, '4': 8067, '9': 8012, '7': 8006, '8': 7995})

Sixth digit? More normalised but the decimal pace is not really that common here.

Counter({'8': 10235, '2': 10166, '4': 10114, '9': 10032, '6': 10007, '3': 9969, '7': 9911, '0': 9883, '1': 9872, '5': 9804, '.': 7})

Ninth digit? Now we're getting flatter

Counter({'2': 9418, '1': 9406, '9': 9279, '3': 9269, '0': 9258, '4': 9248, '7': 9228, '5': 9227, '8': 9215, '6': 9208, '.': 7244})

Where do we see the decimal place?

    Counter(str(get_uniform()*1234567890).find(".") for i in range(100000))

Counter({9: 72887, 10: 18823, 8: 7460, 7: 740, 6: 81, 5: 7, 4: 2})

Fundamentally, we've taken a random series of bytes, turned them into a very regular pattern (3-3-3...) and added a significant bias towards particular digits in particular places.

How about the length?

Counter({13: 90052, 12: 9150, 11: 792, 10: 6})

We've got something with a very predictable structure, in short.

Multiplying by 10 I don't think makes it any less secure, it's just silly. All you do is move the decimal place over by one, although to be fair at least it doesn't add any more bias.

That line isn't used in anything sensitive.

The JsDoc for the function where

  var cnonce = MD5.hexdigest(""
      + (Cryptocat.random() * 1234567890));

occurs is

  /** PrivateFunction: _sasl_challenge1_cb
   *  _Private_ handler for DIGEST-MD5 SASL authentication.
   *
   *  Parameters:
   *    (XMLElement) elem - The challenge stanza.
   *
   *  Returns:
   *    false to remove the handler.
   */

which is only called by

  /** PrivateFunction: _connect_cb
   *  _Private_ handler for initial connection request.
   *
   *  This handler is used to process the initial connection request
   *  response from the BOSH server. It is used to set up authentication
   *  handlers and start the authentication process.
   *
   *  SASL authentication will be attempted if available, otherwise
   *  the code will fall back to legacy authentication.
   *
   *  Parameters:
   *    (Strophe.Request) req - The current request.
   */

Now, I might be nuts, but unless the documentation is incorrect, this appears to be a "sensitive" application.

To make sure I'm not just going on innuendo, I read into SASL authentication a bit ... seems `cnonce' is pretty important:

  A unique, encoded value that is generated by the client 
  for each challenge response, and that is used to avoid
  chosen plaintext attacks, provides some message integrity
  protection, and provides mutual authentication. This
  authentication is provided mutually in that the server
  proves it knows the user’s secret information and not in
  that the server proves its identity. The nonce must be
  specified if a QOP directive is sent.

Am I dead wrong, or are you hand-waving to defend your product?

I notice they've continued their defense in an update to the blog post:

"One more small note: Much has been said about a line of code in our XMPP library that supposedly is a sign of bad practice — this line is not used for anything security-sensitive. It is not a security weakness. It came as part of the third-party XMPP library that Cryptocat uses."

What sort of reaction would you feel is appropriate when someone builds a bridge incorrectly, and it collapses? "Oh hey, that's too bad, good try though!"? When someone does something horrible wrong and demonstrates that they are incompetent, that needs to be said. Everyone needs to know "this person is incompetent, do not use their work".

Because this is more true in crypto than anywhere else.

"There are horrible people who, instead of solving a problem, tangle it up and make it harder to solve for anyone who wants to deal with it. Whoever does not know how to hit the nail on the head should be asked not to hit it at all." - Friedrich Nietzsche