Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1100603638.1139871103145.JavaMail.jira@ajax.apache.org>
Date: Mon, 13 Feb 2006 23:51:43 +0100 (CET)
From: "Sunitha Kambhampati (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on
 Solaris 10
In-Reply-To: <1844336454.1136300522487.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ 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