Hi Vanitas, On Sun, 4 Jun 2017 15:01:45 +0200 Vanitas Vitae wrote:
> Hi! > > 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 [1]. 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. Regards, Andrey [*] 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 [1]. [1] https://bouncycastle.org/devmailarchive/msg14988.html _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
