Live data from Hacker News

Show HN: Terminal-based group chat with end-to-end encryption

github.com

41–45 of 45 posts

Re: Show HN: Terminal-based group chat with end-to-end encryption

#41
post #18

Earlier quoted context omitted.

How will people learn if they don't try? The problem is not creating and releasing such applications; the problem is overclaiming their security, or putting early confidence in them. Crypto is hard, we get it. Beginners and non-experts are going to mess it up, we get it. Even experts almost always mess it up, we get it. Still, a good programmer of crypto software (or even just, "wise user of battle-tested crypto libr…

Yeah, my question is what is anyone supposed to do? What if we want something to be secure? Are we supposed to just say "well, I'm never supposed write anything involving crypto"? How do we do things right? Seriously.

No. You learn to do cryptography. You get a book, you sit down and you read it. Understand what are cryptography primitives. Understand how they can be used together to create cryptographic systems. Understand every part of that system. Then learn what are the common errors, learn how misuse of cryptographic primitives can lead to disaster. Be able to talk for hours about why WEP encryption can be easily cracked by a low-powered netbook.

When you've done all of that, you'll know that you are abysmally incompetent at cryptography. When you know that, you can start learning how to become good at cryptography. Some people divide learning in four steps: unconscious incompetence (you don't know that you're bad), conscious incompetence, conscious competence and unconscious competence.

Even when you're competent, you will make mistakes, because cryptography is very hard. We've seen how MD5 is now broken, yet still people use it as message authentication ciphers even when it's trivial to perform a length extension attack. But MD5 wasn't always broken. I'm sure it was designed by competent people, but they can't foresee all flaws.

That is why someone who is incompetent at cryptography should not do it.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#42
post #23

Earlier quoted context omitted.

Broken social networking websites and YouTube clones are relatively harmless, so that philosophy makes sense. Broken cryptography can cause loss of money, infrastructure, and life. Imagine if a group of dissidents where to start using this program, the crypto implementation was subtly wrong somewhere, and they were disappeared by their government early one morning. Imagine if some transmitted a password through what…

Yes, so the message should be: "add disclaimers, avoid promoting where rigorous security is required, educate yourself on best practices". Not, "stop releasing hobby projects". The reckless non-technical user who grabs any project that mentions a slight sheen of crypto-sparkles, and then trusts that software with their life or savings, is doomed anyway. The existence of one more hobby project with amateurish crypto i…

I'm okay with hobby projects that use cryptography if every time the user tries to do anything in which security can be expected they flash a message that makes the user type "I understand my data may be read by an adversary."

Re: Show HN: Terminal-based group chat with end-to-end encryption

#43
post #40
post #38

Earlier quoted context omitted.

If that's the case, why go through all this hassle? Simply use IRC with SSL and you have exactly the same level of security. As long as you trust the server, you are fine.

I think there's still value in hiding the conversation from the server even if you must still trust the server to not behave maliciously. If some three-letter agency contacts the server operator asking for a back channel to listen in, he or she could respond that it's not possible without malicious intent towards a user: http://www.macobserver.com/tmo/article/apples-imessage-encry...

Point taken, you're correct - 1.1 is bigger than 1.0, and if the choice is open, choosing the 1.1/semi secure option is definitely better.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#44
post #33

Hey all, great discussion. Apologies for not chiming in earlier, I posted this to HN in the morning and left for 4th of July activities, certainly not expecting it to make the front page. Here're some thoughts and clarifications: * No, I am not a cryptography expert. I've had a nascent interest in the field for awhile and this was my way of getting my feet wet while scratching an itch. I thought I'd post it on HN to…

Learning is fine, just add a disclaimer that it's actually probably not so secure. Oh please don't get me started on FiSH, and PLEASE don't model anything after fish. I had the same problem as you, there's no useable crypto for irc.

- The FiSH plugin for Xchat has a (possibly remote) buffer overflow in the Diffie-Hellman key exchange.

- FiSH uses ECB mode. Seriously. ECB.... ECB... might as well use no crypto.

- IIRC FiSH wastes two bytes per 8 byte block the way it does Base64, not sure about this anymore, it's been a while.

So I tried to find a better plugin and mod it a bit which I did (https://gitorious.org/fishslim/dumfish). But I didn't realize back then that FiSH uses ECB mode.

Since the DH key exchange is not authenticated it's useless. So I dropped it and hacked my own (for Xchat, https://github.com/lawl/dumfish), which doesn't offer DH key exchange but CBC mode instead of ECB, we exchanged keys manually via OTR. (And just makes me realize I also don't have a disclaimer, so I'll add this now.)

Disclaimer: Also not a cryptographer, so it's probably not secure. Do not use for anything serious.

If you want to look at a secure protocol, please look at OTR: http://www.cypherpunks.ca/otr/

Re: Show HN: Terminal-based group chat with end-to-end encryption

#45
post #16

Please, please, please, please, please, stop releasing hobby applications that use cryptography. You're bound to do it wrong. Please stop it.

Can you point to a flaw in the cryptography? Otherwise, while I understand where you're coming from I think your criticism is misguided. Cryptography is very interesting and is fun to implement. It is also difficult to get right. Does that mean hobbyists shouldn't implement it? No, it just means that you shouldn't expect security from hobbyist implementations. I find it disconcerting to see comment after comment on H…

It would be very much easier to ignore hobbyist implementations of crypto if they came with suitably huge warnings.

"This is just a proof of concept. It's not secure. It's just a learning exercise. Don't use it for anything other than learning."

I haven't looked at this project, so maybe it does have those warnings.

Post reply on HN