информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Атака на InternetПортрет посетителяСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / dnet / faq / проект rc5-72
FAQ
главная
общая информация
как принять участие
статистика
клиентская программа
персональный прокси
серверы ключей
завершенные проекты
проект ogr
проект rc5-72
старый командный faq




Подписка:
BuqTraq: Обзор
RSN
РВС
БСК




Проект RC5-72

Проект, направленный на взлом сообщения, зашифрованного с помощью 72-битного шифра RC5. (RSA Laboratories Secret-Key Challenge, RC5-32/12/9).

Дополнительная информация о самом проекте может быть получена на странице, ему посвященной.


Зачем этим заниматься?

Вероятно, существует столько же причин, сколько и участнков. Перечислим некоторые самые популярные.

Сделать что-то со всей этой вычислительной мощью
Это было естественным шагом после завершения проектов RC5-56 и RC5-64, поскольку существующий клиентский код мог быть достаточно легко модифицирован для запуска RC5-72. Вместо того, чтобы начинать дикую гонку по выпуску общецелевых клиентов следующего поколения, мы решили сделать незначительные модификации с тем, чтобы позволить существующим клиентам принять участие в 72-битном конкурсе как можно быстрее. Быстрый выпуск обновленного клиента позволил поддержать интерес огромного числа наших добровольцев, предоставив им задачу, над которой мы смогли продолжить работу в качестве сохранившейся группы.

Доказать, что шифрование с короткими ключами неудовлетворительно
Группа людей, относительно слабо связанных между собой через Internet, в свободное время дешифровала закодированное сообщение. Это могло бы стать достаточным поводом для правительств, компаний, занимающихся безопасностью, и т.п., чтобы пересмотреть их текуще взгляды на то, что является "безопасным" размером ключей. Дешифровка все более стойких кодов только укрепляет этот аргумент, раздвигая границы наших представлений о том, какие длины ключей могут считаться достаточными.

Исследовать возможности совместных сетевых многопроцессорных вычислений
Это захватывающее зрелище - как легко (и сложно) связать вместе так много компьютеров, использующих так много операционных систем, в столь многих часовых поясах, и заставить их всех работать над общей вычислительной задачей.

Потому что это забавно
Примерно как некоторых людей увлекает написание программ для игры в крестики-нолики в sendmail.cf, это стало стоящим развлечением для всех участников.

Потому что вы можете выиграть деньги!
Установлен приз в 10 тысяч долларов США для победителя этого соревнования. После победы в RC5-56 мы отдали одну тысячу владельцу компьютера, обнаружившего победивший ключ, дну тысячу оставили себе, и пожертвовали оставшиеся 8 тысяч Проекту Гутенберг. Распределение приза в этом соревновании будет аналогичным, и каждый участник может проголосовать за то, какая из екоммерческих организаций получит большую часть денег. Подробнее о распределении призовых денег можно прочитать здесь. Другие денежные призы были аналогичным образом распределены по завершении RC5-64, CSC, DES-II-1, DES-II-2 и DES-III

Чтобы познакомиться с большим числом людей
Вы будете изумлены числом людей, с которыми можно повстречаться, участвуя в этом проекте, особенно если вы подключитесь к каналу #distributed на IRC, или подпишетесь на листы рассылки.

Чтобы привлечь лиц противоположного пола
Ну, может, да, а может, и нет. Кто его знает :)


Что произойдет, когда ключ будет найден?

Когда клиент найдет ключ, корректно дешифрующий первые несколько байтов сообщения (известно, что первая часть сообщения - текст "The unknown message is:"), и отправит его на сервер, тот пошлет извещение об этом организаторам distributed.net.

Далее, используя другие программы, мы попытаемся расшифровать все сообщение. В случае успеха будет извещена RSA. После того как RSA подтвердит факт обнаружения правильного ключа, мы и они выпустим по пресс-релизу, а чек на призовую сумму будет отправлен в адрес distributed.net. distributed.net затем распределит деньги так, как это было описано ранее.


