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