Change encryption algorithm

Question

Does anyone know good tutorials to change PBEWithMD5AndDES encryption PBEWithMD5AndDES to AES for Java application? Specifically, I want to know what precautions I should take by modifying this algorithm for a safer one. Any important test cases to check before and after changing the algorithm. Another question, since I used PBEWithMD5AndDES , most user passwords are encrypted using this algorithm. Therefore, if I change my algorithm to AES , how can I make sure that password decryption happens with the old algorithm, while I can still use the new algorithm for any new encryption.

Answer 1

Usually you do not encrypt the user password, you just want to use it instead of salt.

Switching from one encryption system to another will be a little painful, as I see you have two options:

• Decrypt during the upgrade process, then re-encrypt all passwords
• Add a flag indicating the encryption method used. All existing passwords will obviously be set to the current standard. New users will be tuned to whatever method you choose, and you can migrate other users when they change their password.

Answer 2

If you already have data encrypted in a format, and you want to start using a different encryption scheme, b , I can think of two ways to achieve this:

• Decrypt all your data and re-encrypt it with `b`. This approach will be good if you can disconnect your data warehouse and "fix it all at once."
• For each element you are trying to decrypt, try to decrypt it, using `b` first. If this fails, decrypt it with `a`. The next time you try to encrypt something, make sure you use `b`. This approach can be used when you cannot use your data warehouse offline, but you want to encrypt all your data using a different algorithm. All your data will eventually be encrypted using a different algorithm.

Answer 3

In fact, there are no problems with changing the algorithms. What you need to do is decrypt the encryption text, and then encrypt the resulting text text with a new algorithm. It's simple. If you intend to make this transition over time, I would suggest creating a new database table that keeps track of whether a particular object (based on a unique identifier) ​​has been migrated to the new algorithm. If so, then you simply use the new algorithm to decrypt it, and you can forget about it, if not, then you use the old algorithm to decrypt it. Despite this, all new encryption should be performed using the new algorithm.

Now there is a second problem. Why are you trying to decrypt passwords? Just save the password hash and forget about it. If you can decrypt passwords, you can introduce a potential vulnerability. If an attacker can take possession of your key, which you use to encrypt these passwords, he can gain access to a simple text password. The user could not only use this information to compromise your system, if your users use the same combination of username and password for other sites, these accounts will also be compromised. You should only store the password hash (SHA is good, do not use MD5), and then when the user tries to log in, you enter data and compare the two results. You do not need to know what a plain text password is.

Answer 4

you can look in ESAPI - java http://code.google.com/p/owasp-esapi-java/

ESAPI 1.4 used PBEWithMD5AndDES, but in 2.0 they introduced AES

check your mail chain here

you can check the difference between the two implementations

Answer 5

PBEWithMD5AndDES is a user password entry method, and it PBEWithMD5AndDES an encryption scheme that can be used to protect further data. This is not a password verification or encryption method.

If you are only interested in password verification, decrypt the passwords and replace them with a secure hash and map the hashes in the future. You will also need a password reminder service for the reset password service.

The question is, where is the password that you pass to the PBE algorithm? If this is a fixed password for your application, you just need to replace it and do some rolling update. As an observation, if you store the encrypted data as text, either in hex encoding or in the base-64, there are characters that cannot be displayed in text output and which, therefore, can be added to indicate a new encryption scheme. For example, the symbol : not displayed in the base-64. This will allow you to determine what has been updated and what has not.

If passwords come from the user, each user has his own encrypted password. In this case, you can only re-encrypt all data encrypted with user encryption when the user provides his password.

The most direct replacement will go along the PBEWithSHA256And256BitAES lines. Unfortunately, this is not supported by Java 6, so you will need a third-party JCE library such as Bouncy Castle . Bouncy Castle offers PBEWithSHA256And256BitAES-CBC-BC , which would be a suitable replacement.

The encryption update process is a problem. No matter what data was encrypted using DES, it can only be decrypted using a user password. I assume that you do not have access to passwords. This means that you can only re-encrypt the data when it is given by a person who knows the password. You will have a long period of time when your system contains a mixture of ciphers, so you need a way to determine what is being converted.

If we are talking about files, you can change the suffix of the file or the folder in which they are stored. If we are talking about BLOBs in a database, you can add an additional column to the database table to say what encryption is. If none of these are possible, you can add some form of header to the data to indicate that it has been encrypted in a new way. This is a little risky, since your existing data does not have a header, and it is likely that it will accidentally meet a new header.

It may also be advisable to keep a list of those users who have not yet converted the data, so you can offer them to convert.