Hacker News Reader

Comment by lawl | Hacker News Reader

When I saw this I really hoped I would click the link and it would say there that OTRv3 supports group chats now. Sadly that is not the case. But support for multiple logged in clients and a key for file transfer or voice is also cool.

I would hope that means that libjingle based voice chat's can soon be OTR'd too? Now pidgin just needs a decent interface for them...

Then we convince everyone to use XMPP (or google and facebook to [re]enable XMPP federation) and we can finally drop Skype.

wakes up from his dream

View on HN

Group chats would be multi-party OTR (a/k/a mpotr). There are a whole bunch of people working on this, and it's not hard to find draft specs, but they are drafts; doing the crypto right for this is a really hard problem.

Why is it so hard? It doesn't work where A simply OTR encrypts her message to the keys of B, C, D and broadcasts them together? Or is it more of a problem where the continuous key re-negotiation is hard?

I'm guessing they want to set up a single session key, maintain deniability as well as authentication, and avoid leaks of the key when someone leaves the chat... It certainly seems that maintaining all of OTR's guarantees is a lot more difficult with more than one party involved.

With two parties, you either have a chat (both in conversation) or the session is ended (one or both parties leave).

If all you want is "traditional" encrypted chat alternatives might serve you better.

I'm not sure if I think re-using the OTR public keys/ids for encrypted chat that effectively isn't OTR (deniability, forward secrecy) is a good idea or not. Perhaps demand some form of indication from the user agent that clearly show group chat and individual chat is different?

As for "just broadcast multiple copies" -- that also depends on use-case. 100 person chat room? 10 person video conference? 10/100x bandwidth might not be the best approach.

Let's say Alice, Bob, Caesar and Dolores want to communicate. Couldn't Alice just open a 1 on 1 chat with Bob, then with Caesar, and then a third one with Dolores. And couldn't she then just copy and paste her message to all of them at the same time? And couldn't this be automated?

Yes, but then Caesar would have to trust Alice to relay Bob (which could be a fine and pragmatic solution for some use-cases, but wouldn't really be "otr-for-workgroups"). It would also suffer from poor network topology which could be a problem for large chats and/or high bandwith (and/or low latency) chats (file transfer, audio/video chat).

You should checkout Jitsi [1]. It does voice and video over ciphered XMPP.

[1] http://jitsi.org/

ZRTP actually, XMPP is used only to set up the calls (using Jingle) and for ICE discovery.

A WhatsApp client with OTR would be sweet as well.

Technically there is no reason why it shouldn't have one.

If WhatsApp would just try to make their XMPP costumizations a standardized XMPP extension and enable federation on their service. Finally we have unified Instant Messanging.

dreams again

(btw there's nothing stopping you from adding OTR support to one of the open, reverse engineered, whatsapp clients)

> (btw there's nothing stopping you from adding OTR support to one of the open, reverse engineered, whatsapp clients)

Except, you know, DMCA notices: https://github.com/github/dmca/blob/master/2014-02-12-WhatsA....

Yes, this is complete bullshit. Especially how they try to use a DMCA notice for trademark infringement.

Why? I thought the selling point of this non-federated, proprietary jabber client was it's existing user base which would probably continue to use the official client. So what would be the benefit of an WhatsApp client with OTR?

Egzactly — the reason to use WhatsApp is that you’re pretty much guaranteed that the other side of the conversation sees your emoji, photos, videos and similar. The client-side unity is a feature.

We didn’t grow a standard on that side on our own, so it got done to us.

OTR for mobile chat messaging like WhatsApp was discussed several times. At least the former ones (do not know version 3) did not allow OTR because both clients have to be online for handshaking and exchanging keys which is very often not the case for two mobile phones.

Modified version of OTR (by Moxie) works around that restriction.

https://www.whispersystems.org/blog/asynchronous-security/

Doesn't this solution require trust in the server caching the pre-keys?

No, because you can still verify a user's fingerprint after the handshake has been completed. That's something that you'd want to do with traditional, non-asynchronous OTR as well.

And BTW. There is a solution also with group chat and encrypted (Android and iOS): https://threema.ch . Servers and company in Switzerland and only one small one time fee.

Threema seems nice. Too bad it's not free software, especially since it comes with security claims.

I think you meant "too bad the source isn't published" - one can security audit code that's published but copyrighted just as well as one can audit Free (as in speech) code.

If it's not free (as in freedom) software and I can't compile the version of the sources that the community inspected, then I don't really care that some source code is publicly shown. I can't verify that it's actually the code I run when downloading the precompiled app.

Thinking of it, it would be interesting to be able to display such proof…

If you can't ensure that the code you're running is compiled from the version of the sources that the community inspected, then yes, that isn't any useful version of "the source is published".

However, verification is a technical problem, not a licensing one. It's probably -easier- for free software, but that doesn't mean that's a necessary characteristic to be able to achive the goal of 'usefully aduited'.

https://telegram.org/

You have the option to use a second layer of encryption (via OTR), even without OTR it's encrypted... but it offers OTR for the more paranoid of folk.

It even advertises as a WhatsApp private alternative.

https://telegram.org/faq#q-why-not-open-source-everything

Support for more clients... what does that mean?

One of the reason I don't really use OTR as much as I would like to is that I cannot really take conversations from PC to Android phone, and then to another PC, and so on.

Does OTRv3 fix that?

That's actually one of the main things that's addressed by this v3 protocol:

> Both fragmented and unfragmented messages contain sender and recipient instance tags. This avoids an issue on IM networks that always relay all messages to all sessions of a client who is logged in multiple times. In this situation, OTR clients can attempt to establish an OTR session indefinitely if there are interleaving messages from each of the sessions.

If you've ever tried to have multiple devices logged in to one account using OTR, and you've ended up with an endless spam of "invalid message, resending" or some such, this is what they're talking about. Clients that support v3 properly shouldn't do that anymore, and you should be able to keep both your PC and phone logged in without problems.

That seems great! Is there some app implementing it correctly, on both mobile+PC? (Linux will do)

That is really an implementation of the app. The protocol does not prevent this in any way.

You would need an app that somehow upload some info to the server and that synchronizes this info across your devices in a secure way.

Synchronizing that info accross your devices is exactly something you'd need a protocol for. If you want to preserve the forward-secrecy that OTR offers, then you can't just "encrypt, upload" on one client and "download, decrypt" on another. You somehow need to do a key exchange between your own devices.

Reply on news.ycombinator.com