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!):
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
___
