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

Michael Rogers michael at briarproject.org
Sat Apr 11 06:40:48 EDT 2015


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?

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

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

> * 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?

Cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20150411/559c60b6/attachment.sig>


More information about the guardian-dev mailing list