DecryptoCat | Hacker News Reader

DecryptoCat

tobtu.com

516 pointsthejosh276 comments

The hardest part of this to read for me isn't the vulnerability, but rather:

     2011 Passwords: BPKDF2-HMAC-SHA1 with 1000 iterations
     2011 Passwords: BPKDF2-HMAC-SHA1 with 600 iterations
     2011 768 bit RSA
     2011 512 bit RSA
     2011 600 bit RSA
     2011 1280 bit RSA
     2011 1024 bit RSA
     2011 1048 bit RSA
     2011 1536/1152 bit RSA (Chrome/other)
     2011 1536/1024 bit RSA (Chrome/other)
     2011 "3072 bit" D-H	
     2011 "3072 bit" D-H	
     2011 "4096 bit" D-H	
     2012 ECC Curve25519

(edited for clarity)

Major red flag. The difference between symmetric-keyed password-based encryption, RSA, Diffie-Hellman and ECC (presuming ECDH?) isn't minor; it isn't a feature-level distinction. These are radically different designs. I'm not sure I've ever seen a system as popular as this so quickly take a tour of so much of cryptography. How could anyone have any kind of grip on the safety of a system that fundamentally changes its crypto constructions so often?

A lesson here: if you have to implement cryptography --- and you and your users would be much better off if you didn't, and rather relied on a standard implementation like PGP --- do one thing and stick with it. Think of it like being a little kid lost in a shopping mall. Don't make it harder to get found.

What about NACL? It seems more flexible that PGP but still provides a fairly high level of abstraction. Not sure what is a good library for doing PBKDF2 or similar though.

Probably the best KDF you'll get right now is scrypt[1]. NaCl did not see common adoption because until a relatively recent distribution called Sodium[2], it was not portable. And I mean really, not portable. Like, just to give an example, suppose you want to use NaCl in Node.js, which is pretty good about accepting C/C++ modules. You have two options today: one doesn't work on a 64-bit system[3] and one isn't C, it's JS which was transpiled with Emscripten[4]. I mean, don't get me wrong: the fact that we can now do this in pure JS via Emscripten is amazing, but yeah, NaCl was not universally buildable and therefore was not reliably deployable, and nobody really wanted to fix it until Sodium came along.

[1] https://www.tarsnap.com/scrypt.html

[2] https://github.com/jedisct1/libsodium

[3] https://github.com/thejh/node-nacl

[4] https://github.com/tonyg/js-nacl

scrypt is great if you want to store passwords, but not really helpful in other contexts. Nacl is a complete cryptosystem; think of it as a stronger, more modern, library-ized version of GPG.

Don't use a JS translation of Nacl. Nacl goes to pains to ensure that it doesn't expose side channels; no Javascript implementation can make the claims Nacl makes.

scrypt is great if you want to store passwords, but not really helpful in other contexts

I'd say that scrypt is most useful when generating derived keys for file encryption. For login passwords you probably want a fairly low work factor (say, 0.1 seconds), both to make logins responsive and to make it harder for an attacker to use login attempts to DoS you; but for file encryption you can easily spend 5 seconds or more.

Using a KDF with a decent encryption algorithm (ie. AES) doesn't really help much, (it doesn't make it worse, either). Considering you'll be using something like AES-CBC, you will already have a salt/IV as part of the encryption process, and you are safe against people finding your key from multiple ciphertexts.

