[DERBY-1088] Verify handling of invalid encryption keys

• Type: Task
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 10.2.1.6
• Component/s: Services
• Assignee: Unassigned
• Reporter: Kristian Waagan
• Created: 08/Mar/06 23:53
• Updated: 08/Mar/06 23:55

Description

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.

Issue Links

• relates to: DERBY-788 'store/encryptionKey.sql' fails on Solaris 10