[
https://issues.apache.org/jira/browse/DERBY-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737171#action_12737171
]
Rick Hillegas commented on DERBY-3710:
--------------------------------------
I believe that the bug is caused by special logic in JCECipherFactory. For AES
encryption, we pad the encryption key to a 16 byte boundary. This means that
for AES encryption, a 192 bit key is extended to 256 bits. An MD5 digest is
appended to the encrypted key. At initial boot time, this digest is computed on
the unpadded value. But on subsequent boots, we check the stored digest against
a digest computed on the padded value. The reboot fails because the unpadded
digest does not equal the padded digest. I will submit a patch and test for
this.
> cannot access a database using AES encryption with encryptionKeyLength=192
> after it's been shutdown
> ---------------------------------------------------------------------------------------------------
>
> Key: DERBY-3710
> URL: https://issues.apache.org/jira/browse/DERBY-3710
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.5.1.1
> Environment: reproduced with ibm's jdk 1.5 and 1.6, and sun's jdk15.
> AES encryption with encryptionKeyLength=192 requires unrestricted security
> policy jars on your jvm
> Reporter: Myrna van Lunteren
> Assignee: Rick Hillegas
> Attachments: repro-3710.sql, repro.sql
>
>
> Accessing a database created using encryptionAlgorithm: AES/CBC/NoPadding,
> and encryptionKeyLength=192 after it's been shutdown fails like so:
> -----------------------
> ERROR XJ040: Failed to start database 'encdbcbc_192', see the next exception
> for details.
> ERROR XBM06: Startup failed. An encrypted database cannot be accessed without
> the correct boot password.
> ----------------------
> This does not occur when you use encryptionKeyLength=128 (does not require
> unrestricted jars) nor encryptionKeyLength=256 (does require unrestricted
> policy jars).
> Note: our test (in derbyall): store/aes.sql does not test this, firstly it
> doesn't test the larger sizes (because it would diff & fail unless you have
> been able to adjust your jvm's policy jars), and secondly it doesn't shutdown
> before reconnecting.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
