Я написал короткую программу на С++ для шифрования XOR в файле, которую я могу использовать для некоторых личных файлов (если он взломан, это не имеет большого значения - я просто защищаю от случайных зрителей). В принципе, я беру пароль ASCII и повторно XOR пароль с данными в файле.
Теперь мне любопытно: если кто-то хотел взломать это, как бы они это сделали? Это займет много времени? Это зависит от длины пароля (то есть, что такое большой-O)?
Проблема с XOR-шифрованием заключается в том, что для длинных прогонов тех же символов очень легко увидеть пароль. Такие длинные прогоны чаще всего являются пробелами в текстовых файлах. Скажем, что ваш пароль имеет 8 символов, а текстовый файл имеет 16 пробелов в некоторой строке (например, в середине таблицы ASCII-графики). Если вы просто XOR с вашим паролем, вы увидите, что на выходе будут повторяться последовательности символов. Злоумышленник будет искать только такие, попытаться угадать символ в исходном файле (пробел будет первым кандидатом для попытки) и получить длину пароля из длины повторяющихся групп.
Двоичные файлы могут быть еще хуже, поскольку они часто содержат повторяющиеся последовательности 0x00 байтов. Очевидно, что XORing с ними не работает, поэтому ваш пароль будет отображаться в виде обычного текста на выходе! Примером очень распространенного двоичного формата, который имеет длинные последовательности нулей, является .doc.
Я согласен с объяснения XOR. Для тех, кого это интересует, рассмотрим базовый обзор стандартного алгоритма, используемого для прерывания тривиального шифрования XOR за несколько минут:
Определите, как долго ключ находится. Эта выполняется путем XORing зашифрованных данных с самим собой менялись разные числа мест, и изучив, сколько байты одинаковы.
Если байты, которые равны, больше определенного процента (6% по сравнению с Брюсом Шнайером Вторая прикладная криптография редакция), то вы данных кратным длине ключа. Найдя наименьшее количество что приводит к большому количество равных байтов, вы найдете Длина ключа.
Сменить текст шифрования на keylength и XOR против самого себя. Это удаляет ключ и оставляет вас с открытым текстом XORed с plaintext сдвинул длину ключ. Должно быть достаточно открытый текст для определения сообщения содержание.
Подробнее на Вопросы шифрования, часть 1
Шифрование XOR может быть достаточно сильным, если выполняются следующие условия:
* Разумно сильное значение не может быть нарушено тривиальными, математическими средствами, как в сообщении GeneQ. Он по-прежнему не сильнее вашего пароля.
В дополнение к уже упомянутым пунктам XOR-шифрование полностью уязвимо для атак с открытым текстом:
cryptotext = plaintext XOR key
key = cryptotext XOR plaintext = plaintext XOR key XOR plaintext
где XORring открытые тексты отменяют друг друга, оставляя только ключ.
Не уязвимость для известных атак с открытым текстом является необходимым, но не достаточным свойством для любого "безопасного" метода шифрования, когда один и тот же ключ используется для нескольких блоков незашифрованного текста (то есть одноразовый блок по-прежнему защищен).
Способы работы XOR:
Используйте несколько ключей с каждой длиной ключа, равной простому числу, но не всегда одинаковой длины для ключей. Используйте исходное имя файла как другой ключ, но не забудьте создать механизм для извлечения имени файла. Затем создайте новое имя файла с расширением, которое позволит вам знать, что это зашифрованный файл. Причина использования нескольких ключей длины простых чисел заключается в том, что они приводят к тому, что полученный ключ XOR должен быть ключом A TIMES Key B длиной до повторения. Сжимайте любые повторяющиеся шаблоны из файла до его зашифрования. Создайте случайное число и XOR это число каждые X Offset (помните, этот номер также должен быть rereatable. Вы можете использовать RANDOM SEED для длины файла.
После выполнения всего этого, если вы используете 5 ключей длиной 31 и выше, вы получите длину ключа примерно в 100 мегаграмм!
Для ключей имя файла является одним (включая полный путь), STR (Размер файла) + STR (Filedate) + STR (Date) + STR (Time), Random Generation Key, Full Name, Закрытый ключ, созданный один раз.
База данных для хранения ключей, используемых для каждого файла, зашифрованного, но сохраняющего DAT файл на USB-накопителе и НЕ на компьютере.
Это должно помешать повторному шаблону в таких файлах, как "Картинки" и "Музыка", но фильмы, состоящие из четырех концертов в длину и более, могут оставаться уязвимыми, поэтому может понадобиться шестой ключ.
У меня лично есть файл данных, зашифрованный на карте памяти (Dat файл для использования с Microsoft Access). Я использовал метод 3-Key для шифрования, потому что он никогда не будет THAT большим, являясь каталогом файлов с соответствующими ключами.
Причина множественных ключей, а не случайного генерирования одного очень большого ключа, заключается в том, что простые числа простых чисел получают большую скорость, и у меня есть некоторый контроль над созданием ключа, и вы ЗНАЕТЕ, что на самом деле нет такой вещи, как истинно случайное число, Если я создал одно большое случайное число, кто-то другой может сгенерировать тот же номер.
Способ использования ключей: зашифруйте файл одним ключом, затем следующий, затем следующий, пока все ключи не будут использоваться. Каждый ключ используется снова и снова, пока весь файл не зашифрован этим ключом.
Поскольку ключи имеют разную длину, перекрытие повторения различается для каждой клавиши и поэтому создает производный ключ длиной ключа один раз. Эта логика повторяется для остальных клавиш. Причиной для простых чисел является то, что повторение будет происходить при разделении длины ключа, поэтому вы хотите, чтобы деление было равным 1 или длине ключа, hense, prime.
ОК, предоставлено, это больше, чем простой XOR в файле, но концепция одинаков.
Копье
Я просто защищаю от случайных зрителей
Пока это предположение верно, ваша схема шифрования в порядке. Люди, которые считают, что Internet Explorer является "интернетом", не способны его нарушить.
Если нет, просто используйте некоторую криптографическую библиотеку. Есть уже много хороших алгоритмов, таких как Blowfish или AES для симметричного криптования.
Цель хорошего шифрования - сделать его математически сложным для дешифрования без ключа.
Это включает в себя желание защитить сам ключ.
технология XOR - это в основном простой шифр, который легко сломается, как описано здесь.
Важно отметить, что XOR используется в криптографических алгоритмах.
Эти алгоритмы работают над внедрением в них математических трудностей.
Norton Anti-virus использовал метод использования предыдущей незашифрованной буквы в качестве ключа для следующей буквы. Это заняло у меня дополнительные полчаса, чтобы понять, если я правильно помню.
Если вы просто хотите остановить случайного зрителя, это достаточно хорошо; Я использовал для скрытия строк в исполняемых файлах. Тем не менее, он не будет стоять 10 минут любому, кто действительно пытается.
Все сказанное, в наши дни доступны гораздо лучшие методы шифрования, поэтому почему бы не воспользоваться чем-то лучше. Если вы пытаетесь просто спрятаться от "случайного" пользователя, даже что-то вроде gzip сделает эту работу лучше.
Другой трюк заключается в генерации хеша md5() для вашего пароля. Вы можете сделать его еще более уникальным, используя длину защищенного текста в качестве смещения или сочетая его с вашим паролем, чтобы обеспечить лучшее распределение для коротких фраз. И для длинных фраз вы можете изменить свой хеш md5(), объединив каждый 16-байтовый блок с предыдущим хешем - сделав весь XOR-ключ "случайным" и не повторяющимся.
RC4 - это, по сути, шифрование XOR! Как и многие потоковые шифры - ключ является ключом (каламбур не предназначен!), Вы НИКОГДА не используйте его повторно. EVER!
Я немного опоздал с ответом, но так как никто еще не упомянул об этом: это называется шифром Vigenère.
Википедия дает ряд криптоаналитических атак, чтобы сломать их; тем не менее, поскольку большинство файловых форматов имеют фиксированный заголовок, будет XOR заголовок plaintext с зашифрованным заголовком, предоставляя вам ключ.
То, что " > 6%" упоминает GeneQ, является показателем совпадения английского текста телеграммы - 26 букв с пунктуацией и цифрами. Фактическое значение для длинных текстов - 0,0665.
< 4% - индекс совпадения для случайного текста в 26-символьном алфавите, который равен 1/26 или 0,385.
Если вы используете другой язык или другой алфавит, конкретные значения будут разными. Если вы используете набор символов ASCII, Unicode или двоичные байты, конкретные значения будут сильно отличаться. Но обычно присутствует разница между IC открытого текста и случайным текстом. (Сжатые двоичные файлы могут иметь интегральные схемы, очень близкие к случайным, и любой файл, зашифрованный любым современным компьютерным шифрованием, будет иметь IC, который точно соответствует случайному тексту.)
После того, как вы XORed текст против себя, то, что вы оставили, эквивалентно шифру autokey. В Википедии есть хороший пример взлома такого шифрования.