&xep0234; describes a very flexible and powerful method for peer-to-peer file transfer with interchangable transports. Unfortunatly only some of those transports can by encrypted (e.g. &xep0261;) and none integrate into existing end-to-end encryption schemes. This specification defines an approach to encrypt the actual file before transferring it by using the OMEMO encryption. Note that the encryption can and should happen on the fly.

• Keep the protocol flow as close to Jingle File Transfer as possible and only change the file description
• Keep the required changes for a client that already supports Jingle File Transfer and the OMEMO encryption to a minimum

Remeo and Juliet are already engaged in a private, OMEMO encrypted conversation and want to negotiate a file transfer. The session-initiate stanza of an OMEMO encrypted file tranfer differs from the session-initiate of a regular Jingle File Transfer in that the 'file' element is wrapped in an 'encrypted' element. This reuses the KeyTransportElement from the OMEMO specification.

The rest of the negotiation is analogous to a regular file transfer. The file is then encrypted and decrypted respectively using the key/IV pair extracted from the encryption header in AES-GCM. The crypto operation SHOULD happen on the fly.

Even though AES-GCM comes with build-in integrity protection the hosting entity can—at any time during the lifetime of the session—communicate the checksum of the encrypted file.

• AES-GCM being a block cipher will influence the file size. The file size reported in the session intilization MUST be the encrypted one.
• The file hash MUST be the hash of encrypted file.
• 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.

To advertise its support for the OMEMO Encrypted Jingle File Transfer, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version of this protocol that the entity supports -- e.g., 'urn:xmpp:jingle:apps:encrypted:file-transfer:0' for this version &VNOTE;.

In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

Since the OMEMO Encryption does not provide a direct relation between resources and Device ID’s the initiating entity might not the Device ID of the resource it is creating a session with. Thus it MAY include a key for every trusted device of the foreign entity. However it SHOULD omit the keys for its own devices.

• Being built upon both Jingle File Transfer and OMEMO encryption, the same security considerations apply.
• Only the raw file is being encrypted. The encryption does not apply for the meta data sent with the session initialization including the content-type and the description

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

tbd