Как я узнаю, не мой ли компьютер обнаружил ключ?

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

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


Как насчет ITAR?

ITAR ("International Traffic in Arms Regulations", "Международные правила распространения оружия") - набор правил, установленных правительством США, который, помимо прочего, ограничивает стойкость криптографических алгоритмов, реализованных в программном обеспечении, предназначенном для экспорта из США. По крайней мере, в приложении к криптографии, правила ITAR просто возмутительны. Привлечение общественного внимания к этой проблеме является одной из причин существования сети distributed.net.

Клиенты проекта RC5-72 не относятся к нелегальному экспорту. Вкратце, наши программы не могут быть использованы для кодирования или декодирования данных других людей. Они работают только над первыми несколькими байтами предварительно закодированного сообщения, сравнивая полученный результат с заранее известным фиксированным текстом ("The unknown message is:"). Следовательно, они не подпадают под ограничения ITAR в отличие от криптопрограмм общего назначение типа PGP (Pretty Good Privacy, популярная программа шифрования, доступная через Internet).


Почему сопроцессор не ускоряет работу над взломом RC5?

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

В настоящее время ни один из клиентов не пытается использовать сопроцессор, и мы считаем, что любое использование сопроцессора приведет только к замедлениею клиента. По крайней мере одна светлая голова предположила, что это не обязательно так - и мы не исключаем, что он может быть прав. Нам было бы очень интересно услышать, что кто-то смог подготовить ядро RC5-72, использующее сопроцессор x86 для ускорения общей скорости клиента. Если вам инетересно заняться этим, код ядра для x86 доступен и может быть забран с http://www.distributed.net/source/.


Почему PowerPC и (большинство) Intel-платформ гораздо быстрее работают с RC5-72, чем другие платформы?

Неотъемлемой частью математической основы алгоритма RC5 ясляются операции 32-битного циклического сдвига.

По каким-то причинам, создатели архитектур IA32 (32bit Intel x86) и PowerPC architectures решили реализовать функции сдвига в виде аппаратных инструкций.

Во многих других процессорах нет встроенных аппаратных команд циклического сдвига, и они должны эмулировать их (по крайней мере) двумя сдвигами и логическим ИЛИ. Эта фора является причиной того, что многие процессоры счи

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

Заметим, что архитектура IA32 используется в процессорах Intel 80386, 80486, Pentium, Pentium Pro, Pentium II, Pentium III и Pentium 4, однако у Pentium 4 нет аппаратной реализации циклического сдвига.


Как изменились адреса серверов и номера портов в RC5-72?

До запуска RC5-72 все наши клиенты, соединяющиеся с DNS-серверами, использовали адреса вида *.v27.distributed.net, такие как us.v27.distributed.net or jp80.v27.distributed.net. Обычно использовался 2064 порт (специализированные серверы, такие как jp80.v27.distributed.net или euro23.v27.distributed.net использовали, соответственно, порты 80 и 23).

Начиная с клиентов версии 2.9 мы перешли на адреса вида *.v29.distributed.net. Это позволило нам осуществить плавное обновление серверов, а также прекратить соединения с наиболее старыми клиентами, удалив через некоторое время старые имена хостов (известив об этом заранее за несколько месяцев).

Несмотря на то, что порт 2064 использовался distributed.net только после старта RC5-64 (в RC5-56 использовался 2056), было решено не использовать для нового проекта новый номер порта. Поскольку мы аккуратно усовершенствовали используемый протокол взаимодействия клиентов и серверов с точки зрения обратной совместимости, теперь нет необходимости занимать новый порт для поддержки более новых клиентов. Кроме того, продолжение использования старого порта позволяет уменьшить число изменений настроек межсетевых экранов, которые придется делать сетевым администраторам при апгрейде их машин.


Почему RC5-72 медленнее RC5-64?

