Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1099331138.1141833339028.JavaMail.jira@ajax>
Date: Wed, 8 Mar 2006 15:55:39 +0000 (GMT)
From: "Kristian Waagan (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Created: (DERBY-1088) Verify handling of invalid encryption
 keys
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Verify handling of invalid encryption keys 
-------------------------------------------

         Key: DERBY-1088
         URL: http://issues.apache.org/jira/browse/DERBY-1088
     Project: Derby
        Type: Task
  Components: Services  
    Versions: 10.2.0.0    
    Reporter: Kristian Waagan
    Priority: Minor


The handling and checking/verification of external encryption keys passed in to Derby is possibly not good enough. Some information was obtained while investigating bug DERBY-788. The most important information is copied here, see the issue for more background information.

----------
"...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." 

----------
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. 

-- 
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