Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 45 posts

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

#21

Post by superuser2 »

gojomo wrote: post #18
jdiez17 wrote: post #16

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

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…

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 they thought was a secure chat, and that password led to an industrial control system for, say, a subway, water treatment plant, foundry furnace, or explosive chemical storage tank. Software doesn't just move Tweets. There are massive, hot, high-voltage, fast-moving objects controlled by software also. Letting people believe information is safe when it isn't can have very real consequences.

Unless it is obviously written all over your software that "THIS IS A TOY AND YOU SHOULD NOT EXPECT IT TO ACTUALLY KEEP ANYTHING SECRET," your obviously and embarrassingly broken crypto (to a crypto expert) might look just fine to a nontechnical user with dollars and/or lives riding on your product.

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

#22

Post by orclev »

Shish2k wrote: post #12

Slightly tangential, but can people please stop naming their software "salt"? This is like the 4th or 5th relatively high profile project I've seen with that name recently :/ More on topic - does anyone have any good reference guides for how to not suck at cryptography, preferably more "API guide for programmers in a hurry" than "maths textbook for people who want to learn the inner details of algorithms for their ow…

The problem is really that doing crypto "right" has a lot of very subtle very complicated corner cases that are very easy to get wrong if you don't fully understand the internals. I'm not an expert on crypto, but I know enough to know I wouldn't ever dream of rolling my own. Your best bet is to get one of the well established (and well regarded) crypto libraries, pick a suitably large key length (if in doubt, go larger), and follow the documentation exactly.

Even using a good crypto library won't save you if you don't follow the docs or try to get creative with the API. For instance, using multiple passes of different encryption algorithms won't necessarily improve the strength of the encryption. Due to subtle mathematical interactions it can often lead to exploits that wouldn't have existed in the individual algorithms, but do exist in the combined algorithm. Similarly doing encryption quickly might seem like an important goal, but often consistency is more important lest you inadvertently create a potential timing attack.

TL;DR; Use a good crypto library, a large key size, a good source of entropy, and follow the documentation exactly, don't try to get creative with it.

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

#23

Post by gojomo »

superuser2 wrote: post #21
gojomo wrote: 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…

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 isn't going to kill or bankrupt him twice over.

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

#24

Post by lawl »

Wow.

> WARNING: Unable to decrypt. One of you may have changed keys or might be an imposter. Run /idexch if you trust this person.

This may very well be the worst advice you could possibly give.

Suppose Alice and Bob already have a conversation. Then Eve wants to start MITM'ing during middle of the conversation and has already missed the key exchange (where she could easily switch Alice and Bob's public keys because your application doesn't even try to authenticate). Now she just needs to corrupt the packages so your app tells them to do a key exchange again and now can easily switch alice and bobs public keys for a set of her own ones and read everything.

Key exchanging is the hardest problem your app would have to overcome to actually be secure, telling your users to just do it again over an unauthenticated connection is just ... stupid, sorry.

Plus from glancing over it it lacks things like session keys etc.? Though that might well be in the NaCl lib, so I'm not sure about this.

I'd just ask you to label this as POC or something, because no one should use this application for anything that needs to even remotely stay secret.

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

#25

Post by lelandbatey »

gojomo wrote: post #18
jdiez17 wrote: post #16

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

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.

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

#26

Post by _b8r0 »

superuser2 wrote: post #21
gojomo wrote: 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…

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…

Crypto experts are not beautiful or unique snowflakes, armchair or otherwise.

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

#27

Post by davidroetzel »

StavrosK wrote: post #9

Don't we already have a secure chat protocol, SILC? Is that not good enough to use? Maybe Cryptocat et al could implement it, rather than creating their own.

SILC has it own set of problems though: https://we.riseup.net/riseup+tech/problems-with-silc

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

#28

Post by lukashed »

Shish2k wrote: post #12

Slightly tangential, but can people please stop naming their software "salt"? This is like the 4th or 5th relatively high profile project I've seen with that name recently :/ More on topic - does anyone have any good reference guides for how to not suck at cryptography, preferably more "API guide for programmers in a hurry" than "maths textbook for people who want to learn the inner details of algorithms for their ow…

Maybe it's due to the name, but the "other" salt, saltstack, apparently had a serious problem with cryptography: https://github.com/saltstack/salt/commit/5dd304276ba5745ec21...

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

#30

Post by laumars »

lawl wrote: post #24

Wow. > WARNING: Unable to decrypt. One of you may have changed keys or might be an imposter. Run /idexch if you trust this person. This may very well be the worst advice you could possibly give. Suppose Alice and Bob already have a conversation. Then Eve wants to start MITM'ing during middle of the conversation and has already missed the key exchange (where she could easily switch Alice and Bob's public keys because…

This is one of the reasons why I think HTTPS isn't as secure as many perceive. Users have become so acclimatised to ignoring SSL warnings due to mixed content, expired or self signed certs and browsers have made it so inconsequential to skip said warnings that many users wouldn't think twice about ignoring those errors if there was a genuine MITM attack.
Post reply on HN