[OTR-dev] Re: Requirements for libotr4

Ian Goldberg ian at cypherpunks.ca
Fri Jun 20 09:26:10 EDT 2008

On Thu, Jun 19, 2008 at 11:15:06PM -0400, Paul Wouters wrote:
> > I don't want to put anything thready into libotr, but we can have a
> Please remember to put a method in the API to send over symmetric session
> keys for support of file transfers, voice/video talk etc.

How's this:

To tell the other side to use a symmetric key (chosen by libotr),
attach an OTRL_TLV_SYMKEY TLV to a Data message.  The contents of that
TLV can be anything you like (an id identifying the key, a filename,

The receiver will get a callback:

    /* We received a request from the buddy to use the current "extra"
     * symmetric key.  The key will be passed in symkey, of length
     * OTRL_EXTRAKEY_BYTES.  The TLV which carried the request will be
     * passed in tlv, so that the applications can communicate other
     * identifiers (some id for the data transfer, for example). */
    void (*received_symkey)(void *opdata, ConnContext *context,
           OtrlTLV *tlv, const unsigned char *symkey);

[OTRL_EXTRAKEY_BYTES is currently 32, so you can use, say, the first
half as an encryption key and the second half as a MAC key.  Or
encryption keys for two directions, or whatever you like.]

But note that there are no other semantics defined.  How will Bob's IM
application know what to do when it receives this key?  Do you have a
use case for this feature in mind?  I suppose the spec could say "unless
you have some (secure) mechanism telling you what you're supposed to do
with this key, you must ignore this TLV."

Note that this secure mechanism can be the information in the TLV, so
long as there's common agreement on what the values mean.  But that
seems a little tricky.  I guess whoever wants to use this feature (to
implement encrypted file transfers, say), should define the meaning of
the contents of the TLV.  Say the first 4 bytes are an identifier of the
semantic use of the key (00000001 == file transfer, 00000002 ==
encrypted voice, etc.) and the format of the rest depends on that value?

Any thoughts?

   - Ian

More information about the OTR-dev mailing list