Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 3 Sep 2014 06:47:51 +0000 (UTC)
From: "Dyre Tjeldvoll (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12706175.1396446338000.4104.1409726871569@Atlassian.JIRA>
In-Reply-To: <JIRA.12706175.1396446338000@Atlassian.JIRA>
References: <JIRA.12706175.1396446338000@Atlassian.JIRA>
 <JIRA.12706175.1396446338181@arcas>
Subject: [jira] [Closed] (DERBY-6537) StringUtil.fromHexString is used to
 convert encryptionKey to byte[]
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-6537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dyre Tjeldvoll closed DERBY-6537.
---------------------------------

Fix verified

> StringUtil.fromHexString is used to convert encryptionKey to byte[]
> -------------------------------------------------------------------
>
>                 Key: DERBY-6537
>                 URL: https://issues.apache.org/jira/browse/DERBY-6537
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation, Services
>    Affects Versions: 10.10.1.1
>            Reporter: Dyre Tjeldvoll
>            Assignee: Kim Haase
>            Priority: Minor
>             Fix For: 10.11.1.1
>
>         Attachments: DERBY-6537.diff, DERBY-6537.stat, DERBY-6537.zip
>
>
> The javadoc for StringUtil.fromHexString states that its intended use is to "Convert a hexidecimal string generated by toHexString() back into a byte array", and that null is returned if the length of the hex-string is not even. 
> But in JCECipherFactory.init() it is being used to convert the encryptionKey property string to byte[]. For this usage such a restriction makes no sense, and is confusing as it is not documented (at least not in the dev guide chapter about encrypting databases).
> For this usage it would be better to use 
> new BigInt(encryptionKey,16).toByteArray() which would not have this restriction. But even with this change the documentation should probably be updated to state that the value for the key must be a valid hex-string, as that is what it will be interpreted as. The first section of the doc should probably also mention that DES is the default algo, and what its minimum key length requirements are (now you need to look at the section about specifying an alternate algo, to find that).


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)