> Then maybe a separate issue for handling the block size. There are two > issues I see for block size.
Yes, these are separate issues. > 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? Remember that whole security of any secure cryptographic algoritm lies in the key and the key only. Obscuring algorithm used will not improve security at all unless you choose a known insecure algorithm. So, no harm done in showing block size, or even the algorithm type itself. Block size is completely unrelated to key size. It is a property of block cipher algorithm itself. Block sizes are not generally a parameter of the algorithm - they affect the computation and thus the algoritm itself. You change block size, you get different algorithm. I'm not aware of any algoritm that would have several variants with different block sizes referred to with the same name. It is hard to keep an algorithm secure with variable block size, as the cryptographic strength of the algorithm may vary with it. So the algorithm designers prefer to stick to one well tested block size. > 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? My Javadoc (JDK5.0) does not say that, and it would not make much sense anyway. It would mean that different providers would implement different incompatible algorithms with the same name, which would be a disaster. Arent you mistaking it with default key size? >> Currently the java API does not allow a way to request an algorithm >> with a particular block size. And for a good reason. There is no such thing. Jan
signature.asc
Description: OpenPGP digital signature
