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

[Patrick Connolly]

Just to chime in: Rather than entertain the idea of GCM (if that was the
implication?), might be an opportunity to investigate MQTT:

https://en.wikipedia.org/wiki/MQTT
https://github.com/mqtt/mqtt.github.io/wiki/libraries#java
http://www.cloudmqtt.com/


--------------------------------------------
Q: Why is this email [hopefully] five sentences or less? | A:
http://five.sentenc.es

*NOTE* that my emails are delayed from arriving in my inbox until 9am
daily. If urgent, please use another way of getting in touch.
#slowwebmovement <http://www.musubimail.com/gmail_timer.html>

On Sun, Apr 12, 2015 at 10:59 PM, Hans of Guardian <
hans at guardianproject.info> wrote:

>
> On Apr 11, 2015, at 6:40 AM, Michael Rogers wrote:
>
> > On 10/04/15 22:17, Hans-Christoph Steiner wrote:
> >>
> >> I don't know the details of iOS, so I can't really say much there.  So
> correct
> >> me if I get any of that part wrong.  But I think you get the gist of
> the idea.
> >> And to be clear, when I say 'zerobin', I mean any instance of the
> zerobin
> >> software, not only https://zerobin.net.
> >
> > If you're encrypting the file yourself rather than using zerobin's JS
> > crypto then you could use any pastebin, right?
>
> pastebin.com generally blocks tor.  But yes, your theory generally
> stands: encrypted base64 text could be posted to any pastebin-like
> service.  That's actually what Chris and I were originally talking about,
> but it seemed too difficult to handle all of the variances of the services.
>
>
> >> 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.
>
>
> >> * Phone1 adds content to background service to upload to zerobin using
> an
> >> upload URL that does not include the key in it (should be possible)
> >
> > Must be possible, otherwise zerobin could decrypt the content.
>
> Yup, and hopefully we can post to a zerobin instance using the iOS
> background service.  That's probably the bigger question mark here.
>
>
> >> * Phone1 sends a OTR-encrypted message to Phone2 via XMPP that includes
> the
> >> URL to download the content, as well as the key used (we can't rely on
> OTR's
> >> Extra Symmetric Key on Phone2 since the OTR session might be gone by
> the time
> >> Phone2 gets the message to download the content)
> >>
> >> * Phone2 receives OTR-encypted message and adds URL to background
> download
> >> service, and securely stores the zerobin URL that includes the key
> >>
> >> * once Phone2 gets the whole file, next time it is in the foreground,
> it can
> >> decrypt and display the file
> >>
> >> This approach hides the most metadata, especially if one side uses Tor
> to send
> >> or receive.  But it does not work with push services.  Ideally the
> download
> >> URL without the key would be sent via a push service, and that message
> would
> >> be encrypted with a key that both sides have already.  That's the hard
> part.
> >
> > 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.
>
> .hc
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150413/ab61e83b/attachment.html>