db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10
Date Mon, 13 Feb 2006 22:51:43 GMT
    [ 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


Mime
View raw message