Kristian Waagan wrote:
Actually, the test won't be able to create the encrypted database,
which is the initial step for almost all test cases exercised by the
ij script.
An alternative solution would be to reduce the key length, as I have
described in the Jira issue. Since there are no comments about the key
length, I do not know if the test was written to test the handling of
keys that are too long, or if the key is just too long (for the
specified encryption algorithm) for some other reason. We could
perhaps modify the test to use a key of correct length for all test
cases except one, and then use Myrna's trick of using sed to mask out
the differing lines.
Just for information, the code block where things go wrong is a
try-catch. If the code inside the try block fails, a security provider
method is executed in the catch block to translate the apparently
invalid key to a valid key. Then the same steps as those inside the
try block are retried. If it fails again (but this time in the catch
block - the code is duplicated), i.e. the key was/could not be
translated to a valid key, the exception from the Cipher.init method
is wrapped and thrown.
I would appreciate some more information of what the test is actually
written to test before I go ahead and change it!
I looked at the test. As per the comments in the test, the tests are
for testing using encryption using the encryptionKey. I dont think it
is trying to pass in an invalid key length for DES.
So some possible options:
1) how about changing the algorithm to use AES , and in AES the cipher
length is 16bytes. Is that available with the 'SunPCKS11-Solaris' ?
2) change the key length for DES ( as you suggest).
I'll look at the derby code too and see if we can/should be doing
something else for DES or other algorithms and report back.
Thanks,
Sunitha.
