По поводу RC4

[vendor]

В данной системе, в настоящее время, насколько я понял, при шифрованной связи абонентов Extra Systems Cypher Net используется потоковое шифрование RC4. Но мне доводилось слышать, что оно на данный момент, вроде как, уже не считается безопасным. Что фирма-производитель данного продукта может сказать по этому поводу?

[george]

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

Вы совершенно правы: в настоящий момент в системе шифрованной связи Extra Systems Cypher Net, по умолчанию, действительно используется алгоритм потокового шифрования сеансов связи между абонентами RC4. И мы действительно считаем его совершенно безопасным, поскольку его так называемый «взлом», о котором Вы говорите, произошел (не у нас, конечно) в таком контексте, которого в нашей системе на данный момент нет (и, более того, никогда и не было).

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

Кроме того, мне хотелось бы обратить Ваше внимание на то обстоятельство, что используемый в настоящее время нами алгоритм потокового шифрования RC4 отнюдь не является безальтернативным. В случае наличия такого их желания, мы готовы снабдить наших клиентов и иными вариантами алгоритмов потокового шифрования. Однако, по нашему мнению, на сегодняшний день, алгоритм RC4 является во всех отношениях оптимальным выбором для клиентов Extra Systems Cypher Net. Я со всей ответственностью готов утверждать, что по этому вопросу нет и ни у кого из наших абонентов никогда не будет никаких проблем.

[teleport]

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

Думаю, что Вы правы. Если почитать не только желтую прессу (как это, увы, обычно практикуется в среде дилетантов), которая пестрит заголовками о "взломе RC4", а и профессионально углубиться в тему (детально изучить ситуацию), то тут же выясняется, что все эти так называемые "взломы" имели место в случаях неправильно организованного разработчиками взаимодействия RC4 с SSL и TLS, когда злоумышленники отправляли на WEB-сервер (имея такую возможность) множество специально сформированных пакетов, что, конечно же, к работе Extra Systems Cypher Net не имеет ни малейшего отношения.

[george]

профессионально углубиться в тему (детально изучить ситуацию), то тут же выясняется

Вы совершенно правы, именно это я и имел в виду. Все эти возражения против RC4 (в контексте Extra Systems Cypher Net), на самом деле, яйца выеденного не стоят. Выдвигаются еще и такие (на поверку - смехотворные) возражения, что якобы с вероятностью 1/128, а не 1/256 второй байт кодовой таблицы будет равен 0. То есть, с повышенной (но, заметьте, никак не с большой) вероятностью можно будет предположить, что вторая буква сообщения это, например, "а". Или, скажем, "б". Ну и что? Еще раз подчеркиваю - все это не с большой, а лишь только с повышенной вероятностью. Даст это что-то для расшифровки (только перехваченного, но отнюдь не созданного злоумышленником) сообщения (всякий раз меняющегося, и всякий раз имеющего новый ключ шифрования)? На мой взгляд - совершенно ничего. Я считаю, что все это - просто смехотворно. Неким теоретикам просто нечем себя занять, вот они и сотрясают воздух.

Как бы там ни было, все эти спекуляции и фантазии к вопросам надежности Extra Systems Cypher Net не имеют никакого отношения.

[televendor]

Неким теоретикам просто нечем себя занять, вот они и сотрясают воздух.

Но, как следует из того, что написано внизу страницы RC4 на сайте продукта, Вам все же пришлось бросить кость этим горе-теоретикам. Я имею в виду добавление Вами вызова процедуры encrypt_buffer в процедуру инициализации ключа шифрования make_crypt_key_table для холостого прогона первых RC4_SKIP_TRASH байт шифра RC4. При этом Вы пишите, что

Конкретное значение RC4_SKIP_TRASH нами не публикуется, тем более что оно может меняться в зависимости от пожеланий конкретного клиента.

Меня интересует следующий момент. Если значения RC4_SKIP_TRASH у неких двух клиентов различны, то ведь они не смогут проводить переговоры из-за рассогласования их шифров, не так ли? Как с этим быть?

[george]

Меня интересует следующий момент. Если значения RC4_SKIP_TRASH у неких двух клиентов различны, то ведь они не смогут проводить переговоры из-за рассогласования их шифров, не так ли? Как с этим быть?

Конечно, не смогут. И это, кстати говоря, еще один слой защиты. Наша фирма, по умолчанию, снабжает всех клиентов неким стандартным значением RC4_SKIP_TRASH (которое не публикуется, чтобы не облегчать работу вражеских криптоаналитиков), что позволяет им без проблем связываться друг с другом. Однако некие заказчики могут создавать свои отдельные, закрытые для прочих абонентов, сети, и для этого запрашивать себе индивидуальное значение RC4_SKIP_TRASH, которое, естественно, будет одно у всех комплектов, предоставленных для абонентов этого отдельного закрытого сообщества. И Вы совершенно правы: рассогласование RC4_SKIP_TRASH даже на один байт делает невозможным расшифровку потока поступающей информации.

