6 ms·

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 mu

by lawl 13y ago

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

XorNot 13y ago
A WhatsApp client with OTR would be sweet as well.
- lawl 13y ago
  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)
  - xnyhps 13y ago
    > (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-WhatsApp.md 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.
- phaer 13y ago
  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?
  - LaGrange 13y ago
    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.
- therealmarv 13y ago
  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.
  - exo762 13y ago
    Modified version of OTR (by Moxie) works around that restriction. https://www.whispersystems.org/blog/asynchronous-security/ https://www.whispersystems.org/blog/asynchronous-security/
    - ciex 13y ago
      Doesn't this solution require trust in the server caching the pre-keys?
      - jlund 13y ago
        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.
- therealmarv 13y ago
  And BTW. There is a solution also with group chat and encrypted (Android and iOS): https://threema.ch https://threema.ch . Servers and company in Switzerland and only one small one time fee.
  - p4bl0 13y ago
    Threema seems nice. Too bad it's not free software, especially since it comes with security claims.
    - mst 13y ago
      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.
      - p4bl0 13y ago
        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…
        mst 13y ago
        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'.
- iknowwhatuwant 13y ago
  https://telegram.org/ 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.
  - sdfjkl 13y ago
    https://telegram.org/faq#q-why-not-open-source-everything https://telegram.org/faq#q-why-not-open-source-everything
runn1ng 13y ago
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?
- Ihmahr 13y ago
  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.
  - xnyhps 13y ago
    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.
    - deleted 13y ago
      [deleted]
- ef4 13y ago
  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.
  - 13y ago
p4bl0 13y ago
You should checkout Jitsi [1]. It does voice and video over ciphered XMPP. [1] http://jitsi.org/ http://jitsi.org/
- sdfjkl 13y ago
  ZRTP actually, XMPP is used only to set up the calls (using Jingle) and for ICE discovery.
rst 13y ago
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.
- cypherpunks01 13y ago
  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?
  - e12e 13y ago
    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.
    - im3w1l 13y ago
      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?
      - e12e 13y ago
        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).

by lawl 13y ago

XorNot 13y ago

A WhatsApp client with OTR would be sweet as well.

lawl 13y ago
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)
- xnyhps 13y ago
  > (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-WhatsApp.md 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.
phaer 13y ago
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?
- LaGrange 13y ago
  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.
therealmarv 13y ago
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.
- exo762 13y ago
  Modified version of OTR (by Moxie) works around that restriction. https://www.whispersystems.org/blog/asynchronous-security/ https://www.whispersystems.org/blog/asynchronous-security/
  - ciex 13y ago
    Doesn't this solution require trust in the server caching the pre-keys?
    - jlund 13y ago
      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.
therealmarv 13y ago
And BTW. There is a solution also with group chat and encrypted (Android and iOS): https://threema.ch https://threema.ch . Servers and company in Switzerland and only one small one time fee.
- p4bl0 13y ago
  Threema seems nice. Too bad it's not free software, especially since it comes with security claims.
  - mst 13y ago
    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.
    - p4bl0 13y ago
      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…
      - mst 13y ago
        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'.
iknowwhatuwant 13y ago
https://telegram.org/ 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.
- sdfjkl 13y ago
  https://telegram.org/faq#q-why-not-open-source-everything https://telegram.org/faq#q-why-not-open-source-everything

runn1ng 13y ago

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?

Ihmahr 13y ago
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.
- xnyhps 13y ago
  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.
  - deleted 13y ago
    [deleted]
ef4 13y ago
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.
- 13y ago

p4bl0 13y ago

You should checkout Jitsi [1]. It does voice and video over ciphered XMPP. [1] http://jitsi.org/ http://jitsi.org/

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

rst 13y ago

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.

cypherpunks01 13y ago
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?
- e12e 13y ago
  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.
  - im3w1l 13y ago
    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?
    - e12e 13y ago
      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).