[sip-comm-dev] Usage of crypto functions


#1

All,

after some recent update of SRTP and ZRTP we don't require
a full blown Java JCE anymore only some basic cryptography like
AES, Diffie-Hellman, SHA* and alike. Thus I tried to reduce the
overall size of the crypto library. By removing unused classes
the size is now about 430KB down from 1.5MB, maybe even some
more reduction is possible :wink: .

Removing unused JCE classes serves several purposes: we would
detect any accidental use of Java JCE (which requires some
JCE policy files) and of course the stated reduction in overall
size.

Before I go on to further test this and eventually replace the
crypto lib I like to know if any other modules except ZRTP and SRTP
requires crypto functions and if so which one.

Regards,
Werner

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey Werner,

Werner Dittmann wrote:

All,

after some recent update of SRTP and ZRTP we don't require
a full blown Java JCE anymore only some basic cryptography like
AES, Diffie-Hellman, SHA* and alike. Thus I tried to reduce the
overall size of the crypto library. By removing unused classes
the size is now about 430KB down from 1.5MB, maybe even some
more reduction is possible :wink: .

Removing unused JCE classes serves several purposes: we would
detect any accidental use of Java JCE (which requires some
JCE policy files) and of course the stated reduction in overall
size.

Before I go on to further test this and eventually replace the
crypto lib I like to know if any other modules except ZRTP and SRTP
requires crypto functions and if so which one.

You are referring to the org.bouncycastle packages, right? These are
indeed only used by the media service.

I was wondering however, whether modifying the bc lib would also impact
in some way use of the javax.crypto packages as these are used by the
msn and ssh protocol implementations.

Cheers
Emil

路路路

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Emil,

thanks for the info.

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

All,

after some recent update of SRTP and ZRTP we don't require
a full blown Java JCE anymore only some basic cryptography like
AES, Diffie-Hellman, SHA* and alike. Thus I tried to reduce the
overall size of the crypto library. By removing unused classes
the size is now about 430KB down from 1.5MB, maybe even some
more reduction is possible :wink: .

<SNIP --- SNAP>

I was wondering however, whether modifying the bc lib would also impact
in some way use of the javax.crypto packages as these are used by the
msn and ssh protocol implementations.

Yes, indeed I was talking about the BC libs. If MSN and SSH use the BC
libs with JCE provider _and_ require strong encryption then it would be
necessary to install the "strong encryption policy" files together with
SC. Usualy only the system administrator can install these files.

This problem was the main reason to modify ZRTP/SRTP to use
the lightweight version of BC and getting rid of the JCE stuff. This
enables installation of SC for "normal" users.

If other packages require JCE then again we need to install the
policy files if these packages require strong encryption. Is it possible
to crosscheck the usage of JCE in other packages/functions of SC?
Most probably by the authors. (I also do some grep'ing to check for
javax.crypto imports).

However, after I modified ZRTP/SRTP to use BC lightweight only I removed
all JCE related classes (javax.crypto) from felix.client.run.properties
and until now nobody complained about missing classes :slight_smile: .

Regards,
Werner

路路路

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Werner,

Werner Dittmann wrote:

Emil,

thanks for the info.

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

All,

after some recent update of SRTP and ZRTP we don't require
a full blown Java JCE anymore only some basic cryptography like
AES, Diffie-Hellman, SHA* and alike. Thus I tried to reduce the
overall size of the crypto library. By removing unused classes
the size is now about 430KB down from 1.5MB, maybe even some
more reduction is possible :wink: .

<SNIP --- SNAP>

I was wondering however, whether modifying the bc lib would also impact
in some way use of the javax.crypto packages as these are used by the
msn and ssh protocol implementations.

Yes, indeed I was talking about the BC libs. If MSN and SSH use the BC
libs with JCE provider _and_ require strong encryption then it would be
necessary to install the "strong encryption policy" files together with
SC. Usualy only the system administrator can install these files.

MSN and ssh do not require the installation of the "strong encryption
policy" files. Does this mean that their use of javax.crypto won't be
affected by your changes?

You could actually test this very easily by simply creating an MSN
account. If you could make it log in from your local sandbox then I
guess we are alright, and you could go ahead and commit.

Cheers
Emil

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Emil,

I've checked this. MSN as well as SSH use crypto methods that are
coverby by the standard limited strength policy file and use
Sun's JCE implementation that is part of the standard JRE.

ZRTP as well as SRTP use encryption methods that require longer
keys, in particular AES256. Thus it save to use the BC lightweight.
I'll do some more tests and perform a check-in during the weekend.

Regards,
Werner

Emil Ivov schrieb:

路路路

Hey Werner,

Werner Dittmann wrote:

Emil,

thanks for the info.

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

All,

after some recent update of SRTP and ZRTP we don't require
a full blown Java JCE anymore only some basic cryptography like
AES, Diffie-Hellman, SHA* and alike. Thus I tried to reduce the
overall size of the crypto library. By removing unused classes
the size is now about 430KB down from 1.5MB, maybe even some
more reduction is possible :wink: .

<SNIP --- SNAP>

I was wondering however, whether modifying the bc lib would also impact
in some way use of the javax.crypto packages as these are used by the
msn and ssh protocol implementations.

Yes, indeed I was talking about the BC libs. If MSN and SSH use the BC
libs with JCE provider _and_ require strong encryption then it would be
necessary to install the "strong encryption policy" files together with
SC. Usualy only the system administrator can install these files.

MSN and ssh do not require the installation of the "strong encryption
policy" files. Does this mean that their use of javax.crypto won't be
affected by your changes?

You could actually test this very easily by simply creating an MSN
account. If you could make it log in from your local sandbox then I
guess we are alright, and you could go ahead and commit.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Werner Dittmann wrote:

Emil,

I've checked this. MSN as well as SSH use crypto methods that are
coverby by the standard limited strength policy file and use
Sun's JCE implementation that is part of the standard JRE.

Great, that's good to know!

ZRTP as well as SRTP use encryption methods that require longer
keys, in particular AES256. Thus it save to use the BC lightweight.
I'll do some more tests and perform a check-in during the weekend.

OK, thanks for the update!
Cheers
Emil

路路路

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

Emil,

thanks for the info.

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

All,

after some recent update of SRTP and ZRTP we don't require
a full blown Java JCE anymore only some basic cryptography like
AES, Diffie-Hellman, SHA* and alike. Thus I tried to reduce the
overall size of the crypto library. By removing unused classes
the size is now about 430KB down from 1.5MB, maybe even some
more reduction is possible :wink: .

<SNIP --- SNAP>

I was wondering however, whether modifying the bc lib would also impact
in some way use of the javax.crypto packages as these are used by the
msn and ssh protocol implementations.

Yes, indeed I was talking about the BC libs. If MSN and SSH use the BC
libs with JCE provider _and_ require strong encryption then it would be
necessary to install the "strong encryption policy" files together with
SC. Usualy only the system administrator can install these files.

MSN and ssh do not require the installation of the "strong encryption
policy" files. Does this mean that their use of javax.crypto won't be
affected by your changes?

You could actually test this very easily by simply creating an MSN
account. If you could make it log in from your local sandbox then I
guess we are alright, and you could go ahead and commit.

Cheers
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net