So there are no real problems that adding scrypt solves, besides "making it slower".

  for P in password candidates do:
    compute K = KDF(P, salt);
    M_0 = decrypt(block #0 of cyphertext, K, IV);
    if M_0 looks like plaintext:
      store P for future analysis
    fi
  od

Encryption using a passphrase needs a good KDF just as much as login password hashing does.

I may have been a bit rash to say, "there are no problems that adding scrypt solves," but whether you need a KDF for encryption is more of a practical problem. There are many circumstances where it makes sense, but I'd consider that a part of your password policy. In general, encryption is secure by itself, and I'd avoid adding unneeded steps.

As for password hashing, that is a very different application than deriving a key for encryption. You are storing the result (usually in a database), and in the case there is a leak, hoping that no one can brute-force the passwords. This is when you start the process of changing salts and work values (in the case of scrypt), and getting everyone to change their password. Using a KDF in this case makes a lot of sense.

To take a concrete example of encryption using a key derived from a passphrase: SSH keys. OpenSSH uses MD5 as a key derivation function, so if someone steals a passphrased SSH key file you'd better hope that the passphrase is very strong.

Using a KDF such as scrypt for that example does make a lot of sense, and after considering some others, I must admit, makes a lot of sense for most circumstances.

I also had a quick look at the tarsnap source code, and I see you do exactly that for the passphrased keyfile.

Yes -- in fact, that's why I invented scrypt, because I was adding passphrase encryption to tarsnap key files and wanted to do it as securely as possible.

Note that it's possible to convert your keys to use PBKDF2: http://martin.kleppmann.com/2013/05/24/improving-security-of...

Couldn't you use the output of scrypt as a key for a symmetric cipher?

You could if you were going to design your own cryptosystem, but not doing that is the point of this subthread.

Nacl still leaves you with the necessity to manage your keys, whether you're deriving them from passphrases (in which case you should use a KDF, and scrypt should work) or storing them.

Ok, that's true; if you use the secretbox APIs and aren't using randomized keys, you'd want something like scrypt. You're right.

Even if you're using the non-secretbox APIs like crypto_box.

At what point aren't you designing your own cryptosystem? Even if you use NaCl you must store your keys, determine when and when not to encrypt, decide how to generate nonces, pick between symmetric and asymmetric ciphers. I understand strongly that you should work with as large a black box as you can afford, but it becomes increasingly grey as you move toward operational stuff over "obvious" crypto stuff.

Scrypt is a Key Derivation Function, as well as a password hash, so it has a few uses. If you want to take many parameters, and make a random key, it will work well. If you want to record a secret value (ie. password database), it works incredibly well. If you want to use it on a password for something like AES-CBC, then you probably don't need it, since AES-CBC is already secure.

Most encryption algorithms are already designed to take a users key, and apply them in a secure fashion. Unless you aren't using such an algorithm, you should trust the crypto primitives that have already been built for you. Of course, many people will have special use cases, but they should already know what they are.

I really can't recommend skipping a KDF for encryption on the basis that AES-CBC is "already secure." Use of a strong KDF has a direct bearing on the compute time required for an attacker to brute force the key.

I think he means that your AES-CBC should already be doing key derivation from the user supplied password.

> Don't use a JS translation of Nacl. Nacl goes to pains to ensure that it doesn't expose side channels; no Javascript implementation can make the claims Nacl makes.

What specifically are the side channels you see that Javascript exposes?

Lack of evidence for side channels is not good enough. You deserve an encryption system that's carefully constructed to prevent all known forms of leakage.

The usual side channel is timing. Some numeric operations take longer than others depending on the key, and an adversary can measure these to narrow down possible keys: https://en.wikipedia.org/wiki/Timing_attack

Javascript engines have complicated numeric type conversion rules, together with single-entry type caches that seem very likely to leak.

> Lack of evidence for side channels is not good enough. You deserve an encryption system that's carefully constructed to prevent all known forms of leakage.

While I agree that absence of evidence is not evidence of absence I have to take you up on that second statement. I'd say you deserve an encryption that's carefully constructed to provide appropriate protection against a threat model matching the use case.

A case in point would be MD5. MD5 is vulnerable to collisions, does that mean that we should use MD5 for passwords? Of course not but because of moore's law and scrypt, not because of collisions. Should we use MD5 for hashing content? For anything forensic, no. For situations where collisions aren't important, perhaps yes.

Many software crypto systems are susceptible to direct leakage through RAM, that doesn't mean that we shouldn't use them.

Be aware that we don't know how bad browser side channels are going to be. People were surprised when Boneh and his team showed RSA key extraction over an IP network using just timing a decade or so ago; people will be surprised when someone pulls a key out of a browser by having them visit a spoofed site, too.

Why assume the risk?

As someone who's done a lot of non-crypto side channel stuff (particularly around signal modulation for exfil) I'm of the view that side channel stuff happens and it's not exclusive to crypto. State generally leaks. It's a matter of having something resilient enough for the use case not to matter.

I see where you're coming from with it but to take your point I can pull keys out of a memory dump, who cares which process it comes from? In this case does it mean we should all wait for a perfect OS that scrubs memory on everything properly and encrypts swap?

That's not to say you're wrong, I think you have some valid points but in every other domain it appears there's a good enough level and when I at least encounter UK government crypto we're told it's the same. The thing about the cryptocat thing is that there are questions about transparency that are valid (and I've seen your conversation on twitter and agree with some of your points), but I'm trying to avoid falling into that situation.

JavaScript runs inside a VM. It is impossible to avoid side-channel attacks without direct access to the CPU.

I like Nacl. I also like Keyczar. I would be very worried about a project that oscillated from PGP to Nacl to Keyczar, though.

Cryptography is hard.

Software is full of bugs. Most of those bugs can be left without too much impact on the users. See any bug tracker for bugs which have been left for years.

With cryptographic software a small, subtle, hard to find bug could render the product pointless; could make the cryptography trivially easy to crack.

Smart people and many eyes make mistakes with crypto. See, for example, the random number generator bug in Debian.

People learn by doing. They read a book or two, they read some source code, and then they implement their own version. This is especially dangerous for crypto because these people might not understand the bugs they've created. It's fine to release your code snippets as "proof of concept" or "demonstrations" so long as you give warnings that these are not to be used in real life.

Cryptocat did not give those warnings. Cryptocat said it was secure. They ignored the advice from many people. They even took the ultimate snakeoil step of running a competition to crack their software. Except the badguys are not going to enter your competition; the badguys either already know how to break the crypto or they use all the publicly available entries as help.

People shouldn't have been waiting for something like DecryptoCat before they stopped using CryptoCat.

It's particularly frustrating because people risk death or torture or long term imprisonment in some parts of the world, and they need strong crypto.

