[guardian-dev] zerobin as possible temp store for ChatSecure iOS

[Yaron Goland]

The key issue I'm trying to understand is if the expectation is that one can use existing XMPP and ZeroBin providers to enable iOS users to do background downloads over HTTPS. Or is this a situation where users are expected to set up and run their own servers?
    Thanks,
        Yaron

________________________________________
From: guardian-dev <guardian-dev-bounces+yarong=microsoft.com at lists.mayfirst.org> on behalf of Michael Rogers <michael at briarproject.org>
Sent: Monday, April 13, 2015 1:21 AM
To: Hans of Guardian
Cc: guardian-dev at lists.mayfirst.org >> guardian-dev
Subject: Re: [guardian-dev] zerobin as possible temp store for ChatSecure iOS

On 13/04/15 03:59, Hans of Guardian wrote:
>>> We do have to work out how to protect some of the details, and figure out how
>>> to integrate with various push services like Apple or Google GCM.  Here's an
>>> attempt to flush some of that out, based on your outline:
>>>
>>> * Phone1 encrypts content with OTR Extra Symmetric Key
>>
>> Phone1 could use a fresh key here in order to avoid potentially
>> encrypting more than one file with the same key.
>
> As far as I understand it the OTR TLV8 Extra Symmetric Key is generated per session, but I could be wrong.  It has the big advantage of both sides being able to generate it without actually sending it to each other.

But there's only one key per session, right? What happens if you send
more than one file in a session?

>> How much work is the push message handler allowed to do? Can you, for
>> example, maintain a separate OTR session for push messages?
>
> Hmm, interesting idea.  I think that the timeframe might be too slow for OTR, but maybe there could be an axolotl session via the push framework.  That sounds a lot more complicated to implement though.  TextSecure uses GCM to do all of the message sending, so it should be possible.  I don't know about Apple's push though.

Does OTR have time limits? The only reference I can see to time in the
OTRv3 spec is the configurable time between heartbeat messages. It looks
like that could be made arbitrarily long if the implementation allows.

On the other hand, OTR requires in-order delivery - I don't know whether
push messages guarantee that.

Cheers,
Michael