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

Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

darkwire.io

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#31

Post by nialo »

rqs wrote: post #18
zaarn wrote: post #13

Earlier quoted context omitted.

What you describe is MtE (Mac Then Encrypt), which is generally not recommended because you have to decrypt ciphertext before you can check the MAC. This can lead to various timing or padding oracle vulnerabilities. The recommended, more safer and sturdier method is EtM (Encrypt then MAC), in which you encrypt the plaintext then MAC the ciphertext. This way you can verify the cipher before you operate on it. EtM is […

I implemented a protocol that uses MtE on a CFB mode cipher. And that's why I asked that question. Now, it seems like I may did it horribly wrong, I'm going to fix it right now. Thank you! EDIT: After I read an answer[0] on StackExchange, I realized I maybe did it right (Because of the CFB mode is different than CBC). Looks like I need to learn a whole lot more before start that fixing. Next time I'll just use GCM an…

In the spirit of learning about these things, you might want to try these: https://cryptopals.com/

In particular, problem number 17 from set 3 is an attack against CBC mode AES used with Mac-the-Encrypt. Maybe a fun exercise would be to first implement that attack against CBC mode, and then try to see if you can make it work against your CFB-HMAC protocol.

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#32

Post by alanfriedman »

tptacek wrote: post #3

This doesn't look especially safe. In addition to the fact that the crypto is delivered by the server, and so every browser/server transaction is an opportunity for the server to surreptitiously backdoor the crypto operations, the underlying crypto here appears to be CBC+HMAC where the payloads are decrypted before the HMAC is checked.

Firstly, thanks for inspecting the source and offering a suggestion for improvement. The latter point should be a relatively easy fix.

As for your first point, there’s little we can do to prevent TLS or AWS tampering. But we can make it easier to choose e2e encryption in the first place. So we focused on reducing barriers to entry (no signup required, simple URL-based rooms) as well as providing these benefits over alternatives:

- Open source code

- Ephermeral message history (not persisted in a DB)

- Opt-out anonymity

We think these features make Darkwire a good solution for many users seeking secure, private online communication. Having said that, no solution is perfect and we hope to see contributions from the open source community to make it even better.

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#33

Post by snvzz »

mxuribe wrote: post #27

Kudos for working in this space...but why not just contribute to something like matrix? See: https://matrix.org/docs/guides/faq.html#what-is-matrix

Not the same thing by far. Matrix is a complex sindicalised protocol, this is a simple centralised chat with encryption.

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#34

Post by alanfriedman »

DyslexicAtheist wrote: post #20

Without looking deeper into the app ... The WebCrypto standard makes a lot of assumptions in terms of underlying security and is dangerous (if not negligent) without proper security headers (XSS, CSRF, CSP), in place[0]. Since this site positions itself as a security relevant app, mistakes like these are incredibly worrying. https://securityheaders.io/?q=https%3A%2F%2Fdarkwire.io%2FSk...

Thanks for pointing this out. We'll work on getting fixes in ASAP.

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#37

Post by tptacek »

zaarn wrote: post #21
rqs wrote: post #18

Earlier quoted context omitted.

I implemented a protocol that uses MtE on a CFB mode cipher. And that's why I asked that question. Now, it seems like I may did it horribly wrong, I'm going to fix it right now. Thank you! EDIT: After I read an answer[0] on StackExchange, I realized I maybe did it right (Because of the CFB mode is different than CBC). Looks like I need to learn a whole lot more before start that fixing. Next time I'll just use GCM an…

MtE isn't the worst choice, I've seen way worse. The best I can recommend is to take NaCl and then just using secret box. That picks the good defaults for you. Anything after that needs some research as even seemingly harmless naive implementations can ruin the entire cryptography of a program.

I don't know what "not the worst choice" means in this context. MtE compositions are generally vulnerable. Are there more flagrant ways to be vulnerable? Sure, I guess?

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#38

Post by tptacek »

alanfriedman wrote: post #32
tptacek wrote: post #3

This doesn't look especially safe. In addition to the fact that the crypto is delivered by the server, and so every browser/server transaction is an opportunity for the server to surreptitiously backdoor the crypto operations, the underlying crypto here appears to be CBC+HMAC where the payloads are decrypted before the HMAC is checked.

Firstly, thanks for inspecting the source and offering a suggestion for improvement. The latter point should be a relatively easy fix. As for your first point, there’s little we can do to prevent TLS or AWS tampering. But we can make it easier to choose e2e encryption in the first place. So we focused on reducing barriers to entry (no signup required, simple URL-based rooms) as well as providing these benefits over a…

Just to be clear: I didn't look carefully; I looked for about 2 minutes, found the first indication of unsound crypto I could, and then stopped.

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#39

Post by rndgermandude »

alanfriedman wrote: post #32
tptacek wrote: post #3

This doesn't look especially safe. In addition to the fact that the crypto is delivered by the server, and so every browser/server transaction is an opportunity for the server to surreptitiously backdoor the crypto operations, the underlying crypto here appears to be CBC+HMAC where the payloads are decrypted before the HMAC is checked.

Firstly, thanks for inspecting the source and offering a suggestion for improvement. The latter point should be a relatively easy fix. As for your first point, there’s little we can do to prevent TLS or AWS tampering. But we can make it easier to choose e2e encryption in the first place. So we focused on reducing barriers to entry (no signup required, simple URL-based rooms) as well as providing these benefits over a…

Given that the server distributes the keys, and there is no way for the user to compare/verify known-good keys of other users, it's possible for the server to MITM everything, actively, meaning modification instead of just eavesdropping.

>- Open source code

Open source doesn't save you either, because a user cannot inspect what is actually running on the server.

And even the client side, while the code is technically there (downloaded to the browser in minified form), it's not feasible for a user no matter what level of skills to verify the distributed code is actually what's open sourced in your github repository and that the code stays like that whenever you refresh or reopen the site.

So basically, you need to trust the server (operator) and your webcrypto scheme does not provide any additional security whatsoever given that the server (operator) can MITM it trivially. The only thing preventing third parties other than the server (operator) in a MITM position to do harm is the TLS, but not your webcrypto scheme.

>- Ephermeral message history (not persisted in a DB)

Even with best intensions, what happens when you receive some National Security Letter, court order or similar, which forces you into silently MITM the key exchanges, thereby enabling you to MITM the messages and then log every message and pass that to some state actor?

To say something positive, I like the minimal UI and the way you handle file uploads. Even tho your service cannot fulfill the strong user-to-user security it somewhat claims, it's still a nice chat tool.

However, since your service is easy to use (copy-paste just one URL and type away), I'd guess soon enough you'll run into the same troubles as similar services where some bad users (e.g. from the chans) will use your service to e.g. distribute child pornography, revenge porn and other very illegal content.

Re: Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)

#40

Post by alanfriedman »

rndgermandude wrote: post #39
alanfriedman wrote: post #32

Earlier quoted context omitted.

Firstly, thanks for inspecting the source and offering a suggestion for improvement. The latter point should be a relatively easy fix. As for your first point, there’s little we can do to prevent TLS or AWS tampering. But we can make it easier to choose e2e encryption in the first place. So we focused on reducing barriers to entry (no signup required, simple URL-based rooms) as well as providing these benefits over a…

Given that the server distributes the keys, and there is no way for the user to compare/verify known-good keys of other users, it's possible for the server to MITM everything, actively, meaning modification instead of just eavesdropping. >- Open source code Open source doesn't save you either, because a user cannot inspect what is actually running on the server. And even the client side, while the code is technically…

Thanks for the feedback. If we assume the server is compromised then it's true that a MITM attack is trivial. However it seems to me this would be the case for any web-based e2e chat application, all of which must use a server by definition.

Regardless, it's easy enough to spin up your own instance of Darkwire (`docker compose`) and operate the server yourself if so inclined.

Post reply on HN