-----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 <[email protected]> > 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-----
