[jitsi-dev] Problems with master password


#1

After some time I did a fresh update of the sources and built Jitsi.
After starting Jitsi is not able to decrypt the stored passwords.

The root cause ist this:

Caused by: javax.crypto.BadPaddingException: Given final block not properly padded

I've never set a master password, thus it is a hardcoded one. Something is
wrong with the block cipher mode I assume :slight_smile:

Werner

路路路

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#2

As reported below I had problems to recover my stored passwords. After some more
debugging and code analysis I could temporarily fix the problem.

The following happened:

Until 2 weeks ago I used the standard Sun/Oracle Java JRE that uses the vanilla security
setting/policies, thus restricting the key length for AES to 128 bits. All passwords were
encrypted with this key length.

During a system update the update process switched to the Java open-jdk which does not have
this key length restriction and now the AES crypto class instantiates the AES cipher
with 256 bit key length instead of 128bit key length. This is done automatically without any
way to configure it. Obviously this leads to an incorrect decryption.

It was a bad design decision to select different key length purely based on the fact if the
cipher can be instatiated with a particular key length or not. This very much depends on the
Java installation on a particular system and its update status (see my experiences). An unaware
user may lose its stored passwords.

Proposal: in AESCrypto catch a possible decrypt error and try to reset the cipher with the
other key length. This is sort of a temporary fix. IMHO we shall use a fixed key length only.
AES with 128bit key length is secure, no need to check or use 256bit key length. This also
reduces the dependency on the Java installation.

If somebody insists to use 256bit key length then use the BouncyCastle lightweight
crypto API as it is done for the other security modules. This API is always available (not
restricted by some policy files) and BC is already included in Jitsi. If this is changed then
please _do not use ECB crypto mode_ anymore. Use CFB mode, then no padding is rquired and it's
a secure mode.

Werner

路路路

Am 21.09.2012 17:44, schrieb Werner Dittmann:

After some time I did a fresh update of the sources and built Jitsi.
After starting Jitsi is not able to decrypt the stored passwords.

The root cause ist this:

Caused by: javax.crypto.BadPaddingException: Given final block not properly padded

I've never set a master password, thus it is a hardcoded one. Something is
wrong with the block cipher mode I assume :slight_smile:

Werner

--
----------------------------------------------
Werner Dittmann Werner.Dittmann@t-online.de
Tel +49 176 993 462 95
PGP key: 82EF5E8B


#3

Hi,

this is the same problem I reported some time ago
(http://java.net/nonav/projects/jitsi/lists/users/archive/2012-03/message/27).
Unfortunately, I didn't have much time to really work on this yet, but
it is still high on my to-do list.
But if you want to take it, it's yours ;-).

Cheers

Tomas

路路路

On 24.9.2012 9:36, Werner Dittmann wrote:

As reported below I had problems to recover my stored passwords. After some more
debugging and code analysis I could temporarily fix the problem.

The following happened:

Until 2 weeks ago I used the standard Sun/Oracle Java JRE that uses the vanilla security
setting/policies, thus restricting the key length for AES to 128 bits. All passwords were
encrypted with this key length.

During a system update the update process switched to the Java open-jdk which does not have
this key length restriction and now the AES crypto class instantiates the AES cipher
with 256 bit key length instead of 128bit key length. This is done automatically without any
way to configure it. Obviously this leads to an incorrect decryption.

It was a bad design decision to select different key length purely based on the fact if the
cipher can be instatiated with a particular key length or not. This very much depends on the
Java installation on a particular system and its update status (see my experiences). An unaware
user may lose its stored passwords.

Proposal: in AESCrypto catch a possible decrypt error and try to reset the cipher with the
other key length. This is sort of a temporary fix. IMHO we shall use a fixed key length only.
AES with 128bit key length is secure, no need to check or use 256bit key length. This also
reduces the dependency on the Java installation.

If somebody insists to use 256bit key length then use the BouncyCastle lightweight
crypto API as it is done for the other security modules. This API is always available (not
restricted by some policy files) and BC is already included in Jitsi. If this is changed then
please _do not use ECB crypto mode_ anymore. Use CFB mode, then no padding is rquired and it's
a secure mode.

Werner

Am 21.09.2012 17:44, schrieb Werner Dittmann:

After some time I did a fresh update of the sources and built Jitsi.
After starting Jitsi is not able to decrypt the stored passwords.

The root cause ist this:

Caused by: javax.crypto.BadPaddingException: Given final block not properly padded

I've never set a master password, thus it is a hardcoded one. Something is
wrong with the block cipher mode I assume :slight_smile:

Werner