Java discussion forum to accompany the Javamex web site.
PBE questions and clarifications
The PBE article was very useful and I have a couple of questions that I'd appreciate your thoughts on if you have any/have the time.
I work in the IT arm of a fairly large organisation and have a requirement to ensure that passwords used by Java apps to connect to RDBMS (for example), are not stored in cleartext on the file system.
The guidelines laid down from on high say we should use PBE to encrypt passwords and hold PBE password, algorithm and the encrypted credential in property files.
There is no requirement to have a memorable PBE password so the guidelines also recommend that we randomly generate the PBE password.
My first question is do the characteristics of the initial PBE password have any bearing on the strength of the encryption when using PBE. For example does it add anything to encryption strength to use a randomly generated 112 bit TripleDES key as the PBE password ?
Secondly with standard install of Sun 1.5 JRE, the security jurisdication policy files prohibit the use of PBEWithMD5AndTripleDES. Our internal standard JRE doesn't come with the unlimited jurisdiction files and changing it is a bureaucratic nightmare.
However we have found that on top of the three PBE Cipher schemes you mention in the article, I think the Sun JDK from 1.5 supports PBEWithSHA1AndDESede (see http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide....)
Interestingly this appears to work with the standard (strong), policy files.
This being the case (and please correct if this is wrong), what is the difference between TripleDES and DESede - I thought they were analogous. In which case why is one scheme available with standard (strong), 1.5 policy files and the other prohibited?
I'm assuming this is something to do with maximum key sizes which leads onto my final question (if not answered already), how do I determine the max size of the encryption key and more importantly the size of the key that will actualy be used (do we have any control over that)? Driver behind this question is that our IT security guidelines say we must use a key of at least n bits so if my standard JRE allows me to use PBEWithSHA1AndDESede how do I know if this algorithm can be used to generate a key of n bits, and then how do I ensure that it does?
I work in the IT arm of a fairly large organisation and have a requirement to ensure that passwords used by Java apps to connect to RDBMS (for example), are not stored in cleartext on the file system.
The guidelines laid down from on high say we should use PBE to encrypt passwords and hold PBE password, algorithm and the encrypted credential in property files.
There is no requirement to have a memorable PBE password so the guidelines also recommend that we randomly generate the PBE password.
My first question is do the characteristics of the initial PBE password have any bearing on the strength of the encryption when using PBE. For example does it add anything to encryption strength to use a randomly generated 112 bit TripleDES key as the PBE password ?
Secondly with standard install of Sun 1.5 JRE, the security jurisdication policy files prohibit the use of PBEWithMD5AndTripleDES. Our internal standard JRE doesn't come with the unlimited jurisdiction files and changing it is a bureaucratic nightmare.
However we have found that on top of the three PBE Cipher schemes you mention in the article, I think the Sun JDK from 1.5 supports PBEWithSHA1AndDESede (see http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide....)
Interestingly this appears to work with the standard (strong), policy files.
This being the case (and please correct if this is wrong), what is the difference between TripleDES and DESede - I thought they were analogous. In which case why is one scheme available with standard (strong), 1.5 policy files and the other prohibited?
I'm assuming this is something to do with maximum key sizes which leads onto my final question (if not answered already), how do I determine the max size of the encryption key and more importantly the size of the key that will actualy be used (do we have any control over that)? Driver behind this question is that our IT security guidelines say we must use a key of at least n bits so if my standard JRE allows me to use PBEWithSHA1AndDESede how do I know if this algorithm can be used to generate a key of n bits, and then how do I ensure that it does?
About
© 2024 Created by Neil Coffey.
Powered by
