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?

Ritaritardando

I'm using J2SE 1.5.0_18 with Apache Derby 10.5.3.0 (latest release). – Ritaritardando

The top URL actually has "create=true" but it is omitted here for clarity of the comparison. – Ritaritardando

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

Fournier

Thanks for your clear and detailed explanation and demonstration. I tested it out myself and was convinced that it is secure. Have a great Christmas (if you celebrate it) and New Year! – Ritaritardando

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.

Lytic

Thanks for the idea. When I boot the second time without the "dataEncryption=true" it still boots an allegedly Triple DES encrypted DB with plain DES. – Ritaritardando

Doesn't the key contain everything required after all? – Lytic

I want to be sure that it is encrypted with strong ( >=128bit ) encryption, not 64bit. Although the boot password is large enough for 168bit (Triple DES) I think it could also be used for 64bit with the extra characters being ignored. Key size (encryptionKeyLength parameter) does not appear to be honored. Please expound on what you mean? – Ritaritardando

Thanks for your efforts, Pascal! They were very helpful in arriving at a solution. Joyeuse Fêtes et bonne année! – Ritaritardando

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.

Dialectician

Thanks for that clarification, now I understand what Pascal was trying to say, but I don't believe it is correct: "Booting an Encrypted Database: If the algorithm that was used when the database was created is not the default algorithm, you must also specify the encryptionAlgorithm attribute. The default encryption algorithm used by Derby is DES/CBC/NoPadding." db.apache.org/derby/docs/10.5/devguide/tdevdvlp40140.html – Ritaritardando

It looks like there are definitely some weak points in the documentation in these areas, and also some cases where Derby is quietly ignoring your connection attributes rather than explicitly warning you that they are being ignored. Some of these are already logged in the Apache JIRA (e.g., DERBY-4328, DERBY-2409). It would be great if you could come visit the Derby site and log some of the other problems that you've found so that we can improve Derby's documentation and error-handling. I thought that Paul Wagland's answer, below, was very thorough and helpful, btw. – Dialectician

Thanks for your help Bryan! I have filed a bug. Have a great New Year! – Ritaritardando