| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Про глюки XOR алгоритма [D7, WinXP]
ares18 © (2007-08-27 18:54:00)Привет корифеям 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;
сперва шифруется и дешифруестся нормально (как строки так и мемо-поля),однако в какой то момент при шифровке или дешифровке теряется часть строки ( как в строках, так и в мемо). Возникает глюк случайно и вроде от пароля не зависит.
Anatoly Podgoretsky (2007-08-30 12:21:00) [21]Это ему только кажется, что нулевых, а жизнь сложнее.
У автора проблема с понимание, что после шифровки это уже не текст и применять текстовые функции к нему бессмысленно, будут только грабли, при том заранее не предугадаешь какие.
palva (2007-08-30 12:19:00) [22]Инс © (30.08.07 11:59) [25]
Автора не интересует ваш спор. Его беспокоит появление после шифрования нулевых байтов, вернее исчезновение части строки.
Что же касается XOR, то он широко применяется как заключительная часть шифрования. Иногда это называется гаммированием. Т. е. по ключу вырабатывается "гамма", последовательность байтов, похожая на случайные числа. Эта гамма накладывается при помощи XOR на открытый текст. В результате получается зашифрованный текст. У автора выработка гаммы сводится к многократному повторению ключа. Конечно это очень уязвимый способ. Противнику стоит один раз получить из каких-нибудь других источников открытый текст, и он узнает ключ, точнее начальный участок гаммы. Этот участок будет пригоден для расшифровки других сообщений.
На практике принимаются меры, чтобы гамма не повторялась. Например, выработку гаммы по ключу делают зависимой от некоторого случайного параметра, который можно передать вместе с шифровкой в открытом виде.
Инс (2007-08-30 11:59:00) [23]Я думаю, прежде чем продолжить спор, может стоит спросить у автора, чего он хочет добиться. Что и от кого он хочет спрятать.
Anatoly Podgoretsky (2007-08-30 11:48:00) [24]> Инс (30.08.2007 11:03:23) [23]
Ключи не надо передавать, они уже должны быть на обеих сторонах. К качестве ключей могут быть любые существующие файлы, например БСЭ
Передавать надо информацию, смещение в ключе и/или номер ключа.
Инс (2007-08-30 11:03:00) [25]
> Я посмотрю как ты его взломаешь при длине ключа больше длины
> сообщения и одноразовых ключах
Зачем большей? Достаточно одинаковой. И ключ действительно должен быть одноразовым и известным только получателю и отправителю. Это называется "одноразовый блокнот". Такой шифр действительно не ломается, единственное что - это нужно как-то "секретно" передать сам ключ.
Anatoly Podgoretsky (2007-08-30 10:59:00) [26]> Инс (30.08.2007 10:42:21) [21]
Я посмотрю как ты его взломаешь при длине ключа больше длины сообщения и одноразовых ключах
Инс (2007-08-30 10:42:00) [27]Почитайте у Шнайера написано для защиты от кого подходит алгоритм XOR, его уязвимости, и как он взламывается.
@!!ex (2007-08-30 09:18:00) [28]> У него ж всего 255 вариантов.
Поэтому и шифруеться с ключом, не по одному закону.
Германн (2007-08-30 01:14:00) [29]
> TStas © (29.08.07 23:38) [17]
>
> Ну хоть динамическим XORом шифруйте.
>
А что это за зверь?
DVM (2007-08-29 23:44:00) [30]
> А разве XOR - это шифрование?
да
> У него ж всего 255 вариантов
на каждый символ
TStas (2007-08-29 23:38:00) [31]А разве XOR - это шифрование? У него ж всего 255 вариантов. Ну хоть динамическим XORом шифруйте.
Anatoly Podgoretsky (2007-08-29 21:23:00) [32]> ares18 (29.08.2007 21:18:15) [15]
SetLength(S, Lg)
S использовать как двоичный буферю
ares18 (2007-08-29 21:18:00) [33]
> Юрий Зотов © (28.08.07 16:05) [14]
> Бинарный буфер вместо строки снимает все проблемы.
А как это реализовать для memo-полей?
Вроде-как, это должно увеличить время шифрования.
Нет ли примера кода у кого нить?
Юрий Зотов (2007-08-28 16:05:00) [34]Бинарный буфер вместо строки снимает все проблемы.
palva (2007-08-28 13:59:00) [35]>Ты не подумал о последствиях, ведь надо не только зашифровать, а это будет уже не возможно.
А какие последствия? Расшифровка по тому же алгоритму. То что данный байт остался не зашифрован, не зная ключа определить не возможно.
Anatoly Podgoretsky (2007-08-28 13:37:00) [36]
> Т. е. не шифровать очередной символ, если он совпадает с
> символом ключа.
Ты не подумал о последствиях, ведь надо не только зашифровать, а это будет уже не возможно.
Кроме того при шифровки действительны все 256 возможных значений и символ #0 никому не мешает, кроме танцоров. После шифровки результат никак нельзя считать текстом, а только двоичным значением.
palva (2007-08-28 13:12:00) [37]Исправление к [9]
if text[i] <> longkey[i] then
toto := chr((ord(text[i]) xor ord(longkey[i])))
else
toto := text[i];
palva (2007-08-28 13:10:00) [38]palva © (28.08.07 13:02) [9]
Недостаток такого подхода в том, что он предполагает отсутствие в строке нулевых байтов. Если всё же требуется шифровать строки, в которых возможен нулевой байт, то нужно также отказаться от шифрования нулевых байтов. В этом случае расположение нулевых байтов в строке будет видно в зашифрованном тексте. Зато остальные байты будут зашифрованы.
palva (2007-08-28 13:02:00) [39]Можно изменить алгоритм. Т. е. не шифровать очередной символ, если он совпадает с символом ключа. Как-нибудь так:
if text[i] <> longkey[i] then
toto := chr((ord(text[i]) xor ord(longkey[i])));
Тогда нулевых символов не будет.
TUser (2007-08-27 22:09:00) [40]Глюки в xor - это ладно, вот когда глюки в begin начнутся, вот это будет караул.
| |
Страницы: 