[jitsi-dev] SRTP and ZRTP cleanup and small enhancements


#1

Dear all,

I'm just going to push a new ZRTP library and some code cleanup
in SRTP related classes. These modifications do not add new functions
that a visible outside the related code.

The main topics are:
1) fix the F8 crypto mode for SRTP. Because it was never used it also
聽聽聽was not tested in depth :wink: . This fix and some other cleanup for
聽聽聽F8 mode was necessary to implement the next enhancement.

2) Delete (overwrite with null bytes) all secret SRTP keys as soon as
聽聽聽possible. This makes it much harder to detect key material in memory
聽聽聽or forced memory dumps because the secret key material only lives
聽聽聽for a very short amount of time.

As it stood up to now _several_ copies of secret key material were held
at various places in long living objects. These objects live at least as
long as the audio/video session lasts. Also the key material was not
destroyed during garbage collection thus it could remain in memory for
quite some time.

Topic 2 involved code in normal Jitsi SRTP code as well as code in ZRTP
library.

I have tested the modifications with ZRTP and SRTP that was created and
controlled by ZRTP. Bacuse I don't have a SDES environment I couldn't test
it. However, I checked the SDES related SRTP code and this also looks ok
to me. Ingo, can you retest with SDES please?

I'm doing some more analysis (there are still some places to check) but
this will take some more time and testing. Stay tuned :slight_smile: .

Best regards,
Werner


#2

Hey Werner

I'm just going to push a new ZRTP library and some code cleanup
in SRTP related classes. These modifications do not add new functions
that a visible outside the related code.

The main topics are:
1) fix the F8 crypto mode for SRTP. Because it was never used it also
聽聽聽was not tested in depth :wink: . This fix and some other cleanup for
聽聽聽F8 mode was necessary to implement the next enhancement.

2) Delete (overwrite with null bytes) all secret SRTP keys as soon as
聽聽聽possible. This makes it much harder to detect key material in memory
聽聽聽or forced memory dumps because the secret key material only lives
聽聽聽for a very short amount of time.
As it stood up to now _several_ copies of secret key material were held
at various places in long living objects. These objects live at least as
long as the audio/video session lasts. Also the key material was not
destroyed during garbage collection thus it could remain in memory for
quite some time.

Well that's a start, thanks! :slight_smile:
The account passwords that are kept in memory everywhere should probably
also handled likewise, but, well, different topic.

Topic 2 involved code in normal Jitsi SRTP code as well as code in ZRTP
library.

May I remind you about Emil's 'libsrc' announcement?
http://java.net/projects/jitsi/lists/dev/archive/2012-02/message/200

I have tested the modifications with ZRTP and SRTP that was created and
controlled by ZRTP. Bacuse I don't have a SDES environment I couldn't test
it. However, I checked the SDES related SRTP code and this also looks ok
to me. Ingo, can you retest with SDES please?

I'm not at the university until April, so I can currently only test with
Jitsi<->Jitsi. And this worked fine, with AES as well as with F8. Given that
your patch only modifies SRTP internals and removed some unused parts of the
public API, I don't see where or why it should break SDES.

I'm doing some more analysis (there are still some places to check) but
this will take some more time and testing. Stay tuned :slight_smile: .

Best regards,
Werner

Regards,
Ingo


#3

Hey Werner

<SNIP>---<SNAP>

May I remind you about Emil's 'libsrc' announcement?
http://java.net/projects/jitsi/lists/dev/archive/2012-02/message/200

I didn't catch this - thank's for reminding me. I'll have to look how
to do it in an efficient way. Having several copies of sources around
also has some drawbacks for the developer - I have to keep them in sync.
For the C/C++ implementation I just managed to have one master source
for ZRTP and large parts of SRTP code. Project that use this implementation
can just perform a simple copy or issue a "git clone" to get the master
source and have it ready to compile in their respective libs if they
require it.

<SNIP> --- <SNAP>

I'm not at the university until April, so I can currently only test with
Jitsi<->Jitsi. And this worked fine, with AES as well as with F8. Given that
your patch only modifies SRTP internals and removed some unused parts of the
public API, I don't see where or why it should break SDES.

This is one of the next steps: enhance ZRTP to be able to negotiate the F8
mode. I just did some quick tests but I need to synchronize with Phil Z. about
the enhancements, maybe sort of "private" enhancements but in sync with overall
ZRTP protocol.

I'm doing some more analysis (there are still some places to check) but
this will take some more time and testing. Stay tuned :slight_smile: .

Ingo, I'll come back to you during the next days or so. I've identified
parts in the Transformer classes that I like to address/modify. These mods
could also tangle SDES code. As soon as I have implemented/checked the mods
we shall discuss before commit.

Regards,
Werner

路路路

Am 11.03.2012 13:11, schrieb Ingo Bauersachs:

Best regards,
Werner

Regards,
Ingo


#4

There's no need for synchronisation really. In this case the code in libsrc
will be immutable. We'd just like to keep a copy of all lib sources there
so that whoever's interested can easily check it out without needing to
spend time looking for it or ( in some cases) without discovering it's no
longer available.

Just a zip of rhe sources you used to build the jar would be enough.

Thanks for the update btw!
Emil

--sent from my mobile

路路路

On Mar 11, 2012 6:55 PM, "Werner Dittmann" <Werner.Dittmann@t-online.de> wrote:

Am 11.03.2012 13:11, schrieb Ingo Bauersachs:
> Hey Werner
>

<SNIP>---<SNAP>
>
> May I remind you about Emil's 'libsrc' announcement?
> http://java.net/projects/jitsi/lists/dev/archive/2012-02/message/200
>

I didn't catch this - thank's for reminding me. I'll have to look how
to do it in an efficient way.