(https://www.schneier.com/blog/archives/2008/05/random_number...)

> Cryptocat did not give those warnings. Cryptocat said it was secure. They ignored the advice from many people.

Yeah, I saw a bunch of people I respect saying things like "Nadim[1] is a good kid and he's learning, give him the benefit of the doubt" when I suggested that nobody use CryptoCat.

But...

> It's particularly frustrating because people risk death or torture or long term imprisonment in some parts of the world, and they need strong crypto.

We have an obligation to the safety of others (especially in light of the fact that we know all the transmitted cyphertext is being stored) to denounce poor crypto implementations whenever and wherever we see them, regardless of the implementor.

[1] https://en.wikipedia.org/wiki/Nadim_Kobeissi

>> Cryptography is hard.

>> Smart people and many eyes make mistakes

These things are true BUT the article says this - "They seem to not understand simple programming concepts such as a byte vs a decimal digit character" There seem to be some serious problems with the aptitude of the developers if that really is the case.

I don't know what he usually says, because I don't follow him, but I remember hearing him in a speech say that "you shouldn't use Cryptocat if your life depends on it" or something like that.

I've just checked, and he seems to give that warning on the site, although below the fold:

"Cryptocat is not a magic bullet. You should never trust any piece of software with your life, and Cryptocat is no exception"

https://crypto.cat/

To me that disclaimer sounds rather like those disclaimers on dietary supplements. They have to write that the supplement isn't medicine and might not work but the whole product packaging and marketing implies that it will work just like medicine.

"Yeah, yeah, crypto cat is software and no software is perfect. But ... that's just a stupid disclaimer. Use cryptocat anyways, guys."

Elsewhere: "Cryptocat Passes Security Audit With Flying Colors". "It’s no secret that there was a lot of celebration here at Cryptocat over these results. Completely passing an audit with zero weaknesses or vulnerabilities is a rare event even for very high-profile software. This is perhaps Cryptocat’s greatest achievement yet."

Would it pass a Matasano audit? ;)

I have no idea. We wouldn't have assessed it. A single person/week to assess a whole multiparty cryptosystem? Absurd.

https://blog.crypto.cat/2012/12/lebanese-government-asking-f...

vvvvvv quote begins vvvvvv

(هذا المقال مترجم إلى اللغة العربية فالأسفل) – Arabic Translation follows

We’d like to talk about today’s news in Lebanon concerning the Lebanese Internal Security Forces demanding access to Facebook passwords from the Minister of Telecommunications. This notion is unacceptable, and the Cryptocat Project is moving forward on proposing solutions for Lebanese people on how to protect themselves against this sort of seizure, should it happen.

What Cryptocat can do for you

We would like to suggest to Lebanese citizens to use Cryptocat instead of Facebook chat to communicate. You can download Cryptocat here (it’s available in Arabic) — to the best of our ability, we have attempted to make Cryptocat a private, useful and open platform for easy to use IM. We want to offer it as an alternative in this time of potential legislative abuse. Cryptocat cannot promise you perfect privacy — at best, we are promising a slightly better alternative to Facebook chat.

What Cryptocat can’t do for you

Here we must repeat the warning from our project website: Cryptocat is not yet ready to be used in extreme situations. Don’t rely on Cryptocat if your life is threatened — it’s experimental software. But that doesn’t mean that Cryptocat can’t provide reliable, useful privacy for many individuals. Use Cryptocat if you are in Lebanon and want to talk with your friends without the notion of a government request for Facebook passwords hanging over your head.

I am in Beirut

I (Nadim, Cryptocat developer) am currently in Beirut. You can reach me at nadim@crypto.cat — send me an email if you have any questions on how you or your community can protect your digital privacy, please come to my workshop at the Lamba Labs hackerspace tomorrow.

^^^^^^ end of quote ^^^^^^

Well, that's good. I can't edit my comment, so I accept here that I'm wrong about that.

It's somewhat undermined by the statement directly above it:

"LGBTQ activists use Cryptocat to keep private matters private. Journalists use Cryptocat to keep their stories and research confidential. Cryptocat is made for everyone."

which suggests that it is secure and reliable enough to be used in sensitive situations.

Outings in large parts of the world - even in the first world can be life threatening.

This contradicts directly with don't use it if your life depends on it.

> With cryptographic software a small, subtle, hard to find bug could render the product pointless

Exactly, cryptography is science and not engineering. That's why the cryptocat response makes them seem even worse to me.

They are clearly still approaching the problem as if they can iterate on it and incrementally improve things. That's the wrong approach when things are so much closer to a binary right/wrong situation than in other types of software development.

> Cryptocat did not give those warnings. Cryptocat said it was secure.

This is just not true. There are ample warnings on the front page of the website as well as on the login screen on the app. Cryptocat has never said it's completely secure.

The warnings, hidden away behind a link (unlike the stuff about journalists and LGBTQ activists)

> What Cryptocat Doesn't Do

> While Cryptocat aims to offer strongly encrypted, private Instant Messaging, it's important to note what Cryptocat does not protect you against:

> Cryptocat does not anonymize you: While your communications are encrypted, your identity can still be traced since Cryptocat does not mask your IP address. For anonymization, we highly recommend using Tor.

> Cryptocat does not protect against key loggers: Your messages are encrypted as they go through the wire, but that doesn't mean that your keyboard is necessarily safe. Cryptocat does not protect against hardware or software key loggers which might be snooping on your keyboard strokes and sending them to an undesired third party.

> Cryptocat does not protect against untrustworthy people: Parties you're conversing with may still leak your messages without your knowledge. Cryptocat aims to make sure that only the parties you're talking to get your messages, but that doesn't mean these parties are necessarily trustworthy.

None of those seem to relate to the crypto itself.

Wow, so you rely on heavy encryption but you do not read through the website of that encryption?

Anyways, if I relied on super secure encryption, I wouldn't use such uncirculated software anyway. I would really only on stuff like OpenSSH, OpenVPN or GPG. These tools enable you to use UNIX talk, or tunnel into a network doing messaging there or whatever.

Who is the "you" that you are referring to? I don't use CryptoCat at all. I merely pointed out that the usage stories are presented on the home page without needing a click, but the warnings are hidden behind a click and don't even refer to the crypto.

