Про глюки XOR алгоритма

← →
ares18 © (2007-08-27 18:54) [0]

Привет корифеям Delphi!
Кто нить сталкивался с таким косяком шифрования:
при использовании шифрования, в частности xor алгоритма
типа

procedure TForm1.code ;

var
key, text, longkey, result: string;
i: integer;
toto, c: char;
begin
key:=edit1.Text;
longkey:=edit2.Text;
text:=w;

for i := 0 to (length(text) div length(key)) do
longkey := longkey + key;
for i := 1 to length(text) do
begin
toto := chr((ord(text[i]) xor ord(longkey[i]))); // XOR àëãîðèòì
result := result + toto;
q:= result;
end;

text:="";
end;

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

← →
Reindeer Moss Eater © (2007-08-27 18:55) [1]

Ну и при чем здесь сам ксор?

← →
Reindeer Moss Eater © (2007-08-27 19:01) [2]

в какой то момент при шифровке или дешифровке теряется часть строки

Дай угадаю. Это происходит тогда, когда шифруемый символ и символ ключа совпали?
:)

← →
Anatoly Podgoretsky © (2007-08-27 19:03) [3]

> ares18 (27.08.2007 18:54:00) [0]

У XOR глюков нет!

← →
Юрий Зотов © (2007-08-27 19:07) [4]

> ares18 © (27.08.07 18:54)

> Возникает глюк случайно

Не случайно. А потому, что в теле строки появляется символ #0, на котором она потом обрезается. Так и должно быть.

← →
ares18 © (2007-08-27 21:41) [5]

> Не случайно. А потому, что в теле строки появляется символ
> #0, на котором она потом обрезается. Так и должно быть.

Да вроде как с #0 все тип-топ.

> Reindeer Moss Eater © (27.08.07 19:01) [2]
> в какой то момент при шифровке или дешифровке теряется часть
> строки
>
> Дай угадаю. Это происходит тогда, когда шифруемый символ
> и символ ключа совпали?
> :)
> <Цитата>

Кажись так оно есть:

скажем если для данного кода:

key:="abbkinfkljf";

longkey:="gvghwv";

text:="qweqw";

то в рез-те операции кодирования и раскодирования

получим: qweq

w потерялась, вроде-как, из-за присутствия в longkey.
(т.е. решается заменой w на другой символ в longkey или в тексте)

Но тогда, какой же брать ключ?
Из тех символов к-е никогда в тексте не встретятся?

← →
ares18 © (2007-08-27 21:48) [6]

Но тогда, какой же брать ключ?
Из тех символов к-е никогда в тексте не встретятся?
Не встретятся ни в обычном виде, ни в зашифрованном?

← →
Anatoly Podgoretsky © (2007-08-27 21:53) [7]

Ты что работаешь с результатом как с текстом, это зря. Работай как с двоичными данными.

← →
TUser © (2007-08-27 22:09) [8]

Глюки в xor - это ладно, вот когда глюки в begin начнутся, вот это будет караул.

← →
palva © (2007-08-28 13:02) [9]

Можно изменить алгоритм. Т. е. не шифровать очередной символ, если он совпадает с символом ключа. Как-нибудь так:
if text[i] <> longkey[i] then toto := chr((ord(text[i]) xor ord(longkey[i])));
Тогда нулевых символов не будет.

← →
palva © (2007-08-28 13:10) [10]

palva © (28.08.07 13:02) [9]
Недостаток такого подхода в том, что он предполагает отсутствие в строке нулевых байтов. Если всё же требуется шифровать строки, в которых возможен нулевой байт, то нужно также отказаться от шифрования нулевых байтов. В этом случае расположение нулевых байтов в строке будет видно в зашифрованном тексте. Зато остальные байты будут зашифрованы.

← →
palva © (2007-08-28 13:12) [11]

Исправление к [9]
if text[i] <> longkey[i] then toto := chr((ord(text[i]) xor ord(longkey[i]))) else toto := text[i];

← →
Anatoly Podgoretsky © (2007-08-28 13:37) [12]

> Т. е. не шифровать очередной символ, если он совпадает с
> символом ключа.

Ты не подумал о последствиях, ведь надо не только зашифровать, а это будет уже не возможно.
Кроме того при шифровки действительны все 256 возможных значений и символ #0 никому не мешает, кроме танцоров. После шифровки результат никак нельзя считать текстом, а только двоичным значением.

← →
palva © (2007-08-28 13:59) [13]

>Ты не подумал о последствиях, ведь надо не только зашифровать, а это будет уже не возможно.
А какие последствия? Расшифровка по тому же алгоритму. То что данный байт остался не зашифрован, не зная ключа определить не возможно.

← →
Юрий Зотов © (2007-08-28 16:05) [14]

Бинарный буфер вместо строки снимает все проблемы.

← →
ares18 © (2007-08-29 21:18) [15]

> Юрий Зотов © (28.08.07 16:05) [14]
> Бинарный буфер вместо строки снимает все проблемы.

А как это реализовать для memo-полей?
Вроде-как, это должно увеличить время шифрования.
Нет ли примера кода у кого нить?

← →
Anatoly Podgoretsky © (2007-08-29 21:23) [16]

> ares18 (29.08.2007 21:18:15) [15]

SetLength(S, Lg)

S использовать как двоичный буферю

← →
TStas © (2007-08-29 23:38) [17]

А разве XOR - это шифрование? У него ж всего 255 вариантов. Ну хоть динамическим XORом шифруйте.

← →
DVM © (2007-08-29 23:44) [18]

