[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