я мельком увидел, что этот алгоритм слабее RC4 тем, что не берет еще один раз state[state[x]+state[y]]. Если это сделано для увеличения скорости в ущерб стойкости, то эти действия нужно очень серьезно аргументировать ПЕРЕД ТЕМ, как предлагать алго к публичному использованию и обсуждению... иначе, вступать в дискуссии просто неинтересно.
2Solo Неужели трудно самому проверить(исходники ведь я дал), что это ЗНАЧИТЕЛЬНО ослабляет алгоритм. К тому же еще раз повторю, что к RC4 этот алгоритм не имеет никакого отношения(в основе лежат абсолютно разные принципы. Если бы я совершенствовал RC4, то все бы "серьезно аргументировал" Кроме того, это самосинхронизирующийся поточный шифр и оценка его криптостойкости несколько отличается от обычных поточных шифров. Данный алгоритм это всего лишь криптодвижок целого семейства шифров на любой вкус. Например, нелюбители XOR могут заменить его на ADD и SUB или применить вместо него стохастическое преобразование и т.д.
сорри, одного нюанса не заметил. Принцип, действительно другой. Только теперь я не понимаю, почему шифр назван самосинхронизирующимся? Ведь для этого нужно, чтобы он на конечной длине, а не с начала ТШ синхронизировался. А тут, насколько я понял, нужен весь ТШ для синхронизации?
LazyCat Гм. а на результаты криптоанализа данного алгоритма можно посмотреть? К каким типам атак чувствителен и т.п.
2 Solo Меня самого смущает этот термин, но по определению у самосинхронизирующихся шифров каждый бит потока ключей является функцией n предыдущих битов шифротекста(в данном случае, действительно, n=длина текста) 2 CreatorCray Я не работаю в ФАПСИ и, тем более, я не Шамир, поэтому богатым опытом криптоанализа не обладаю да и инструментов для этого не имею. Мой криптоанализ может показаться детским и непрофессиональным - это мое видение предмета. Если рассматривать входной поток графически, то я исследовал линейные, пилообразные, треугольные, трапецевидные и др. функции. При этом оценивалась равномерность выходного потока и полное отсутствие каких-либо автокорреляций. Также оценивалась корреляция потоков, созданных разными ключами при одном plain. И, естественно, рассматривалась корреляция в случаях повторной шифрации и дешифрации разными ключами. Отклонений от равномерного распределения выявлено не было
по-моему n должно быть конечным и ограниченным, иначе непонятно, что с чем синхронизируется... Ну а статтесты для шифралгоритмов - это очень примитивная проверка. Одно то, что статтестами невозможно отличить шифрование от компрессии уже говорит о том, что такого тестирования далеко недостаточно для утверждения о том, что шифр хороший... а еще... очень некрасиво этот алгоритм выглядит при атаке по известному ТО и ТШ. Слишком много внутренних переменных становится известно. Очень возможно, что эта атака может дать информацию о ключе... Кому не лень - поковыряйте
В данном случае синхронизация абсолютно не важна, а это свойство шифра используйтся исключительно для отказа от проверки контрольной суммы(в отличие, например, от WEP или Skype, где ипользуется RC4) либо при использовании его в качестве хеш-функции. С этим никто не спорит да и никто на них не опирался что алгоритм неплохой, раз довел энтропию до 1 без сжатия данных. Еще более некрасиво в этом случае выглядит RC4, и появляется возможность вычислить ключ(что исключено в ZC4). Кроме того непонятно зачем в данном случае что-либо ломать, имея ТО(см. первый пост)
в skype rc4, по-моему, используется только для обфускации и ключ делается из 4 байт, передающихся перед ТШ. Если шифру присваивается свойство самосинхронизации, то синхронизация важна. Существует множество преобразований, доводящих энтропию до 1 без сжатия, но при этом шифрами их назвать язык не поворачивается. Ну а устойчивость к атаке на ключ по известным ТО и ТШ - одно из важнейших свойств шифров. В RC4 восстанавливается только гамма. Но никаких сведений о внутренних состояниях шифра, и тем более, о ключе получить из этого еще никому не удавалось...
Повторю еще раз. RC4 всегда используется с вычислителем контрольной суммы, т.к. сам алгоритм не имеет контроля целостности данных и вдобавок очень чувствителен к пропуску или вставке данных. Если Вы такой специалист по классификации, то попробуйте сами отнести этот алгоритм к какому-нибудь классу, тем более что их всего 2(советую обратить внимание на шифр SAPPHIRE) Например ? Для того, чтобы шифр был криптостоек необходимо, чтобы он обладал хорошими рассеивающими свойствами(но не наоборот). Это основа основ. И в ZC4 и в RC4 восстанавливается только гамма. Но, зная гамму RC4, мы можем подделывать ТШ, что делает устройство(убедительно прошу перечитать 1-й пост несколько раз) абсолютно незащищенным, более того можно вскрывать все последующие апдейты, тем самым даже предотвратить смену ключа или криптоалгоритма !!! Кроме того при малой длине ключа возможен брутфорс(он также возможен при знании маленького кусочка ТО). Знание гаммы ZC4 вообще ничего не дает, да и сама гамма зависит от ТО,что сильно затрудняет брутфорс, а подделку данных делает невозможной. Ваше высказывание: мне очень напоминает другое: "Взломать RSA очень просто, нужно лишь факторизовать модуль !"
Если я правильно понимаю, перед каждым шифрованием надо вызывать initialize_machine, перед этим еще обнулять state ?
Я только одного не могу понять, как на форуме программистов не понимают простых вещей !!! Или эту ветку программисты не читают ???
А про то, что если у Вас возникло свое мнение, не мешало бы его проверить(исходник я ведь дал) !!!!!! А вдруг оно неправильное А уже потом постить. flankerx На глупые выпады не отвечаю !
LazyCat Это и не выпад вовсе. вообще это не очень хорошим тоном считается - отсылать собеседников к исходникам. ни на одном уважающем себя профильном форуме такое не покатит. почитай ru.crypt, там много на эту тему рассуждали
flankerx Я всегда говорю по теме и не развожу демагогию ! Если человек критикует исходник, я ему прямо и советую внимательнее изучить исходник. Если при этом он говорит, что он программист, то, я надеюсь, ему это не составит большого труда. Внимательнее походите по веткам этого форума...
Каждый раз разворачивать ключ, конечно снижает скорость. Но это особенность таких потоковых шифров. Есть у меня, к примеру, куча зашифрованных строк (БД например), к которым нужно произвольно осуществлять доступ. Сравнивал его в этом случае с блочным RC5, RC5 оказался гораздо быстрее, т.к. разворачивает ключ всего один раз. Значительно повысить скорость удалось немного извратным способом: при инициализации создаются две таблицы, одна используется при шифровании, при переинициализации вторая копируется в первую.