Not sure what the relevance of your final paragraph is.

What's interesting is that the creator of Cryptocat, Nadim Kobeissi (who has no problem with the media introducing him as "cryptographer" or "security researcher") commented the following last year to journalists when asked about an issue with MEGA's (mega.co.nz) encryption:

“It’s a nice website, but when it comes to cryptography they seem to have no experience,” says Nadim Kobeissi, a 22-year old cryptographer and creator of the secure chat software Cryptocat, who began poring over the public portions Mega’s code as soon as it debuted over the weekend. “Quite frankly it felt like I had coded this in 2011 while drunk.” (see: http://www.forbes.com/sites/andygreenbe ... -promises/)

Perhaps he was on drugs when he coded Cryptocat...

What is it with people in the crypto community always coming across as complete and utter jerks? Question for those in this space: is it possible for you to give constructive criticism for a project without calling people "incompetent"?

Seriously, if there any domain in CS more full of these types of personalities I can't think of it.

> 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

I was really hoping Nadim would be successful with CryptoCat, but at least in my eyes, this bug is the failure of the project — especially because his response is, "Cryptocat is not any different from any of the other notable privacy, encryption and security projects, in which vulnerabilities get pointed out on a regular basis and are fixed. Bugs will continue to happen in Cryptocat, and they will continue to happen in other projects as well. This is how open source security works." <http://blog.crypto.cat/2013/07/new-critical-vulnerability-in...

No. This is how open-source "security" fails. GnuPG has not had a security bug since 2008, and I don't think it's ever had a security bug that left your encrypted messages open to interception. You can't start with insecure cryptographic software and bugfix it until it's secure. You'll just bugfix it until only the bad guys know where the new holes are. How long has the Russian equivalent of the NSA (or, if you're Russian, the NSA) known about Lucky Thirteen, for example? How long did they know about the Million Message Attack?

(That, and the array of "15-bit" single-digit integers.)

Cryptography is different than regular software. It requires even more than full transparency or even "full" competency. It requires radical humility. Both from the creators and the critics. Once the dialog stops, sides are chosen and people dig in, the project fails regardless of how well or poorly it had been doing.

Does anyone remember this.. https://news.ycombinator.com/item?id=5194489

The story where he thought his computer was backdoored by a government agency and provides no evidence other than some weird paranoid hunches.

His original blog post http://log.nadim.cc/?p=110 has been removed, but you can find it here: https://gist.github.com/chrisbutcher/4748293/

For all the people ranting about what an incompetent this guy is, why does no one complain that stuff like GPG is so complicated that

1) Ordinary people probably can't use it.

2) It probably would be pretty easy to talk ordinary people into sending you their private keys/passphrases/etc... in the guise of 'helping' them, because it's so complicated.

No one seems to talk about horrible complexity as a big security vulnerability.

Also, I agree that there is something not quite right in the security community that often makes them talk with their Comic Book Guy voices.

I hear this all the time but I think it's a little verkakte. Here's why:

First, GPG isn't that hard to use. When people say this, I assume they're referring to the command-line tools. But nobody advocating GPG for "ordinary people" thinks they should be using the command line tools. Here's the day-to-day UX for GPG in Mail.app: (1) ask for acquaintance's key, (2) double click it in the email message when it arrives, (3) optionally call acquaintance the first time you use the key to verify it, (4) send acquaintance mail. Depending on your settings, you may need a step (5), "push encryption button in mail composer window".

Second, to the extent that GPG is fussy, it's fussy because it's trying to solve a difficult problem. Wanting the problem to be easier doesn't make it easier. We would all be better off if all mail was opportunistically encrypted (OE was the dream of the late '90s, where you wouldn't even need to ask, and software would just figure out when it was possible to encrypt traffic). But GPG is doing more than OE does, because GPG is guaranteed end-to-end, even in conversations with multiple people. OE-style encryption is not that far from what we already have today with certificate-pinned DHE TLS to Gmail.

We could definitely use better UX for PGP (the fact that GPGMail is the best we have right now is telling).

But that's not what tools like this are; they're not a better UX for a proven system. They're not even the same kind of system. Cryptocat provides weaker guarantees than GPG does. It's simpler to use because it's a simpler, less secure system.

As to Comic Book Guy voice: yes, that's something that happens in infosec. You should be able to see why: it's a field populated by nerds that is uniquely adversarial. Bruce Schneier hasn't taken that tone with Cryptocat, but he's taken it with other people. If you go looking for patronizing, pedantic, dismissive tone in infosec, you're sure to find it. But let's not lose sight of the fact that the people taking that tone are (a) in this case right and (b) taking the time to communicate that rightness on their own dime.

Nobody paid Steve Thomas or Adam Langley to find bugs in Cryptocat.

I don't really have a dog in this fight, I'm not defending cryptocat, but pointing out that the "dealing with people" part is difficult, too, and that in some ways, crypto software hasn't done a particularly good job at it, especially in the past. Presumably, they have improved at it over time thanks to the suggestions, comments, and help of others. I agree that it's a difficult thing to make simple for 'ordinary people'.

I think "adversarial nerds" hits the nail on the head. I understand it, but I don't have to like it.

Out of curiosity, since you mention Mail.app, do you have a link to any good guides on hardening OSX? Or is it pretty good out-of-the box?

