[Standards] Encrypted Jingle File Transfer
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
> - 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
> - 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.
More information about the Standards