 |  |
https://bugtraq.ru/dnet/faq/rc572/ |
|
|||
|
|
|
||
| https://bugtraq.ru/dnet/faq/rc572/ |
||||
| ||||
Проект, направленный на взлом сообщения, зашифрованного с помощью 72-битного шифра RC5. (RSA Laboratories Secret-Key Challenge, RC5-32/12/9).
Дополнительная информация о самом проекте может быть получена на странице, ему посвященной.
- Зачем этим заниматься?
- Что произойдет, когда ключ будет найден?
- Как я узнаю, не мой ли компьютер обнаружил ключ?
- Как насчет ITAR?
- Почему FPU не ускоряет работу над взломом RC5?
- Почему PowerPC и (большинство) Intel-платформ гораздо быстрее работают с RC5-72, чем другие платформы?
- Как изменились адреса серверов и номера портов в RC5-72?
- Почему RC5-72 медленнее RC5-64?
- Почему я получаю ошибку "file is not in distributed.net client format" (файл не формата клиента distributed.net)?
- Какие версии клиентов и прокси необходимы для работы RC5-72?
- Обновленные бинарники клиента/прокси для моей платформы еще недоступны.
- Почему клиент выбирает неверное ядро? (или: Почему клиент каждый раз выбирает разные ядра?)
Вероятно, существует столько же причин, сколько и участнков. Перечислим некоторые самые популярные.
Сделать что-то со всей этой вычислительной мощью
Это было естественным шагом после завершения проектов 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 ("International Traffic in Arms Regulations", "Международные правила распространения оружия") - набор правил, установленных правительством США, который, помимо прочего, ограничивает стойкость криптографических алгоритмов, реализованных в программном обеспечении, предназначенном для экспорта из США. По крайней мере, в приложении к криптографии, правила ITAR просто возмутительны. Привлечение общественного внимания к этой проблеме является одной из причин существования сети distributed.net.
Клиенты проекта RC5-72 не относятся к нелегальному экспорту. Вкратце, наши программы не могут быть использованы для кодирования или декодирования данных других людей. Они работают только над первыми несколькими байтами предварительно закодированного сообщения, сравнивая полученный результат с заранее известным фиксированным текстом ("The unknown message is:"). Следовательно, они не подпадают под ограничения ITAR в отличие от криптопрограмм общего назначение типа PGP (Pretty Good Privacy, популярная программа шифрования, доступная через Internet).
Алгоритм RC5 задействиет большое количество операций целочисленного сложения, циклических сдвигов и исключающих ИЛИ. Он не требует вычислений с плавающей точкой и, в целом, никак не выиграет от их аппаратной поддержки. В последнее время было множество дискуссий по поводу того, возможно ли ускорить расчет (по крайней мере на архитектуре x86), используя тот факт, что для целочисленные вычисления и вычисления с плавающей точкой осуществляются с помощью разных конвейеров команд (мы уступаем читателю право самостоятельно догадаться, каким образом производить над вещественными числами сдвиги и исключающие ИЛИ).
В настоящее время ни один из клиентов не пытается использовать сопроцессор, и мы считаем, что любое использование сопроцессора приведет только к замедлениею клиента. По крайней мере одна светлая голова предположила, что это не обязательно так - и мы не исключаем, что он может быть прав. Нам было бы очень интересно услышать, что кто-то смог подготовить ядро RC5-72, использующее сопроцессор x86 для ускорения общей скорости клиента. Если вам инетересно заняться этим, код ядра для x86 доступен и может быть забран с http://www.distributed.net/source/.
Неотъемлемой частью математической основы алгоритма RC5 ясляются операции 32-битного циклического сдвига.
По каким-то причинам, создатели архитектур IA32 (32bit Intel x86) и PowerPC architectures решили реализовать функции сдвига в виде аппаратных инструкций.
Во многих других процессорах нет встроенных аппаратных команд циклического сдвига, и они должны эмулировать их (по крайней мере) двумя сдвигами и логическим ИЛИ. Эта фора является причиной того, что многие процессоры счи
Заметим, что архитектура IA32 используется в процессорах Intel 80386, 80486, Pentium, Pentium Pro, Pentium II, Pentium III и Pentium 4, однако у Pentium 4 нет аппаратной реализации циклического сдвига.
До запуска 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 использует размеры блоков начиная с 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 процесс все большей оптимизации будет продолжаться.
Если ваш клиент выдал ошибку такого вида:
[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 и выше).
Клиент: Версия 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 так, чтобы он использовал явно прошитый в нем выбор ядер в зависимости от идентификатора процессора, что устранит необходимость микротестирования.
До тех пор вы при желании можете явно указатьв настройках клиента номер используемого ядра. Это может быть особенно полезно для людей, часто перезагружающих свои машины, поскольку это устранет затраты на микротестирование при каждой перезагрузке. Кроме того, это устраняет возможность выбора клиентом каждый раз нового ядра, что может привести к потере ранее сделанной работы (поскольку клиент начинает обработку блока с нуля, если обнаруживает, что часть работы была выполнена другой версией клиента или ядра).
Не забывайте, что в случае ручного задания номера используемого ядра, он будет использоваться и в дальнейшем - даже если вы установите версию клиента с другими ядрами (и с другой нумерацией ядер), или если изменится относительная производительность некоторых ядер (и старое ядро, выбранное вами, перестанет быть самым быстрым).
|
|
|