You can probably find a lot of links, but I can give you a quick punch list (from memory; we have an audit process that our internal team uses for this, so I haven't had to think about it in awhile):

* Disable all sharing

* Enable the firewall

* Enable full-disk encryption

* Change the power management settings so the key isn't resident in memory at sleep

* Create a separate admin account and remove admin from your normal account

* Run software update

There are other things we do but they're fussy.

eh, I've said that many times. I've even said it on HN.

But why would anyone even bother trying to fix the situation? Any attempt to will just result in the entire crypto community community calling you "worthless" and "unqualified".

This is the entire problem. Funnily enough, I imagine the original implementers of the major crypto libraries we use today and take for granted would probably equally be called "idiots" and "losers" if judged by today's internet crypto heroes.

The crypto community is flat out toxic. You ain't gonna see progress from anywhere until the situation changes.

I think you're being unfair by painting them all with the same brush. But there is definitely a 'tone' in that community that I find very off-putting.

This thread was interesting - tptacek seems like a nice enough guy - he's very helpful here and certainly knowledgeable, and generally pleasant to interact with:

https://news.ycombinator.com/item?id=5776111

I agree with you that the "don't do that" attitude seems a bit... binary. Who decides who gets to do what? At what point does it become 'ok' to do crypto stuff? What kind of crypto stuff? Putting together pieces like SSL and GPG? Writing crypto libraries? New crypto algorithms? I'm mostly a believer in leaving the latter to people who have demonstrable competence in the field, but lots of people need to put together pieces in some way and the "don't do that" attitude does not really solve that problem.

You know, it's funny, because as a programmer and watching this interaction happen over the years (between programmers and people that are good at cryptography/security) I've come to this conclusion:

It's down to the fact that developers are not engineers. In the sense that anyone can "sling" some code together and call it an application; but that isn't engineering.

Cryptographers have a similar set of moral and ethical imperatives that medical doctors, civil engineers, or even aerospace engineers (may) have. If the guy down the street that's read a few books and built a few tree houses (or maybe even something more complex and impressive) goes to build a bridge intended to be used by anyone; any sane civil engineer would have every right to trash on him.

I don't entirely understand the mushy "be nice to him, he's learning" attitude everyone has (that's what school and learning environments are for!!!) because it's precisely that personal attitude that has resulted in the loss of credit card data, sensitive passwords stored in big services, secrets that people would (literally) kill for, &c...

This shit isn't a joke and I fully support any cryptographer being a hard-ass because they are the ones that put in the time to learn, practice, fuck up, and re-learn what it means to encrypt something.

As programmers we don't even have a code of conduct, or ethical pact. Cryptographers have one but, they do, not because they all sat down and decided they should but because it's a natural consequence of what it is they are working on.

As a cryptographer you cannot morally support an incompetent (and even a competent) programmer in rolling their own crypto; not because they are all assholes, but because they believe in privacy to a degree the rest of us don't.

It's my perception that people seriously involved in mathematics, particularly sensitive things like crypto, must have a thick skin. It's a field that is all hard skills and no soft skills, and I'm not sure it could practically be any other way. The professional is either intensely correct or incorrect, and often provably so.

Like in this case. I can call your ChicagoBoss application crap, say it is far from OTP design principle, baked with magic parse transforms, etc. and I'd be an asshole because it's a matter of design opinion, not provable fact. The author here has published a crack that absolutely proves that the CryptoCat guys were wrong, and that matters.

It's very easy to say someone is wrong, though, without calling them a shithead. Indeed, you could even go so far as to say that it fosters a more open, inviting atmosphere if you concentrate on what's right, and what's wrong, and let people have the freedom to be wrong without being labeled assholes, incompetents, and worse. This is why you don't find, in most scientific papers, descriptions of other scientists work as 'crap' or 'stupid', even if they do point out the most glaring of errors. It's left to the reader to assign the 'stupid' label.

In this specific case, I agree that there's some justified anger at labeling something ready for public consumption that appears not to be. But I just get a sense of so many crypto/security discussions being a dick-waving contest.

Don't let me off the hook; I am 1000% "that guy" when it comes to software security stuff. Also US law, sous vide cooking, C software development, the music of the Elephant 6 collective, tech entrepreneurship, and parenting.

Wait, if someone created documents to help people use PGP or GPG, and released those as beta versions, I believe they'd get mostly useful help and advice.

I agree that they'd still get some toxic comments. This is a problem. As understand it the Math stack-exchange site had problems with toxic members. Perhaps it's a math thing?

It's more than documents, it's that they wrote those programs with complex ways of interacting with them. To be fair, they have improved with time, but I don't want to let that get in the way of making my point.

I'm going to dredge up my best Comic Book Guy to comment as an example:

"The audacity these security guys have to release such critical software with such a poorly considered user interface is mind boggling, and makes it clear that they care not one whit for their users. Someone so incompetent in the field of user interaction should probably stay in their room playing with crayons. This software is full of stupid UI mistakes, and run by people who clearly know nothing about interacting with other human beings - our only meager consolation from this is that they will clearly never manage to reproduce".

Now, I'm just kidding around, am extremely glad we have the software we do have, and am pretty shitty at making UI's myself, but that kind of discussion is really not pleasant at all to deal with.

I can personally verify this. Anecdotal, but still: for the past several months I've been working on an app that makes PGP/GPG easier to use for average people[0], and the crypto community has been astoundingly supportive (I was scared, at first). The difference is that my team isn't rolling our own crypto, and we've been adamant about that from the start.

0. http://parley.co

Unfortunately I am not too well-versed in cryptography, and I guess I must start taking the Matasano crypto challenge. I am very scared too use most crypto platforms for reasons like this; I would never have picked up on such stuff. I only trust PGP because it has decades of skepticism and so far no one has scared me out of using that. The other stuff needs more eyeballs, and I am more or less blind. Time to read some books.

What about NACL? http://nacl.cr.yp.to/index.html

Seems to provide most of the building blocks you would need and has bindings for various languages.

I have seen it. I am a middling programmer at best. I guess I need to step it up.

I'm pretty sure there's a nicer way of saying "You're doing crypto wrong."

I don't know the author of either software, but as software professionals we have to maintain a certain level of respect for one another.

People tried politely telling Cryptocat that they were doing crypto wrong.

Cryptocat ignored those people. Cryptocat dismissed the advice they were being given.

I disagee, The cryptocat team must 'suck it up' and do better, or GTFO. If they know anything about their field, they should not expect any respect or politeness.

As software professionals we have a responsibility to accept criticisms from others in our field, no matter what their tone and manner may be - and this is especially true in crypto. In our field we have a lot of very bright people with literally no politeness or respect - and we must still work with them to make things better.

People relied on crypto.cat, some probably with their lives.

Who gives a crap about hurt feelings of the author who failed at crypto for so long, while advertising it as secure?

It is not "hurt feelings", it is "the tone of the environment."

Really, education and politeness have much more to do with "building a strong society" (and by society I mean "developers' environment") than "not hurting the feelings of an individual."

Think big, not small. Think long-term, not short. Think global, not local. If you do these, then you will end up also thinking small, short and local.

(Edit typos etc)

Reedit: The first comment by DanBC is what I deem "polite criticism". One does not need to mince words but one does not need to insult either.

Although I agree with that fact the the article was a bit harsh, I have to say that it's not really about "thinking big" or "small", it's about the result of such mistakes. If a pizza delivery order got messed because of a bug in the web service, the result would be that you won't have any pizza today for example (which is acceptable). But when it comes to software that affects lives, and when it's being advertised in the media (of course with the patronage of the author) as a secure solution, then it's a big problem that could really affect many people. You can't think long or short term in these issues, you have to take the immediate consequences into consideration, you have to shock the users into knowing how bad the problems are. I'm sure the intention for such harshness is not directed towards the author, but in fact towards the community of users relying on this piece of software. Imagine learning that TOR is insecure or compromised for example, that would mean a very hideous end for many activists around the world. I really mean hideous as being persecuted, captured, tortured, and eventually killed. That is something that should be stopped in any way without giving any second thoughts to feelings, or "strong developer environment".

From a technical point of view, nothing could be said about the author, because this is how software is, weather it's proprietary or open source. As many have said before me, the smallest bug could render an amazing software pointless.

Just chiming in with something that I feel strongly about.

You are right in what you say. Absolutely.

I am just speaking about the "tone". Long term/short term tone-wise.

If you go to the Perl community you will understand what I am talking about. Not just TIMTOWTDI, not that. Just

"This is wrong and does not work as intended".

Instead of

"Fuck it, man, this sucks completely and is crap".

Steve only said: "CryptoCat doesn't work as expected". "The creators are incompetent of taking on such task" (which is his opinion that he's entitled to have), and "Here's why it doesn't work".

Sorry, but people that continually ignore polite advice to the detriment of the community badly need naming and shaming like this. People's lives are literally on the line.

Way to miss the point. This isn't about Nadim. Ask yourself this question: If there's an intelligent person with expert skills to contribute to either of two communities, and one of them is full of naming and shaming but the other iusn;t, where will they go?

If they're into crypto, hopefully the one with a robust attitude to handling security flaws, rather than the one where pointing them out is considered bad form.

Why should we be polite to a person who endangered people who relied on his expertise? He had one task (that he chose), that task was extremely sensitive and had to be implemented correctly. He failed. Shaming and ridicule is the least he deserves.

Well I hope you shall never make a mistake.

Search for "Patriot missile bug" and think about it. Just a suggestion.

1) If I ever make a mistake of that magnitude, I will accept any level of criticism, in any way shape or form.

2) I will never implement a crypto system that lives depend on without fully understanding it.

