[guardian-dev] OTR file transfer work day

Abel Luck abel at guardianproject.info
Tue Apr 9 05:00:44 EDT 2013


I dabbled with this library for xmpp bots before, it is insanely simple:
http://xmppflask.org/

Just another data point :)

~abel

Hans-Christoph Steiner:
> 
> Miron and I met at Scal.io's office to figure out how to do OTR key syncing
> via OTR messages.  This is originally inspired by Miron's work on OTR file
> transfer.  Originally we planned on using the TLV Type 8 "Extra Symmetric Key
> Data" field in an OTR packet since it provides an area for generic data with a
> 4-byte ID as the first bit of data.  We looked at libotr, otr4j and
> pure-python-otr to see whether we could do this, and we saw that we could just
> use some other TLV number that we chose instead of using Type 8 for something
> that it wasn't designed for.  Miron then changed his TLV Type 8 implementation
> for otr4j to have an API for getting generic TLVs.  That part is done.
> 
> Next up, we have to figure out how to add/update the keys once Gibberbot
> receives them.  We looked at Gibberbot's OTR implementation for places to
> plugin.  Ideally, Gibberbot would update the key information while its
> running, and that seems feasible by dealing with OtrAndroidKeyManager.  It
> will require some modifications to allow live input of OTR key data.
> 
> Gibberbot will also need to be able to kill active OTR sessions if it is going
> to update any key related to that session.  To do that, Gibberbot needs to
> first find all active OTR sessions.  otr4j maintains a list of active
> sessions, but its private, so either Gibberbot would have to register a
> listener and keep a list itself, or this would need to be exposed somehow in
> otr4j.
> 
> Then during the sync proces, as new keys are received, Gibberbot checks if
> that key exists and is different from existing one.  If its different, kill
> related OTR sessions and update that key.
> 
> It terms of the XMPP traffic, each key to be synced would be encapsulated in
> its own message.  Gibberbot needs to receive keys to sync, then also send keys
> upon request.  I've started messing around with python-jabberbot, its a
> framework for writing XMPP bots which is really nice and simple.  Adding OTR
> support to it should be pretty simple since its got clear send and receive
> methods.
> 
> For the fingerprint/verified key data, this protocol would retain the
> tab-separated value format of the libotr otr.fingerprints file.  We talked
> about possibilities for the account public/private keys, there is no clear
> standard across OTR implementation there (libotr uses S-expressions, otr4j
> uses base64 binary format, and pure-python-otr uses a pure binary format).  We
> talked about using a binary format but feared dealing with endian issues.  We
> thought a TSV format like the fingerprints might be easiest, even tho this
> format does not exist elsewhere.
> 
> For future work, Miron is going to continue on with the Gibberbot work, he has
> a couple days a month to spend on this. I'll continue exploring
> python-jabberbot and working out the rest of the protocol.
> 
> .hc
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/abel%40guardianproject.info
> 
> You are subscribed as: abel at guardianproject.info
> 



More information about the Guardian-dev mailing list