[Standards] Encrypted Jingle File Transfer

Vanitas Vitae vanitasvitae at riseup.net
Wed Jun 7 18:30:48 UTC 2017

Hi Andrey!

Am 07.06.2017 um 20:20 schrieb Andrey Gursky:
> [ 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)
That was my plan so far. Pre-encrypt the data makes file transfer much
easier (same is false for streams unfortunatelly).
> 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 [*]. 
That is true.
> Thus the
> only way I see is to encrypt data chunks separately. 
I don't see why this is necessary for file encryption. When the
transmission fails, the receiver can simply ask for another attempt the
transmit the encrypted data from offset n.
A precondition would be that either the sender keeps the key/encrypted
file, or the receiver sends back the key on re-initiation (Its generally
a nice idea to let the initiator deliver the key). Since the encrypted
data is then the same as in the previous transfer, the transmission can
continue from the point where it stopped or am I completely missing
something? :)


More information about the Standards mailing list