4 ms·

I wonder how they encrypted their chat on the web client. Scince the Signal protocol is kind of the gold standard right now, probably their solution might in th

by stemuk 10y ago

I wonder how they encrypted their chat on the web client. Scince the Signal protocol is kind of the gold standard right now, probably their solution might in the end be the better one.

eps 10y ago
> Since the Signal protocol is kind of the gold standard right now Oy vey. The perils of reading HN too much.
- mintplant 10y ago
  What, in your opinion, is the gold standard?
  - drdaeman 10y ago
    For now, isn't is still plain old boring OTR? No less secure (and because of its mature age, it had received more auditors attention), far more ubiquitous, and while not perfect, still doesn't seem to have too severe limitations that make its use too hard or impossible.
    - moxie 10y ago
      OTR doesn't work in asynchronous environments, which makes it infeasible to deploy on mobile devices. I think that's a pretty severe limitation in today's world. In terms of ubiquity, Signal Protocol is running on over two billion monthly active devices. I would be surprised if OTR's active install base exceeds a hundred thousand.
      - drdaeman 10y ago
        Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering. Which doesn't seem too severe to me, if the saying about "always connected" world is true enough in reality. Maybe I'm deeply mistaken here. But, I mean, 99% of my conversations are when both participants are online, and it does work for me in practice (and I can't realistically replace it with Signal) - that's why I've had the opinion that it's still haven't gave up on "gold" yet. As for ubiquity - 2 billion devices is great (and hope there will be more!), but I meant the other sort of it. I've ran OTR sessions over XMPP, ICQ, Skype and Telegram. I guess, it's a wrong sort of ubiquity, probably not something that works for the goal of "encryption for everyone", but it still works if I don't want to hop the services but layer security instead. Maybe that's too old-fashioned. Hope there will be Signal Protocol-based addons/libraries like this one day.
        moxie 10y ago
        > Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering. It's an asynchronous world, trying to use a synchronous protocol in that world doesn't make a lot of sense. If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the device out of their pocket and physically tap the notification (which just says something like 'you might get a message soon'), then receive the response (which might involve pulling the device out of your pocket and physically tapping the notification which says something like 'you can send a message now'), before you can send the actual message. This isn't just "initial presence," either. OTR is a three-step ratchet, so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation and "start" an OTR session at the beginning of the next one. Except we don't live in a world where there are "beginnings" and "endings" anymore. People aren't sitting down at their computers and chatting until they get up again, it's just one long asynchronous conversation now. > I guess, it's a wrong sort of ubiquity, probably not something that works for the goal of "encryption for everyone", but it still works if I don't want to hop the services but layer security instead. Maybe that's too old-fashioned. Hope there will be Signal Protocol-based addons/libraries like this one day. You can do this today if you want to, but what's the point when Signal Protocol is being baked into the messaging services themselves. Layering encryption has been a losing strategy for a decade or more now, building something that works so seamlessly that it can be a part of the default experience is actually showing progress.
        drdaeman 10y ago
        > If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the device out of their pocket and physically tap the notification Is it still the case? I have never wrote code for iOS, but believe I heard this was the limitation only for very old versions and was solved quite a long time ago, with introduction of "silent" pushes (or whatever they call it, when there's no notification message but only a data transfer that wakes up the application). Should work unless the user had force-quit the app, in which case iOS won't start it. > so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation [edit/upd some minutes later] I'm confused now. If full system state (incl. long-term keys) is compromised, the whole system isn't secure anymore, no matter how many times it's rekeyed. And if only ephemeral keys (but not long-term ones) are compromised, won't OTR "heal" itself after a few messages, so FS property remains? I was misunderstanding OTR - I had assumed "ending" the conversation is required for deniability (by disclosing the MAC keys so anyone can forge the messages later), and encryption keys are changing as the conversation goes. > You can do this today if you want to In theory, yes, I suppose so. In practice, I've looked for a libpurple patch/fork with SP OTR-like overlay support, but haven't found any. > but what's the point when Signal Protocol is being baked into the messaging services themselves The problem is some popular services (e.g. Skype or Telegram) won't bake SP in. And a lot of users are there and aren't switching. The only viable short-term scenario is to ask them to layer the encryption (in my experience, there's way less resistance than when asking everyone to hop to another network) until the platform dies or otherwise becomes uncool.
niftich 10y ago
They use a Rust library [1] they wrote for the Axolotl protocol, which is the old name for the Signal protocol before it was renamed [2]. They refer to their implementation as 'Proteus'. [1] https://github.com/wireapp/proteus https://github.com/wireapp/proteus [2] https://whispersystems.org/blog/signal-inside-and-out/ https://whispersystems.org/blog/signal-inside-and-out/ EDIT: Their webapp is written in Coffeescript, including their cryptography functions used in said webapp [3]. [3] https://github.com/wireapp/wire-webapp/search?q=proteus&type=Code https://github.com/wireapp/wire-webapp/search?q=proteus&type...
- moxie 10y ago
  Wire does not use Signal Protocol. They used some of our code, but created a protocol of their own devising that we do not recommend. We renamed the Axolotl ratchet and Axolotl protocol because there was a lot of confusion around what it meant to say "Axolotl." Some people who continue to use the term "Axolotl" do so because they seek to benefit from that confusion. It is great that Wire has finally open sourced their software. They have been advertising themselves as open source for the past two years, though, so I guess they weren't really able to make an announcement about this.
  - niftich 10y ago
    That confusion definitely worked on me. This clarifies a lot, thanks!
moxie 10y ago
Signal Protocol supports both multi-device and groups out of the box. WhatsApp's choice to use "device routing" was not driven by encryption protocol limitations. The Signal desktop client, for instance, does not use device routing.

by stemuk 10y ago

I wonder how they encrypted their chat on the web client. Scince the Signal protocol is kind of the gold standard right now, probably their solution might in the end be the better one.

eps 10y ago

> Since the Signal protocol is kind of the gold standard right now Oy vey. The perils of reading HN too much.

mintplant 10y ago
What, in your opinion, is the gold standard?
- drdaeman 10y ago
  For now, isn't is still plain old boring OTR? No less secure (and because of its mature age, it had received more auditors attention), far more ubiquitous, and while not perfect, still doesn't seem to have too severe limitations that make its use too hard or impossible.
  - moxie 10y ago
    OTR doesn't work in asynchronous environments, which makes it infeasible to deploy on mobile devices. I think that's a pretty severe limitation in today's world. In terms of ubiquity, Signal Protocol is running on over two billion monthly active devices. I would be surprised if OTR's active install base exceeds a hundred thousand.
    - drdaeman 10y ago
      Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering. Which doesn't seem too severe to me, if the saying about "always connected" world is true enough in reality. Maybe I'm deeply mistaken here. But, I mean, 99% of my conversations are when both participants are online, and it does work for me in practice (and I can't realistically replace it with Signal) - that's why I've had the opinion that it's still haven't gave up on "gold" yet. As for ubiquity - 2 billion devices is great (and hope there will be more!), but I meant the other sort of it. I've ran OTR sessions over XMPP, ICQ, Skype and Telegram. I guess, it's a wrong sort of ubiquity, probably not something that works for the goal of "encryption for everyone", but it still works if I don't want to hop the services but layer security instead. Maybe that's too old-fashioned. Hope there will be Signal Protocol-based addons/libraries like this one day.
      - moxie 10y ago
        > Doesn't it? Not to challenge the authority, but I believe the only requirements OTR impose are constraints on the initial presence (thus, lack of offline operation) and constraints on message ordering. It's an asynchronous world, trying to use a synchronous protocol in that world doesn't make a lot of sense. If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the device out of their pocket and physically tap the notification (which just says something like 'you might get a message soon'), then receive the response (which might involve pulling the device out of your pocket and physically tapping the notification which says something like 'you can send a message now'), before you can send the actual message. This isn't just "initial presence," either. OTR is a three-step ratchet, so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation and "start" an OTR session at the beginning of the next one. Except we don't live in a world where there are "beginnings" and "endings" anymore. People aren't sitting down at their computers and chatting until they get up again, it's just one long asynchronous conversation now. > I guess, it's a wrong sort of ubiquity, probably not something that works for the goal of "encryption for everyone", but it still works if I don't want to hop the services but layer security instead. Maybe that's too old-fashioned. Hope there will be Signal Protocol-based addons/libraries like this one day. You can do this today if you want to, but what's the point when Signal Protocol is being baked into the messaging services themselves. Layering encryption has been a losing strategy for a decade or more now, building something that works so seamlessly that it can be a part of the default experience is actually showing progress.
        drdaeman 10y ago
        > If you want to initiate an OTR session with your friend on an iPhone, you have to wait for them to pull the device out of their pocket and physically tap the notification Is it still the case? I have never wrote code for iOS, but believe I heard this was the limitation only for very old versions and was solved quite a long time ago, with introduction of "silent" pushes (or whatever they call it, when there's no notification message but only a data transfer that wakes up the application). Should work unless the user had force-quit the app, in which case iOS won't start it. > so if you want the benefits of forward secrecy, you have to "end" your OTR session after each conversation [edit/upd some minutes later] I'm confused now. If full system state (incl. long-term keys) is compromised, the whole system isn't secure anymore, no matter how many times it's rekeyed. And if only ephemeral keys (but not long-term ones) are compromised, won't OTR "heal" itself after a few messages, so FS property remains? I was misunderstanding OTR - I had assumed "ending" the conversation is required for deniability (by disclosing the MAC keys so anyone can forge the messages later), and encryption keys are changing as the conversation goes. > You can do this today if you want to In theory, yes, I suppose so. In practice, I've looked for a libpurple patch/fork with SP OTR-like overlay support, but haven't found any. > but what's the point when Signal Protocol is being baked into the messaging services themselves The problem is some popular services (e.g. Skype or Telegram) won't bake SP in. And a lot of users are there and aren't switching. The only viable short-term scenario is to ask them to layer the encryption (in my experience, there's way less resistance than when asking everyone to hop to another network) until the platform dies or otherwise becomes uncool.

niftich 10y ago

They use a Rust library [1] they wrote for the Axolotl protocol, which is the old name for the Signal protocol before it was renamed [2]. They refer to their implementation as 'Proteus'. [1] https://github.com/wireapp/proteus https://github.com/wireapp/proteus [2] https://whispersystems.org/blog/signal-inside-and-out/ https://whispersystems.org/blog/signal-inside-and-out/ EDIT: Their webapp is written in Coffeescript, including their cryptography functions used in said webapp [3]. [3] https://github.com/wireapp/wire-webapp/search?q=proteus&type=Code https://github.com/wireapp/wire-webapp/search?q=proteus&type...

moxie 10y ago
Wire does not use Signal Protocol. They used some of our code, but created a protocol of their own devising that we do not recommend. We renamed the Axolotl ratchet and Axolotl protocol because there was a lot of confusion around what it meant to say "Axolotl." Some people who continue to use the term "Axolotl" do so because they seek to benefit from that confusion. It is great that Wire has finally open sourced their software. They have been advertising themselves as open source for the past two years, though, so I guess they weren't really able to make an announcement about this.
- niftich 10y ago
  That confusion definitely worked on me. This clarifies a lot, thanks!

moxie 10y ago

Signal Protocol supports both multi-device and groups out of the box. WhatsApp's choice to use "device routing" was not driven by encryption protocol limitations. The Signal desktop client, for instance, does not use device routing.