[guardian-dev] serverless XMPP as
Kevin Steen
mayfirstorg at kevinsteen.net
Thu Apr 19 05:30:24 EDT 2012
I think it could be done without any mDNS broadcast by putting the
listening IP port & addresses with a key/fingerprint in a QR code
displayed on the screen :
- User selects 'Start Sync' on the 1st device ('server')
- Server starts listening on a random port
- Server displays Port number, IP address(es), certificate
fingerprint/OTR key and a QR code incorporating all that
information.
- User selects 'Start Sync' on 2nd device ('client'), then
selects 'Scan QR code' button & scans QR code.
- Client connects to server, providing a client certificate/key and
sends a random string.
- Server changes displayed QR code to show it's own random string
and the client's random string.
- Client scans second QR code to authenticate the server, then sends
the server code via the secure connection.
- Server receives displayed code and authenticates client.
- Both devices display the peer details and a list of sync-able
categories then request a positive Proceed or Cancel selection
from the user.
- Server starts sync protocol over secured, authenticated connection.
After the first time, both sides can store the peer's certificate/key so
as to skip the second scan for future sync connections. The user
interface could allow the naming of different devices and control over
which items should be synced with that device.
This aims for a more peer-to-peer approach, so that the link between
devices could be extended to allow syncing public PGP keys, documents,
etc between friends.
I think the keys/certificates used for syncing should not be available
to sync between devices, but should be persistent to each device+user
combination. i.e. My phone would only have a single key since it is only
used by me, but a shared PC might have a key for each user account.
I believe the ManusVexo project already has code for displaying QR codes
on Android.
-Kevin
On 19/04/12 03:30, Hans-Christoph Steiner wrote:
>
> Yeah, it definitely shouldn't be always on, but something that the user enables. A regular session would go like this:
>
> - in Gibberbot, user clicks "Start Sync"
> - Gibberbot activates serverless XMPP account dedicated to sync
> - Gibberbot broadcasts mDNS service announcement
> - OTRConverter picks up the broadcast and adds Gibberbot as a sync option
> - OTRConverter sends AUTH to Gibberbot sync account
> - OTRConverter sends GET to Gibberbot sync account
> - Gibberbot sends otr_keystore to OTRConvertor
> - OTRConverter syncs it with local Pidgin/Adium/etc. keystores
> - OTRConverter sends Gibberbot a PUT with the new synced otr_keystore
> - Gibberbot replaces its otr_keystore with the new one
> - Gibberbot turns off sync account
>
> In order to setup the sync, the user would have to do this on the first syncattempt:
> - in Gibberbot, user clicks "Start Sync"
> - Gibberbot activates serverless XMPP account dedicated to sync
> - Gibberbot broadcasts mDNS service announcement
> - Gibberbot shows a screen with OTR fingerprints
> - OTRConverter picks up the broadcast
> - OTRConvertor shows its screen with OTR fingerprints
> - user verifies and clicks "NEXT"
> - Gibberbot shows a screen with a passphrase + QR Code version of it
> - user enters passphrase into OTRConverter prompt screen (or via QR scan)
> - OTRConverter sends AUTH to Gibberbot sync account
> - OTRConverter sends GET to Gibberbot sync account
> - Gibberbot sends otr_keystore to OTRConvertor
> - OTRConverter syncs it with local Pidgin/Adium/etc. keystores
> - OTRConverter sends Gibberbot a PUT with the new synced otr_keystore
> - Gibberbot replaces its otr_keystore with the new one
> - Gibberbot turns off sync account
>
> .hc
>
>
>
> On Apr 18, 2012, at 7:59 PM, Miron wrote:
>
>> It's an interesting idea. I think it's important that the user be aware
>> of the account, but yes, we could have multiple such accounts. In fact,
>> that might already work.
>>
>> We should also think about security and privacy implications, as well as
>> technical considerations. For example, the serverless account does a
>> multicast. That has an impact on privacy if always on. Also, should
>> the connection be used as a sequence of packets or a stream?
>>
>> It would be interesting to figure out how to use automated OTR
>> communication in other contexts.
>>
>> On 18/04/12 16:08, Hans-Christoph Steiner wrote:
>>> Hey Miron,
>>>
>>> In case you missed this in #guardianproject today:
>>>
>>> n8fr8 and I were just discussing the possibility of using serverless XMPP as a protocol for syncing the OTR key info with the desktop. I'm writing a desktop client, then we'd make Gibberbot have a protocol to get and put the keys. It could be via HTTPS or just some TLS socket, but it seems cooler to do it with serverless XMPP. I guess there would have to be an invisible serverless account in Gibberbot to be the sync agent. Could there be multiple serverless accounts?
>>>
>>> .hc
>>> _______________________________________________
More information about the Guardian-dev
mailing list