
DecryptoCat - thejosh
http://tobtu.com/decryptocat.php
======
tptacek
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.

~~~
jiggy2011
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.

~~~
drostie
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](https://www.tarsnap.com/scrypt.html)

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

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

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

~~~
tptacek
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.

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

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

~~~
kragen
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.

~~~
tptacek
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.

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

------
DanBC
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...](https://www.schneier.com/blog/archives/2008/05/random_number_b.html))

~~~
mtgx
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/](https://crypto.cat/)

~~~
tptacek
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."

~~~
thesmileyone
Would it pass a Matasano audit? ;)

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

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

~~~
jerguismi
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.

~~~
DanBC
> 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.

~~~
rst
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.

~~~
scythe
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.

~~~
rst
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-...](http://www.newyorker.com/online/blogs/elements/2013/06/what-
its-like-to-get-a-national-security-letter.html) (If you want to see the part
I quoted, scroll right to the end.)

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

~~~
im3w1l
People need cryptography everywhere. Otherwise the fact that cryptography _is
being used_ leaks information.

------
kragen
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...](http://blog.crypto.cat/2013/07/new-critical-
vulnerability-in-cryptocat-details/>)

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

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

------
wyck
Does anyone remember this..
[https://news.ycombinator.com/item?id=5194489](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](http://log.nadim.cc/?p=110) has been removed, but
you can find it here:
[https://gist.github.com/chrisbutcher/4748293/](https://gist.github.com/chrisbutcher/4748293/)

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

~~~
tptacek
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.

~~~
javajosh
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?

~~~
tptacek
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.

------
616c
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.

~~~
jiggy2011
What about NACL?
[http://nacl.cr.yp.to/index.html](http://nacl.cr.yp.to/index.html)

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

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

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

~~~
rorrr2
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?

~~~
pfortuny
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.

~~~
beshrkayali
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.

~~~
pfortuny
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".

~~~
beshrkayali
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".

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

~~~
jlgreco
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?

~~~
StavrosK
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.

~~~
jlgreco
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.

~~~
StavrosK
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.

~~~
jlgreco
* 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.

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

------
amouat
Crytpocat have now posted a reply:

[https://blog.crypto.cat/2013/07/new-critical-
vulnerability-i...](https://blog.crypto.cat/2013/07/new-critical-
vulnerability-in-cryptocat-details/)

------
EliRivers
_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.

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

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

Maybe they are Erlang programmers :-)

~~~
rwg
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.

~~~
Dylan16807
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.

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

------
phryk
[https://blog.crypto.cat/2013/07/new-critical-
vulnerability-i...](https://blog.crypto.cat/2013/07/new-critical-
vulnerability-in-cryptocat-details/) 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.

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

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

~~~
DanBC
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.

~~~
plg
If this is true, then it is disappointing.

------
networked
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/](http://manuels.github.io/unix-toolbox.js-gnupg/).

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

~~~
amouat
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.

~~~
networked
> 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.

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

~~~
DanBC
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.

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

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

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

------
arthulia
> 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?

~~~
bmh100
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.

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

------
leke
Steve's pages are very easy on the eyes.

------
mykhal
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")

------
jaekwon
What alternatives are there for group chatting?

------
dakimov
It is totally fine! Compare this to Android: [http://bluebox.com/corporate-
blog/bluebox-uncovers-android-m...](http://bluebox.com/corporate-blog/bluebox-
uncovers-android-master-key/)

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

------
kimlelly
Give RetroShare a try:
[http://retroshare.sourceforge.net/](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.

~~~
InternalRun
You need to stop spamming this.

------
parennoob
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?

~~~
DanBC
> that fixes all of the problems

Yet again: Cryptocat is broken. It is so broken that there is _no possibility_
of making it work.

