encrypt and decrypt a file in Java

[Krish Yeruva]

Hi,
Can any body suggest me to encrypt and decrypt a file(file is having any extension) in Java by using any algorithm like md5?

Thanks in advance

[Lester Burnham]

MD5 is not a cipher (which is used to encrypt/decrypt data), but a hash (or digest) - which is a one-way transformation. If you need to recover the data, choose a cipher like AES or Triple-DES.

The Java API for for encryption is called JCE; you'll find introductory articles about it in the SecurityFaq.

[Krish Yeruva]

Hi Lester,
Thanks for your reply.
What I need is like if I have a A.txt or A.pdf or (A.any extension) file. I need to encrypt that file and decrypt the same.
Can you send me the code sample for that please.

[Soumyajit Hazra]

Giving you a very basic example of encode and decode a string using AES. Hope this might help

package foo;

import java.security.InvalidKeyException;
import java.security.NoSuchAlgorithmException;

import javax.crypto.BadPaddingException;
import javax.crypto.Cipher;
import javax.crypto.IllegalBlockSizeException;
import javax.crypto.NoSuchPaddingException;
import javax.crypto.spec.SecretKeySpec;

public class EncryptDecryptTest {
	
	public static Cipher getCipher(
           String synchro1, String synchro2, String synchro3, String synchro4,boolean isEncryptMode)
	throws NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException
	{
		byte raw[] = (synchro1 + synchro2 + synchro3 + synchro4).getBytes();
		SecretKeySpec skeySpec = new SecretKeySpec(raw, "AES");
		Cipher cipher = Cipher.getInstance("AES");
		if(isEncryptMode){
			cipher.init(Cipher.ENCRYPT_MODE,skeySpec);
		}
		else{
			cipher.init(Cipher.DECRYPT_MODE,skeySpec);
		}		
		return cipher;
	} 

	public static byte[] hexToByte(String hex)
	{
		byte bts[] = new byte[hex.length() / 2];
		for(int i = 0; i < bts.length; i++){
			bts[i] = (byte)Integer.parseInt(hex.substring(2 * i, 2 * i + 2), 16);
		}

		return bts;
	}

	public static String toHexString(byte bytes[])
	{
		StringBuffer retString = new StringBuffer();
		for(int i = 0; i < bytes.length; i++)
			retString.append(Integer.toHexString(256 + (bytes[i] & 0xff)).substring(1));

		return retString.toString();
	}

	public static String encrypt(String text)
              throws InvalidKeyException, NoSuchAlgorithmException, NoSuchPaddingException, IllegalBlockSizeException, BadPaddingException{
		javax.crypto.Cipher cipher = getCipher("bb5","1860", "17a74", "213f",true);
		return toHexString(cipher.doFinal(text.getBytes()));
	}

	public static String decrypt(String text)
              throws IllegalBlockSizeException, BadPaddingException, InvalidKeyException, NoSuchAlgorithmException, NoSuchPaddingException{
		javax.crypto.Cipher cipher = getCipher("bb5","1860", "17a74", "213f",false);
		String st=new String(cipher.doFinal(hexToByte(text)));		
		return st;
	}

	public static void main(String []str) throws Exception{
		String secretText="javaranch";
		String enSecretText=encrypt(secretText);

		System.out.println("\""+secretText+"\" after encryption---->"+enSecretText);

		String deSecretText=decrypt(enSecretText);
		System.out.println("After decryption --->"+deSecretText);
	}
}

Check the main. It encodes the string "javaranch" and decode it back.

[James Sabre]

Soumyajit Hazra wrote:Giving you a very basic example of encode and decode a string using AES. .

That code has two obvious security flaws and at least one implementation flaw. Also, by providing code like that is that it does not do what the OP requested in that it does not encrypt and decrypt a file the OP will be tempted to shoe-horn the content of a file into a String and encrypt that.

1) By specifying just AES for for the Cipher creation one gets AES/ECB/PKCS5Padding. ECB mode is susceptible to forgery by splicing of ciphertext and one should use one of the feedback modes such as CBC using a random IV.

2) Placing the key in the code means that it can easily be extracted. Trivial using a decompiler and not so difficult just looking for string literals in a jar file.

3) The obvious implementation flaw is that the platform default character encoding is being used to turn the cleartext String into bytes. The default character encoding may not be able to completely represent all the characters in the String and it depends on the platform, locale and Java version being used. This means the the resultant ciphertext file may not be decipherable on some computers.

