Question

I have a question regarding encrypting and decrypting a string

I have to send a encrypted string over the network.(an android app is the client) this is what i did so far

byte[] input = getByteArray(filePath);//get the message stored in a file as a byte array

by going through some tutorial i managed to get the String message to a byte array and
encrypted it using javax.crypto

Cipher cipher = Cipher.getInstance("DES/CBC/PKCS5Padding");

cipher.init(Cipher.ENCRYPT_MODE, key, ivSpec);

encrypted msg is retrived as a byte array

byte[] encrypted

i even managed to decrypt it using the reverse method and get the message again

but my problem comes when i try to convert this encrypted byte array to strings (to pass it over the network)
and then reconvert it to a byte array

i tryed this

String encryptedStrn = new String(encrypted); // convert to string

when i convert it to the byte array by
byte[] enc = encryptedStrn.getBytes();

and use this enc array to decrypt but the output does not come correctly.

Have i missed some basic stuff regarding converting. Please help me.
thanks in advance

Answer 1

As CodeInChaos wrote in a comment, you shouldn’t use the String(byte[]) constructor to create a string from opaque binary data. The string constructors are intended for text data which has been encoded using an encoding like ASCII, UTF-8 etc. Opaque binary data such as the result of encryption, or an image file, is not encoded text data in the same way, so you end up losing information.

You should use base64 instead, which encodes any binary data into ASCII. There are various 3rd party libraries for this, including a good public domain one. Alternatively, on Android you can just use the Base64 class.

Additionally, even when you are encoding or decoding real text, you shouldn’t use String.getBytes() and the String(byte[]) constructor anyway – they use the platform default encoding, which is almost always the wrong choice. Instead, you should use the overloads which explicitly take a CharSet or the name of a character encoding. UTF-8 is typically a good encoding to use if you’re able to control both ends – if you’re only controlling one end, you need to know which encoding the other end is expecting.