Honestly, it does not matter whether YOU accept that level of criticism. It is not about the perpetrator, it is about the environment.

I am not complaining for myself, really.

And, on the other hand, I would suggest not being so sure about the future.

I agree that criticism should be constructive, and that it never needs to be toxic. I agree that "we" should be working to reduce toxic environments.

When you release a crypto product you will receive a lot of criticism. You need to be humble with the release, and humble with the acceptance of criticism, because the people giving that criticism tend to be very good at what they do and thus their time and knowledge is valuable.

So part of the problem is a toxic environment, but part of the problem is certainly the unhelpful attitude of people working on cryptocat.

I guess there's something in here about defensiveness and accepting criticism and cognitive dissonance.

I totally agree with you.

As I said above, yours are examples of clear, detailed, polite, constructive and useful criticism: one does not need to say so and so is a good man but has made this tiny mistake in order to be polite: just distinguish between facts, actions and persons.

So thanks for your efforts and keep up the good job.

I wish people would get involved with projects like Cryptocat instead of pointing the finger with some kind of superiority that will never construct anything, at least this is what I would do if I were a Cryptographer, but why bother? It is better to work for a bank and use others mistakes to make some self-promotion and maybe feel better with myself. You missed a excellent opportunity to make some good.

If I were to write a book that pretended to teach laymen how to perform major surgery in their own kitchen, would it be reasonable for real surgeons to tell me to knock it the fuck off, or should they "get involved" and attempt to provide me with constructive criticism?

