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. 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. The actual key exchange could be done in a number of ways; < http://tools.ietf.org/html/draft-miller-xmpp-e2e> has one possible approach included. - m&m Matthew A. Miller <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
