|
Added component 'Regression Test Failure', as this test fails on Solaris10 with the 'SunPCKS11-Solaris' Java Security provider (which is the default provider). Will fail until the test is changed or the provider is changed/fixed. See earlier comment for more details.
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. According to the comment, Sunitha is having a look at the code/test. Awaiting feedback before we decide what to do with the test.
Since the test is testing the codepath when encryptionKey attribute is used, changing the test so it passes with the JCE provider on Solaris (SunPCKS11-Solaris) should be ok and I think this is what we should do ( either implement 1 or 2)
1) change test to either use DES with 8byte encryptionKey 2) change test to use AES algorithm with 16byte encryptionKey provided AES support is available with the PCKS11-Solaris. That should solve the test failure issue and we would still be testing this case for encryptionKey. Just as an fyi , I tried the first connection url with AES and it works ok with the Sun JCE with jdk 142 on windows. ===================== That said, I think it is interesting that we cant expect the translateKey to always translate the key for us. I found this in the java api for SecretKeySpec. public SecretKeySpec(byte[] key, String algorithm)Constructs a secret key from the given byte array. This constructor does not check if the given bytes indeed specify a secret key of the specified algorithm. For example, if the algorithm is DES, this constructor does not check if key is 8 bytes long, and also does not check for weak or semi-weak keys. In order for those checks to be performed, an algorithm-specific key specification class (in this case: DESKeySpec) should be used. In derby code, there is // Since the key may be a series of bytes generated by an arbitary means // we need to translate it into a key suitable for the algorithm. secretKey = skf.translateKey(new SecretKeySpec(secretKey.getEncoded(), secretKey.getAlgorithm())); I think you are right about - that we cannot assume that invalid key checks would not happen with the call. I looked at the Java api for 1.4.2 but I didnt find any AES specific KeySpec but found for others like DES and DESede. I think we should open another jira so we can record what we learnt here so we can improve this. Thanks Kristian for your analysis and following up on this jira. One question - does the exception come from the Cipher.init , or the (SecretKeyFactory) skf.translateKey method ?
For the cases I have tested, the exception comes from the Cipher.init method. The skf.translateKey seems to simply return what is passed in when it does not know what to do with the key. Note that the capabilities of the method depends on the implementation/provider.
I tried using AES instead of DES, but got a few errors. I suspect they are only minor changes in the error message that are reported, but I have not investigated. I plan on rewriting this test to a JUnit test, but I am awaiting some JUnit framework commits. Then we could have the test run with both DES and AES with minimal changes and code duplication in the test. My suggestion is that we create a new Jira issue to track the general problem regarding use of the skf.translageKey method (as Sunitha suggested), and that the 16 byte key is replaced with a 8 byte key to stop the test from failing in the regression test on Solaris10. I will start/do the rewrite during a few days if I don't get pushback. '
One test case is changed; where it previously tested a key that was of incorrect length (longer than 8 bytes, shorter than 16), it now tests an incorrect key of the correct length. It is not possible to make the test pass on Solaris10 with a key of incorrect length, because keys of length less than 8 bytes are caught by a check in the code, and keys longer than 8 bytes cause the underlying security provider to fail ('SunPCKS11-Solaris'). This issue will be addressed in Ran derbyall on Solaris10, which resulted in 6 known errors (some are already fixed according to the tinderbox test). 'store/encryptionKey.sql' passed. I'm planning to review and commit this patch.
Patch looks good. store/encryptionKey.sql does not fail under
Solaris 10 / Sun JVM 1.5.0. Derbyall passes without errors. Committed revision 381333. Linked to issue
Fix verified. Created DERBY-1088 to track general issues/weaknesses in the way external encryption keys are handled.
Committed to 10.1 branch with revision 397972.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Minor
'store/encryptionKey.sql' fails on Solaris 10
"...it is not clearly defined how SecretKeyFactories and Ciphers behave when passed a key that is "too long". In most cases I would expect the two to behave the same. That means that even though your technique worked for DES and the providers you have tried, it may not work for other algorithms or providers."
This raises a few questions:
1) Is the approach used by Derby valid? (wrt. what we can expect from crypto providers)
Why allow the user to believe, say, a 512 byte key is used, when in fact only the first 8 bytes are used for encrypting/decrypting the database? Are we able to enforce a valid key length for a given algorithm? (without hardcoding limits in Derby code)
2) Why does the test use a 16 byte key for the DES algorithm?
Should it be changed to 8 byte, or is the test written to test the behavior of Derby when the key is not according to the specifications for the given algorithm?
I will take no further action until I get some feedback. Until a) the 'SunPCKS11-Solaris' is changed, b) the test is changed or c) another default provider is set for Solaris10, the test will continue to fail on Solaris10 (and probably higher versions).