Your analogy means that people shouldn't expect to have secure group chatting capability. It would be more like (groan) saying "I want to perform surgery in my kitchen so I'll just read some books while I'm opening the person up, but real surgeons are telling me to knock it the fuck off and read all the books before trying it".

It's legitimate and commendable to try to write your own cryptosystem, but winging it is not going to end well.

No...

People can expect secure communications, just like they can expect lung transplants. They should should not expect either done by an amature rejecting supervision.

There was nothing wrong with what they wanted done, only with who was doing it and how.

In your analogy:

* Writing a book = developing cryptocat.

* Knock it (writing the book) the fuck off = stop developing cryptocat.

* Real surgeons = cryptographers.

* Teach laymen how to perform major surgery in their kitchen = communicate securely.

If people "can expect secure communications", then, by your analogy, people "can expect to be taught how to perform major surgery in their kitchen". They cannot both be expected "to be taught how to perform major surgery in their kitchen" and not expect to have it "done by an amateur rejecting supervision".

Hence my amendment to the flawed analogy.

* perform major surgery = communicate securely.

* Teach laymen to .... in their kitchen (ie, the shit that is hopelessly wrong about my surgery book) = the shit that is hopelessly wrong about cryptocat.

I think either works fine.

You're right. However, the guy actually did write a patch for Cryptocat, so you have to give him that.

Which was subsequently modified to make it less secure before being added to the project. That tends to dampen one's enthusiasm to contribute.

It's always fun to watch patches you make to projects get removed or changed a few weeks/months later for arbitrary reasons :(

Nadim Kobeissi spends most of his spare time fighting with people who know better. This is no surprise. I remember the 50 long twitter reply chains with a number of crypto developers calling him out for bad design choices.

Crytpocat have now posted a reply:

https://blog.crypto.cat/2013/07/new-critical-vulnerability-i...

Also I learned that it means nothing when I hear "it is open source and peer reviewed".

I get his point, but I take exactly the other conclusion from this; perhaps ironically, because Steve Thomas has ripped it to pieces and gone to town on the code, as long as the flaws he found are fixed, I now have greater faith in it because it's open source and peer reviewed - Steve Thomas' own peer review is a big part of that.

Perhaps we should take open source and peer reviewed as meaning it can be peer reviewed; it's still on us to check who's done those reviews and, if needs be, do it ourselves and give something back.

There should be no benefit of the doubt or warm encouragement for these developers. The bug with the array of decimal digits shows minimal programming competence: the author either does not understand how numbers and strings work in a computer, or doesn't read API documentation. Nadim seems like a naive person without a computer science background who is attracted to cryptography as an activist, but has no knowledge beyond a 3-page tutorial. It is extremely arrogant and irresponsible for a developer with such little domain expertise to promote this product as secure.

> The bug that lasted 347 days was the confusion between a string and an array of integers.

Maybe they are Erlang programmers :-)

Every programmer should be forced to implement a non-trivial algorithm that involves lots of bit twiddling in a few languages that don't have integers ("all you need are double-precision IEEE 754 floats...and love!"), don't have unsigned integers, have undefined or implementation-specific integer sizes, and/or don't have a "convenient" string type.

Honestly I think you need to make that challenge harder. Lua, for example, has built-in 32-bit bitwise operations despite having no integer types. I did a prototype implementation of SHA3 and it was a walk in the park, I wouldn't expect that to change with a larger algorithm.

Watch out, he's just trying to get you to implement ECDLP in Applescript and DOS BAT files.

Shouldnt this be called DecryptoDog? I've never trusted any in browser/java nonsense crypto since FireGPG was exposed for dozens of problems and leaks.

https://blog.crypto.cat/2013/07/new-critical-vulnerability-i... There seems to be a response to this on the cryptocat dev blog. Since I have no clue about crypto, I can't make any assessments though; Still might be interesting for some of you guys.

I would just like to say that it makes me very happy to see even modestly technical discussions about cryptology make it so high up on HN.

Lately it has seemed like all the highly ranked articles have been about the PEOPLE or COMPANIES doing crypto, and not about the cryptology itself.

Crypto is interesting not because people are doing it, breaking it, and improving it every day. Crypto is interesting because of HOW people are breaking it and improving it.

Nadim has a good idea here in Cryptocat. The implementation has some problems, clearly. Is anyone surprised (including Nadim)? Clearly Nadim is learning as he goes. Let's dispense with the personal attacks and instead, if we think Cryptocat is a good idea, let's help make it as secure as we can. Can we get experienced crypto experts on board? Nadim ought to be interested in that.

Cryptocat have rejected the advice from experienced crypto experts.

Cryptocat have been given a lot of advice and they argue against it; they tell experienced crypto experts that they are wrong and that the flaws are not really flaws.

If this is true, then it is disappointing.

Rolling your own crypto is incredibly perilous. Now, the Cryptocat team could discard their own code, compile GnuPG with emscripten [1] and adopt the existing UI/UX to using that but who's to say GnuPG is still going to work correctly on that new platform?

The only "easy" (if insane) solution I can think of for building GPG on a known platform and still having it run in the browser is to use something like JSLinux [2] and run GnuPG inside a hidden VM communicating with it over an emulated serial interface. Then again, I'm sure that could introduce all sorts of interesting issues related to timing and randomness.

