Fixing (Encryption + AIM Direct IM)

Thu Dec 18 13:16:03 EST 2008

Hello

you want to send encryption over standard message protocols like AIm or
XMPP?
We discussed the same for a pidgin plugin and OTR is a good solution.
There are currently developers working on making the protocol libretroshare
(http://retroshare.sf.net and http://retromessenger.sf.net ) pugged in for
pidgin.
If you know or test this, you see, that all is encrypted by default and the
chat ID or adress is the PGP key. So if you want to use this in the client,
you need to generate always an ID.
Once done, the question is, why not all people with that ID use this
protocol for encryption, and the sulution is: direct from node to node,
without any server, as this protocol is serverless.
So the idea, to make encyption working over e.g. AIM - OSKAR - AIM is not
needed, but is you switch OTR to libretroshare, you have small encrypted
packetes sent over AIM - OSKAR - AIM and you have a second lane, though you
could message as well PIDGIN - PIDGIN, without the server. Why then not
using this encryption library to exclude the OSKAR Server? If not wanted you
even can use the encryption over this server.
So you need not to think about chunk size or fragement size if libretroshare
encryption offers you any connection you want, which is OTR by itself is not
doing.
Regards Max

2008/12/18 Evan Schoenberg <evan.s at dreskin.net>

>
> On Dec 17, 2008, at 3:10 PM, Paul Aurich wrote:
>
> I love the idea -- it could also make OTR behave a little better in the
>> XMPP world, where it currently sends Purple IM markup encoded in the
>> <body> element (ideally it would encrypt the plaintext-formatted and
>> XHTML-IM markup separately and stuff the marked-up content into the the
>> XHTML tag.)
>>
>> I think this has the serious potential to break OTR and cause a loop,
>> though. If a message is 'too big' (by OTR's definition), it will
>> fragment the message and reinject multiple ones (via serv_send_im). It
>> should be possible to have prpls wrap calling the sending-im-msg signal
>> in a check that it's not currently in that signal handler, but that
>> would require all prpls that handle the signal to do that (and I can see
>> bad situations with 3rd-party prpls not offering that protection).
>>
>
> Also: What happens if the plaintext and the XHTML-IM messages require
> different number of fragments?
>
> I thought about fragmentation in the AIM Direct IM case.... but it's a
> nonissue because over Direct IM there is no maximum packet size, so
> fragmentation simply never occurs.  XMPP does have a maximum message size,
> though?
>
> -Evan
>
> _______________________________________________
> Devel mailing list
> Devel at pidgin.im
> http://pidgin.im/cgi-bin/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20081218/468824a5/attachment.html>