[ http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12366257 ]
Sunitha Kambhampati commented on DERBY-788: ------------------------------------------- there was some discussion on the derbydev list, cut & paste. 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. > 'store/encryptionKey.sql' fails on Solaris 10 > --------------------------------------------- > > Key: DERBY-788 > URL: http://issues.apache.org/jira/browse/DERBY-788 > Project: Derby > Type: Bug > Components: Services, Test, Regression Test Failure > Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1 > Environment: Solaris 10 (generic hardware) > Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider > Reporter: Kristian Waagan > Assignee: Kristian Waagan > Priority: Minor > Fix For: 10.2.0.0 > > The 'store/encryptionKey.sql' test fails on Solaris 10. > Investigation revealed that the failure is caused by a difference in behavior > between the 'SunPCKS11-Solaris' provider and other providers (tested with > 'SunJCE' and 'IBMJCE'). > The initialization of the DES cipher fails because the 16 byte key (specified > in the test) is not translated to a 8 byte DES key by > SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't > know the spec). Enquiries are being made. > The exception is being thrown from the constructor of > 'impl.services.jce.JCECipherProvider'. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
