[Standards] Encrypted Jingle File Transfer
andrey.gursky at e-mail.ua
Wed Jun 7 18:20:51 UTC 2017
On Sun, 4 Jun 2017 15:01:45 +0200 Vanitas Vitae wrote:
> As part of my GSoC project I'd like to think of a way to enable
> end-to-end encrypted Jingle file transfer. It should be possible for
> participants to exchange files encrypted by exchanging a key using the
> encryption scheme of their choice (OMEMO, OpenPGP, OTR...).
> Some nice-to-have properties I can think of are:
> 1. authenticity and integrity (recipient must be sure, the content was
> sent by the sender and has not been tampered with)
> 2. All known transport methods can be used
> 3. no leaking of metadata about the file (filename, size, extension,
> type, hash etc.)
> First of all I have to point out that I'm pretty new to the XMPP
> community, so there are most definitely things I forgot/did not think of :)
> I threw together a naive first approach to solve the problem and
> sketched it out as session-initiate jingle elements.
> The main idea is, that the session-initiate stanza contains an AES key
> used to decrypt the file that will be sent during the session.
> This key is - along with metadata about the file - encrypted using the
> encryption method of choice. The recipient would decrypt the key and
> information, than the user would accept the transfer and later use the
> key to decrypt the file.
[ snip ]
Since files are mostly too big to be transfered at once, the data is
actually transferred in chunks. If you consider the Goffi's proposal,
then you have only some chunks of data to transfer, no files in
general. What happens if a transfer has been interrupted? You should be
able to resume it. But can you do it?
With conventional cyphers, there is no problem: what has been received
can be decrypted. The size of a partial received file then can be sent
during session initialization. The sender should start with encryption
only after receiving this information.
A problem arises once you switch to newer authenticated cyphers like
AES GCM. Even if the whole data is pre-encrypted (in opposite to the
on-the-fly encryption) and thus it is possible to obtain the
authentication block, which could be sent in advance. Still it
shouldn't be possible to decrypt the partially received data, because
it is not possible to verify the authentication partially [*]. Thus the
only way I see is to encrypt data chunks separately. Say for every 64
KB, which is a conventional size for file I/O operations buffer. While
it is not necessary to use a new KEY for every new data chunk, it seems
it is unavoidable to use a new IV . An agreement can be made, that
consecutive IVs are not random, but incremented. This could be even
considered as an advantage, since this will guarantee, that for a
particular KEY, there will be no same IV, which would be fatal. And for
one KEY the total amount of data that can be encrypted is big enough.
[*] Would be nice to obtain the current value of the authentication
block and send it with every data chunk, but who knows, whether it
wouldn't break the security .
More information about the Standards