[jitsi-users] Profile sharing


#1

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal


#2

Hey Tomas,

Sorry for the late reply.

Unfortunately, I am not sure why there would be differences in the way
passwords are encrypted on Linux and Windows. That kind of profile
sharing is not a priority for us though so I don't think anyone at the
BlueJimp side would have time to look into this any time soon.

Of course, I'd be curious to hear any suggestions.

In the mean time, you may want to try using provisioning to achieve the
same:

http://jitsi.org/provisioning

Given that you only care about your profile, simply making your
properties file accessible through HTTPS should be enough.

Hope this helps,
Emil

···

On 12.03.12 09:46, Tomas Kopal wrote:

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal

--
http://jitsi.org


#3

Hi,

I made some experiments with jitsi using the sources. (BTW, the nightly
source snapshots are not working, the latest is early december last year.)

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

I think that relying on the first available cipher to be always the same
is a bit strong assumption to make. This might be a problem not only
when sharing profiles, but also when e.g. upgrading java, or when moving
profiles between computers.

It would be nice to have the cipher used somehow stored in the
configuration, next to the password (or maybe even together with the
encrypted password), so the right one is used to decrypt it (if
possible), regardless if the more preffered one is available. If the
requred cipher is not available, at least more meaningfull error message
may be displayed.

What do you think? Can you change this? Or shall I prepare a patch? (I
am not really strong in Java, I am more C/C++ guy).

Thanks

Tomas

···

On 2012-03-20 12:54, Emil Ivov wrote:

Hey Tomas,

Sorry for the late reply.

Unfortunately, I am not sure why there would be differences in the way
passwords are encrypted on Linux and Windows. That kind of profile
sharing is not a priority for us though so I don't think anyone at the
BlueJimp side would have time to look into this any time soon.

Of course, I'd be curious to hear any suggestions.

In the mean time, you may want to try using provisioning to achieve the
same:

http://jitsi.org/provisioning

Given that you only care about your profile, simply making your
properties file accessible through HTTPS should be enough.

Hope this helps,
Emil

On 12.03.12 09:46, Tomas Kopal wrote:

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal

--
http://jitsi.org


#4

Hey

I made some experiments with jitsi using the sources. (BTW, the nightly
source snapshots are not working, the latest is early december last year.)

Thanks for the investigation.

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

Ahm, without having looked into this, the assumption that
AES/ECB/PKCS5PADDING are different ciphers is wrong. Actually, AES is the
cipher, ECB is "Electronic Code Book" - the mode how the chunks of data are
feed into the cipher, and the PKCS5PADDING is how the last block of data is
padded when it is shorter than the operation mode of AES.

I don't know why AES should not be available on Windows and what our
fallback would be.

I think that relying on the first available cipher to be always the same
is a bit strong assumption to make. This might be a problem not only
when sharing profiles, but also when e.g. upgrading java, or when moving
profiles between computers.

It would be nice to have the cipher used somehow stored in the
configuration, next to the password (or maybe even together with the
encrypted password), so the right one is used to decrypt it (if
possible), regardless if the more preffered one is available. If the
requred cipher is not available, at least more meaningfull error message
may be displayed.

What do you think? Can you change this? Or shall I prepare a patch? (I
am not really strong in Java, I am more C/C++ guy).

Patches are always welcome :slight_smile:

Thanks
Tomas

Regards,
Ingo


#5

Hi,

Hi,

I made some experiments with jitsi using the sources. (BTW, the nightly
source snapshots are not working, the latest is early december last year.)

The nightly snapshots are working fine there are located here:
http://download.jitsi.org/jitsi/nightly/src/
Maybe you were looking at the stable one and got confused by the name
nightly in the name :slight_smile:
http://download.jitsi.org/jitsi/src/.

Cheers
damencho

···

On Thu, Mar 22, 2012 at 7:40 PM, Tomas Kopal <Tomas.Kopal@altap.cz> wrote:

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

I think that relying on the first available cipher to be always the same
is a bit strong assumption to make. This might be a problem not only
when sharing profiles, but also when e.g. upgrading java, or when moving
profiles between computers.