Cryptography is damn hard.

Edit: I'm aware that they've used CryptoJS but, much like calling OpenSSL directly, I would still count that as "rolling your own".

[1] See, e.g., http://manuels.github.io/unix-toolbox.js-gnupg/.

[2] http://bellard.org/jslinux/

But they didn't roll their own crypto as far as I can tell. They used CryptoJS [1]. They just failed to use it correctly.

EDIT: Here's the code https://github.com/cryptocat/cryptocat/blob/master/src/core/...

[1] https://code.google.com/p/crypto-js/

Whilst there may still be plenty of scope for error, I think there is a large difference between using CryptoJS and "rolling your own".

I wonder how "correct" CryptoJS itself is though.

> Whilst there may still be plenty of scope for error, I think there is a large difference between using CryptoJS and "rolling your own".

I agree to some extent but as the article we're commenting on proves, the scope for error is enough for you to render your encryption useless against an attacker armed with just a modern desktop PC.

If everyone here who complains about the folks behind Cryptocat being dumb is such much smarter, how about some of you build something like this so we can all see compare. Commenting in HN doesn't prove you know better, ship something and we can all be sure.

I genuinely don't know if you're trolling or not.

Some of the people criticising cryptocat are respected, knowledgeable, experienced researchers with shipped product used by many people everyday.

Other people criticising cryptocat know enough about crypto to know that they should not be doing it. That's not a negative, that's a strong positive point.

It would almost be too comical if cryptocat was actually sponsored (developed)? in proxy by some secret service. In general, people that use cryptocat are probably using it to discuss more intellectual thoughts, such thoughts might be useful to record and analyze. It is interesting that as the relative adoption of the service grew, the encryption mechanism became weaker..

Does anyone know if there are any issues with the javascript OTR library they use (https://github.com/arlolra/otr)? Or are all the issues only with their custom multi party chat encryption system?

Are there any implications for the WebCrypto API after this? I think he used Javascript crypto at first, but not sure after he turned it into a "Chrome app" (presumably based on Native Client - or is it still Javascript?).

> Both comments are wrong since "Cryptocat.randomString(64, 0, 0, 1, 0)" generates a string that is 64 decimal digits which is 212.6 bits or 26.6 bytes.

How can you have .6 bytes or bits?

A bit is a 0 or a 1. Two bits is 00, 01, 10, or 11. Each bit doubles the amount of information. This means that information representing information as bits products powers of 2. To get the number of bits (the power of 2 to represent the number), one takes the log, base 2, of the number. If I took the example of 2 bits and limited it to 00, 01, 10, there would be 1.6 bits. Log2(3) = 1.6.

Author complains "I learned that it means nothing when I hear it is open source and peer reviewed." Yet his article wonderfully illustrates the opposite.

Steve's pages are very easy on the eyes.

i think that someone, who is teaching others that they are writing crap crypto, should express himself less vaguely than like: "... depending on your browser you might get these two lines of extra data ..." (in "public key")

What alternatives are there for group chatting?

It is totally fine! Compare this to Android: http://bluebox.com/corporate-blog/bluebox-uncovers-android-m...

Security, privacy, copyright — these are three problems the humankind is as dumb as a monkey with.

Give RetroShare a try: http://retroshare.sourceforge.net/

It's:

1. Decentralized (real p2p, no central servers)

2. Encrypted communication

3. Easier to set up than encrypted email: Install -> Exchange "certificates" -> Done.

You need to stop spamming this.

4. Not developed by cryptographers.

BTW, everyone using the "But lives depend upon this, the CryptoCat author put lives at risk!" argument to excuse Steve Thomas's attacking tone in this article is more or less being a hypocrite.

What about the fact that Steve Thomas, by releasing a tool that makes it extremely easy to decrypt the conversations encoded by CryptoCat at specific times, has done exactly the same thing? Disclosing a vulnerability in this public manner and providing a decryption tool on a platter has probably done more damage to the hypothetical journalists who were hypothetically using CryptoCat.

I don't think bad crypto should be forgiven, but it would be easier and probably less arrogant to just submit a diff / pull request publicly that fixes all of the problems that the author observed, and then have people comment upon it. If the author rejects it, these "you are incompetent" comments can go there.

Arrogant takedowns like this "the author clearly has no effing idea about crypto" make it more difficult for newbies like me to understand and try to work on crypto. What chance do I have if any piece of software I write is going to be destroyed by withering comments like "you're a moron" without mathematically explaining what the problem is and laying out the fixes clearly and positively?

> that fixes all of the problems

Yet again: Cryptocat is broken. It is so broken that there is no possibility of making it work.

by releasing a tool that makes it extremely easy to decrypt the conversations encoded by CryptoCat at specific times, has done exactly the same thing?

Assuming that cryptocat is used to avoid the monitoring of entire nations, you can be absolutely certain that those with the motivations have long ago cracked this. That is exactly why security professionals get so passionate about this, because they know that bad crypto is literally much worse than no crypto at all -- at least in the latter case you have no illusions.

Cryptocat has been under significant criticism for a long time. For instance-

https://news.ycombinator.com/item?id=5194713

-and for very good reason. After the farcical story about being investigated by CSIS (which seems laughable, because if there's one thing that government security agencies love, it's bad crypto), this project seems to be held aloft by nothing more than people saying "But he's young and passionate, so give him a chance" -- that isn't credible reasoning for crypto.

Reply on news.ycombinator.com