Some clarification needed on PKCS #5 PBE

Question

Hi all,
This is my first time posting on SUN Forums. Hope to be able to get your assistance in the programming field.
I have questions about PKCS #5, as I couldn't understand how it can help improve security when using salt and iteration count.
PKCS #5 states that salt and iteration count does not need to be kept secret as it is normally appended with the encrypted data.
To my understanding,
On encryption side, user will input a password and salt will be appended to the password, followed by a hashing algorithm.
key[1] = SHA-1(password+salt)
Iteration count addeds to key strengthening by:
Key [1] = SHA-1(password+salt)
key[2] = SHA-1(Key[1])
Key[i] = SHA-1 (Key[i-1]
Encrypted Data will then be obtained by:
Ciphertext = AES(Key[i] and Plaintext)
Hence the data payload will be as follows:
|| Encrypted Data+Salt+Iteration Count ||.
When the receiver receives the message, the decryption is similar.
key[1]= (password+obtained salt) from Payload
Key[i] will then be obtained depends on the Iteration Count,
and encrypted Data will be decrypted with Key.
My lack of understanding here is how does using salt increases security when the salt is public?
If a 56bit salt is used and only available to the receiver, any attacker who wants to decrypt the message might need to try 2^56 possible keys using a SINGLE password.
But if the salt is public, the only difference from adding salt and not adding salt is the key strengthening process.
How is password based encryption safer when comparing to AES-128 when the password the user input maybe commonly 48 bits?
Thank you all in advance! Hope to receive replies!
Regards,
Brandon

Answer 1

barnnod wrote:
Hi Sabre150,
Thank you for your suggestion. My application is enterprise based hence I think it is okay that the password is made known to employees only. (E.g one password per day, different department deploys different password each day). So each day each department has to distribute it's daily password to each department it needs to communicate with. So not just once every now and then do you have a key distribution problem you have one every day.
>
My actual scenario given by the school is:
"An organisation's daily operations involve frequent data messaging among mobile devices. The data transmitted are confidential and recently it has been observed that there is an increased number of incidents involving unauthorised tapping of data signals from unknown sources. Due to the sensitivity of data, the senior management has commissioned its IT security team to propose a prototype for a secured messaging application to enhance data transmittion security. The solution must also fufil operational needs such as response time and peak traffic tranmission."
I am very glad that you are helping me in this. What kind of encryption scheme do you think I can adopt? As I said. I would use Public Key cryptography probably using RSA.
What I have thought about is:
1) PBE I view PBE as suitable for personal use only. For example - if I want to encrypt data just for myself then using a password based approach makes sense since I don't have to distribute the key. I just keep it in my head.
2) PKCSYou would need to elaborate on this since PKCS is a broad brush.
3) Create a messaging server who can help distribute public keys. (But I left with 3 weeks upon completion and im not very confident of this because i dont know how to :( )Public Key distribution is fairly easy since you want everybody to have access to your public key. The public key could be broadcast as an SMS message or posted on a web server for people to download. I publish my public key on my web server.
So as what I derived from your post, the key distribution problem can be solved using asymmetric key algorithm. Pretty much so but not completely. One needs to be able to verify that a particular public key belongs to who you think it does. This process is normally done by distributing a certificate that contains the Public Key. The certificate is signed by a Certification Authority who does checks to make sure the purported owner is actually the owner. Since this is for internal use, rather than paying a fortune to a third party CA, one can use one of the free ones. You might want to take a look at [http://www.devx.com/Java/Article/10185|http://www.devx.com/Java/Article/10185] but there are others out there.
>
Meaning the Sender A uses Receiver A's public key and using RSA(randomly generated symmetric key), and send the ciphertext over to Receiver A. Receiver A uses it's own private key to decrypt the ciphertext, and obtain the private symmetric key between Sender A and Receiver A. Sender A and Receiver A .That is the way I would do it
then can securely do messaging from then on. The session keys would not be used more than once. Each message would use a different random session key.
But I do not know how can I derive the Receiver A's public key. I guess the use of a messaging server can solve this.Yes. Or a simple Web server. An admin person just publishes the public keys for each user and each user just sends his public key to the admin person just once.
>
Please advice!
Thank you :)You background makes doing the whole thing in 3 weeks a bit tight so you should leverage any third party software you can.
Since this is a school/university project you might just want to use PBE for the moment and then in your report explain the key distribution problem and explain how to a more comprehensive and secure system could be achieved. That way you get to do the work and to show your examiners that you have thought about the problems associated with your naive PBE based solution and can propose a better solution. In your position I would ask my Tutor for advice on this - it could save you a load of effort.
I don't work with Mobile devices so I don't know what libraries are available. I suspect you may need design your solution around what tools you have available.
Edited by: sabre150 on Sep 27, 2009 12:45 PM