4 ms·

These "serious cryptographers" really never seem to deliver usable solutions themselves - and therefore the average users use software like cryptocat, or they d

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.

jlgreco 13y ago
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.
- jerguismi 13y ago
  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.
  - flebron 13y ago
    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.
  - jiggy2011 13y ago
    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.
  - DanBC 13y ago
    > Doing is always good. Until the government cracks the crypto used for your messages and locks you up for life.
Nursie 13y ago
And look what happened. People thought they had a secure channel but they didn't.
DanBC 13y ago
> 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 13y ago
brl 13y ago
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.
- makomk 13y ago
  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.
Nursie 13y ago
>> Cryptocat managed to bring cryptography to the masses Not really! Obfuscation perhaps.

jlgreco 13y ago

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.

jerguismi 13y ago
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.
- flebron 13y ago
  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.
- jiggy2011 13y ago
  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.
- DanBC 13y ago
  > Doing is always good. Until the government cracks the crypto used for your messages and locks you up for life.

Nursie 13y ago

And look what happened. People thought they had a secure channel but they didn't.

DanBC 13y ago

> 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 13y ago

brl 13y ago

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.

makomk 13y ago
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.

Nursie 13y ago

>> Cryptocat managed to bring cryptography to the masses Not really! Obfuscation perhaps.