> А разве XOR - это шифрование?

да

> У него ж всего 255 вариантов

на каждый символ

← →
Германн © (2007-08-30 01:14) [19]

> TStas © (29.08.07 23:38) [17]
>
> Ну хоть динамическим XORом шифруйте.
>

А что это за зверь?

← →
@!!ex © (2007-08-30 09:18) [20]

> У него ж всего 255 вариантов.

Поэтому и шифруеться с ключом, не по одному закону.

← →
Инс © (2007-08-30 10:42) [21]

Почитайте у Шнайера написано для защиты от кого подходит алгоритм XOR, его уязвимости, и как он взламывается.

← →
Anatoly Podgoretsky © (2007-08-30 10:59) [22]

> Инс (30.08.2007 10:42:21) [21]

Я посмотрю как ты его взломаешь при длине ключа больше длины сообщения и одноразовых ключах

← →
Инс © (2007-08-30 11:03) [23]

> Я посмотрю как ты его взломаешь при длине ключа больше длины
> сообщения и одноразовых ключах

Зачем большей? Достаточно одинаковой. И ключ действительно должен быть одноразовым и известным только получателю и отправителю. Это называется "одноразовый блокнот". Такой шифр действительно не ломается, единственное что - это нужно как-то "секретно" передать сам ключ.

← →
Anatoly Podgoretsky © (2007-08-30 11:48) [24]

> Инс (30.08.2007 11:03:23) [23]

Ключи не надо передавать, они уже должны быть на обеих сторонах. К качестве ключей могут быть любые существующие файлы, например БСЭ
Передавать надо информацию, смещение в ключе и/или номер ключа.

← →
Инс © (2007-08-30 11:59) [25]

Я думаю, прежде чем продолжить спор, может стоит спросить у автора, чего он хочет добиться. Что и от кого он хочет спрятать.

← →
palva © (2007-08-30 12:19) [26]

Инс © (30.08.07 11:59) [25]
Автора не интересует ваш спор. Его беспокоит появление после шифрования нулевых байтов, вернее исчезновение части строки.

Что же касается XOR, то он широко применяется как заключительная часть шифрования. Иногда это называется гаммированием. Т. е. по ключу вырабатывается "гамма", последовательность байтов, похожая на случайные числа. Эта гамма накладывается при помощи XOR на открытый текст. В результате получается зашифрованный текст. У автора выработка гаммы сводится к многократному повторению ключа. Конечно это очень уязвимый способ. Противнику стоит один раз получить из каких-нибудь других источников открытый текст, и он узнает ключ, точнее начальный участок гаммы. Этот участок будет пригоден для расшифровки других сообщений.

На практике принимаются меры, чтобы гамма не повторялась. Например, выработку гаммы по ключу делают зависимой от некоторого случайного параметра, который можно передать вместе с шифровкой в открытом виде.

← →
Anatoly Podgoretsky © (2007-08-30 12:21) [27]

Это ему только кажется, что нулевых, а жизнь сложнее.
У автора проблема с понимание, что после шифровки это уже не текст и применять текстовые функции к нему бессмысленно, будут только грабли, при том заранее не предугадаешь какие.

← →
Инс © (2007-08-30 12:33) [28]

Автору:
Если все-таки очень хочется вывести как текст, можно преобразовать в base64.

Anatoly Podgoretsky © (30.08.07 12:21) [27]
Ну да. В частности, бессмысленно показывать шифровку в Memo-поле. Может быть, хвост шифровки вовсе не исчез, просто Memo-поле показывает текст только до нулевого байта.

Инс © (30.08.07 12:33) [28]
Если не предполагается использование текстовых функций, например передача по каналу, то лишнее.

> Ну да. В частности, бессмысленно показывать шифровку в Memo-
> поле. Может быть, хвост шифровки вовсе не исчез, просто
> Memo-поле показывает текст только до нулевого байта.

Ну да, обычная текстовая функция, обрезка по нулевому символу, но это ему еще очень повезло, на самом деле проблема со всеми символами, с кодами менее 32 - не печатные символы.

> Если не предполагается использование текстовых функций,
> например передача по каналу, то лишнее.

Разумеется. Это именно приведение к виду, который можно отобразить как текст.

> на самом деле проблема со всеми символами, с кодами менее
> 32 - не печатные символы.

Это еще и от шрифта зависит. Для некоторых и русские буквы непечатные символы.

> Разумеется. Это именно приведение к виду, который можно
> отобразить как текст.

Это и есть передача по каналу
двочные коды -> текстовый приемник.

Ну и ладно. Какая разница как это назвать. Что-то я не понимаю смысл [30], если в [28] я сказал то же самое.

Не связаные вещи

> Не связаные вещи

Бррр, не научился я еще разгадывать ваши ребусы...

> Инс (30.08.2007 13:43:36) [36]

Это пройдет.
Зачем показывать в мемо код в Base64

> Зачем показывать в мемо код в Base64

Откуда я знаю. Автору надо. Произвольные двоичные данные в Memo так просто не отобразить по понятным причинам. Вот и предлагаю преобразовать в base64 или на крайняк в hex. Подходит ему это или нет, решит сам автор.

Автору не надо, он не владеет основами

> Я думаю, прежде чем продолжить спор, может стоит спросить
> у автора, чего он хочет добиться. Что и от кого он хочет
> спрятать.

цель - зашифровать текст мемо-поле БД Paradox.
т.к. защита паролем (у Paradox) никакая.

Про глюки XOR алгоритма Найти похожие ветки