db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Created: (DERBY-1088) Verify handling of invalid encryption keys
Date Wed, 08 Mar 2006 15:55:39 GMT
Verify handling of invalid encryption keys 

         Key: DERBY-1088
         URL: http://issues.apache.org/jira/browse/DERBY-1088
     Project: Derby
        Type: Task
  Components: Services  
    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 message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message