Seriously, if there any domain in CS more full of these types of personalities I can't think of it.
Cryptocat had many such bits of constructive criticism. They chose to ignore it. They continued to promote their broken product as secure.
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.
And his to tell you to fuck off and ignore you from then on if you did.
"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
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.
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.
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.
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.
(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.)
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
Sometimes you just have to hit the thing with a bat to get attention.
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.)
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.
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.
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.
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
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.
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 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.
> 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.
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.
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.
> 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.
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.
> 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.
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)
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.
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.
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?
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.
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.
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.
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 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.
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.
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.
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.
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.
No, I didn't. I called a hypothetical and clearly homicidal person who I doubt was ever participating in this thread insane.
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)
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>"
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.
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 "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.
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.
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.
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.
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.
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.
"I managed to produce shit while you refused to produce shit!" is not something to be proud of.
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.
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.
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.
Until the government cracks the crypto used for your messages and locks you up for life.
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 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 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.
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?
Q: Do you encrypt all your own email, as a result
of this stuff?
A: No, that's really hard.
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.)
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).
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.
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.
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.
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.
Not really! Obfuscation perhaps.
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.
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 mean come on, Im not a crypto-programmer, but this, Cryptocat.random()*123456789 !?
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.
And they don't understand that they don't understand programming.
foo.random() * 123456789
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.
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))
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))
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.
var cnonce = MD5.hexdigest(""
+ (Cryptocat.random() * 1234567890));
/** PrivateFunction: _sasl_challenge1_cb
* _Private_ handler for DIGEST-MD5 SASL authentication.
*
* Parameters:
* (XMLElement) elem - The challenge stanza.
*
* Returns:
* false to remove the handler.
*/
/** 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.
*/
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.
"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."
"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