It would be nice to have the cipher used somehow stored in the
configuration, next to the password (or maybe even together with the
encrypted password), so the right one is used to decrypt it (if
possible), regardless if the more preffered one is available. If the
requred cipher is not available, at least more meaningfull error message
may be displayed.

What do you think? Can you change this? Or shall I prepare a patch? (I
am not really strong in Java, I am more C/C++ guy).

Thanks

Tomas

On 2012-03-20 12:54, Emil Ivov wrote:

Hey Tomas,

Sorry for the late reply.

Unfortunately, I am not sure why there would be differences in the way
passwords are encrypted on Linux and Windows. That kind of profile
sharing is not a priority for us though so I don't think anyone at the
BlueJimp side would have time to look into this any time soon.

Of course, I'd be curious to hear any suggestions.

In the mean time, you may want to try using provisioning to achieve the
same:

http://jitsi.org/provisioning

Given that you only care about your profile, simply making your
properties file accessible through HTTPS should be enough.

Hope this helps,
Emil

On 12.03.12 09:46, Tomas Kopal wrote:

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal

--
http://jitsi.org


#6

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

Ahm, without having looked into this, the assumption that
AES/ECB/PKCS5PADDING are different ciphers is wrong. Actually, AES is the
cipher, ECB is "Electronic Code Book" - the mode how the chunks of data are
feed into the cipher, and the PKCS5PADDING is how the last block of data is
padded when it is shorter than the operation mode of AES.

I don't know why AES should not be available on Windows and what our
fallback would be.

Hmm, of course you are right. Thank you for spotting this. I was too
quick in making conclusions what the loop iterates over :-).

So, here goes second try:

There are two possible key lengths:

private static int[] KEY_LENGTHS = new int[]{256, 128};

In AESCrypto constructor, the key lengths are tried in a loop. On Linux,
the first key length is selected, on Windows, the first one fails, but
the second succeeds.

The end result is the same, though, password encrypted on Linux can not
be decrypted on Windows, and passwords encrypted on Windows can not be
decrypted on Linux.

Also, I think that the point that this could be causing trouble in other
cases may be also still valid.

No idea why the longer key fails on windows (maybe one of those stupid
export regulations?).

Patches are always welcome :slight_smile:

:-). Ok, I will try. But I need more time to understand what is really
going on in the code and what might be a good fix...

Tomas

···

On 22.3.2012 23:04, Ingo Bauersachs wrote:


#7

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

Ahm, without having looked into this, the assumption that
AES/ECB/PKCS5PADDING are different ciphers is wrong. Actually, AES is the
cipher, ECB is "Electronic Code Book" - the mode how the chunks of data are
feed into the cipher, and the PKCS5PADDING is how the last block of data is
padded when it is shorter than the operation mode of AES.

I don't know why AES should not be available on Windows and what our
fallback would be.

Hmm, of course you are right. Thank you for spotting this. I was too
quick in making conclusions what the loop iterates over :-).

So, here goes second try:

There are two possible key lengths:

private static int[] KEY_LENGTHS = new int[]{256, 128};

In AESCrypto constructor, the key lengths are tried in a loop. On Linux,
the first key length is selected, on Windows, the first one fails, but
the second succeeds.

The end result is the same, though, password encrypted on Linux can not
be decrypted on Windows, and passwords encrypted on Windows can not be
decrypted on Linux.

Also, I think that the point that this could be causing trouble in other
cases may be also still valid.

No idea why the longer key fails on windows (maybe one of those stupid
export regulations?).

Patches are always welcome :slight_smile:

:-). Ok, I will try. But I need more time to understand what is really
going on in the code and what might be a good fix...

Tomas

···

On 22.3.2012 23:04, Ingo Bauersachs wrote:


#8

Hi,

thanks for checking this. You are right, I was on the "stable" one. I
followed a link on http://jitsi.org/index.php/Development/VersionControl
It leads to the stable only, and there is no mention it is stable, it is
stating it is a nightly snapshot. Maybe the page should be updated then?

Tomas

···

On 23.3.2012 7:39, Damian Minkov wrote:

Hi,

On Thu, Mar 22, 2012 at 7:40 PM, Tomas Kopal <Tomas.Kopal@altap.cz> wrote:

Hi,

I made some experiments with jitsi using the sources. (BTW, the nightly
source snapshots are not working, the latest is early december last year.)

The nightly snapshots are working fine there are located here:
http://download.jitsi.org/jitsi/nightly/src/
Maybe you were looking at the stable one and got confused by the name
nightly in the name :slight_smile:
http://download.jitsi.org/jitsi/src/.

Cheers
damencho

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

I think that relying on the first available cipher to be always the same
is a bit strong assumption to make. This might be a problem not only
when sharing profiles, but also when e.g. upgrading java, or when moving
profiles between computers.

It would be nice to have the cipher used somehow stored in the
configuration, next to the password (or maybe even together with the
encrypted password), so the right one is used to decrypt it (if
possible), regardless if the more preffered one is available. If the
requred cipher is not available, at least more meaningfull error message
may be displayed.

What do you think? Can you change this? Or shall I prepare a patch? (I
am not really strong in Java, I am more C/C++ guy).

Thanks

Tomas

On 2012-03-20 12:54, Emil Ivov wrote:

Hey Tomas,

Sorry for the late reply.

Unfortunately, I am not sure why there would be differences in the way
passwords are encrypted on Linux and Windows. That kind of profile
sharing is not a priority for us though so I don't think anyone at the
BlueJimp side would have time to look into this any time soon.

Of course, I'd be curious to hear any suggestions.

In the mean time, you may want to try using provisioning to achieve the
same:

http://jitsi.org/provisioning

Given that you only care about your profile, simply making your
properties file accessible through HTTPS should be enough.

Hope this helps,
Emil

On 12.03.12 09:46, Tomas Kopal wrote:

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal

--
http://jitsi.org


#9

Hi,

thanks for checking this. You are right, I was on the "stable" one. I
followed a link on http://jitsi.org/index.php/Development/VersionControl
It leads to the stable only, and there is no mention it is stable, it is
stating it is a nightly snapshot. Maybe the page should be updated then?

Tomas

···

On 23.3.2012 7:39, Damian Minkov wrote:

Hi,

On Thu, Mar 22, 2012 at 7:40 PM, Tomas Kopal <Tomas.Kopal@altap.cz> wrote:

Hi,

I made some experiments with jitsi using the sources. (BTW, the nightly
source snapshots are not working, the latest is early december last year.)

The nightly snapshots are working fine there are located here:
http://download.jitsi.org/jitsi/nightly/src/
Maybe you were looking at the stable one and got confused by the name
nightly in the name :slight_smile:
http://download.jitsi.org/jitsi/src/.

Cheers
damencho

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

I think that relying on the first available cipher to be always the same
is a bit strong assumption to make. This might be a problem not only
when sharing profiles, but also when e.g. upgrading java, or when moving
profiles between computers.

It would be nice to have the cipher used somehow stored in the
configuration, next to the password (or maybe even together with the
encrypted password), so the right one is used to decrypt it (if
possible), regardless if the more preffered one is available. If the
requred cipher is not available, at least more meaningfull error message
may be displayed.

What do you think? Can you change this? Or shall I prepare a patch? (I
am not really strong in Java, I am more C/C++ guy).

Thanks

Tomas

On 2012-03-20 12:54, Emil Ivov wrote:

Hey Tomas,

Sorry for the late reply.

Unfortunately, I am not sure why there would be differences in the way
passwords are encrypted on Linux and Windows. That kind of profile
sharing is not a priority for us though so I don't think anyone at the
BlueJimp side would have time to look into this any time soon.

Of course, I'd be curious to hear any suggestions.

In the mean time, you may want to try using provisioning to achieve the
same:

http://jitsi.org/provisioning

Given that you only care about your profile, simply making your
properties file accessible through HTTPS should be enough.

Hope this helps,
Emil

On 12.03.12 09:46, Tomas Kopal wrote:

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal

--
http://jitsi.org


#10

Hi,

thanks for pointing it. I've edited the page, is it ok now?

Thanks
damencho

···

On Fri, Mar 23, 2012 at 1:35 PM, Tomas Kopal <Tomas.Kopal@altap.cz> wrote:

