Hi Paul,
12.06.2017, 22:04, "Vanitas Vitae" <[email protected]>:
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?
Well, if you're on the bleeding edge of the XMPP development, it doesn't
mean, that you're not also on experimental versions of other components
:) which could lead to loosing access to the running XMPP client.
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 :)
Resuming of file transfer is trivial in general: no need to cache data,
keys or remember something else. Just point your client to save the file
under the same name which already exists, then the length of that file
could be queried and transmitted to the sender. You could look how
wget/curl work.
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.
If "possible reusing KEY/IV" could be easily avoided, better to avoid it
sooner.
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?
AES-GCM is already a one. The question is only when to append MAC, so
that a piece could be not only decrypted but also
authentication-verified. Just use either a fixed length of a chunk (e.g.
8, 16, 64 KByte) or a 16 bit length field (as in TLS) and specify the
particular length during a handshake.
That's why I'm tending to the "chunk" approach now.
Andrey
Jingle File Transfer does support resuming. Adding encryption is a
wanted thing (thank you for working on it!), provided you're not
dropping other features (that are not in contradiction to a new
encryption feature).
Regards,
Andrey
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
