This blog: ---> http://tobtu.com/decryptocat.php makes claims that Crypto.Cat is less secure than previously thought.
From the above link: Quote: Cryptocat's public key scheme is now good after being bad since pretty much the beginning. I would suggest not using Cryptocat as there's no telling how long it will be until they break their public key encryption. Good news is if they read this they'll make a better effort not to change public key algorithms or the way they generate private keys. I'm sure there are plenty of bugs and other bad crypto in other parts because I only looked at random generation and found a bug, at public key algorithm and found a bug, and quickly looked where random is used and found something scary.
For those unfamiliar with https://crypto.cat/ this site has been the purveyor of peer to peer encrypted communications since its inception a couple/few years ago.
The coder and owner of https://crypto.cat/ has been detained on numerous occasions while he traveled to/in/from the USA to/from Canada and other nations.
Unfortunately, this news comes at a time when I was beginning to use Crypto.cat more often than compared to the past.
Judging by the response from https://crypto.cat/ their service remains a viable choice of encrypted communications, but until we get more eyes on the project we are on our own when deciding whether, or not, to trust sensitive communications to https://crypto.cat/
With the rise of quantum computing we need to also increase our efforts to remain ahead of the cryptographic-curve, in a manner of speaking, by continuing to implement increasingly more complex encryption schemes.
Here is Kobeissi's blog post of 04-July-2013, from his site @ https://blog.crypto.cat/ in which he explains the situation, as well as the steps he's taking to mitigate the situation:
Quote:Cryptocat Development Blog
New Critical Vulnerability in Cryptocat: Details
Thursday, July 4th, 2013
In the unlikely event that you are using a version of Cryptocat older than 2.0.42, please update to the latest version immediately to fix a critical security bug in group chat. We recommend updating to the 2.1.* branch, which at time of writing is the latest version. We apologize unreservedly for this situation. (Post updated Thursday June 4, 7:45PM UTC to add new details regarding SSL, and more.)
What happened?
A few weeks ago, a volunteer named Steve Thomas pointed out a vulnerability in the way key pairs were generated for Cryptocat’s group chat. The vulnerability was quickly resolved and an update was pushed. We sincerely thank Steve for his invaluable effort.
The vulnerability was so that any conversations had over Cryptocat’s group chat function, between versions 2.0 and 2.0.42 (2.0.42 not included), were easier to crack via brute force. The period between 2.0 and 2.0.42 covered approximately seven months. Group conversations that were had during those seven months were likely vulnerable to being significantly easier to crack.
Once Steve reported the vulnerability, it was fixed immediately and the update was pushed. We’ve thanked Steve and added his name on our Cryptocat Bughunt page’s wall of fame.
In our update log for Cryptocat 2.0.42, we had noted that the update fixed a security bug:
IMPORTANT: Due to changes to multiparty key generation (in order to be compatible with the upcoming mobile apps), this version of Cryptocat cannot have multiparty conversations with previous versions. However private conversations still work.
Fixed a bug found in the encryption libraries that could partially weaken the security of multiparty Cryptocat messages. (This is Steve’s bug.)
The first item, which made some changes in how keys were generated, did break compatibility with previous versions. But unlike what Steve has written in his blog post on the matter, this has nothing at all to do with the vulnerability he reported, which we were able to fix without breaking compatibility.
Due to Steve’s publishing of his blog post, we felt it would be useful to publish an additional blog post clarifying the matter. While the blog post published by Steve does indeed point to a significant vulnerability, we want to make sure it does not also cause inaccurate facts to be reported.
Private chats are not affected: Private queries (1-on-1) are handled over the OTR protocol, and are therefore completely unaffected by this bug. Their security was not weakened.
Our SSL keys are safe: For some reason, there are rumors that our SSL keys were compromised. To the best of our knowledge, this is not the case. All Cryptocat data still passed over SSL, and that offers a small layer of protection that may help with this issue. Of course, it does not in any way save from the fact that due to our blunder, seven months of conversations were easier to crack. This is still a real mistake. All the same, we are rotating our SSL keys. We should also note that our SSL setup has implemented forward secrecy since the past couple of weeks.
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.
Finally, an apology: Bad bugs happen all the time in all projects. At Cryptocat, we’ve undertaken the difficult mission of trying to bridge the gap between accessibility and security. This will never be easy. We will always make mistakes, even ten years from now. 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.
Every time there has been a security issue with Cryptocat, we have been fully transparent, fully accountable and have taken full responsibility for our mistakes. We will commit failures dozens, if not hundreds of times more in the coming years, and we only ask you to be vigilant and careful. This is the process of open source security. On behalf of the Cryptocat project, team members and volunteers, I apologize unreservedly for this vulnerability, and sincerely and deeply thank Steve Thomas for pointing it out. Without him, we would have been a lot worse off, and so would our users.
We are continuing in the process of auditing all aspects of Cryptocat’s development, and we assure our users that security remains something we are constantly focused on.
Posted in Security |
Thoughts?
Alternative measures?
Please share here.
Thank you.
|
