ZRTP Support

[Dustin Gathmann]

Hi Daniel, hi Peter,


Am 27.05.2013 09:39, schrieb Daniel Kraft:

> On 05/26/2013 09:59 PM, Peter Lawler wrote:
>> On 27/05/13 04:42, Daniel Kraft wrote:
>>
>>> Do you think that would still be a feasible project
>>> to tackle?  Would you be interested in adding ZRTP support?  And would
>>> you give me a helping hand from time to time should I really attempt
>>> this and have questions regarding the code-base?
>>
>> Hi Daniel,
>> I only speak for myself, but I'd be interested in Pidgin having ZRTP
>> support. I suspect there are others who would be interested and would
>> probably build upon ZRTP support in Pidgin.
> 
> Well, that's a good first thing to know! ;)  But also the ticket already
> had some comments suggesting that interest is there.  (And in my
> opinion, it is an obvious addition.)
> 

I also think it's important, so I've already started to work on integrating
ZRTP into Pidgin some time ago.


It's still very incomplete and unstable, but I think it's going in the
right direction.

Currently, there's the SAS in the media window and an icon that claims to
know the current authentication state.
The rest -- communication between the components (the media window,
libpurple and actual ZRTP) etc. -- works mostly in theory atm.

This still needs a bit of work, but I'll publish the patches as soon as
things are in a usable or at least discussible state.


The essential ZRTP part is handled by Werner Dittmann's experimental
GstZrtpFilter plugin for GStreamer/Farstream. [1]

Control of these GstZrtpFilters is mostly left to Farstream (handled by a
modified fsrtpconference object), so that not much -- if any -- logic is
needed in the IM client to start the encryption.

[..]

> Yes, I'm absolutely not opposed to implementing that into the base code
> itself (and would also be in favour of having OTR there).  The question
> then is probably whether the community would accept such a change, or
> would rather have it as plugin.
> 
> BTW, how's that with OTR at the moment?  Is is just nobody implementing
> it, or are some people opposed to it and that's the reason why it
> stalls?  If it is the former, maybe that would be a good first step for
> me to get familiar with the code before trying to add ZRTP.  What do you
> think, would that be an easier (and also welcomed) thing to do?

In february, there was some discussion about OTR integration on this list.
Haven't looked at the OTR plugin myself, but I guess it's a good example
of how to maintain and present authentication information (and of the
possiblities of a plugin in general).

Almost all of Pidgin's voice/video session logic is in PurpleMedia &
PurpleMediaBackend (see ./libpurple/media* ), the rest in the respective
prpl (for practical purposes jabber: ./libpurple/protocols/jabber/jingle).

>> Would it be 'better' (if at all possible) to have ZRTP support in
>> GStreamer? In theory, as it stands right now Pidgin supports anything
>> that GStreamer can throw at it (hence, the current lack of Voice/Video
>> on Windows [but I've heard movements on that front over the past few
>> weeks...]). *IF* ZRTP could be added to GStreamer, this would bring the
>> functionality to more than just Pidgin. Further, it would mean that
>> Pidgin don't have to maintain it directly. Not saying that Pidgin should
>> or shouldn't maintain it, I'm just thinking that maybe it's more
>> suitable elsewhere. I don't even know if GStreamer can do key exchange
>> type foo. But I'd sure as heck like to think it could.

SRTP/ZRTP manipulates and creates RTP packets before they go to the net, so
it normally has to be placed somewhere between the RTP payloader and UDP.

In the case of Pidgin, RTP--UDP are inside the GStreamer/Farstream
pipeline, and AFAICS there is no easy way to either
a) let Pidgin add a ZRTP element to the pipeline or
b) attach ZRTP elsewhere outside the pipe (UDP/shared mem proxy or the like?)

I guess letting GStreamer do ZRTP is the easiest way (and I'm not sure if
ZRTP support _outside_ GStreamer would at all be possible). ;-)

> [..]
> 
> Another possibility could be to implement SRTP in gstreamer (it does the
> encryption when you give it the keys to use) and do the ZRTP key
> exchange, SAS verification and all that *before* we arrive at a SRTP key
> in Pidgin.  Would that make sense?  Maybe we should contact also the
> gstreamer community about that?

ZRTP's key negotiation takes place on the same UDP port as the encrypted
SRTP session will, so Pidgin would still somehow have to plug into this
data stream.


Regards,

Dustin

[1] https://github.com/wernerd/gstzrtp