This package provides a library that adds ZRTP support to the GNU ccRTP stack and serves as library for other RTP stacks (PJSIP, GStreamer). Phil Zimmermann developed ZRTP to allow ad-hoc, easy to use key negotiation to setup Secure RTP (SRTP) sessions.
The GNU ZRTP implementation is compliant to RFC 6189 and adds some more algorithms. Currently GNU ZRTP C++ supports the following features:
- multi-stream mode
- Finite field Diffie-Hellman with 2048 and 3072 bit primes
- Elliptic curve Diffie-Hellman with 256 and 384 bit curves (NIST curves)
- Elliptic curves Curve25519 and Curve3617 (Dan Bernstein, Tanja Lange)
- Skein Hash and MAC for ZRTP
- AES-128 and AES-256 symmetric ciphers
- Twofish-128 and Twofish-256 bit symmetric ciphers
- The SRTP authentication methods HMAC-SHA1 with 32 bit and 80 bit length and the Skein MAC with 32 bit and 64 bit length
- The Short Authentication String (SAS) type with base 32 encoding (4 characters) and the SAS 256 type using words.
Some features like pre-shared mode are not supported but the GNU ZRTP C++ implementation defines the necessary external interfaces and functions for these enhanced features.
Note: The Elliptic curves Cure25519 and Curve3617 are available only if you select the crypto standalone mode during build.
The newer versions (starting with 4.1) implement an extensible mechanisms to define algorithm selection policies that control selection of Hash, symmetric cipher, and the SRTP authentication. Currently two policies exist: Standard and PreferNonNist. The Standard policy selects algorihms based on the preferences (order) in the Hello packet, the PreferNonNist policy prefers non-NIST algorithms, for example Skein and Twofish, if the selected public key (Diffie-Hellman) algorithm is also one of the non-NIST algorithms. This is fully backward compatible and in-line with RFC6189.
Refer to new NEWS file for a summary of changes.
This release also provides SDES support. The SDES implementation does not
support all of the fancy stuff but is usable in most cases. This implementation
however supports the new SDES crypto mixing to overcome some security issues
for SIP forking. Please look for draft-zimmermann-mmusic-sdesc-mix-00.
During the development of ZRTP and its sister implementation ZRTP4J (the Java version of the ZRTP) Phil Zimmermann, his developers, and I worked together to make sure Phil's Zfone implementation and the GNU ZRTP implementations can work together.
Note: Zfone is now outdated and not supported anymore
The ZRTP4J implementation is a copycat of the original C++ code. I used the same overall class structure and copied a lot of C++ functionality to Java. Of course some Java adaptation were done, for example to overcome the problem of non-existing pointers :-), thus I use some non-obvious array handling. If you are interessted in the Java implementation of ZRTP then you may have a look here. The Jitsi project uses the Java implementation. Jitsi is a powerful communication client and is definitely worth a look.
To enable C based code to use ZRTP C++ I did a C wrapper that offers the same functionality to C based RTP implementations. The first use of the ZRTP C wrapper was for the PJSIP library, actually the RTP part of this library. The ZRTP handler for PJSIP is here. This port enables PJSIP based clients to use ZRTP. One of the first clients that uses this feature is CSipSimple, a very good open source Android SIP client.
The first application that demonstrated the embedded ZRTP was Minisp (now defunct). Minisip has it's own RTP stack and the very first version of this embedded ZRTP implementation worked together with this specific RTP stack.
A few weeks later I implemented the GNU ccRTP glue code and ZRTP became part of the official GNU ccRTP project and was named GNU ZRTP C++. The Twinkle softphone uses GNU ccRTP and GNU ZRTP C++ since it's 0.8.2 release and Michel de Boer, the implementor of Twinkle, created a nice user interface. All following versions of Twinkle included GNU ZRTP C++ as well.
This is historic info, most of the named products are not supported anymore.
I changed the license of the ZRTP core source files from LGPL to Apache V2. Other sources files may have own license. Please refer to the copyright notices of the files.
Thus the core ZRTP modules are is licensed under the Apache V2. Some other modules, mainly crypro modules, use different licenses or are even in public domain. Refer to the LICENSES file for a summary.
In general the files within the client directory are examples how to use the ZRTP
library and usually belong to other project which have their own license policy. These
files are not part of the core ZRTP code.
For further information refer to the ZRTP FAQ and the GNU ZRTP howto. Both are part of the GNU Telephony wiki and are located in its documentation category.
Source code in the directory clients/tivi and below is not licensed under the
GNU LGPL and is for reference and review only. Refer to the copyright statements
of the source code in these directories, in particular the sqlite3 sources which
have their own license.
Since version 1.6 GNU ZRTP C++ supports the cmake based build process only. The cmake build process is (IMHO) simpler than the GNU automake/autoconf process. To build GNU ZRTP C++ perform the following steps after you unpacked the source archive or pulled the source from Github:
cd <zrtpsrc_dir>
mkdir build
cd build
cmake ..
make
The CMakeLists.txt supports several options. If you don't specify any options
then cmake generates the build that supports GNU ccRTP library and it uses
the standalone cryptographic modules, thus no it's not necessary to install an
cryptographic library on the system. Optionally you may configure ZRTP to use
sqlite3 instead of a simple file to store the ZRTP cache data. For example
cmake -DSQLITE=true ..
creates the build files that use sqlite3.
Please have a look at the CMakeLists.txt for other options.
Running cmake in a separate build directory is the preferred way. Cmake and
the following make generate all files in or below the build directory. Thus
the base directory and the source directories are not polluted with *.o,
*.la, or other files that result from the build process. You may delete the
build directory and create a new one to start from fresh (this is the ultimate
make clean :-) ) or you may create a second directory to build with
different settings without mixing the two builds.
The CMake files support creation of an Android.mk file for the Tivi client
and may give you an idea how to do it for other clients. The generated
Android.mk generates buildinfo_*.c files in the root directory. You may
delete these files after the Android static libraries are ready.
Since version 4.1.1 the example Android build files require NDK r9c or better.