function TCryptoFunction.CoderString(str: string): string; var i: integer; b: byte; c: byte; k: byte; begin Result := ''; RandSeed := key; for i := 1 to length(str) do begin k := random(255); b := ord(str); c := (b+k) mod 256; Result := Result + chr(c); end; end; Мой друг написал подобный алогоритм шифрования для защиты сообщений в программы подобной ICQ. В коде как вы видете идет генерация значения k, а генерация инициализирована key, которая берется из ini-файла. В итоге как для шифровки(код выше), так и для расшифровки (отличие в этой строчке c := (b-k) mod 256 будет одинаковая генерация последовательность k! Мне интересно на сколько это криптостойко, и помимо ГПСЧ, что еще является слабым звеном?
каков размер RandSeed? В самом плохом случае (стойкий ГПСЧ) прийдется перебирвать столько значений, сколько может принимать этот сид. А вообще это обычный поточный шифр... И если использовать хороший генератор ПСЧ (и нормально его инициализировать, и не хранить seed в инишнике ) ), то все будет ок Что касается приведенной схемы -- то она плохая. Seed не меняется. Это значит что последовательность k будет одинакова для всех сообщений. А это значит что зная одну пару открытый текст-шифртекст можно определить часть последовательности (гаммы) длины равной длине известного текста. Зная гамму можно без проблем читать сообщения (точнее, столько знаков сообщения, сколько байт гаммы мы знаем). При использовании поточных шифров первое правило -- не допускать повторения гаммы!
Я не уверен, но мне кажется, что в выходной последовательности (Result) не будет равновероятного выхода символов. В нижепривденной операции: c:= (b+k) mod 256; прибавляется (допустим) абсолютно случайное число k, но вот b имеет (видимо, это символы в-основном) явно неслучаное распределение, поэтому сумма может также иметь неслучайное распределение. Например, если b - только большие английские буквы (41h..), то бит 5 (40h) у них в-основом 1, а бит 7 - в-основном 0. При добавлении случайного бита к этим битам такая особенность может сохраниться и в выходной последовательности. Хотя я могу и ошибаться - думал минуты 2
_Chingachguk_ да нет, если сложить случайную последовательность с неслучайной то получится все-равно случайная
как тут уже сказали получаем случайную последовательность с ключом, равным длине сообщения (!), что не есть гуд...т.е. надо где-то хранить его, т.к. он будет немаленького размера, что будет проблематично. Поэтому смысл этого шифрования я не совсем пойму...тогда придется хранить где-то зашифрованый ключ, т.к. при его получении str легко восстанавливается, алгоритм шифрования тут несложный.
Господа, а смысл? Неужели разработчиков не устраивает что-либо проверенное временем (RCx, AES, Blowfish и т.п.)?
При длине ключа равной длине файла вскрыть невозможно, да и потеря ключа если файл не сперли не проблема. Главное ключ сгенерить удачно. Я пробовал в качестве ключей свои exe'шники и temporaly internet файлы с накладкой на вводимый вручную. Хотя правда у меня никто не взламывал их.
NeX ты не совсем прав. гамма действительно имеет длину равную длине сообщения, но получается она из гораздо более короткого ключа -- key (RandSeed). ТАк устроены все современные поточные шифры -- это ГПСЧ, вырабатывающий гамму, которая просто накладывается на сообщение. Так что хранить _всю_ гамму совершенно необязательно.
Randseed скока бит? 32? ИМХО перебор за реальное время возможен даже на обычной тачке. Прога правда будет сложной. Серьезной криптостойкости нет...
Skif для сообщений, AES и другие тяжеловесные алгоритмы будут через чур громоздки. Это все равно что из пушки по воробьям. >Randseed скока бит? 32? Нет, не 32, а порядка двух eax:edx Этот ключ будет для каждого сообщения абоненту А от Б менятся и передаваться в виде добавки к сообщению. На эту добавки будет накладываться Мастер_Кей заранее оговоренный и по размеру равный Ключу - сообщения.
EvilsInterrupt Реализация "хорошего" генератора псевдослучайных последовательностей дело достаточно сложное, и соотв. алгоритмы ничуть не проще алгоритмов шифрования навроде AES (более того, зачастую именно эти алгоритмы и используются). В принципе, широко известный алгоритм RC4 есть ничто иное как тот самый ГПСЧ, и существуют атаки на него, использующие эту "особенность". Тем не менее, при соотв. допущениях RC4 вполне криптостоек. Посмотрите в его сторону, может, понравиться
EvilsInterrupt т.е. 64? т.е. один раз определяем сеансовый ключ и восстанавливаем мастер-ключ? супер! Ерунда. Ты же под ПК а не под микроконтроллеры пишешь. А RC4 так вообще очень компактный и нетребовательный. Ну ты уж определись Или будешь защищать информацию, или нет. Если да -- то защищать нужно надежно, и чем тебя не устраевает AES или что-то другое -- не понятно :/
Алгоритм в самом начале да гост я практически в руках держу, т.е.80: ясно вижу что и зачем и почему и как там делается, а rijndael немогу так, еще не дорос до такого уровня!
