CODEWITHSUNDEEP
javaencryptionxor
Daniel Lopez
Daniel Lopez

Reputation: 1798

My java class implementation of XOR encryption has gone wrong

I am new to java but I am very fluent in C++ and C# especially C#. I know how to do xor encryption in both C# and C++. The problem is the algorithm I wrote in Java to implement xor encryption seems to be producing wrong results. The results are usually a bunch of spaces and I am sure that is wrong. Here is the class below:

public final class Encrypter {

    public static String EncryptString(String input, String key)
    {


        int length;
        int index = 0, index2 = 0;
        byte[] ibytes = input.getBytes();
        byte[] kbytes = key.getBytes();
        length = kbytes.length;
        char[] output = new char[ibytes.length]; 
        for(byte b : ibytes)
        {
            if (index == length)
            {
                index = 0;

            }
            int val = (b ^ kbytes[index]);
            output[index2] = (char)val;
            index++;
            index2++;
        }


        return new String(output);
    }
    public static String DecryptString(String input, String key)
    {
        int length;
        int index = 0, index2 = 0;
        byte[] ibytes = input.getBytes();
        byte[] kbytes = key.getBytes();
        length = kbytes.length;
        char[] output = new char[ibytes.length]; 
        for(byte b : ibytes)
        {
            if (index == length)
            {
                index = 0;

            }
            int val = (b ^ kbytes[index]);
            output[index2] = (char)val;
            index++;
            index2++;
        }


        return new String(output);
    }
}

Upvotes: 0

Views: 1934

Answers (2)

dty
dty

Reputation: 18998

Strings in Java are Unicode - and Unicode strings are not general holders for bytes like ASCII strings can be.

You're taking a string and converting it to bytes without specifying what character encoding you want, so you're getting the platform default encoding - probably US-ASCII, UTF-8 or one of the Windows code pages.

Then you're preforming arithmetic/logic operations on these bytes. (I haven't looked at what you're doing here - you say you know the algorithm.)

Finally, you're taking these transformed bytes and trying to turn them back into a string - that is, back into characters. Again, you haven't specified the character encoding (but you'll get the same as you got converting characters to bytes, so that's OK), but, most importantly...

Unless your platform default encoding uses a single byte per character (e.g. US-ASCII), then not all of the byte sequences you will generate represent valid characters.

So, two pieces of advice come from this:

  1. Don't use strings as general holders for bytes
  2. Always specify a character encoding when converting between bytes and characters.

In this case, you might have more success if you specifically give US-ASCII as the encoding. EDIT: This last sentence is not true (see comments below). Refer back to point 1 above! Use bytes, not characters, when you want bytes.

Upvotes: 2

Joni
Joni

Reputation: 111369

If you use non-ascii strings as keys you'll get pretty strange results. The bytes in the kbytes array will be negative. Sign-extension then means that val will come out negative. The cast to char will then produce a character in the FF80-FFFF range.

These characters will certainly not be printable, and depending on what you use to check the output you may be shown "box" or some other replacement characters.

Upvotes: 0

Related Questions