Daniel John Debrunner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sunitha Kambhampati wrote:
Do not store the encryption key length and the encryption block size in service.properties for encrypted database when external key is used.
Regarding fix for derby 42 (http://nagoya.apache.org/jira/browse/DERBY-42 ): 1)The encryption key length is used only for error checking and the fix to not store this information is OK and simple. Also attached is patch to fix this first part .
2)However removing the encryption block size property is little more
involved:
Currently, the encryption block size is obtained during creation of the
encrypted database and stored in service.properties. On subsequent
connections, this stored value is used for padding of logs.
I think that Derby-42 should be just be for removing the key length from service.properties. That would then be fixed with your patch.
I agree.
Derby supports block cipher algorithms.Then maybe a separate issue for handling the block size. There are two issues I see for block size.
1) Does having the block size in service.properties compromise the security of an ecrypted database in any way? E.g. does it give a clue to the key length or algorithm?
An encryption algorithm is specified as algorithmName/feedbackMode/Padding.
Having the encryption block size in service.properties does not for sure indicate the entire algorithm that was used. But it will give hint towards the algorithm name or atleast to the set of algorithms that could probably have been used.
As an example : currently Sun JCE implementation of DES , Triple DES, Blowfish support block sizes of 8 bytes whereas AES requires 16 bytes.
Thus, if an encryption block size stored in service.properties is 8 bytes , then it gives hint that the encryption algorithm is one of the three (DES or TripleDES or Blowfish).
I am aware of AES algorithm implementations of Sun, that supports 16 bytes block size. Thus if the encryption block size stored is 16, it gives an hint that the encryption algorithm used was probably AES.
Note, that it still does not give any hints to the entire algorithm used (ie the feedback mode etc) and also does not give information about the key length that was used. .
I have tested with Sun JCE and IBM JCE implementations, and the information above is based on that. If anyone has tested or is aware of any other implementation of the agorithms, please post to the list.
Currently the java API does not allow a way to request an algorithm with a particular block size. The way the derby code works right now is :2) Since default block size is provider specific (from Javadoc for Cipher), what does the Derby code do with the block size when an encrypted database is booted? Does it request an algorithm with that block size?
1) on creation of database, the block size is obtained from Cipher.getBlockSize() and this block size is used for padding purposes. This block size is then stored in the service.properties.
2) on subsequent boots, the block size that was stored in the service.properties is used for decrypting as well as encrypting purposes. This works under the assumption that
* the algorithm implementation will continue to support the block size that was used when creating the database or else it will throw an IllegalBlockSizeException exception that will be wrapped in a StandardException with SQLState.CRYPTO_EXCEPTION.
If in the future, the java api supports a way of requesting an algorithm with a specific block size, then that code can be added in derby to request it and use it accordingly.
Sunitha.
Dan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBdUwcIv0S4qsbfuQRAqNOAJ9vVFnEnMAtRfmeteQupGtA1vLHBACg5kLT BAx3mcNhe0md0JvwViIvgO4= =qhI3 -----END PGP SIGNATURE-----
