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 Vanitasvitae _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
