[Standards] Encrypted Jingle File Transfer

Andrey Gursky andrey.gursky at e-mail.ua
Mon Jun 12 19:36:00 UTC 2017


Hi Vanitas,

On Wed, 7 Jun 2017 20:30:48 +0200 Vanitas Vitae wrote:

> 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? :)

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?

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.

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.

That's why I'm tending to the "chunk" approach now.

Andrey


More information about the Standards mailing list