Enable zrtp support for AES-256 bit encryption between two csipsimple clients

[GoogleCodeExporter]

What steps will reproduce the problem?
1. start a call between two devices
2. zrtp sas is displayed
3.

What is the expected output? What do you see instead?
Expected output is AES-256 bit encryption
Actual output is twofish-256 bit encryption

What version of the product are you using? On what operating system?
0.04-03 r1911
android version 4.0.3

Please provide any additional information below.

Original issue reported on code.google.com by jdthom...@gmail.com on 19 Sep 2012 at 10:05

[GoogleCodeExporter]

Apparently in latest ZrtpCpp twofish-256 is preferred over AES-256 (that is 
preferred over twofish-128 and aes-128)
 (cf https://github.com/wernerd/ZRTPCPP/blob/master/zrtp/ZrtpConfigure.cpp#L205 )
AES-128 seems the only one mandatory to support but if there is better 
available on other side, better will be selected.

I guess Werner had a good reason for choosing it as the preferred one. 
On my side not an expert on symetric cipher to tell which is the best ;)
Is there a reason why you prefer AES over Twofish? 
With a good reason I could ask for more details on this choice on zrtpcpp 
library side.

Original comment by r3gis...@gmail.com on 19 Sep 2012 at 10:45

• Changed state: Need-Details

[GoogleCodeExporter]

From wikipedia page of twofish :

--
On most software platforms Twofish was slightly slower than Rijndael (the 
chosen algorithm for Advanced Encryption Standard) for 128-bit keys, but 
somewhat faster for 256-bit keys.[3]
-- 

so apparently for 256 it's better choice than AES in terms of speed. 

Original comment by r3gis...@gmail.com on 19 Sep 2012 at 10:50

[GoogleCodeExporter]

I'm looking to do a fips 140-2 compliant voip client and fips 140-2 mandates 
aes256.

Guess there's no way to change that to use aes?  I remember reading about the 
zrtpcpp library and noted that it supports all 4: aes128,256 and 
twofish128,256.  Just a thought: maybe it's a matter of specifying the protocol 
rather than accepting the default??  

from https://github.com/wernerd/ZRTPCPP:
The GNU ZRTP implementation is compliant to RFC 6189. Currently GNU ZRTP C++ 
supports the following features:

multi-stream mode
Finite field Diffie-Helman with 2048 and 3072 bit primes
Elliptic curve Diffie-Helman with 256 and 384 bit curves
AES-128 and AES-256 symmetric cipher
Twofish-128 and Twofish-256 bit symmetric ciphers

Original comment by jdthom...@gmail.com on 20 Sep 2012 at 3:02

[GoogleCodeExporter]

btw, this is a great product you have your hands on!!!  good job!! 

Original comment by jdthom...@gmail.com on 20 Sep 2012 at 3:11

[GoogleCodeExporter]

So no problem... 
CSipSimple is actually compliant as it does support aes256 ;)

It's not the selected method if you call between two csipsimple as the best 
*chosen* is twofish256 (as preferred over aes256).
*But* if you call another sip client that only support what is mandatory for 
you (aes256)... it will select aes256 ;)
So no problem, it's compliant with any voip client that is compliant with 
anything considering aes256 as mandatory.

It just select just better in case there is something better available on 
remote side. But mandatory encryption cipher for your needs (aes256) *is 
supported*.

It's just like codec negotiation. If you have a remote side that supports g711 
only it will select g711. If remote side support a better codec it will select 
the better codec (depending of codec priority list).

If you have a closer look to the piece of code I sent the link on (line 205) 
you'll see that it's a voluntary preferred order of zrtpccp to have the 
following priority list :
twofish256, aes256, twofish128, aes128
It's a priority list. So if remote only support the mandatory aes256 will just 
be fine ! If the remote supports twofish256 as results in better cpu 
performance (if I correctly understood) and as good security, it will choose 
twofish256.

Some question about fips validation. Can you point me the document where fips 
validation required the aes256. It's for my culture. I'm a little bit confused 
with that. Sounds to me some validation step passed over software and that is 
done by a federal agency and that needs to be done on each software. It seems 
to me independent of choosen crypto module.

BTW, some point you might be interested in : csipsimple will not use (unless 
you rebuild it) an openssl version that has been stamped with "fips" validation 
(cf : http://www.openssl.org/docs/fips/fipsvalidation.html). It will use the 
one of the device for performance reason (and also because if there is security 
fixes pushed to the device, will benefit it). 
So it will use the crypto module of the device (whatever has been fips 
validated or not). It's possible however to build a version of the app with 
openssl fully included (and so get the openssl version you want). Also, AFAIK, 
zrtpcpp has not been validated.

About zrtp. The mandatory cipher is aes128 (not 256). See section 5.1.3 of the 
RFC : 
http://tools.ietf.org/html/rfc6189#section-5.1.3
You may also be interested in reading the section 5.1.5 on how the negotiation 
is made
http://tools.ietf.org/html/rfc6189#section-5.1.5

So to sum up (correct me if I'm wrong) :
 - The app is compliant with anything that mandates aes256.
 - If the remote side supports twofish256 it will select it as *preferred* one
 - The app also supports (derivated from zrtpcpp) all following ciphering methods : twofish256, aes256, twofish128, aes128. So it's compliant with ZRTP RFC 6189 and with anything that has a mandatory list included is this list.

It would be possible from csipsimple to change config of zrtpcpp and select 
different *priority order*, but I think that if twofish256 is the preferred one 
in zrtpcpp it's for good reason (I completely trust the good job made by Werner 
and from what I could read digging a little bit in the question, is that 
twofish for 256 is faster than aes). If you have some inputs that could make 
this priority order different let me know. If it's arguments like security 
level or cpu performance, I can ask Werner to review and give his opinion on 
that, and will benefit all apps using zrtpcpp ;).

If you want to do a build of csipsimple with aes256 as highest priority (for 
other reasons than security and performance), should not be to hard. I can 
guide you. One important point if you release something based on that is that 
what you release *must* be released under GPL license terms (so release source 
code, inform users they have gpl rights, allow them to redistribute the app 
etc).

Original comment by r3gis...@gmail.com on 20 Sep 2012 at 6:42

[GoogleCodeExporter]

Thanks for all of your input, you're truely a master of your craft.

When it comes to the FIPS, I was mistaken.  The main customer we service 
requires aes256.  

Regarding the distribution of the code thanks for the reminder we have accepted 
that as a possibility if we go down this route.  We are also experimenting with 
another solution that is already FIPS compliant.  

For my personal use nothing beats csipsimple.  Thanks for making it for the 
world to use.  Thanks also for helping me to understand the protocols a little 
better :)

ttyl

Original comment by jdthom...@gmail.com on 21 Sep 2012 at 2:01