Hello community,
here is the log from the commit of package libzrtpcpp for openSUSE:Factory checked in at 2016-02-26 22:19:44
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/libzrtpcpp (Old)
and /work/SRC/openSUSE:Factory/.libzrtpcpp.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "libzrtpcpp"
Changes:
--------
--- /work/SRC/openSUSE:Factory/libzrtpcpp/libzrtpcpp.changes 2016-02-03 10:19:28.000000000 +0100
+++ /work/SRC/openSUSE:Factory/.libzrtpcpp.new/libzrtpcpp.changes 2016-02-26 22:19:57.000000000 +0100
@@ -1,0 +2,9 @@
+Mon Feb 8 12:34:06 UTC 2016 - jengelh@inai.de
+
+- Update to new upstream release 4.6.2
+* add-on to the code to implement handling of the disclosure flag.
+ See RFC6189, chapter 11 for more details.
+* A fix in the ZrtpCWrapper to initialize and use the ZRTP
+ master instance in case of multi-stream usage.
+
+-------------------------------------------------------------------
Old:
----
V4.5.0.tar.gz
New:
----
V4.6.2.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ libzrtpcpp.spec ++++++
--- /var/tmp/diff_new_pack.5OWdaN/_old 2016-02-26 22:19:59.000000000 +0100
+++ /var/tmp/diff_new_pack.5OWdaN/_new 2016-02-26 22:19:59.000000000 +0100
@@ -18,7 +18,7 @@
Name: libzrtpcpp
%define lname libzrtpcpp4
-Version: 4.5.0
+Version: 4.6.2
Release: 0
Summary: A ccrtp extension for ZRTP support
License: GPL-3.0+
@@ -64,7 +64,7 @@
%prep
%setup -qn ZRTPCPP-%version
-chmod a-x INSTALL NEWS
+chmod a-x INSTALL
%build
mkdir build
@@ -98,7 +98,7 @@
%files -n %lname
%defattr(-,root,root,0755)
-%doc AUTHORS COPYING NEWS README.md
+%doc AUTHORS COPYING README.md
%_libdir/libzrtpcpp.so.4*
%files devel
++++++ V4.5.0.tar.gz -> V4.6.2.tar.gz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/CMakeLists.txt new/ZRTPCPP-4.6.2/CMakeLists.txt
--- old/ZRTPCPP-4.5.0/CMakeLists.txt 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/CMakeLists.txt 2016-02-04 16:32:31.000000000 +0100
@@ -13,10 +13,10 @@
PROJECT(libzrtpcpp)
SET(CPACK_PACKAGE_VERSION_MAJOR 4)
-SET(CPACK_PACKAGE_VERSION_MINOR 5)
-SET(CPACK_PACKAGE_VERSION_PATCH 0)
+SET(CPACK_PACKAGE_VERSION_MINOR 6)
+SET(CPACK_PACKAGE_VERSION_PATCH 2)
-set (VERSION 4.5.0)
+set (VERSION 4.6.2)
set (SOVERSION 4)
# Define supported command line parameters.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/NEWS new/ZRTPCPP-4.6.2/NEWS
--- old/ZRTPCPP-4.5.0/NEWS 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/NEWS 1970-01-01 01:00:00.000000000 +0100
@@ -1,507 +0,0 @@
-== GNU ZRTP 4.5.0 ==
-
-Added a new SAS algorithm 'B32E' that uses 32 Unicode Emoji
-code points instead of 32 ASCII characters. Application that
-are able to display Emojis may use this new SAS algorithm to
-display nice Emojis instead of 'boring' ASCII letters and
-digits.
-
-Some technical details:
-- the 32 selected emojis are easily distinguishable, known to
- everyone, not offending etc, and use standard Unicode code
- points
-- select colored emojis that look good on white and on black
- backgrounds (most emojis look good on white only)
-- select emojis that are available on iOS, Android, Mac OS X
- (Windows not checked)
-- the resulting SAS string is UTF-8 encoded, suitable for most
- platforms except Java.
-
-To use the codes for Java the application needs to translate the
-UTF-8 encoding into UTF-16 encoding. Because most of the emojis
-are Unicode supplementary characters the UTF-8 to UTF-16 conversion
-must generate the necessary UTF-16 surrogate pairs.
-
-To support the UTF-8 / UTF-16 conversion the common directory
-contains conversion functions that I extracted from ICU C/C++
-library source.
-
-
-== GNU ZRTP 4.4.0 ==
-
-Changes the handling of HMAC and Hash contexts to avoild tool
-many malloc/free calls and thus memory pointer problems.
-
-Enhance the handling an check the nonce when using multi-stream
-mode. This required a modification to the class file and some
-modifications on the API. The old functions are now deprecated
-but still usable. Nevertheless you should change your application
-to use the new fuctions which support the new nonce handling and
-checks.
-
-Some bug fixing as well.
-
-== GNU ZRTP 4.3.1 ==
-
-This is a bugfix release. It fixes several compiler issues in
-iOS8 Clang, Mircosoft C++ compiler (VS 2012) etc.
-
-This release also adds a fix to address a possible problem when
-using 'memset(...)' on a memory area immediately followed by a
-'free(...)' call to free this memory area. Some compilers may
-otpimize the code and do not call 'memset(...)'. That's bad for
-software that deals with secure keys :-) . The fix removes this
-possible vulnerability.
-
-
-== GNU ZRTP 4.3.0 ==
-
-This version adds some new API that provide to set retry timer
-values and to get some retry counters.
-
-Application may now set some values of the retry counters during
-the discovery (Hello) and the negotiation phase. Applications may
-increase the number of retries or modify the capping to support
-slow or bad networks.
-
-To get some idea about the actual number of retries during ZRTP
-negotiation an application may now use the new API to get an array
-of counters. The ZRTP state engine records how many retries occured
-during the different protocol states.
-
-Note: only the ZRTP initiator performs packet retries after the
-discovery (Hello) phase. The responder would always return zero
-alues for the other retry counters.
-
-Because we have a new set of functions the API changed, thus it's
-necessary to recompile applications that use the new library version.
-
-
-== GNU ZRTP 4.2.4 ==
-
-Only small changes to enable Android X86 (see clients/tivi/android)
-as an example.
-
-Rename functions aes_init() to aes_init_zrtp() to avoid names clashes
-with other libreries that may include own AES modules.
-
-
-== GNU ZRTP 4.2.3 ==
-
-The optional SAS relay feature (refer to RFC6189, chapter 7.3) is
-not longer compiled by default. If your project needs this support
-then modify the CMakeLists.txt file and uncomment a 'add_definition'
-statments. See comment in the CMakelists.txt file.
-
-The reasons to disable this optional feature in the default build:
-it's rarely used and some concerns about misusing this feature.
-
-
-== GNU ZRTP 4.2.2 ==
-
-A small enhancement in SRTP handling to provide a longer bit-shift
-register with 128 bits. The replay now check accepts packets which
-are up to 127 sequence number behing the current packet. The upper
-layer (codecs) gets more packets on slower/bad networks that we may
-see on mobile 3G/4G connections.
-
-If the codecs do not remove silence then this may lead to some longer
-audio replay, similar to sattelite communication.
-
-
-== GNU ZRTP 4.2.1 ==
-
-Bug fixes in the SRTP part that checks for replay and updates the ROC.
-
-The wrong computations lead to false replay indications and to wrong
-HMAC, thus they dropped to much packets, in particular under bad network
-conditions.
-
-Changed the handling the the zrtp_getSasType function the the ZrtpCWrapper.
-Please check the inline documentation and the compiler warning how to
-use the return value of the function.
-
-
-== GNU ZRTP 4.2.0 ==
-
-Implemented a new function to read the ZID file if the ZID file backend
-is SQlite3. This is not a security problem because the ZRTP cache was
-always public and readable, refer to RFC6189.
-
-SQL statement returns all ZID records, sorted by date, newest on top. The
-function can then step thru the DB cursor and read the records.
-
-The version also include sevral fixes, usually compiler warnings, some
-small problems reported by 'cppcheck' analyser.
-
-Because we have a new set of functions the API changed, thus it's necessary
-to recompile applications that use the new library version.
-
-
-== GNU ZRTP 4.1.2 ==
-
-Fix the library's name in libzrtpcpp.pc.make
-
-== GNU ZRTP 4.1.1 ==
-
-Is a bug fix release that fixes some problems when building a standalone
-version of the library, i.e. with embedded crypto algorithms and not using
-on openSSL.
-
-Another fix was necessary for NetBSD thread handling.
-
-
-== GNU ZRTP 4.1.0 ==
-
-Small enhancements when dealing with non-NIST algorithms. An application may
-set a ''algorithm selection policy'' to control the selection behaviour. In
-addition the the standrad selection policy (as per RFC6189) this version
-provides a _non-NIST_ selection policy: if the selected public key algorithm
-is a non-NIST ECC algorithm then the other selection functions prefer non-NIST
-HASH algorithms (Skein etc).
-
-
-== GNU ZRTP 4.0.0 ==
-
-For this version I added some new algorithms for the DH key agreement
-and the Skein Hash for ZRTP. Not further functional enhancments.
-
-Added a new (old) build parameter -DCORE_LIB that will build a ZRTP core
-library. This was available in V2.3 but I somehow lost this for 3.0
-You may add other build parameters, such as SQLITE and CRYPTO_STANDALONE
-if you build the core library.
-
-
-== GNU ZRTP 3.2.0 ==
-
-The main ZRTP modules contain fixes for three vulnerabilities found by Mark
-Dowd. Thus we advise application developers to use this version of the
-library. The vulnerabilities may lead to application crashes during ZRTP
-negotiation if an attacker sends prepared ZRTP packets. The fixes remove these
-attack vectors.
-
-Some small other enhancements and cleanup, mainly inside client code.
-
-Some enhancements in cache handling and the handling of retained shared
-secrets. This change was proposed by Phil, is a slight security enhacement and
-is fully backward comaptible.
-
-Because of some API changes clients must be compiled and linked with the new
-library.
-
-For details please refer to the Git logs.
-
-
-== GNU ZRTP 3.1.0 ==
-
-This version adds some new features and code that supports some other
-client and this accounts for the most changes inside this release.
-
-The ZRTP core functionality was not changed as much (bug fixes, cleanup
-mainly) and remains fully backward compatible with older library
-versions. However, one nice enhancement was done: the addition of a standalone
-SDES support module. This module supports basic SDES only without the fancy
-stuff like many other SDES implementations. Thus it's pretty interoperable.
-
-Some other features are:
-- add some android support for a client, may serve as template for others
-- documentation and code cleanup
-
-Because of some API changes clients must be compiled and linked with the new
-library.
-
-
-== GNU ZRTP 3.0.0 ==
-
-This is a major enhancement and restructuring of the overall ZRTP
-distribution. This was necessary because more and more other clients use ZRTP
-and add their specific glue code. Also some clients are not prepared to use
-openSSL or other crypto libraries to their code and distributions.
-
-Here a summary of the changes
-- a new directory layout to accomodate various clients
-- add standalone crypto modules, for example for AES, to have a real
- standalone ZRTP/SRTP library that does not require any other crypto library
- (optional via CMake configuration)
-- Re-structure ZRTP cache and add SQlite3 as optional storage backend
-
-The default settings for CMake build the normal ZRTP library that use openSSL
-as crypto backend, use the normal file based cache and include the GNU ccRTP
-modules. This is a librray that is to a large degree compatible with the
-earlier builds.
-
-Please refer to the top level CMakeFile.txt for options how to switch on the
-standalone crypto mode or the SQlite3 based cache storage.
-
-
-== GNU ZRTP 2.3.0 ==
-
-Add a "paranoid" mode to ZRTP. If and applications switches to this mode then
-the ZRTP stack _always_ asks the user to confirm the SAS thus ZRTP behaves as
-if it does not have a cache to store the retained secrets. However, setting
-the paranoid mode does not diable the cache, only the GUI behaviour.
-
-Enhance the CMake scripts to build a ZRTP library that does not contain GNU
-ccRTP modules and does not require ccRTP dependencies.
-
-== GNU ZRTP 2.2.0 ==
-
-Add stubs, callbacks and other provisions to prepare the full implementation
-of the SAS signing feature, see RFC6189, section 7.2. This feature needs
-support from applications and is rarely used if at all.
-
-As usual smaller fixes, code clean up etc.
-
-Because of some API changes clients must be compiled and linked with the new
-library.
-
-== GNU ZRTP 2.1.2 ==
-
-The main topic of this release was to add SRTCP support and some missing
-optional features of ZRTP.
-
-As such I've added some new API and classes that applications may use to add
-SRTCP or to use the new ZRTP features. the ZRTP stack now supports PBX
-handling, refer to RFC6189 section 7.3ff.
-
-Because of some API changes clients must be compiled and linked with the new
-library.
-
-== GNU ZRTP 2.0.0 ==
-
-Modify some files to use the new uCommon/commoncpp libraries instead
-of the GNU CC++ commoncpp2. This affects the ccRTP depended modules
-such as ZrtpQueue and the Timeout stuff.
-
-Updated to version 2.0.0 to be in synch with the ccRTP version number
-scheme.
-
-
-== GNU ZRTP 1.6.0 ==
-
-This version implements the Elliptic Curve Diffie-Helman (ECDH)
-public-key algorithm.
-
-ZRTP also supports new algorithms which are defined as optional
-in the ZRTP RFC. These are:
-- Skein Hash
-- Skein MAC for authentication
-- Twofish symmetric ciphers
-
-Twofish ciphers and Skein MAC are supported by GNU ccRTP SRTP
-implmentation as well.
-
-
-== GNU ZRTP 1.5.4 ==
-
-The changes in this release affect the ZRTP Configure mechanism only.
-Some housekeeping stuff (desctructors) was added and the C Wrapper
-how support ZRTP configure as well.
-
-Because of some API changes (added destructors) clients must be compiled
-and linked with the new library.
-
-
-== GNU ZRTP 1.5.2 ==
-
-Quite a lot of enhancements:
-- a CMake based build process was added
-- a C wrapper was added to enable C programs to use GNU ZRTP
-- some fixes in the code (race condition solved)
-- better support of multi-stream mode
-- change the old cxx file extension to cpp, some build system don't
- like the old cxx (Android NDK for example)
-- and much more
-
-Because of API changes clients must be compiled and linked with the new
-library.
-
-== GNU ZRTP 1.5.0 ==
-
-Adds a first version of a ZrtpConfigure class that provides applications
-to select which crypto and hash methods to use.
-
-Because of API changes clients must be compiled and linked with the new
-library.
-
-== GNU ZRTP 1.4.5 ==
-
-Modify the Hello repeat timer handling to accomodate slow connections and/or
-slow devices.
-
-Fix a problem when the other party sends only ZRTP packets at the beginning
-of a RTP session.
-
-=== Interface changes in 1.4.5 ===
-
-No external interfaces were changed, external API and ABI remain stable.
-Internal interface modifications only to implement Ping/PingAck handling.
-
-
-== GNU ZRTP 1.4.4 ==
-
-Implement the Ping/PingAck packets and associated protocol extensions
-as defined in [http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-15].
-
-=== Interface changes in 1.4.4 ===
-
-No external interfaces were changed, external API and ABI remain stable.
-Internal interface modifications only to implement Ping/PingAck handling.
-
-
-== GNU ZRTP 1.4.2 ==
-
-Introduce the Key Derivation Function (KDF) as defined in
-[http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-12].
-
-The ZRTP protocol version was updated to 1.10.
-
-=== Interface changes in 1.4.2 ===
-
-No interfaces were changed, API and ABI remain stable.
-
-
-== GNU ZRTP 1.4.0 ==
-
-This is the first release that is conformant to the ZRTP specification
-that eventually will become a RFC. See:
-[http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-10]
-
-The ZRTP protocol version was updated to 1.00.
-
-
-=== Interface changes in 1.4.0 ===
-
-The ZrtpQueue and ZRtp classes implement a new method to get the other
-party's ZID (ZRTP identifier). An application, for example a SIP or XMPP
-client, may use this method to get the other party's ZID and store it
-together in a contact list. This enable the application to check the ZID
-if the user calls the other party again. A client shall implement such
-a feature to enhance security if user's don't compare the SAS on every
-call after they confirmed a SAS once.
-
-Clients must be compiled and linked with the new library.
-
-
-== GNU ZRTP 1.3.1 ==
-
-This is an update to version 1.3.0 and implements the ZRTP multi-stream
-mode handshake. The ZRTP protocl version was updated to 0.90 and
-interoperability tests using the latest Zfone build and Zfone Beta
-(dated September 6, 2008) were successful.
-
-No changes in the external API and ABI with respect to 1.3.0 - thus no
-recompile or rebuild of clients are necessary if they use 1.3.0.
-
-To checkout version 1.3.1 specify revision 494 (-r 494).
-
-
-== GNU ZRTP 1.3.0 ==
-
-This version is and update to version 1.1.0 an implements the latest
-changes define in the ZRTP draft. The changes resulted in an update of the
-API, therefore existing applications must be recompiled.
-
-This version of GNU ZRTP is compatible to and was tested to work with
-the latest Zfone beta (dated June, 10, see Zfone project site). Only
-in one specific error case is a slight incompatibility that will be
-fixed with the next Zfone beta. This incompatibility results in a
-severe error information at the client. The error only happens if
-someone modified the first retained shared secret entry in the
-retained secret cache, for example disk/storage read error. This is
-a very unlikely situation.
-
-=== Interface changes in Version 1.3.0 ===
-
-The Method ''setSipsSecret(...)'' is no longer available. ZRTP does
-not support this additional secret anymore.
-
-The method ''setOtherSecret(...)'' was renamed to ''setPbxSecret(...)''
-to reflect the modification in the draft.
-
-The method ''setSrtpsSecret(...)'' was renamed to ''setAuxSecret(...)''
-to reflect the modification in the draft.
-
-
-== GNU ZRTP 1.1.0 ==
-
-GNU ZRTP 1.1.0 implements the basic ZRTP as specificied in the document
-''draft-zimmermann-avt-zrtp-06x''. You may access this at this URL:
-[http://zfoneproject.com/zrtp_ietf.html]
-
-This version of GNU ZRTP does not support the additiona featur of ZRTP
-such as Multi-stream mode, Pre-shared mode, PBX enrollement, and SAS
-Signature. However, to keep the external interface as stable as
-possible I already implmented stubs for the additional features. Some
-later versions may have these features implemented, depending if they
-are required by the community.
-
-The current version of GNU ZRTP is compatible and was tested to work
-with the latest Zfone beta (dated April, 2nd) (see Zfone project
-site).
-
-=== Interface changes ==
-
-The ''SymmetricZRTPSession'' implements some new methods to control
-ZRTP and its new features. An application usually uses only a few
-methods to setup GNU ZRTP. All others are optional and an application
-may use them only if it requires a special feature (which are not yet
-implemented :-) ).
-
-The ''ZrtpUserCallback'' class was modified as well. From an
-application's point of view
-
- * The methods in ''ZrtpUserCallback'' are not pure virtual anymore
- but just virtual and have a default implementation, usually a
- simple return. An application may extend this class and overwrite
- only those methods it requires.
-
- * Change of the constructor - remove the queue parameter thus we have
- a very simple standard constructor. This modifcation may requires a
- small change in the application or class that uses or extends
- ''ZrtpUserCallback''.
-
- * The method showSAS has an additional parameter:
-
- showSAS(std::string sas, bool verified);
-
- the verified flag is set to true in SAS is verified, false if not verified.
- This allows a more flexible support to display the SAS even if SAS is
- verified. Formerly ZRTP did not call "showSAS()" if SAS was verified. Now
- ZRTP always calls showSAS and provides the verification information
- explicitly.
-
-* The siganture of the following user callback methods was changed:
-
- showMessage(GnuZrtpCodes::MessageSeverity sev, int32_t subCode)
-
- zrtpNegotiationFailed(GnuZrtpCodes::MessageSeverity severity,
- int32_t subCode)
-
- The GNU ZRTP core and the ZRTP ccRTP extension do not contain
- message strings anymore. Both use codes to inform an application
- about events, problems or failure. The folder ''demo'' contains a
- small demo program that shows one way how to map the codes to
- strings. Delegating string handling and formating to the application
- simplifies internationalization etc.
-
-Plaese note: some new callback methods and ''SymmetricZRTPSession''
-methods are only stubs in the currect version. The real implementation
-(filling the stubs with real code) will be done some time later (see
-above about unsupported features).
-
-=== Header files ===
-
-The new version greatly reduces the number of header files installed
-in the include directory. In the new version I decoupled the internal
-header files and implementation from the external classes and
-interfaces an application requires. Only six header files are
-installed in GNU ZRTP's include directory (libzrtpcpp subdirectory in
-the usual include paths)
-
-== Demo program ==
-
-The new folder ''demo'' contains a small demo program that shows
-various ways how to use GNU ZRTP to setup secure RTP (SRTP) sessions
-even without signaling protocols
-
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/NEWS.md new/ZRTPCPP-4.6.2/NEWS.md
--- old/ZRTPCPP-4.5.0/NEWS.md 1970-01-01 01:00:00.000000000 +0100
+++ new/ZRTPCPP-4.6.2/NEWS.md 2016-02-04 16:32:31.000000000 +0100
@@ -0,0 +1,549 @@
+## GNU ZRTP 4.6.2 ##
+
+A small fix in the ZrtpCWrapper to fix an issue within 4.6.1
+;-)
+
+
+## GNU ZRTP 4.6.1 ##
+
+A small fix in the ZrtpCWrapper to initialize and use the ZRTP
+master instance in case of multi-stream usage. Does not affect
+the main ZRTP usage, only projects that use the wrapper such
+as PJSIP or Gstreamer projects.
+
+These project should re-compile if they use the multi-stream
+feature.
+
+
+## GNU ZRTP 4.6.0 ##
+
+Only a small add-on to the code to implement handling of the
+disclosure flag. See RFC6189, chapter 11 for more details
+about the disclosure flag.
+
+Because the API changed, thus it's necessary to recompile
+applications that use the new library version.
+
+
+## GNU ZRTP 4.5.0 ##
+
+Added a new SAS algorithm 'B32E' that uses 32 Unicode Emoji
+code points instead of 32 ASCII characters. Application that
+are able to display Emojis may use this new SAS algorithm to
+display nice Emojis instead of 'boring' ASCII letters and
+digits.
+
+Some technical details:
+
+* the 32 selected emojis are easily distinguishable, known to
+ everyone, not offending etc, and use standard Unicode code
+ points
+* select colored emojis that look good on white and on black
+ backgrounds (most emojis look good on white only)
+* select emojis that are available on iOS, Android, Mac OS X
+ (Windows not checked)
+* the resulting SAS string is UTF-8 encoded, suitable for most
+ platforms except Java.
+
+To use the codes for Java the application needs to translate the
+UTF-8 encoding into UTF-16 encoding. Because most of the emojis
+are Unicode supplementary characters the UTF-8 to UTF-16 conversion
+must generate the necessary UTF-16 surrogate pairs.
+
+To support the UTF-8 / UTF-16 conversion the common directory
+contains conversion functions that I extracted from ICU C/C++
+library source.
+
+Because the API changed, thus it's necessary to recompile
+applications that use the new library version.
+
+
+## GNU ZRTP 4.4.0 ##
+
+Changes the handling of HMAC and Hash contexts to avoid too
+many malloc/free calls and thus memory pointer problems.
+
+Enhance the handling an check the nonce when using multi-stream
+mode. This required a modification to the class file and some
+modifications on the API. The old functions are now deprecated
+but still usable. Nevertheless you should change your application
+to use the new fuctions which support the new nonce handling and
+checks.
+
+Some bug fixing as well.
+
+Because the API changed, thus it's necessary to recompile
+applications that use the new library version.
+
+
+## GNU ZRTP 4.3.1 ##
+
+This is a bugfix release. It fixes several compiler issues in
+iOS8 Clang, Mircosoft C++ compiler (VS 2012) etc.
+
+This release also adds a fix to address a possible problem when
+using 'memset(...)' on a memory area immediately followed by a
+'free(...)' call to free this memory area. Some compilers may
+otpimize the code and do not call 'memset(...)'. That's bad for
+software that deals with secure keys :-) . The fix removes this
+possible vulnerability.
+
+
+## GNU ZRTP 4.3.0 ##
+
+This version adds some new API that provide to set retry timer
+values and to get some retry counters.
+
+Application may now set some values of the retry counters during
+the discovery (Hello) and the negotiation phase. Applications may
+increase the number of retries or modify the capping to support
+slow or bad networks.
+
+To get some idea about the actual number of retries during ZRTP
+negotiation an application may now use the new API to get an array
+of counters. The ZRTP state engine records how many retries occured
+during the different protocol states.
+
+Note: only the ZRTP initiator performs packet retries after the
+discovery (Hello) phase. The responder would always return zero
+alues for the other retry counters.
+
+Because we have a new set of functions the API changed, thus it's
+necessary to recompile applications that use the new library version.
+
+
+## GNU ZRTP 4.2.4 ##
+
+Only small changes to enable Android X86 (see clients/tivi/android)
+as an example.
+
+Rename functions aes_init() to aes_init_zrtp() to avoid names clashes
+with other libraries that may include own AES modules.
+
+
+## GNU ZRTP 4.2.3 ##
+
+The optional SAS relay feature (refer to RFC6189, chapter 7.3) is
+not longer compiled by default. If your project needs this support
+then modify the CMakeLists.txt file and uncomment a 'add_definition'
+statements. See comment in the CMakelists.txt file.
+
+The reasons to disable this optional feature in the default build:
+it's rarely used and some concerns about misusing this feature.
+
+
+## GNU ZRTP 4.2.2 ##
+
+A small enhancement in SRTP handling to provide a longer bit-shift
+register with 128 bits. The replay check now accepts packets which
+are up to 127 sequence number behind the current packet. The upper
+layer (codecs) gets more packets on slower/bad networks that we may
+see on mobile 3G/4G connections.
+
+If the codecs do not remove silence then this may lead to some longer
+audio replay, similar to satellite communication.
+
+
+## GNU ZRTP 4.2.1 ##
+
+Bug fixes in the SRTP part that checks for replay and updates the ROC.
+
+The wrong computations lead to false replay indications and to wrong
+HMAC, thus they dropped to much packets, in particular under bad network
+conditions.
+
+Changed the handling the the zrtp_getSasType function the the ZrtpCWrapper.
+Please check the inline documentation and the compiler warning how to
+use the return value of the function.
+
+
+## GNU ZRTP 4.2.0 ##
+
+Implemented a new function to read the ZID file if the ZID file backend
+is SQlite3. This is not a security problem because the ZRTP cache was
+always public and readable, refer to RFC6189.
+
+SQL statement returns all ZID records, sorted by date, newest on top. The
+function can then step thru the DB cursor and read the records.
+
+The version also include several fixes, usually compiler warnings, some
+small problems reported by 'cppcheck' analyser.
+
+Because we have a new set of functions the API changed, thus it's necessary
+to recompile applications that use the new library version.
+
+
+## GNU ZRTP 4.1.2 ##
+
+Fix the library's name in libzrtpcpp.pc.make
+
+## GNU ZRTP 4.1.1 ##
+
+Is a bug fix release that fixes some problems when building a standalone
+version of the library, i.e. with embedded crypto algorithms and not using
+on openSSL.
+
+Another fix was necessary for NetBSD thread handling.
+
+
+## GNU ZRTP 4.1.0 ##
+
+Small enhancements when dealing with non-NIST algorithms. An application may
+set a ''algorithm selection policy'' to control the selection behaviour. In
+addition the the standrad selection policy (as per RFC6189) this version
+provides a _non-NIST_ selection policy: if the selected public key algorithm
+is a non-NIST ECC algorithm then the other selection functions prefer non-NIST
+HASH algorithms (Skein etc).
+
+
+## GNU ZRTP 4.0.0 ##
+
+For this version I added some new algorithms for the DH key agreement
+and the Skein Hash for ZRTP. Not further functional enhancements.
+
+Added a new (old) build parameter -DCORE_LIB that will build a ZRTP core
+library. This was available in V2.3 but I somehow lost this for 3.0
+You may add other build parameters, such as SQLITE and CRYPTO_STANDALONE
+if you build the core library.
+
+
+## GNU ZRTP 3.2.0 ##
+
+The main ZRTP modules contain fixes for three vulnerabilities found by Mark
+Dowd. Thus we advise application developers to use this version of the
+library. The vulnerabilities may lead to application crashes during ZRTP
+negotiation if an attacker sends prepared ZRTP packets. The fixes remove these
+attack vectors.
+
+Some small other enhancements and cleanup, mainly inside client code.
+
+Some enhancements in cache handling and the handling of retained shared
+secrets. This change was proposed by Phil, is a slight security enhancement and
+is fully backward compatible.
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
+For details please refer to the Git logs.
+
+
+## GNU ZRTP 3.1.0 ##
+
+This version adds some new features and code that supports some other
+client and this accounts for the most changes inside this release.
+
+The ZRTP core functionality was not changed as much (bug fixes, cleanup
+mainly) and remains fully backward compatible with older library
+versions. However, one nice enhancement was done: the addition of a standalone
+SDES support module. This module supports basic SDES only without the fancy
+stuff like many other SDES implementations. Thus it's pretty interoperable.
+
+Some other features are:
+
+* add some android support for a client, may serve as template for others
+* documentation and code cleanup
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
+
+## GNU ZRTP 3.0.0 ##
+
+This is a major enhancement and restructuring of the overall ZRTP
+distribution. This was necessary because more and more other clients use ZRTP
+and add their specific glue code. Also some clients are not prepared to use
+openSSL or other crypto libraries to their code and distributions.
+
+Here a summary of the changes
+
+* a new directory layout to accommodate various clients
+* add standalone crypto modules, for example for AES, to have a real
+ standalone ZRTP/SRTP library that does not require any other crypto library
+ (optional via CMake configuration)
+* Re-structure ZRTP cache and add SQlite3 as optional storage backend
+
+The default settings for CMake build the normal ZRTP library that use openSSL
+as crypto backend, use the normal file based cache and include the GNU ccRTP
+modules. This is a librray that is to a large degree compatible with the
+earlier builds.
+
+Please refer to the top level CMakeFile.txt for options how to switch on the
+standalone crypto mode or the SQlite3 based cache storage.
+
+
+## GNU ZRTP 2.3.0 ##
+
+Add a "paranoid" mode to ZRTP. If and applications switches to this mode then
+the ZRTP stack _always_ asks the user to confirm the SAS thus ZRTP behaves as
+if it does not have a cache to store the retained secrets. However, setting
+the paranoid mode does not disable the cache, only the GUI behaviour.
+
+Enhance the CMake scripts to build a ZRTP library that does not contain GNU
+ccRTP modules and does not require ccRTP dependencies.
+
+## GNU ZRTP 2.2.0 ##
+
+Add stubs, callbacks and other provisions to prepare the full implementation
+of the SAS signing feature, see RFC6189, section 7.2. This feature needs
+support from applications and is rarely used if at all.
+
+As usual smaller fixes, code clean up etc.
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
+## GNU ZRTP 2.1.2 ##
+
+The main topic of this release was to add SRTCP support and some missing
+optional features of ZRTP.
+
+As such I've added some new API and classes that applications may use to add
+SRTCP or to use the new ZRTP features. the ZRTP stack now supports PBX
+handling, refer to RFC6189 section 7.3ff.
+
+Because of some API changes clients must be compiled and linked with the new
+library.
+
+## GNU ZRTP 2.0.0 ##
+
+Modify some files to use the new uCommon/commoncpp libraries instead
+of the GNU CC++ commoncpp2. This affects the ccRTP depended modules
+such as ZrtpQueue and the Timeout stuff.
+
+Updated to version 2.0.0 to be in synch with the ccRTP version number
+scheme.
+
+
+## GNU ZRTP 1.6.0 ##
+
+This version implements the Elliptic Curve Diffie-Helman (ECDH)
+public-key algorithm.
+
+ZRTP also supports new algorithms which are defined as optional
+in the ZRTP RFC. These are:
+
+* Skein Hash
+* Skein MAC for authentication
+* Twofish symmetric ciphers
+
+Twofish ciphers and Skein MAC are supported by GNU ccRTP SRTP
+implementation as well.
+
+
+## GNU ZRTP 1.5.4 ##
+
+The changes in this release affect the ZRTP Configure mechanism only.
+Some housekeeping stuff (destructors) was added and the C Wrapper
+how support ZRTP configure as well.
+
+Because of some API changes (added destructors) clients must be compiled
+and linked with the new library.
+
+
+## GNU ZRTP 1.5.2 ##
+
+Quite a lot of enhancements:
+
+* a CMake based build process was added
+* a C wrapper was added to enable C programs to use GNU ZRTP
+* some fixes in the code (race condition solved)
+* better support of multi-stream mode
+* change the old cxx file extension to cpp, some build system don't
+ like the old cxx (Android NDK for example)
+* and much more
+
+Because of API changes clients must be compiled and linked with the new
+library.
+
+
+## GNU ZRTP 1.5.0 ##
+
+Adds a first version of a ZrtpConfigure class that provides applications
+to select which crypto and hash methods to use.
+
+Because of API changes clients must be compiled and linked with the new
+library.
+
+
+## GNU ZRTP 1.4.5 ##
+
+Modify the Hello repeat timer handling to accommodate slow connections and/or
+slow devices.
+
+Fix a problem when the other party sends only ZRTP packets at the beginning
+of a RTP session.
+
+
+### Interface changes in 1.4.5 ###
+
+No external interfaces were changed, external API and ABI remain stable.
+Internal interface modifications only to implement Ping/PingAck handling.
+
+
+## GNU ZRTP 1.4.4 ##
+
+Implement the Ping/PingAck packets and associated protocol extensions
+as defined in [RFC6189][].
+
+### Interface changes in 1.4.4 ###
+
+No external interfaces were changed, external API and ABI remain stable.
+Internal interface modifications only to implement Ping/PingAck handling.
+
+
+## GNU ZRTP 1.4.2 ##
+
+Introduce the Key Derivation Function (KDF) as defined in [RFC6189][]
+
+The ZRTP protocol version was updated to 1.10.
+
+### Interface changes in 1.4.2 ###
+
+No interfaces were changed, API and ABI remain stable.
+
+
+## GNU ZRTP 1.4.0 ##
+
+This is the first release that conforms to the ZRTP specification
+that eventually will become a [RFC6189][].
+
+The ZRTP protocol version was updated to 1.00.
+
+[RFC6189]: https://tools.ietf.org/html/rfc6189
+
+### Interface changes in 1.4.0 ###
+
+The ZrtpQueue and ZRtp classes implement a new method to get the other
+party's ZID (ZRTP identifier). An application, for example a SIP or XMPP
+client, may use this method to get the other party's ZID and store it
+together in a contact list. This enable the application to check the ZID
+if the user calls the other party again. A client shall implement such
+a feature to enhance security if user's don't compare the SAS on every
+call after they confirmed a SAS once.
+
+Clients must be compiled and linked with the new library.
+
+
+## GNU ZRTP 1.3.1 ##
+
+This is an update to version 1.3.0 and implements the ZRTP multi-stream
+mode handshake. The ZRTP protocl version was updated to 0.90 and
+interoperability tests using the latest Zfone build and Zfone Beta
+(dated September 6, 2008) were successful.
+
+No changes in the external API and ABI with respect to 1.3.0 - thus no
+recompile or rebuild of clients are necessary if they use 1.3.0.
+
+To checkout version 1.3.1 specify revision 494 (-r 494).
+
+
+## GNU ZRTP 1.3.0 ##
+
+This version is and update to version 1.1.0 an implements the latest
+changes define in the ZRTP draft. The changes resulted in an update of the
+API, therefore existing applications must be recompiled.
+
+This version of GNU ZRTP is compatible to and was tested to work with
+the latest Zfone beta (dated June, 10, see Zfone project site). Only
+in one specific error case is a slight incompatibility that will be
+fixed with the next Zfone beta. This incompatibility results in a
+severe error information at the client. The error only happens if
+someone modified the first retained shared secret entry in the
+retained secret cache, for example disk/storage read error. This is
+a very unlikely situation.
+
+### Interface changes in Version 1.3.0 ###
+
+The Method ''setSipsSecret(...)'' is no longer available. ZRTP does
+not support this additional secret anymore.
+
+The method ''setOtherSecret(...)'' was renamed to ''setPbxSecret(...)''
+to reflect the modification in the draft.
+
+The method ''setSrtpsSecret(...)'' was renamed to ''setAuxSecret(...)''
+to reflect the modification in the draft.
+
+
+## GNU ZRTP 1.1.0 ##
+
+GNU ZRTP 1.1.0 implements the basic ZRTP as specificied in the document
+''draft-zimmermann-avt-zrtp-06x''. You may access this document at[URL][]
+
+This version of GNU ZRTP does not support the additional featurs of ZRTP
+such as Multi-stream mode, Pre-shared mode, PBX enrollment, and SAS
+Signature. However, to keep the external interface as stable as
+possible I already implemented stubs for the additional features. Some
+later versions may have these features implemented, depending if they
+are required by the community.
+
+The current version of GNU ZRTP is compatible and was tested to work
+with the latest Zfone beta (dated April, 2nd) (see Zfone project
+site).
+
+[URL]: http://zfoneproject.com/zrtp_ietf.html
+
+### Interface changes ###
+
+The ''SymmetricZRTPSession'' implements some new methods to control
+ZRTP and its new features. An application usually uses only a few
+methods to setup GNU ZRTP. All others are optional and an application
+may use them only if it requires a special feature (which are not yet
+implemented :-) ).
+
+The ''ZrtpUserCallback'' class was modified as well. From an
+application's point of view
+
+ * The methods in ''ZrtpUserCallback'' are not pure virtual anymore
+ but just virtual and have a default implementation, usually a
+ simple return. An application may extend this class and overwrite
+ only those methods it requires.
+
+ * Change of the constructor - remove the queue parameter thus we have
+ a very simple standard constructor. This modifcation may requires a
+ small change in the application or class that uses or extends
+ ''ZrtpUserCallback''.
+
+ * The method showSAS has an additional parameter:
+
+ showSAS(std::string sas, bool verified);
+
+ the verified flag is set to true in SAS is verified, false if not verified.
+ This allows a more flexible support to display the SAS even if SAS is
+ verified. Formerly ZRTP did not call "showSAS()" if SAS was verified. Now
+ ZRTP always calls showSAS and provides the verification information
+ explicitly.
+
+* The signature of the following user callback methods was changed:
+
+ showMessage(GnuZrtpCodes::MessageSeverity sev, int32_t subCode)
+
+ zrtpNegotiationFailed(GnuZrtpCodes::MessageSeverity severity,
+ int32_t subCode)
+
+ The GNU ZRTP core and the ZRTP ccRTP extension do not contain
+ message strings anymore. Both use codes to inform an application
+ about events, problems or failure. The folder ''demo'' contains a
+ small demo program that shows one way how to map the codes to
+ strings. Delegating string handling and formating to the application
+ simplifies internationalization etc.
+
+Please note: some new callback methods and ''SymmetricZRTPSession''
+methods are only stubs in the current version. The real implementation
+(filling the stubs with real code) will be done some time later (see
+above about unsupported features).
+
+### Header files ###
+
+The new version greatly reduces the number of header files installed
+in the include directory. In the new version I decoupled the internal
+header files and implementation from the external classes and
+interfaces an application requires. Only six header files are
+installed in GNU ZRTP's include directory (libzrtpcpp subdirectory in
+the usual include paths)
+
+### Demo program ###
+
+The new folder ''demo'' contains a small demo program that shows
+various ways how to use GNU ZRTP to setup secure RTP (SRTP) sessions
+even without signaling protocols
+
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/README.md new/ZRTPCPP-4.6.2/README.md
--- old/ZRTPCPP-4.5.0/README.md 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/README.md 2016-02-04 16:32:31.000000000 +0100
@@ -30,7 +30,7 @@
**Note:** The Elliptic curves Cure25519 and Curve3617 are available only if you
select the crypto standalone mode during build.
-The newer verisons (starting with 4.1) implement an extensible mechanisms to
+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
@@ -39,6 +39,10 @@
(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.
+
+[NEWS]: NEWS.md
+
### SDES support
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
@@ -62,7 +66,7 @@
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][javazrtp]. The Jitsi project uses the Java implementation. Jitsi is a
-powerfull communication client and is definitely worth a [look][jitsi].
+powerful communication client and is definitely worth a [look][jitsi].
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
@@ -152,4 +156,4 @@
`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.
+Since version 4.1.1 the example Android build files require NDK r9c or better.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/clients/tivi/CtZrtpSession.cpp new/ZRTPCPP-4.6.2/clients/tivi/CtZrtpSession.cpp
--- old/ZRTPCPP-4.5.0/clients/tivi/CtZrtpSession.cpp 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/clients/tivi/CtZrtpSession.cpp 2016-02-04 16:32:31.000000000 +0100
@@ -129,12 +129,12 @@
int iSZ;
char *opt;
int type;
- void zrtp_log( const char *tag, const char *buf);
int b32sas = 0, iDisableDH2K = 0, iDisableAES256 = 0, iPreferDH2K = 0;
int iDisableECDH256 = 0, iDisableECDH384 = 0, iEnableSHA384 = 1;
int iDisableSkein = 0, iDisableTwofish = 0, iPreferNIST = 0;
int iDisableSkeinHash = 0, iDisableBernsteinCurve25519 = 0, iDisableBernsteinCurve3617 = 0;
+ int iEnableDisclosure = 0;
GET_CFG_I(b32sas, "iDisable256SAS");
GET_CFG_I(iDisableAES256, "iDisableAES256");
@@ -151,6 +151,7 @@
GET_CFG_I(iDisableSkeinHash, "iDisableSkeinHash");
GET_CFG_I(iDisableBernsteinCurve25519, "iDisableBernsteinCurve25519");
GET_CFG_I(iDisableBernsteinCurve3617, "iDisableBernsteinCurve3617");
+ GET_CFG_I(iEnableDisclosure, "iEnableDisclosure");
conf->clear();
@@ -161,6 +162,10 @@
*/
conf->setSelectionPolicy(ZrtpConfigure::PreferNonNist);
+ // Set the Disclosure flag if the client SW has DR active.
+ if (iEnableDisclosure == 1)
+ conf->setDisclosureFlag(true);
+
/*
* Handling of iPreferNIST: if this is false (== 0) then we add the non-NIST algorithms
* to the configuration and place them in front of the NIST algorithms. Refer to RFC6189
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/clients/tivi/CtZrtpStream.cpp new/ZRTPCPP-4.6.2/clients/tivi/CtZrtpStream.cpp
--- old/ZRTPCPP-4.5.0/clients/tivi/CtZrtpStream.cpp 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/clients/tivi/CtZrtpStream.cpp 2016-02-04 16:32:31.000000000 +0100
@@ -71,7 +71,7 @@
}
// This function is static (could be global) to reduce visibility
-static void zrtp_log( const char *tag, const char *buf){
+/*static*/ void zrtp_log( const char *tag, const char *buf){
if(_zrtp_log_cb){
_zrtp_log_cb(pLogRet, tag, buf);
}
@@ -495,6 +495,7 @@
secState |= 0x100;
T_ZRTP_I("sec_state", secState);
+ T_ZRTP_I("peerDisclosureFlag", zrtpEngine->isPeerDisclosureFlag()? 1 : 0);
T_ZRTP_LB("buildInfo", zrtpBuildInfo);
// Compute Hello-hash info string
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/zrtp/ZRtp.cpp new/ZRTPCPP-4.6.2/zrtp/ZRtp.cpp
--- old/ZRTPCPP-4.5.0/zrtp/ZRtp.cpp 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/zrtp/ZRtp.cpp 2016-02-04 16:32:31.000000000 +0100
@@ -80,7 +80,8 @@
callback(cb), dhContext(NULL), DHss(NULL), auxSecret(NULL), auxSecretLength(0), rs1Valid(false),
rs2Valid(false), msgShaContext(NULL), hash(NULL), cipher(NULL), pubKey(NULL), sasType(NULL), authLength(NULL),
multiStream(false), multiStreamAvailable(false), peerIsEnrolled(false), mitmSeen(false), pbxSecretTmp(NULL),
- enrollmentMode(false), configureAlgos(*config), zidRec(NULL), saveZidRecord(true), masterStream(NULL) {
+ enrollmentMode(false), configureAlgos(*config), zidRec(NULL), saveZidRecord(true), signSasSeen(false),
+ masterStream(NULL), peerDisclosureFlagSeen(false) {
#ifdef ZRTP_SAS_RELAY_SUPPORT
enableMitmEnrollment = config->isTrustedMitM();
@@ -796,6 +797,9 @@
if (zidRec->isSasVerified() && !paranoidMode) {
zrtpConfirm1.setSASFlag();
}
+ if (configureAlgos.isDisclosureFlag()) {
+ zrtpConfirm1.setDisclosureFlag();
+ }
zrtpConfirm1.setExpTime(0xFFFFFFFF);
zrtpConfirm1.setIv(randomIV);
zrtpConfirm1.setHashH0(H0);
@@ -924,6 +928,9 @@
// Fill in Confirm1 packet.
zrtpConfirm1.setMessageType((uint8_t*)Confirm1Msg);
+ if (configureAlgos.isDisclosureFlag()) {
+ zrtpConfirm1.setDisclosureFlag();
+ }
zrtpConfirm1.setExpTime(0xFFFFFFFF);
zrtpConfirm1.setIv(randomIV);
zrtpConfirm1.setHashH0(H0);
@@ -991,6 +998,10 @@
if (!sasFlag || paranoidMode) {
zidRec->resetSasVerified();
}
+
+ // Store the status of the Disclosure flag
+ peerDisclosureFlagSeen = confirm1->isDisclosureFlag();
+
// get verified flag from current RS1 before set a new RS1. This
// may not be set even if peer's flag is set in confirm1 message.
sasFlag = zidRec->isSasVerified();
@@ -1012,6 +1023,9 @@
if (sasFlag) {
zrtpConfirm2.setSASFlag();
}
+ if (configureAlgos.isDisclosureFlag()) {
+ zrtpConfirm2.setDisclosureFlag();
+ }
zrtpConfirm2.setExpTime(0xFFFFFFFF);
zrtpConfirm2.setIv(randomIV);
@@ -1122,8 +1136,14 @@
*errMsg = CriticalSWError;
return NULL;
}
+ // Store the status of the Disclosure flag
+ peerDisclosureFlagSeen = confirm1->isDisclosureFlag();
+
// now generate my Confirm2 message
zrtpConfirm2.setMessageType((uint8_t*)Confirm2Msg);
+ if (configureAlgos.isDisclosureFlag()) {
+ zrtpConfirm2.setDisclosureFlag();
+ }
zrtpConfirm2.setHashH0(H0);
zrtpConfirm2.setExpTime(0xFFFFFFFF);
zrtpConfirm2.setIv(randomIV);
@@ -1230,6 +1250,9 @@
return NULL;
}
}
+ // Store the status of the Disclosure flag
+ peerDisclosureFlagSeen = confirm2->isDisclosureFlag();
+
return &zrtpConf2Ack;
}
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/zrtp/ZrtpCWrapper.cpp new/ZRTPCPP-4.6.2/zrtp/ZrtpCWrapper.cpp
--- old/ZRTPCPP-4.5.0/zrtp/ZrtpCWrapper.cpp 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/zrtp/ZrtpCWrapper.cpp 2016-02-04 16:32:31.000000000 +0100
@@ -213,7 +213,7 @@
}
void zrtp_setMultiStrParams(ZrtpContext* zrtpContext, char* parameters, int32_t length, ZrtpContext* master) {
- if (!zrtpContext || !zrtpContext->zrtpEngine)
+ if (!zrtpContext || !zrtpContext->zrtpEngine || !master)
return;
if (parameters == NULL)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/zrtp/ZrtpConfigure.cpp new/ZRTPCPP-4.6.2/zrtp/ZrtpConfigure.cpp
--- old/ZRTPCPP-4.5.0/zrtp/ZrtpConfigure.cpp 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/zrtp/ZrtpConfigure.cpp 2016-02-04 16:32:31.000000000 +0100
@@ -490,6 +490,14 @@
return enableParanoidMode;
}
+void ZrtpConfigure::setDisclosureFlag(bool yesNo) {
+ enableDisclosureFlag = yesNo;
+}
+
+bool ZrtpConfigure::isDisclosureFlag() {
+ return enableDisclosureFlag;
+}
+
#if 0
ZrtpConfigure config;
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/zrtp/libzrtpcpp/ZRtp.h new/ZRTPCPP-4.6.2/zrtp/libzrtpcpp/ZRtp.h
--- old/ZRTPCPP-4.5.0/zrtp/libzrtpcpp/ZRtp.h 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/zrtp/libzrtpcpp/ZRtp.h 2016-02-04 16:32:31.000000000 +0100
@@ -692,6 +692,11 @@
*/
int32_t getZrtpRole() { return myRole; }
+ /**
+ * @brief Get status of our peer's disclosure flag
+ */
+ bool isPeerDisclosureFlag(){ return peerDisclosureFlagSeen; }
+
private:
typedef union _hashCtx {
SkeinCtx_t skeinCtx;
@@ -1022,7 +1027,7 @@
/**
* Save record
*
- * If false don't save record until user vrified and confirmed the SAS.
+ * If false don't save record until user verified and confirmed the SAS.
*/
bool saveZidRecord;
/**
@@ -1085,6 +1090,11 @@
bool paranoidMode;
/**
+ * Is true if the other peer sent a Disclosure flag in its Confirm packet.
+ */
+ bool peerDisclosureFlagSeen;
+
+ /**
* Find the best Hash algorithm that is offered in Hello.
*
* Find the best, that is the strongest, Hash algorithm that our peer
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/zrtp/libzrtpcpp/ZrtpCWrapper.h new/ZRTPCPP-4.6.2/zrtp/libzrtpcpp/ZrtpCWrapper.h
--- old/ZRTPCPP-4.5.0/zrtp/libzrtpcpp/ZrtpCWrapper.h 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/zrtp/libzrtpcpp/ZrtpCWrapper.h 2016-02-04 16:32:31.000000000 +0100
@@ -843,7 +843,7 @@
* and restriction how and when to use multi-stream mode.
*
* @param zrtpContext
- * Pointer to the opaque ZrtpContext structure.
+ * Pointer to the opaque ZrtpContext structure of the master ZRTP session.
* @param length
* Pointer to an integer that receives the length of the char array
* @return
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/ZRTPCPP-4.5.0/zrtp/libzrtpcpp/ZrtpConfigure.h new/ZRTPCPP-4.6.2/zrtp/libzrtpcpp/ZrtpConfigure.h
--- old/ZRTPCPP-4.5.0/zrtp/libzrtpcpp/ZrtpConfigure.h 2016-01-04 16:58:51.000000000 +0100
+++ new/ZRTPCPP-4.6.2/zrtp/libzrtpcpp/ZrtpConfigure.h 2016-02-04 16:32:31.000000000 +0100
@@ -515,6 +515,24 @@
*/
bool isParanoidMode();
+ /**
+ * Enables or disables setting of Disclosure flag.
+ *
+ * For further explanation of the disclosure flage refer to RFC6189, chaper 11
+ *
+ * @param yesNo
+ * If set to true then set the disclosure flag in confirm packets.
+ */
+ void setDisclosureFlag(bool yesNo);
+
+ /**
+ * Check if the protocol should set the disclosure flag.
+ *
+ * @return
+ * Returns true if disclosure falg should be set.
+ */
+ bool isDisclosureFlag();
+
/// Helper function to print some internal data
void printConfiguredAlgos(AlgoTypes algoTyp);
@@ -531,6 +549,7 @@
bool enableTrustedMitM;
bool enableSasSignature;
bool enableParanoidMode;
+ bool enableDisclosureFlag;
AlgorithmEnum& getAlgoAt(std::vector