Proposal to implement the ZRTP enhancement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

This sounds really interesting and would be a very nice and welcome 
addition. Let me give you my two cents:

[snip]

> Description:
>
> GNU ZRTP
> GNU ZRTP is the existing ZRTP implementation that handles the ZRTP
> protocol, performs necessary ZRTP computations, maintains some data in a
> file etc. I implemented this part in C++ (it's stable, tested to work with
> Phil Zimmermann's implementation) and it's licencse is GPL v3. Currently I
> implemented a first version of a C Wrapper to make GNU ZRTP accessible to
> C implementations. The C Wrapper covers the main functions already and will
> be enhanced during the pj project implementation. GNU ZRTP is a library,
> no requirement to have it as third party source in pjproject - it's already
> available as part of the GNU ccRTP project.
>

This sounds fine to me.

>
> transport_zrtp
> This is a new pjmedia transport that links into the transport stream,
> similar to the current SRTP transport. Thus transport acts as a filter that
> controls the flow of ZRTP, RTP, and SRTP data. This is obviously a new
> module. IMHO it should live in the pjmedia source, parallel to the other
> transport modules. This module will be the main development during the
> planned ZRTP integration.
>

According to some notes on the wiki posted by PJSIP members this should 
be the way to go.

>
> SRTP-ZRTP
> Instead of using the existing SRTP implementation I plan to use an own SRTP
> implementation (also a C++ implementation that has a C Wrapper). Some
> reasons why: the current libsrtp does not support AES 256 which is implemented
> for ZRTP. In addition ZRTP defines some more modern authentiation mechanisms
> in SRTP that I will implement step by step. In addition the ZRTP/SRTP module
> uses either openSSL or libgcrpyt as crypto backends, thus no own implementation
> of the AES cipher or bignum but reusing proven an well tested implementations.
> This module would live in an apporpriate third party directory.
>

IMHO it might be better to integrate with the existing transport_srtp 
module and add the missing functionality there. Transport_zrtp could be 
an adapter sitting before transport_srtp which would handle the key 
negotiation and then encrypt the media using transport_srtp and the keys 
negotiated by transport_zrtp.

You might want to confirm this with core PJSIP developers ;-)


Regards,

-- 
Sa?l Ibarra Corretg?
AG Projects



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux