Hi all, Daniel, Goffi, On Sun, 11 Dec 2016 19:12:26 +0100 Andrey Gursky wrote:
> Hi, > > > An encryption header MUST only be used for one session. However when > > doing a rangend tranfer on a previously aborted file the key/IV pair > > MUST be reused and packed into a new header to keep the integrity of > > the file. > > This is a nice catch. But I have two issues with it. > > Once jingle session is closed, all state is disposed. It is not > practical to maintain all the keys being used during all sessions in > some upper layer in case of a ranged transfer appears. > > The second issue: it seems to me not to work at all in practice: > > - Sender initiates a session, sends a file offer and transmits the file. > > - Transmission is aborted. It can be that "100% sent" is reported to > the sender due to quick proxy, but slow receiver. Thus the sender > cannot know how much data the receiver actually have got successfully. > > - Sender is going to transmit the file again and initiates a new > session. The session has a new key/iv. > > - Receiver approves the file offer adding a ranged element. > > - Now the sender sees a ranged element but it is too late: session is > already initiated with a new key/iv. And it continues to transmit the > file. > > - Receiver gets the rest of the file encrypted with different key/iv > and cannot decrypt it. omemo-filetransfer: > Note that the encryption can and should happen on the fly. At that place the described above issue started. What are the advantages of that recommendation? Using encryption on the fly disables the ability to decrypt on the fly. So either sender or receiver cannot do the crypto on the fly. Provided the sender uses a mobile smartphone ("power constrained" resource) and receiver a desktop PC there is indeed an obvious advantage. But in general, where both use smartphones, I don't see any obvious one that could outperform the ability to resume a file transfer and additionally no state must be preserved between sessions. What do you think about the following proposal to fix this issue to obtain the right-now-working solution supported by Conversations (and Gajim soon)? 1. Sender initiates a session, transmits the corresponding file metadata (fake name/date) and adds security precondition for omemo filetransfer (thanks Goffi!): <security xmlns='urn:xmpp:jingle:security:??????????????????:0'/> eu.siacs.omemo.filetransfer (Daniel ?) 2. Receiver approves the session and if necessary appends a range tag for a file with fake name or rejects if support is missing. 3. If rejected receiver/sender terminates the session, otherwise continue. 4. Sender encrypts the file (if needed starting at the 'range' bytes offset), obtains MAC and transmits it along with encrypted key, iv and additionally encrypted true name and date as security-info. 5. Receiver consumes this data to setup an on the fly decryption and acknowledges security-info. 6. Sender transmits the encrypted file. 7. Receiver gets the file and decrypts it on the fly. If necessary it appends the newly decrypted data to the existing file. 8. Once the file is completely transferred, it gets renamed according to the true name and the true timestamp gets applied. I realize, it is only a hot fix. Ideally, libsignal/libolm would get a convenient API for crypto handshake and stream read/write similar to OpenSSL/GnuTLS, so that OMEMO file transfer could be handled exactly as XTLS and all encrypted data is exchanged only over the transport but not the signal channel. Daniel, would you please recommend how to version and add this change as a preferred one but allow a fall-back to the current implementation of the omemo filetransfer? Thanks, Andrey _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________