[Standards] xep-027 encrypted filetransfers

Peter Saint-Andre stpeter at stpeter.im
Wed Oct 17 15:27:04 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/17/12 9:21 AM, Matthew Miller wrote:
> 
> On Oct 17, 2012, at 08:26, Peter Saint-Andre <stpeter at stpeter.im> 
> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 10/17/12 5:57 AM, Александр wrote:
>>> On Пятница, 12-окт-2012 00:46:57 Александр wrote:
>>> 
>>> On Четверг, 11-окт-2012 23:33:48 Andreas Kuckartz wrote:
>>> 
>>>> Александр:
>>> 
>>>>> Hi all, i have implemented encrypted filetransfers in my
>>> 
>>>>> realization of xep-027 in new_gpg plugin fro miranda im/ng,
>>>>>  but
>>> 
>>>>> currently it supported only in miranda, i would like to 
>>>>> extend
>>> 
>>>>> xep-027 to have defined encrypted filetransfers. is it 
>>>>> possible ?
>>> 
>>>> 
>>> 
>>>> Did you look at XEP-0234 ?
>>> 
>>>> 
>>> 
>>>> Cheers,
>>> 
>>>> Andreas
>>> 
>>> 
>>> 
>>> not yet, but my method implement encrypted transfers for any 
>>> type of filetransfer, not just jingle (which as i know not 
>>> supported by most clients currently ?), but my method is very 
>>> primitive ....
>>> 
>>> 
>>> 
>>> i have looked on XEP-0234 and related XEP's, found only some 
>>> information about optional ssl/tls encryption, but this is not
>>>  end-to-end, and not pgp like, i mean it's vulnerable to man in
>>>  middle attack on server side, ot i have missed something ?
>> 
>> We have not yet defined end-to-end encryption of file transfers. 
>> One way would be for the sender to encrypt each stanza to the 
>> public key of the recipient, and then chunk out the file using 
>> XEP-0047. However, that won't work well for huge files because
>> it will take a long time to transfer the file. Another way would
>> be to run your own trusted file transfer proxy, use XEP-0065, and
>> require SSL/TLS on both ends of the proxy. I'm sure there are
>> other solutions, too (e.g., for a while we were discussing
>> something called XTLS). It's not such an easy problem to solve,
>> but your ideas are welcome.
>> 
> 
> Right.
> 
> It's important to separate what the content is from how it is 
> transported.  Both [SI] and [JINGLE] do this to allow for agility
> in transport (Jingle more so than SI), increasing the chance of a 
> successful transfer.  I don't see how relying purely on XEP-0047
> does this.  Plus, I expect XMPP service operators would take
> exception to the transfer of extremely large data through a
> topology designed for lots of rather small chunks of information.

Indeed!

> A more palatable approach is to define a new SI profile (similar
> to XEP-0096) or Jingle descriptor (similar to XEP-0234) that
> indicates the data to exchange is encrypted before entering the
> transport layer.

In theory we have a way to do that already in Jingle:

http://xmpp.org/extensions/xep-0166.html#preconditions

However, as someone once said: "In theory, theory and practice are the
same; in practice, they're not."

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlB+zkgACgkQNL8k5A2w/vwJvQCeL/n6GWJG2IVCGkgilA6vR2y6
Y1UAmwfG4wF9bOXFNiYGWdntaF8+Bvef
=0gLp
-----END PGP SIGNATURE-----



More information about the Standards mailing list