4) Since the ciphertext has no human interpretation it is usually a mistake to Hex or Base64 or ASCII85 encode it unless one is forced to pass it to a channel that only supports characters. Ciphertext is binary and should left as binary unless one absolutely must make it ASCII.

5) When encrypting files it is usually better to use CipherOutputStream and/or CipherInputStream.

The next thing we will see from the OP is him reporting that the code does not work on his .gif files or his .doc files.

P.S. Though there is little point when one as algorithms such as AES available, MD5 or any digest algorithm can be used to encrypt by using the digest to create blocks of pseudo random bits seeded with a key and random IV that may then be XORed with the cleartext to create the ciphertext.

[Soumyajit Hazra]

I appreciate your thorough analysis of the code James.But regarding point 2 I must say it's a mere example not a production code and when we have to write code related to security it's like commonsense that not to put any such string hard coded in the source code. I'll keep in mind all of your point what you have suggested for betterment of the code.And I clearly mentioned this code is encoding a string not a file. It's only to give a idea because often after seeing a code only we understand what exactly we need to achieve.

[James Sabre]

Soumyajit Hazra wrote:I appreciate your thorough analysis of the code James.But regarding point 2 I must say it's a mere example not a production code and when we have to write code related to security it's like commonsense that not to put any such string hard coded in the source code. I'll keep in mind all of your point what you have suggested for betterment of the code.And I clearly mentioned this code is encoding a string not a file. It's only to give a idea because often after seeing a code only we understand what exactly we need to achieve.

It is my experience that though it is common sense not to hard code keys into the source code it is a very common practice (see note 1). It is also common practice to use ECB block mode and to use the default character encoding when converting strings to bytes and unless it is made clear that these common practice are flawed then the practice gets propagated.

As far as the problem with the code only encrypting strings and not files is concerned, as I said in my first post, the danger here is that the OP is try to convert his files to strings and not change the code to deal with files or streams of bytes. The OP might get away with this for text files but what happens when he tries to encrypt binary files or very large text files? Your code would most probably break under these conditions and though the changes required are straightforward they are esoteric.

I agree that the example is not production code but I don't see how without a total re-write it can be made into production code. This taken with the flaws means that the code does not help the OP at all.

Your heart is obviously in the right place but consider what posting this code is going to do for the OP. If he tries to use it as it is he will most likely end up wasting a load of time that would have probably better been spend learning about modern cryptography and the JCE. Even if he gets the code working fairly quickly by converting his files to string he will have learned nothing useful since he will not even understand the flaws.

I have a load of cryptography examples that I used to publish when appropriate but I found that people did not bother trying to understand the code - they just 'cut and paste' it. I now only publish code (and then usually only fragments) when I see that someone has tried to understand something but has gone slightly wrong and needs to be help back onto the right road.

Note 1 - I have myself hard coded keys in code when it was desired to obfuscate data and not to secure it.

[Soumyajit Hazra]

I am completely agreed with you James. I will keep in mind your advise from next time.Please provide some links where it give some proper idea about file encryption. I searched in google but most of the example are with strings only not for entire file.

[James Sabre]

Soumyajit Hazra wrote:I am completely agreed with you James. I will keep in mind your advise from next time.Please provide some links where it give some proper idea about file encryption. I searched in google but most of the example are with strings only not for entire file.

I don't have a good URL, only book references. A good starting point is "Beginning Cryptography with Java" by David Hook published by Wrox but in some ways I prefer the older and now dated "Java Cryptography" by Jonathan Knudsen published by O'Reilly.

[D. Ogranos]

James Sabre wrote:3) The obvious implementation flaw is that the platform default character encoding is being used to turn the cleartext String into bytes. The default character encoding may not be able to completely represent all the characters in the String and it depends on the platform, locale and Java version being used. This means the the resultant ciphertext file may not be decipherable on some computers.

Can't repeat enough how important this is. I've recently spent a lot of time debugging code that didn't do this. Decryption worked fine on one (windows) system, but failed miserably on another (linux)...because of the different default charsets.

[Krish Yeruva]

Hi James,
Can you post sample code how to encrypt/decrypt a file in java.

Thanks in Advance

[Lester Burnham]

The SecurityFaq -to which I pointed you in the very first reply- links to such code in the "JCE" section.