Моя реализация Java-класса шифрования XOR пошла не так - PullRequest
0 голосов
/ 18 января 2012

Я новичок в Java, но я очень свободно говорю на C ++ и C #, особенно на C #.Я знаю, как сделать шифрование XOR в C # и C ++.Проблема в том, что алгоритм, который я написал в Java для реализации шифрования xor, похоже, дает неправильные результаты.Результаты обычно представляют собой кучу пробелов, и я уверен, что это неправильно.Вот класс ниже:

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);
    }
}

Ответы [ 2 ]

2 голосов
/ 18 января 2012

Строки в Java являются Unicode - и строки Unicode не являются общими держателями для байтов, как могут быть строки ASCII.

Вы берете строку и конвертируете ее в байты, не указывая, какую кодировку символов вы хотите, поэтому вы получаете кодировку по умолчанию для платформы - вероятно, US-ASCII, UTF-8 или одну из кодовых страниц Windows.

Затем вы выполняете арифметические / логические операции над этими байтами. (Я не смотрел на то, что вы здесь делаете - вы говорите, что знаете алгоритм.)

Наконец, вы берете эти преобразованные байты и пытаетесь превратить их обратно в строку, то есть обратно в символы. Опять же, вы не указали кодировку символов (но вы получите то же самое, что и преобразование символов в байты, так что все в порядке), но, самое главное ...

Если в кодировке вашей платформы по умолчанию используется один байт на символ (например, US-ASCII), то не все сгенерированные вами последовательности байтов представляют действительные символы.

Итак, из этого следует два совета:

  1. Не использовать строки в качестве общих держателей для байтов
  2. Всегда указывайте кодировку символов при преобразовании между байтами и символами.

В этом случае вы могли бы добиться большего успеха, если бы вы специально указали кодировку US-ASCII. РЕДАКТИРОВАТЬ: Это последнее предложение не соответствует действительности (см. Комментарии ниже). Вернитесь к пункту 1 выше! Используйте байты, а не символы, если вам нужны байты.

0 голосов
/ 18 января 2012

Если вы используете не-ascii строки в качестве ключей, вы получите довольно странные результаты. Байты в массиве в килобайты будут отрицательными. Расширение знака означает, что val выйдет отрицательным. Затем приведение к персонажу создаст персонажа в диапазоне FF80-FFFF.

Эти символы, безусловно, не будут печататься, и в зависимости от того, что вы используете для проверки вывода, вам могут отображаться «квадрат» или некоторые другие заменяющие символы.

...