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

11–20 of 48 posts

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

#11

Post by gurgus »

marknadal wrote: post #6

Quick response to some of the comments here: - 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,…

> - 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.

Whatsapp does have a browser based app. web.whatsapp.com

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

#12

Post by rqs »

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.

I agreed with most of part, but

> 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?

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

#13

Post by zaarn »

rqs wrote: post #12
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.

I agreed with most of part, but > 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 wha…

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 [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.

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

#14

Post by rakoo »

rqs wrote: post #12
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.

I agreed with most of part, but > 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 wha…

The Cryptographic Doom Principle (https://moxie.org/blog/the-cryptographic-doom-principle/)

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.

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

#15

Post by rqs »

rakoo wrote: post #14
rqs wrote: post #12

Earlier quoted context omitted.

I agreed with most of part, but > 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 wha…

The Cryptographic Doom Principle ( https://moxie.org/blog/the-cryptographic-doom-principle/ ) 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 a…

Thank you for the link and explanation, I've learned a lot today.

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

#16

Post by edoceo »

rymate1234 wrote: post #8
marknadal wrote: post #6

Quick response to some of the comments here: - 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,…

Isn't the web crypto API chrome only at the moment?

No

https://caniuse.com/#search=Crypto

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

#18

Post by rqs »

zaarn wrote: post #13
rqs wrote: post #12

Earlier quoted context omitted.

I agreed with most of part, but > 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 wha…

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 and save all these troubles.

[0] https://crypto.stackexchange.com/questions/42369/is-this-sym...

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

#19

Post by marknadal »

gurgus wrote: post #11
marknadal wrote: post #6

Quick response to some of the comments here: - 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,…

> - 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. Whatsapp does have a browser based app. web.whatsapp.com

I get a "download the app to scan QR code and login" wall / lock-out. This wouldn't count as being browser-based!

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

#20

Post by DyslexicAtheist »

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...

Post reply on HN