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

Hans-Christoph Steiner hans at guardianproject.info
Fri Apr 10 17:17:48 EDT 2015


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.

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 adds content to background service to upload to zerobin using an
upload URL that does not include the key in it (should be possible)

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

I suppose ChatSecure could use the OTR Extra Symmetric Key as the key, and
just store the Extra Symmetric Keys for the past few sessions.  But storing
keys is not ideal, but very difficult to avoid with async communication. If
the file has not been received by the time a couple of OTR sessions have
passed, it would no longer available.  If ChatSecure is storing a couple of
keys from past OTR sessions, then the key would not need to be sent in an OTR
message, just the URL.

.hc


Yaron Goland:
> I'm new so please be gentle. :)
> 
> But is the assumption here that Guardian (or equivalent) provides a public XMPP server in the same sense that zerobin appears to be providing a free upload server? And so one iOS phone can send an IM to the XMPP server who will store it and forward it when the second iOS phone shows up?
> 
> Is the idea that:
> 
> Phone 1 - Uploads content for Phone 2 to zerobin
> Phone 1 - Sends a XMPP message to Phone 2 via some XMPP server providing data about the zerobin location and key (presumably encrypted with Phone 2's key)
> Phone 2 - Is in the background the whole time but has a regular background download setup in iOS pointed at the HTTP front end for the XMPP server.
> Phone 2 - Eventually the phone does a background download from the HTTP front end of the XMPP server and receives the message from phone 1, process it in the network trigger (I think iOS gives network triggers on background downloads?) and then sets up a second background download pointed at zerobin's HTTP front end.
> 
> Is this the idea?
> 
>     Thanks,
> 
>             Yaron
> 
> ________________________________________
> From: guardian-dev <guardian-dev-bounces+yarong=microsoft.com at lists.mayfirst.org> on behalf of Hans-Christoph Steiner <hans at at.or.at>
> Sent: Thursday, April 9, 2015 8:09 AM
> To: Guardian Dev
> Subject: [guardian-dev] zerobin as possible temp store for ChatSecure iOS
> 
> Chris Ballinger and I were discussing the most private possible methods to
> transmit data on ChatSecure iOS that will work in the background.  Basically,
> iOS does not let normal apps operate in the background, but provides a service
> to do HTTP uploads and downloads in the background.  For many users, using a
> direct HTTPS file transfer that sends an end-to-end encrypted file is private
> enough, and the usability gain over OTRDATA on iOS would be then worthwhile.
> 
> This can be implemented using OTR TLV8 with a specific TLV8 bytecode to
> represent this kind of transfer.  Signal uses something like this, but with
> Amazon S3 as the store. I just found out about Zerobin from BastienLQ on
> #fdroid.  I think it can provide the perfect store for a system like this.  It
> is Free Software with an instance available here:
> https://www.zerobin.net/
> http://zerobinqmdqd236y.onion/
> 
> * client encrypts so only encrypted data is stored on the server
> * each paste/file can automatically expire
> * "Burn after reading" for a one time download
> 
> Here is more info on zerobin:
> http://sebsauvage.net/wiki/doku.php?id=php:zerobin
> 
> Here's a rough idea of how the file transfer idea would work for ChatSecure
> iOS using zerobin:
> 
> * zerobin provided by XMPP server
> * sender generates AES key and encrypts file
> * sender uploads encrypted file to zerobin using background service
>    * optionally, the URL is uploaded in foreground via Tor/.onion
> * sender sends AES key and zerobin URL in an OTR TLV8
> * next time receiver is online, it receives the TLV8
> * the AES key and URL is stored in SQLCipher
> * the URL is downloaded via the background service
>    * optionally, the URL is downloaded in foreground via Tor/.onion
> * once the file is downloaded, the AES key is fetched from SQLCipher
> 
> On Android, there is a lot more flexibility with this.  For example, the
> Android app can upload and download in the background via Tor/.onion.  So if
> the Android apps are always transfering via Tor while iOS apps do it directly,
> then there is no metadata link related to that file transfer visible by the
> server.
> 
> Feedback welcome, I think this could help with iOS usability a lot without
> leaking much extra information. I think it could also help make transferring
> large files with ChatSecure on Android more usable as well.
> 
> .hc
> 
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81


More information about the guardian-dev mailing list