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 < [email protected]> 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: [email protected] >
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
