blob: acf2e83282df3aebcd3b12b3aa44fbfcaf35616a [file] [log] [blame]
Alexandre Lision7fd5d3d2013-12-04 13:06:40 -05001== GNU ZRTP 4.0.0 ==
2
3For this version I added some new algorithms for the DH key agreement
4and the Skein Hash for ZRTP. Not further functional enhancments.
5
6Added a new (old) build parameter -DCORE_LIB that will build a ZRTP core
7library. This was available in V2.3 but I somehow lost this for 3.0
8You may add other build parameters, such as SQLITE and CRYPTO_STANDALONE
9if you build the core library.
10
11
12== GNU ZRTP 3.2.0 ==
13
14The main ZRTP modules contain fixes for three vulnerabilities found by Mark
15Dowd. Thus we advise application developers to use this version of the
16library. The vulnerabilities may lead to application crashes during ZRTP
17negotiation if an attacker sends prepared ZRTP packets. The fixes remove these
18attack vectors.
19
20Some small other enhancements and cleanup, mainly inside client code.
21
22Some enhancements in cache handling and the handling of retained shared
23secrets. This change was proposed by Phil, is a slight security enhacement and
24is fully backward comaptible.
25
26Because of some API changes clients must be compiled and linked with the new
27library.
28
29For details please refer to the Git logs.
30
31
32== GNU ZRTP 3.1.0 ==
33
34This version adds some new features and code that supports some other
35client and this accounts for the most changes inside this release.
36
37The ZRTP core functionality was not changed as much (bug fixes, cleanup
38mainly) and remains fully backward compatible with older library
39versions. However, one nice enhancement was done: the addition of a standalone
40SDES support module. This module supports basic SDES only without the fancy
41stuff like many other SDES implementations. Thus it's pretty interoperable.
42
43Some other features are:
44- add some android support for a client, may serve as template for others
45- documentation and code cleanup
46
47Because of some API changes clients must be compiled and linked with the new
48library.
49
50
51== GNU ZRTP 3.0.0 ==
52
53This is a major enhancement and restructuring of the overall ZRTP
54distribution. This was necessary because more and more other clients use ZRTP
55and add their specific glue code. Also some clients are not prepared to use
56openSSL or other crypto libraries to their code and distributions.
57
58Here a summary of the changes
59- a new directory layout to accomodate various clients
60- add standalone crypto modules, for example for AES, to have a real
61 standalone ZRTP/SRTP library that does not require any other crypto library
62 (optional via CMake configuration)
63- Re-structure ZRTP cache and add SQlite3 as optional storage backend
64
65The default settings for CMake build the normal ZRTP library that use openSSL
66as crypto backend, use the normal file based cache and include the GNU ccRTP
67modules. This is a librray that is to a large degree compatible with the
68earlier builds.
69
70Please refer to the top level CMakeFile.txt for options how to switch on the
71standalone crypto mode or the SQlite3 based cache storage.
72
73
74== GNU ZRTP 2.3.0 ==
75
76Add a "paranoid" mode to ZRTP. If and applications switches to this mode then
77the ZRTP stack _always_ asks the user to confirm the SAS thus ZRTP behaves as
78if it does not have a cache to store the retained secrets. However, setting
79the paranoid mode does not diable the cache, only the GUI behaviour.
80
81Enhance the CMake scripts to build a ZRTP library that does not contain GNU
82ccRTP modules and does not require ccRTP dependencies.
83
84== GNU ZRTP 2.2.0 ==
85
86Add stubs, callbacks and other provisions to prepare the full implementation
87of the SAS signing feature, see RFC6189, section 7.2. This feature needs
88support from applications and is rarely used if at all.
89
90As usual smaller fixes, code clean up etc.
91
92Because of some API changes clients must be compiled and linked with the new
93library.
94
95== GNU ZRTP 2.1.2 ==
96
97The main topic of this release was to add SRTCP support and some missing
98optional features of ZRTP.
99
100As such I've added some new API and classes that applications may use to add
101SRTCP or to use the new ZRTP features. the ZRTP stack now supports PBX
102handling, refer to RFC6189 section 7.3ff.
103
104Because of some API changes clients must be compiled and linked with the new
105library.
106
Alexandre Lision51140e12013-12-02 10:54:09 -0500107== GNU ZRTP 2.0.0 ==
108
109Modify some files to use the new uCommon/commoncpp libraries instead
110of the GNU CC++ commoncpp2. This affects the ccRTP depended modules
111such as ZrtpQueue and the Timeout stuff.
112
113Updated to version 2.0.0 to be in synch with the ccRTP version number
114scheme.
115
116
117== GNU ZRTP 1.6.0 ==
118
119This version implements the Elliptic Curve Diffie-Helman (ECDH)
120public-key algorithm.
121
122ZRTP also supports new algorithms which are defined as optional
123in the ZRTP RFC. These are:
124- Skein Hash
125- Skein MAC for authentication
126- Twofish symmetric ciphers
127
128Twofish ciphers and Skein MAC are supported by GNU ccRTP SRTP
129implmentation as well.
130
131
132== GNU ZRTP 1.5.4 ==
133
134The changes in this release affect the ZRTP Configure mechanism only.
135Some housekeeping stuff (desctructors) was added and the C Wrapper
136how support ZRTP configure as well.
137
138Because of some API changes (added destructors) clients must be compiled
139and linked with the new library.
140
141
142== GNU ZRTP 1.5.2 ==
143
144Quite a lot of enhancements:
145- a CMake based build process was added
146- a C wrapper was added to enable C programs to use GNU ZRTP
147- some fixes in the code (race condition solved)
148- better support of multi-stream mode
149- change the old cxx file extension to cpp, some build system don't
150 like the old cxx (Android NDK for example)
151- and much more
152
153Because of API changes clients must be compiled and linked with the new
154library.
155
156== GNU ZRTP 1.5.0 ==
157
158Adds a first version of a ZrtpConfigure class that provides applications
159to select which crypto and hash methods to use.
160
161Because of API changes clients must be compiled and linked with the new
162library.
163
164== GNU ZRTP 1.4.5 ==
165
166Modify the Hello repeat timer handling to accomodate slow connections and/or
167slow devices.
168
169Fix a problem when the other party sends only ZRTP packets at the beginning
170of a RTP session.
171
172=== Interface changes in 1.4.5 ===
173
174No external interfaces were changed, external API and ABI remain stable.
175Internal interface modifications only to implement Ping/PingAck handling.
176
177
178== GNU ZRTP 1.4.4 ==
179
180Implement the Ping/PingAck packets and associated protocol extensions
181as defined in [http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-15].
182
183=== Interface changes in 1.4.4 ===
184
185No external interfaces were changed, external API and ABI remain stable.
186Internal interface modifications only to implement Ping/PingAck handling.
187
188
189== GNU ZRTP 1.4.2 ==
190
191Introduce the Key Derivation Function (KDF) as defined in
192[http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-12].
193
194The ZRTP protocol version was updated to 1.10.
195
196=== Interface changes in 1.4.2 ===
197
198No interfaces were changed, API and ABI remain stable.
199
200
201== GNU ZRTP 1.4.0 ==
202
203This is the first release that is conformant to the ZRTP specification
204that eventually will become a RFC. See:
205[http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-10]
206
207The ZRTP protocol version was updated to 1.00.
208
209
210=== Interface changes in 1.4.0 ===
211
212The ZrtpQueue and ZRtp classes implement a new method to get the other
213party's ZID (ZRTP identifier). An application, for example a SIP or XMPP
214client, may use this method to get the other party's ZID and store it
215together in a contact list. This enable the application to check the ZID
216if the user calls the other party again. A client shall implement such
217a feature to enhance security if user's don't compare the SAS on every
218call after they confirmed a SAS once.
219
220Clients must be compiled and linked with the new library.
221
222
223== GNU ZRTP 1.3.1 ==
224
225This is an update to version 1.3.0 and implements the ZRTP multi-stream
226mode handshake. The ZRTP protocl version was updated to 0.90 and
227interoperability tests using the latest Zfone build and Zfone Beta
228(dated September 6, 2008) were successful.
229
230No changes in the external API and ABI with respect to 1.3.0 - thus no
231recompile or rebuild of clients are necessary if they use 1.3.0.
232
233To checkout version 1.3.1 specify revision 494 (-r 494).
234
235
236== GNU ZRTP 1.3.0 ==
237
238This version is and update to version 1.1.0 an implements the latest
239changes define in the ZRTP draft. The changes resulted in an update of the
240API, therefore existing applications must be recompiled.
241
242This version of GNU ZRTP is compatible to and was tested to work with
243the latest Zfone beta (dated June, 10, see Zfone project site). Only
244in one specific error case is a slight incompatibility that will be
245fixed with the next Zfone beta. This incompatibility results in a
246severe error information at the client. The error only happens if
247someone modified the first retained shared secret entry in the
248retained secret cache, for example disk/storage read error. This is
249a very unlikely situation.
250
251=== Interface changes in Version 1.3.0 ===
252
253The Method ''setSipsSecret(...)'' is no longer available. ZRTP does
254not support this additional secret anymore.
255
256The method ''setOtherSecret(...)'' was renamed to ''setPbxSecret(...)''
257to reflect the modification in the draft.
258
259The methos ''setSrtpsSecret(...)'' is was renamed to ''setAuxSecret(...)''
260to reflect the modification in the draft.
261
262
263== GNU ZRTP 1.1.0 ==
264
265GNU ZRTP 1.1.0 implements the basic ZRTP as specificied in the document
266''draft-zimmermann-avt-zrtp-06x''. You may access this at this URL:
267[http://zfoneproject.com/zrtp_ietf.html]
268
269This version of GNU ZRTP does not support the additiona featur of ZRTP
270such as Multi-stream mode, Pre-shared mode, PBX enrollement, and SAS
271Signature. However, to keep the external interface as stable as
272possible I already implmented stubs for the additional features. Some
273later versions may have these features implemented, depending if they
274are required by the community.
275
276The current version of GNU ZRTP is compatible and was tested to work
277with the latest Zfone beta (dated April, 2nd) (see Zfone project
278site).
279
280=== Interface changes ==
281
282The ''SymmetricZRTPSession'' implements some new methods to control
283ZRTP and its new features. An application usually uses only a few
284methods to setup GNU ZRTP. All others are optional and an application
285may use them only if it requires a special feature (which are not yet
286implemented :-) ).
287
288The ''ZrtpUserCallback'' class was modified as well. From an
289application's point of view
290
291 * The methods in ''ZrtpUserCallback'' are not pure virtual anymore
292 but just virtual and have a default implementation, usually a
293 simple return. An application may extend this class and overwrite
294 only those methods it requires.
295
296 * Change of the constructor - remove the queue parameter thus we have
297 a very simple standard constructor. This modifcation may requires a
298 small change in the application or class that uses or extends
299 ''ZrtpUserCallback''.
300
301 * The method showSAS has an additional parameter:
302
303 showSAS(std::string sas, bool verified);
304
305 the verified flag is set to true in SAS is verified, false if not verified.
306 This allows a more flexible support to display the SAS even if SAS is
307 verified. Formerly ZRTP did not call "showSAS()" if SAS was verified. Now
308 ZRTP always calls showSAS and provides the verification information
309 explicitly.
310
311* The siganture of the following user callback methods was changed:
312
313 showMessage(GnuZrtpCodes::MessageSeverity sev, int32_t subCode)
314
315 zrtpNegotiationFailed(GnuZrtpCodes::MessageSeverity severity,
316 int32_t subCode)
317
318 The GNU ZRTP core and the ZRTP ccRTP extension do not contain
319 message strings anymore. Both use codes to inform an application
320 about events, problems or failure. The folder ''demo'' contains a
321 small demo program that shows one way how to map the codes to
322 strings. Delegating string handling and formating to the application
323 simplifies internationalization etc.
324
325Plaese note: some new callback methods and ''SymmetricZRTPSession''
326methods are only stubs in the currect version. The real implementation
327(filling the stubs with real code) will be done some time later (see
328above about unsupported features).
329
330=== Header files ===
331
332The new version greatly reduces the number of header files installed
333in the include directory. In the new version I decoupled the internal
334header files and implementation from the external classes and
335interfaces an application requires. Only six header files are
336installed in GNU ZRTP's include directory (libzrtpcpp subdirectory in
337the usual include paths)
338
339== Demo program ==
340
341The new folder ''demo'' contains a small demo program that shows
342various ways how to use GNU ZRTP to setup secure RTP (SRTP) sessions
343even without signaling protocols
344