Forgot your password?
typodupeerror
Bug Communications Encryption Privacy Security

Group Chat Vulnerability Discovered in Cryptocat, Project Fixes and Apologizes 83

Posted by Unknown Lamer
from the can't-catch-a-break dept.
alphadogg writes "The founder of an eavesdropping-resistant instant messaging application called Cryptocat has apologized over a now-fixed bug that made some types of messages more vulnerable to snooping. Cryptocat, which runs inside a web browser, is an open-source application intended to provide users with a high degree of security by using encryption to scramble messages. But Cryptocat warns that users should still be very cautious with communications and not to trust their life with the application. The vulnerability affected group chats and not private conversations. The encryption keys used to encode those conversations were too short, which in theory made it easier for an attacker to decrypt and read conversations." The bug report/merge request, and an analysis of the bug (although, in light of the Cryptocat's gracious response, overly acerbic and dismissive of the project).
This discussion has been archived. No new comments can be posted.

Group Chat Vulnerability Discovered in Cryptocat, Project Fixes and Apologizes

Comments Filter:
  • by walshy007 (906710) on Saturday July 06, 2013 @05:23AM (#44202081)
    Why not just use OTR with pidgin? Supports any protocol you'd care to mention.
  • by Anonymous Coward on Saturday July 06, 2013 @05:25AM (#44202089)

    This bug and the history of it point to the cryptocat people being utterly incompetent. It's perfectly possible that they did what they did with the best of intentions and that they reacted as well as they could - that does not change one iota about them being incompetent and that you better don't trust the work of incompetent engineers. It's nice that that civil engineer did not intend to kill anyone and that she helped in rescuing people, but still her incompetence is what caused the bridge to collapse and what makes it reasonable to be suspicious of the other bridges she's responsible for.

    • by Anonymous Coward on Saturday July 06, 2013 @07:35AM (#44202307)

      It is a devastatingly simple and obvious bug that any code review would have spotted. It's laughably amateurish.

      It's especially egregious after the rant the author (isn't there just one?) went on about Javascript cryptography. Couldn't have happened to a nicer guy.

      After all, what's the single biggest challenge in JavaScript cryptography? Random number generation. So what's the FIRST thing you look at when reviewing? Random number generation for keys. And what, pray, is their excuse for not using window.crypto.getRandomValues() with a typed array of bytes, which is guaranteed to be available in every supported browser? What, in fact, is their excuse for not using Uint8Array for carrying keys wherever they go?

      • by gweihir (88907)

        Indeed. That random number generation and use is critical is well-known to anybody with a clue since Netscape messed it up almost 20 years ago (in 1996). Since that time, nobody competent has any excuse to not very carefully scrutinize this part of the system in any review worth the name.

    • by gweihir (88907)

      Indeed. The mistakes made are utter beginners mistakes. Nobody halfway competent in the implementation of cryptography would ever make them, as competent people would have recognized these components as critical for the security of the product. The only other explanation is malicious intent.

      Given these two alternatives, the only possible recommendation is "Stay away from this software, do not use it for any purpose."

  • Does anyone know what happened to the HTML5 (non-plugin) based server-side version of cryptocat?

    I don't care if it's less secure than the new plugin-required version.. it will still probably defend against an eavesdropper in my college dorm or at Starbucks.

  • The really ugly 'gotcha', with any attempt at encrypted/obfuscated/steganographic communication, cryptocat included but hardly alone, is storage.

    If your adversary is just drinking from the firehose, and lacks the ability to do more than a cursory inspection, all you have to do is be better than their cryptoanalysts today. If they have sufficient storage to archive a nontrivial percentage of what passes by(or their cursory inspection is good enough to classify suspicious encrypted traffic for storage) you ha

    • by Eivind (15695)

      True, you have to stay secure for the length of time the message has value. This varies. If you're the military, and reporting the position of a patrol in the field, this doesn't need to stay secret for very long. (3 days later the info is pretty useless anyway)

      Breaktroughs in algorithms makes this hard. You can nest encryption, which means you're safe unless *all* of the levels are cracked, but it's a hassle.

  • by Anonymous Coward

    It's encrypted end to end and you can totally discuss your plans and share secrets using the instant messaging. For better protection, why not wrap them in a PDF labelled 'secret plans NSA do not read"?

    Plus its from a trusted company that never harms their customers, Microsoft, in a country with strong privacy laws, America. So its double plus good private!

  • So, strategies towards social change are better off being legal and transcendent (e.g. Bucky Fuller's idea of creating alternatives that make the status quo obsolete). So a lot of the focus on encrypted communications misses the big picture of the vast 21st century changes we are seeing towards post-scarcity...

    Or as I say here:
    http://www.pdfernhout.net/on-dealing-with-social-hurricanes.html [pdfernhout.net]
    ---
    Our biggest advantage is that no one takes us seriously. :-)

    And our second biggest advantage is that our communicati

  • The last sentence of this article says it all :

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

  • by gweihir (88907) on Saturday July 06, 2013 @03:31PM (#44204563)

    The mistakes made are utter beginner's mistakes that nobody even halfway competent with regard to cryptography would make. The only other possibility is that these mistakes were made intentionally.

    While it is unclear whether utter cluelessness or devious intent is to blame, this software should not be trusted on any level or for any purpose. Of the people writing it can make this kind of mistake, then there will likely be a number of other mistakes in it that affect security and this piece of trash should be regarded as broken for any purpose.

    Doing crypto is not a beginner's game. There are countless ways to get it wrong, and most of them cannot be found by testing, but require in-depth understanding and meticulous analysis of the mechanisms used. And encryption software being OSS only helps if some people with a clue care to review it.

"Card readers? We don't need no stinking card readers." -- Peter da Silva (at the National Academy of Sciencies, 1965, in a particularly vivid fantasy)

Working...