Can Derby / JavaDB _really_ encrypt with Triple DES rather than (plain) DES?

Question

It seems to be confusing Triple-DES (>128bit) with plain DES (64bit). I'm trying to encrypt a Derby database with Triple DES (or DESede) using Java 1.5

I found this discussion forum message about a problem with JDK 1.5 by chance and so checked to make sure that it really was using DESede and not plain DES. When I created the database with a Triple DES (168bit) URL

jdbc:derby:MySecureDB;dataEncryption=true;encryptionAlgorithm=DESede/CBC/NoPadding;bootPassword=$ecureC@deCanBr@kE0074242

I was still able to open it and access it with the (plain) DES (64bit) URL

jdbc:derby:MySecureDB;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;bootPassword=$ecureC@deCanBr@kE0074242

This is not the behavior I expect!!! I should not be able to open it with the wrong encryption algorithm. How can I make sure it really encrypts it with the right (>128bit) algorithm?

Derby seems to use the right function for Java 1.5 mentioned in JCECipherProvider.java. My reading of the code indicates that Derby does not handle Triple DES as different from plain DES... Can I really trust that it is using strong encryption?

Answer 1

I believe that the documentation is wrong, and that you do not actually need to specify the encryption algorithm to use when using a non-default algorithm, since the algorithm that should be used is specified in $DERBY_HOME/database/service.properties

In my case, when I created a database with your parameters my service.properties had the following contents (amongst other non-relevant entries):

log_encrypt_algorithm_version=1
encryptionAlgorithm=DESede/CBC/NoPadding
dataEncryption=true
derby.encryptionBlockSize=8
encryptionKeyLength=168-24
encryptedBootPassword=472b7cc5600605333392dd10a46067d2e2935fd4c350d533-43435
data_encrypt_algorithm_version=1

You can verify that this is used, by changing the algorithm used. If you change the specified algorithm in that file to DES, then you will not be able to restart the database.

For example:

$ ../bin/ij
ij version 10.4
ij> connect 'jdbc:derby:testdb;create=true;dataEncryption=true;encryptionAlgorithm=Blowfish/ECB/NoPadding;bootPassword=$ecureC@deCanBr@kE0074242';
ij> quit;
$ sed -i .o 's/Blowfish/DES/' testdb/service.properties 
$ ../bin/ij
ij version 10.4
ij> connect 'jdbc:derby:testdb;bootPassword=$ecureC@deCanBr@kE0074242';
ERROR XJ040: Failed to start database 'testdb', see the next exception for details.
ERROR XBM06: Startup failed. An encrypted database cannot be accessed without the correct boot password.  
ij> quit;
$ sed -i .o 's/DES/Blowfish/' testdb/service.properties 
$ ../bin/ij
ij version 10.4
ij> connect 'jdbc:derby:testdb;bootPassword=$ecureC@deCanBr@kE0074242';
ij> quit;
$ 

Answer 2

According to Working with encryption from the Java DB Developer's Guide, the first URL looks fine to encrypt a database on creation (because it specifies dataEncryption=true) and should have generated a 168 bits encryption key.

Now, still according to the documentation, I don't think that you should use dataEncryption=true when Booting an encrypted database. My understanding is that you just need to use bootPassword and encryptionAlgorithm.

I admit I didn't test this and, actually, I'm really wondering what happens exactly:

• if you don't specify dataEncryption and use the wrong encryptionAlgorithm in the 2nd URL.
• When you specify dataEncryption=true and use another encryptionAlgorithm (does it recreate an encrypted database?).

The documentation isn't clear about that.

Answer 3

I think the encryptionAlgorithm parameter only matters when you are first doing the encryption (that is, when you are first creating an encrypted database, or when you are first encrypting an unencrypted database).

Once you have encrypted the database, from then on, you just need to specify the bootPassword. Derby already knows what encryption algorithm was used.