[Standards] XEP-0384 and inbox/omemo-filetransfer: Variable length of MAC

Andrey Gursky andrey.gursky at e-mail.ua
Tue Dec 13 23:25:46 UTC 2016

Hi all, hi Goffi,

On Mon, 12 Dec 2016 10:42:14 +0100 Goffi wrote:

> Hello,
> Le dimanche 11 décembre 2016, 21:40:19 CET Andrey Gursky a écrit :
> > Are there any major technical issues with omemo filetransfer that you
> > couldn't solve? Can't they be solved in general or it can be discussed?
> > Are you working on a successor XEP or if I'd need it I'd had to go on my
> > own?
> the file transfer protoXEP had the huge inconvenience of being linked to an 
> application (file transfer), losing one of the major advantage of Jingle (it's 
> flexibility with separation between transport and application).

could you explain this in a little bit more detail? One of the goals was:

> Keep the protocol flow as close to Jingle File Transfer as possible and
> only change the file description

> It should probably use the security precondition defined in XEP-0166 and 
> encrypt the stream between the application and the transport.

So what is now looking as <encrypted> should be placed into <security>
and sent separately in a security-info message?

But still, if I'd like to transfer an encrypted file, I'd have to
advertise its metadata (name, date) as plaintext in the offer. This
must be avoided. I'm wondering, if I'd place an encrypted XML Node with
the file metadata into some tag, would it be OK? Or the proper way is
to prepend an encrypted file transfer with this information over the
transport channel?

One other problem with encryption of the stream, is that the key must
change from time to time, which is unusual, since it would happen in the
middle of the Jingle Session. I'm wondering how this could be achieved
concerning the asynchrony between the transport channel and the signal

> very excited to see all this moves in e2e encryption by the way :)

I'm also. But now it's likely to make a step back :(


More information about the Standards mailing list