[Standards] Encrypted Jingle File Transfer

Vanitas Vitae vanitasvitae at riseup.net
Mon Jun 12 20:04:29 UTC 2017

Hi Andrey :)

Am 12.06.2017 um 21:36 schrieb Andrey Gursky:
> I see two primary disadvantages of this approach:
> 1) From a programmer point of view: the KEY/IV pair must be cached for
>    each file, which IMHO are harder to achieve:
>    - if the application crashes, you lose the ability to resume a
>      transfer.
>    - if the OS session (e.g. DE, X-Server) crashes, the same.
>    - if the OS crashes, the same
>    and nasty to implement:
>    - if the application is restarted too often, additional file might be
>      needed?
>    - if the application is restarted too rarely, additional events must 
>      be issued for cleanup?

I get your points here. But is it really that big of a deal? I mean how
often does the X-server/OS session crash? Also the caching must only
happen on initiator side. When resuming the transfer, the initiator
can/must simply retransmit the key. I don't know, if conventional XMPP
applications are implemented in a way that allows file transfers to be
resumed across application restarts, so you might have a point there :)

> 2) Security
>    Using the same KEY/IV pair to encrypt the same data is allowed. But
>    intentionally making use of this would increase the chances to break
>    security, e.g. the file has been overwritten inbetween, thus
>    violating the requirement.

Note that this only happens on a per-file basis. I wouldn't consider
this much of a deal. I might be wrong of course.

> Other disadvantages:
> - Not possible to use the already received part of file, which is
>   useful for audio/video.
> - Unnecessary re-encryption of the whole file.
> - More processing time.
> - Higher memory / disk (cache) consumption.
> - Doesn't work for streams.

Can we maybe tackle all these points by using a stream cipher?

> That's why I'm tending to the "chunk" approach now.
> Andrey


More information about the Standards mailing list