kurtbrose/pyjks

Hash mismatch; incorrect password or data corrupted

derbymaitland opened this issue · 5 comments

derbymaitland commented

When I try to load a keystore I get the following exception:

Traceback (most recent call last):
  File "./keystore.py", line 5, in <module>
    ks = jks.KeyStore.load('test.keystore', 'lala')
  File "/usr/local/lib/python2.7/dist-packages/jks/jks.py", line 22, in load
    return cls.loads(file.read(), password)
  File "/usr/local/lib/python2.7/dist-packages/jks/jks.py", line 98, in loads
    raise ValueError("Hash mismatch; incorrect password or data corrupted")
ValueError: Hash mismatch; incorrect password or data corrupted

I know however for a fact the password is correct and the archive is not corrupted, as I can open it in Portecle, Keystore Explorer and pure JAVA.

python --version
Python 2.7.6

I would try and replicate it in Python3, but that yields yet another exception:

Traceback (most recent call last):
  File "./keystore.py", line 5, in <module>
    ks = jks.KeyStore.load('test.keystore', 'lala')
  File "/usr/local/lib/python3.4/dist-packages/jks/jks.py", line 22, in load
    return cls.loads(file.read(), password)
  File "/usr/local/lib/python3.4/dist-packages/jks/jks.py", line 47, in loads
    alias, pos = _read_utf(data, pos)
  File "/usr/local/lib/python3.4/dist-packages/jks/jks.py", line 119, in _read_utf
    return unicode(data[pos:pos+size], 'utf-8'), pos+size
NameError: name 'unicode' is not defined
python3 --version
Python 3.4.0

For both Python versions the pyasn1 package is installed. pyjks version is the master/latest.

If it helps I can provide the JAVA code used to create the keystore.

voetsjoeba commented

Indeed, if you have some code that can reproduce the problematic keystore, I'd be interested in seeing that; maybe I can help.

kurtbrose commented

Thank you for the report!

We've noticed as well some JKS do not load properly. Best guess so far is it is certain versions of IBM JVM vs Sun JVM. The algorithm identifier is the same, but the data is clearly encrypted differently.

Supplying the Java code would be helpful -- if it isn't too much trouble, could you also provide a sanitized version of the keystore file as well? (Since it may have something to do with the JVM version.)

voetsjoeba commented

Hmn, I've been able to reproduce this case. I have to investigate further, but it seems to happen in JCEKS keystores as soon as a SecretKey is present.

At first glance, it seems likely that this happens because SecretKeys are unimplemented and thus no data is consumed and the 'pos' variable is not updated. The 'pos' variable is then subsequently used during the SHA1 integrity check though, likely causing the failure.

voetsjoeba commented

Should be resolved by pull request #10

mahmoud commented

With no update and an apparent resolution (complete with tests), I think it's safe to close this issue. Thanks @derbymaitland and @voetsjoeba!