Hi,

thanks for checking this. You are right, I was on the "stable" one. I
followed a link on http://jitsi.org/index.php/Development/VersionControl
It leads to the stable only, and there is no mention it is stable, it is
stating it is a nightly snapshot. Maybe the page should be updated then?

Tomas

On 23.3.2012 7:39, Damian Minkov wrote:

Hi,

On Thu, Mar 22, 2012 at 7:40 PM, Tomas Kopal <Tomas.Kopal@altap.cz> wrote:

Hi,

I made some experiments with jitsi using the sources. (BTW, the nightly
source snapshots are not working, the latest is early december last year.)

The nightly snapshots are working fine there are located here:
http://download.jitsi.org/jitsi/nightly/src/
Maybe you were looking at the stable one and got confused by the name
nightly in the name :slight_smile:
http://download.jitsi.org/jitsi/src/.

Cheers
damencho

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

I think that relying on the first available cipher to be always the same
is a bit strong assumption to make. This might be a problem not only
when sharing profiles, but also when e.g. upgrading java, or when moving
profiles between computers.

It would be nice to have the cipher used somehow stored in the
configuration, next to the password (or maybe even together with the
encrypted password), so the right one is used to decrypt it (if
possible), regardless if the more preffered one is available. If the
requred cipher is not available, at least more meaningfull error message
may be displayed.

What do you think? Can you change this? Or shall I prepare a patch? (I
am not really strong in Java, I am more C/C++ guy).

Thanks

Tomas

On 2012-03-20 12:54, Emil Ivov wrote:

Hey Tomas,

Sorry for the late reply.

Unfortunately, I am not sure why there would be differences in the way
passwords are encrypted on Linux and Windows. That kind of profile
sharing is not a priority for us though so I don't think anyone at the
BlueJimp side would have time to look into this any time soon.

Of course, I'd be curious to hear any suggestions.

In the mean time, you may want to try using provisioning to achieve the
same:

http://jitsi.org/provisioning

Given that you only care about your profile, simply making your
properties file accessible through HTTPS should be enough.

Hope this helps,
Emil

On 12.03.12 09:46, Tomas Kopal wrote:

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal

--
http://jitsi.org


#11

Hi,

it's a long time, but I was finally able to look into this again. Just
for a reminder, my original problem was that jitsi installed on dual
boot computer could not share stored passwords between Windows and Linux.

The reason for this is different supported cipher length on both platforms.

On Linux, I am using OpenJDK, which does not have any crypto limitation,
so it is using the preferred cipher jitsi asks for, AES 256.

On Windows, Jitsi is using it's own copy of Oracle's jre, distributed
along with it. Oracle by default support only AES 128, for longer
ciphers an extension has to be downloaded and installed extra, due to US
export regulations for cryptography. Jitsi's jre does not have this
optional "Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files", so it can not offer AES 256, so fallback of
AES 128 is used.

These two cipher lengths are of course incompatible, so decryption on
Linux fails if the password was encrypted on Windows and vice versa.

I see several possible solutions:
  1) disable the use of AES 256, always use AES 128. Simplest, should be
good enough for this use case.
  2) add JCE policy files to jre distributed with jitsi. Not sure how
legal it is, and will only shift the problem somewhere else.
  3) do not distribute jre with jitsi, rely on jre installed on system,
including JCE policies. Not very reliable, will most probably introduce
more problems thank it solves.
  4) store cipher length along with the encrypted password in the
configuration. Warn, if used cipher is not available. Will not solve the
problem, but at least will point the user to the solution - installation
of JCE files.
  5) If password decryption fails, try all other options (cipher
lengths) available. If it still fails, print some better error message
than current "wrong password" along with information about optional JCE
download.

I think the best option is 1). Windows users are already using this
anyway :-). AES128 is considered unbreakable at this moment, and is
estimated to last at least till 2031 by NIST.

What do you think? I am willing to work on a patch, but I want to make
sure I am going in the right direction first :-).

Thanks a lot

Tomas

···

On 23.3.2012 0:21, Tomas Kopal wrote:

On 22.3.2012 23:04, Ingo Bauersachs wrote:

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

Ahm, without having looked into this, the assumption that
AES/ECB/PKCS5PADDING are different ciphers is wrong. Actually, AES is the
cipher, ECB is "Electronic Code Book" - the mode how the chunks of data are
feed into the cipher, and the PKCS5PADDING is how the last block of data is
padded when it is shorter than the operation mode of AES.

I don't know why AES should not be available on Windows and what our
fallback would be.

Hmm, of course you are right. Thank you for spotting this. I was too
quick in making conclusions what the loop iterates over :-).

So, here goes second try:

There are two possible key lengths:

private static int[] KEY_LENGTHS = new int[]{256, 128};

In AESCrypto constructor, the key lengths are tried in a loop. On Linux,
the first key length is selected, on Windows, the first one fails, but
the second succeeds.

The end result is the same, though, password encrypted on Linux can not
be decrypted on Windows, and passwords encrypted on Windows can not be
decrypted on Linux.

Also, I think that the point that this could be causing trouble in other
cases may be also still valid.

No idea why the longer key fails on windows (maybe one of those stupid
export regulations?).

Patches are always welcome :slight_smile:

:-). Ok, I will try. But I need more time to understand what is really
going on in the code and what might be a good fix...

Tomas


#12

Hi,

yes, now it is perfect :-), thanks.

Tomas

···

On 23.3.2012 12:45, Damian Minkov wrote:

Hi,

thanks for pointing it. I've edited the page, is it ok now?

Thanks
damencho

On Fri, Mar 23, 2012 at 1:35 PM, Tomas Kopal <Tomas.Kopal@altap.cz> wrote:

Hi,

thanks for checking this. You are right, I was on the "stable" one. I
followed a link on http://jitsi.org/index.php/Development/VersionControl
It leads to the stable only, and there is no mention it is stable, it is
stating it is a nightly snapshot. Maybe the page should be updated then?

Tomas

On 23.3.2012 7:39, Damian Minkov wrote:

Hi,

On Thu, Mar 22, 2012 at 7:40 PM, Tomas Kopal <Tomas.Kopal@altap.cz> wrote:

Hi,

I made some experiments with jitsi using the sources. (BTW, the nightly
source snapshots are not working, the latest is early december last year.)

The nightly snapshots are working fine there are located here:
http://download.jitsi.org/jitsi/nightly/src/
Maybe you were looking at the stable one and got confused by the name
nightly in the name :slight_smile:
http://download.jitsi.org/jitsi/src/.

Cheers
damencho

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

I think that relying on the first available cipher to be always the same
is a bit strong assumption to make. This might be a problem not only
when sharing profiles, but also when e.g. upgrading java, or when moving
profiles between computers.

It would be nice to have the cipher used somehow stored in the
configuration, next to the password (or maybe even together with the
encrypted password), so the right one is used to decrypt it (if
possible), regardless if the more preffered one is available. If the
requred cipher is not available, at least more meaningfull error message
may be displayed.

What do you think? Can you change this? Or shall I prepare a patch? (I
am not really strong in Java, I am more C/C++ guy).

Thanks

Tomas

On 2012-03-20 12:54, Emil Ivov wrote:

Hey Tomas,

Sorry for the late reply.

Unfortunately, I am not sure why there would be differences in the way
passwords are encrypted on Linux and Windows. That kind of profile
sharing is not a priority for us though so I don't think anyone at the
BlueJimp side would have time to look into this any time soon.

Of course, I'd be curious to hear any suggestions.

In the mean time, you may want to try using provisioning to achieve the
same:

http://jitsi.org/provisioning

Given that you only care about your profile, simply making your
properties file accessible through HTTPS should be enough.

Hope this helps,
Emil

On 12.03.12 09:46, Tomas Kopal wrote:

Hi,

I am trying to setup a profile shared between windows XP and Linux on a
dual boot computer. Everything seems to be working fine except for
passwords.
If I am not using a master password, then every time I switch OS, all
protocols are asking for password eventhough I have checked the "Remeber
password" option in the other OS.
If I enable usage of master password, I can not login at all in the
other OS than where I set up the master password ("password invalid").

I have compared stored jitsi settings after entering pass in both OS,
and the encrypted password differs between platforms. Looks like Windows
version can't decrypt what Linux encrypted and vice versa.

Does anyone has any idea what could be wrong?

Thanks for any help.

Best regards

Tomas Kopal

--
http://jitsi.org


#13

(moving the discussion to dev)
(bcc-ing users for completeness)

Hey Tomas,

Hi,

it's a long time, but I was finally able to look into this again. Just
for a reminder, my original problem was that jitsi installed on dual
boot computer could not share stored passwords between Windows and Linux.

The reason for this is different supported cipher length on both platforms.

On Linux, I am using OpenJDK, which does not have any crypto limitation,
so it is using the preferred cipher jitsi asks for, AES 256.

On Windows, Jitsi is using it's own copy of Oracle's jre, distributed
along with it. Oracle by default support only AES 128, for longer
ciphers an extension has to be downloaded and installed extra, due to US
export regulations for cryptography. Jitsi's jre does not have this
optional "Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy Files", so it can not offer AES 256, so fallback of
AES 128 is used.

These two cipher lengths are of course incompatible, so decryption on
Linux fails if the password was encrypted on Windows and vice versa.

I see several possible solutions:
  1) disable the use of AES 256, always use AES 128. Simplest, should be
good enough for this use case.
  2) add JCE policy files to jre distributed with jitsi. Not sure how
legal it is, and will only shift the problem somewhere else.
  3) do not distribute jre with jitsi, rely on jre installed on system,
including JCE policies. Not very reliable, will most probably introduce
more problems thank it solves.
  4) store cipher length along with the encrypted password in the
configuration. Warn, if used cipher is not available. Will not solve the
problem, but at least will point the user to the solution - installation
of JCE files.
  5) If password decryption fails, try all other options (cipher
lengths) available. If it still fails, print some better error message
than current "wrong password" along with information about optional JCE
download.

I think the best option is 1).

I suppose we'd accept a patch that uses a cipher length property. This
way users can set the length on Linux and then reuse the file on Windows.

Would this work for you?

Cheers,
Emil

···

On 26.07.12, 16:27, Tomas Kopal wrote:

Windows users are already using this
anyway :-). AES128 is considered unbreakable at this moment, and is
estimated to last at least till 2031 by NIST.

What do you think? I am willing to work on a patch, but I want to make
sure I am going in the right direction first :-).

Thanks a lot

Tomas

On 23.3.2012 0:21, Tomas Kopal wrote:

On 22.3.2012 23:04, Ingo Bauersachs wrote:

In AESCrypto.java, there are three ciphers to try for encoding passwords:

private static final String CIPHER_ALGORITHM = "AES/ECB/PKCS5PADDING";

On Linux, the first one, AES, gets selected during initialization, but
on Windows, for some reason, AES is not available, so ECB gets selected.
So after switching the OS, wrong cipher is used to decrypt the encrypted
password.

Ahm, without having looked into this, the assumption that
AES/ECB/PKCS5PADDING are different ciphers is wrong. Actually, AES is the
cipher, ECB is "Electronic Code Book" - the mode how the chunks of data are
feed into the cipher, and the PKCS5PADDING is how the last block of data is
padded when it is shorter than the operation mode of AES.

I don't know why AES should not be available on Windows and what our
fallback would be.

Hmm, of course you are right. Thank you for spotting this. I was too
quick in making conclusions what the loop iterates over :-).

So, here goes second try:

There are two possible key lengths:

private static int[] KEY_LENGTHS = new int[]{256, 128};

In AESCrypto constructor, the key lengths are tried in a loop. On Linux,
the first key length is selected, on Windows, the first one fails, but
the second succeeds.

The end result is the same, though, password encrypted on Linux can not
be decrypted on Windows, and passwords encrypted on Windows can not be
decrypted on Linux.

Also, I think that the point that this could be causing trouble in other
cases may be also still valid.

No idea why the longer key fails on windows (maybe one of those stupid
export regulations?).

Patches are always welcome :slight_smile:

:-). Ok, I will try. But I need more time to understand what is really
going on in the code and what might be a good fix...

Tomas

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31