Show HN: Darkwire.io – instant encrypted web chat (Socket.io and Web Crypto API)
darkwire.io
darkwire.io
> the payloads are decrypted before the HMAC is checked
I mean, on ClientA, I can calculate the HMACA of the plain-text, then encrypt the plain-text using KeyA to get MessageA
Then, on ClientB, I decrypt the MessageA using KeyB to get plain-text, and calculate HMACB from the plain-text.
After all that, I can still compare HMACA against HMACB to check if the message is authentic.
So what seems to be the problem here?
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 [according to wikipedia] "[...] the only method which can reach the highest definition of security in AE [...]".
Being able to supply arbitrary data into your system and have said system blindly apply a secret key to it is IMO not the safe mode. The safe mode is verifying that the data is from a source we can at least moderately trust to now spew out garbage and has the secret key anyway.
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 and save all these troubles.
[0] https://crypto.stackexchange.com/questions/42369/is-this-sym...
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.
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.
Long story short: writing HMAC code that works correctly is fairly easy, writing Encryption code that works correctly much harder, which means there are way more chances a bug will appear. You don't want to send wild unchecked data to that piece of code, because an attacker might be able to exploit the total lack of checks and extract some information about the plaintext, so you really want to verify it comes from a trusted party before munching it.
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.
>- 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.
Regardless, it's easy enough to spin up your own instance of Darkwire (`docker compose`) and operate the server yourself if so inclined.
You'll want to look into how real cryptographically secure open source comms apps do end to end encryption. Properly implemented, the server can be fully hostile and never recover messages.
Then you'll need to go remove every claim of e2e or cryptographic security from darkchat. Thank you for your time.
Also while I appreciate the feedback, this comment struck me as more hostile than helpful, so I’d suggest having a look at HN comment guidelines for future reference.
I am really interested in knowing how you reached your conclusions based on seeing the js file. I am quite new to analysing the source files of a given website using the firefox web console. I tried copying it to a text editor but, man, it was a mess to read. Any pointers as to how I might proceed ?
Thank you. I will look into this.
However, in this case, I can analyze the source now because it is available to me. What should I do when the source isn't available ? How do I proceed when all I have is the 'minified output'?
https://securityheaders.io/?q=https%3A%2F%2Fdarkwire.io%2FSk...
I've always thought something like this using WebRTC + a (simple) way to independently check that no data is being sent elsewhere would be really cool.
Btw you could declare a content security policy for just your site since you don't load anything off domain https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Good luck!
- WebRTC is great in theory, terrible in practice (doesn't work very well), and still needs a bootstrapping server. So it is better to have a reliable websocket based server as the default/fallback, and WebRTC progressively enhanced.
- Signal and Whatsapp, as others have pointed out, are far from being comfortable as being private (they already know too much, phone number, etc.), and don't have the convenience of a browser based app.
- Yes, this app should be using the Web Crypto API (it is what we switched over to, for our P2P cryptographic user accounts: https://github.com/amark/gun/wiki/auth ) to reduce dependency on the server. You can use the `integrity` attribute to help out with this, but ultimately unless somebody installs it as an Electron app or something, browser based crypto has its limitations.
Whatsapp does have a browser based app. web.whatsapp.com
You can argue semantics if that counts as browser based or not, but I think that's actually a pretty sane way to to things, security wise.
So sad that young generations don't know what an IRC stands for.
I wonder if the word "dark" makes the name have a negative connotation?
I think Matrix (Riot) would be a better choice. It's e2e encrypted like Signal but doesn't have any nonsense reliance on phones or phone numbers. It also has extra features like true multiple device support, a federated protocol and an open server implementation.