RC5-72 использует размеры блоков начиная с 232, а не 228. Изначально мы поддерживали только один блок в пакете, но в последующих версиях это должно измениться. Поскольку каждый блок имеет больший размер, то если учитывать только время расчета отдельного пакета, может показаться, что RC5-72 гораздо медленнее.

Однако, RC5-72 также требует новых ядер для всех архитектур. В некоторых случаях было достаточно легко модифицировать старые ядра RC5-64 для обработки ключей большего размера, но это было возможно далеко не всегда. Иногда новые ядра приходилось писать с нуля, в частности, так пришлось поступить для x86 из-за ограниченного количества регистров. По умолчанию, до тех пор, пока не были готовы обновленные ассемблерные ядра для желаемых платформ, многие первоначальные версии клиентов RC5-72 были собраны с использованием общего ядра, написанного на ANSI C, используя только ту оптимизацию, которую мог предоставить компилятор.

Конечно, общая скорость проекта будет меньше, чем в случае RC5-64, поскольку пространство ключей, которые надо перебрать, теперь больше в 256 раз. Но поскольку компьютеры становятся все быстрее и быстрее с каждым годом, и через Internet подключается все больше и больше участников, мы надеемся завершить этот проект за время, сопоставимое со временем работы над предыдущими проектами.

Если у вас есть опыт по ассемблерной оптимизации для своей платформы, попробуйте взглянуть на общедоступные исходные тексты на http://www.distributed.net/source/, и если вам покажется, что вы в состоянии написать более быстрый код, попробовать свои силы в написании нового обновленного ядра. В будущем мы будем периодически выпускать новые более быстрые версии клиентов. Даже в случае RC5-64 первоначальные версии клиентов были значительно медленнее, чем те, с которыми мы заканчивали проект. И в случае RC5-72 процесс все большей оптимизации будет продолжаться.


Почему я получаю ошибку "file is not in distributed.net client format" (файл не формата клиента distributed.net)?

Если ваш клиент выдал ошибку такого вида:

[Dec 02 11:03:07 UTC] Open failed for 'D:\Program Files\distributed.net\buf ...
                      File is not in distributed.net client format.

то вам следует удалить один или более ваших буферных файлов. Версия 2.9 клиента исспользует новый формат файлов и откажется использовать файлы, созданные ранними версиями клиента.

Если в ваших старых файлах остались рассчитанные блоки, вам имеем смысл сбросить их на сервер с помощью старого клиента, после чего перейти на новую версию.

Отметим, что формат файлов с буферами персонального прокси не изменился с переходом к версиям, поддерживаюзим RC5-72 (версии 330 и выше).


Какие версии клиентов и прокси необходимы для работы RC5-72?

Клиент: Версия 2.9001.477 - минимальная версия, от которой будут приниматься резальтаты RC5-72. (Результаты бета-версий v2.9000 игнорируются). Все клиенты v2.9xxx требуют прокси/сервера по крайней мере версии 330.

Персональный прокси: Версия 331 - минимальная рекомендуемая для поддержки клиентов v2.9xxx clients (хотя и бета-версии 330 будут работать). Прокси версии 331 требует прокси/сервера старшего уровня по крайней мере версии 331.


Обновленные бинарники клиента/прокси для моей платформы еще недоступны.

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

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

Страница с пре-релизами расположена по адресу http://www.distributed.net/download/prerelease.html. Людям, недоверчиво относящимся к неокончательным версиям программ, рекомендуется дождаться формального релиза.


Почему клиент выбирает неверное ядро? (или: Почему клиент каждый раз выбирает разные ядра?)

В настоящее время клиент всегда проводит "микротестирование" для оценки быстрейшего ядра, которое можно использовать на вашем процессоре. Это тестирвоание включает быструю неточную проверку каждого ядра, включенного в клиента, на небольшом числе ключей. Результат микротестирования сильно зависит от активности остальной системы, может быть разным при разных запусках, и это не является ошибкой кода.

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

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

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



Rambler's Top100
Рейтинг@Mail.ru



  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach