db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <skam...@Yngvi.Org>
Subject Re: Regarding Derby42 : Do not store the encryption key length and the encryption block size in service.properties:
Date Tue, 19 Oct 2004 18:43:01 GMT
Daniel John Debrunner wrote:

>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
>>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.

>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?
Derby supports block cipher algorithms.
An encryption algorithm is specified as  

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.

>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?
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 :
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.


>Version: GnuPG v1.2.5 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

View raw message