[teleport]

Как бы там ни было, все эти спекуляции и фантазии к вопросам надежности Extra Systems Cypher Net не имеют никакого отношения.

На данный момент лично я вижу все это следующим образом.
(моя скромная попытка дать небольшое экспертное заключение)

Дано

1. Алгоритм: Реализация RC4 с небольшими модификациями.
2. Ключ: Криптографически случайный, длиной 1000 бит (125 байт).
3. RC4_SKIP_TRASH: Приблизительно 256 (точное значение неизвестно хакеру).
4. Шифротекст: 1000 байт. (например)
5. Известно: Зашифровано сообщение на естественном языке (русский, английский и т.д.).
6. Неизвестно: Исходный текст, точное значение `RC4_SKIP_TRASH`, другие детали.

Особенности реализации

1. Пропуск начальных байт (RC4_SKIP_TRASH): После инициализации ключа генерируется и отбрасывается некоторое количество байт (`RC4_SKIP_TRASH`). Это стандартная практика для RC4, чтобы избежать уязвимостей в начальных байтах.
2. Длина ключа: 1000 бит (125 байт) — это необычно длинный ключ для RC4 (обычно 40-256 бит). Теоретически, это делает bruteforce невозможным.
3. Криптографически случайный ключ: Ключ не имеет слабостей (например, не основан на пароле).

Возможные атаки

1. Атака на слабые ключи RC4: В RC4 есть слабые ключи, но здесь ключ криптографически случайный, так что эта атака не применима.
2. Атака на начальные байты RC4: В классическом RC4 начальные байты могут быть предсказуемыми, но здесь они отбрасываются (`RC4_SKIP_TRASH`), что усложняет атаку.
3. Атака на повторное использование ключа: Если один и тот же ключ используется несколько раз, можно провести атаку. Но здесь ключ используется один раз.
4. Атака на статистические свойства RC4: RC4 имеет небольшие статистические отклонения, но для их использования нужно много данных (гораздо больше 1000 байт).
5. Bruteforce ключа: Длина ключа 1000 бит делает bruteforce невозможным.
6. Атака на известный RC4_SKIP_TRASH: Если бы `RC4_SKIP_TRASH` было известно, можно было бы попытаться восстановить состояние S-box после отбрасывания байт. Но здесь оно неизвестно (известно только приблизительно ~256).

Выводы

1. Ключ слишком длинный: 1000 бит — это огромное пространство ключей. Даже если `RC4_SKIP_TRASH` было бы известно, bruteforce нереалистичен.
2. Неизвестное RC4_SKIP_TRASH: Даже если бы ключ был короче, неизвестное точное значение `RC4_SKIP_TRASH` добавляет сложность, так как хакер не знает, с какого момента начинается шифрование полезных данных.
3. Объем данных мал: 1000 байт — это мало для статистических атак на RC4.
4. Ключ криптографически случайный: Нет слабостей в ключе, которые можно было бы использовать.

Заключение

При данных условиях (криптографически случайный ключ 1000 бит, неизвестное точное `RC4_SKIP_TRASH`, однократное использование ключа, малый объем шифротекста) расшифровка невозможна с использованием современных криптографических методов. Единственная гипотетическая возможность — если реализация RC4 содержит какую-то скрытую уязвимость (например, ошибку в коде), но в данном коде таких уязвимостей не видно.

И это все - даже без учета того, что Ваша система содержит еще один, практически непобедимый слой защиты - предварительное шифрование.

[televendor]

И это все - даже без учета того, что Ваша система содержит еще один, практически непобедимый слой защиты - предварительное шифрование.

Кстати, я уже встречал обсуждения последнего на некоторых зарубежных криптографических форумах, где его называют "метод Павленко" и "шифр Павленко".

Вообще говоря, два последовательных шифрования, ни одно из которых не возможно взломать - это сильный ход. Так сказать, система с двойным обломом (для хакеров). Неплохой слоган для маркетологов, правда?

[vendor]

3. RC4_SKIP_TRASH: Приблизительно 256 (точное значение неизвестно хакеру).

В принципе, я полностью согласен с Вашими выводами и заключением, но рекомендовал бы разработчику увеличить данное значение RC4_SKIP_TRASH в два-три раза.

[george]

В принципе, я полностью согласен с Вашими выводами и заключением, но рекомендовал бы разработчику увеличить данное значение RC4_SKIP_TRASH в два-три раза.

Могу Вас заверить, сэр, что используемые нами значения RC4_SKIP_TRASH существенно превосходят то, которое было указано месье Телепортом. Никаких оснований для беспокойства у наших клиентов нет и никогда не будет. Мы все время за этим тщательно следим.