Автор

Иванов Илья, http://bozza.ru, апрель 2010

Вступление

Если в домене Windows установлен WSUS, админ рад и спокоен - дескать, все, обновления ставятся на автомате, трафик снизился, бегать по компам не надо и пр. В принципе, все осталость то же самое, но ведь не все используют в работе Microsoft Outlook или Internet Explorer (хотя 8-ка очень неплоха). Есть много людей, привыкших работать с почтовиком The Bat!, броузером Opera или Mozilla. Если встает вопрос об обновлениях - либо это головняк админу в виде беготни к каждому компьютеру для обновления всем, скажем, Opera, либо юзеры должны сидеть под админами (пускай и локальными, не доменными).

Естественно, ни первый, ни второй способы - не выход. Значит, надо иметь возможность автоматически устанавливать программы на рабочих станциях, причем желательно делать это до того, как пользователь вошел в систему - ведь если он вошел, он уже не захочет перезагружать машину и т.п. Надо ставить пользователя перед фактом - программа, его любимая Opera, уже обновлена и админа не колбасит, что версия 10.10 почему-то нравится меньше, чем предыдущая. Просто вышло обновление, и его надо применить. Без вариантов.

Самый распространенный вариант ответа на вопрос - КАК? - Конечно, через Active Directory! - скажет вам любой специалист или просто сисадмин. А как через AD? - спросите вы. А вам скажут - ?! Вы не знаете, как через AD? Да там же просто, через policy! - но больше вам скорее сего ничего не скажут, потому что для большинства советчиков этот вопрос такой же неясный, как и для вас. И вам ничего не останется, как гуглить до потери пульса, потому что найти огромный фолиант на тему "как развернуть office 2007" в сети корпорации не проблема, а вот просто и в двух словах - редко что найдете. Не без гордости могу сказать, что данная статья как раз одна из немногих кратких и "без наворотов", попадавшихся мне.

Установка программ из MSI

Все изложенное далее относится к работе с инсталляционными пакетами типа MSI (расширение .msi). Файлы MSI есть (или их можно извлечь) для многих программ (Adobe Acrobat, The Bat, Opera, Firefox и пр.).

Предположим, мы хотим автоматически установить (а по мере выхода обновлений, устанавливать обновления) броузер Firefox. Файл msi для Firefox можно взять здесь (в новом окне).

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

Распределяем права доступа

Предполагаю, что все учетные записи компьютеров (кроме контроллеров домена) находятся в OU "OU Office Computers".

Примечание 1:

Почему лучше не использовать исходное размещение компьютеров (Computers - Компьютеры домена в оснастке Active Directory Users and Computers)? Мне удобнее в дальнейшем управлять политиками для групп компьютеров. К тому же, когда я посещал курсы Microsoft, я видел, что на контроллерах доменов в тестовых системах и в "боевых", настроенных специалистами Microsoft, используются практически только отдельно созданные OU, а не базовые. Я для себя решил повторять опыт специалистов. Пока мне от этого только удобнее. Естественно, ИМХО.

Примечание 2:

Не всем пользователям нужен Firefox (как не всем нужен The Bat, Opera и пр.). Поэтому создадим в "OU Office Computers" отдельную группу компьютеров, на которые будет установлен Firefox. Для ясности назовем группу GFirefoxComputers. Отмечу, что это будет именно группа, а не вложенное OU!

Расшариваем какую-либо папку на сервере (на рисунке это SoftwareDistibution, а не Mozilla Firefox, как может показаться) и даем группе GFirefoxComputers доступ на чтение, админу - полный доступ (не компьютеру админа, а пользователю - все-таки вы должны иметь возможность по сети заливать на шару файлы ;)).

Вообще, для проверки того, как все вообще работает, можно обойтись и без группы GFirefoxComputers. Просто для того, чтобы сразу не усложнять себе жизнь, и не пенять на групповые политики, если что пойдет не так ;)

Политика правит миром! 

На контроллере домена запускаем редактор групповой политики GPMC.MSC:

... и создаем связанную только с нашим OU "OU Office Computers" групповую политику под названием "Firefox 3.6.3 rus":

... редактируем нашу политику "Firefox 3.6.3 rus":

Готовим дистрибутив Firefox для развертывания в сети

В разделе "User Configuration" -> "Software settings" -> "Software Installation" щелкаем правой мышкой и создаем новый объект для установки - наш будущий инсталлятор Firefox.

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

Выбираем "Assigned" (Назначенный):

На этом работа с веткой "Software Installation" закончена.

Закрываем все открытые окна на сервере (если не помешает другим задачам, естественно), Пуск -> Выполнить -> gpupdate /force

Установка на рабочих станциях

Далее достаточно просто перезагрузить рабочие станции, чтобы автоматически установился Firefox ДО того, как появится окно для ввода логина/пароля. Иными словами, пользователь будет не в силах чего-то не установить, забыть и пр. Поэтому этот способ так хорош. Вы удаленно решаете, что будет установлено / обновлено на рабочих станциях.

Windows XP бывает не с первой перезагрузки "принимает" нове политики, поэтому можно подойти к юзеру, выполнить команду "gpupdate /force" (не обязательно под админом) и перезагрузить его компьютер.

Обязательно проверьте установку на своем / тестовом компьютере ДО того, как юзеры придут следующим утром, включат компьютеры... а вдруг косяк? Поэтому хотя бы первый раз сначала испытайте на себе.

Дополнительно

Теперь на любой новый компьютер, введенный в состав подразделения OU Office Computers будет установлена последняя версия броузера Firefox. Вам даже не придется ничего делать. Просто и очень полезно. Таким же образом можно устанавливать практически любой софт, включая Adobe Reader, Adobe Flash Player (которые в обычной ситуации требуют административных прав для установки), The Bat... да мало ли софта у вас в локальной сети, поддерживать который в актуальном состоянии одна из обязанностей системного администратора.

Нюанс: если вы уже установили какой-либо пакет, в нашем случае Firefox 3.6.3 rus, а через некоторое время вам потребуется его обновить (т.к. рано или поздно выйдет новая версия броузера), сначала удалите политику по установке Firefox 3.6.3, после чего создайте новую. Потом "gpudate /force" и вперед!

Введение

Многие небольшие организации используют домены Windows для управления учетными записями пользователей. Но далеко не все устанавливают у себя платные решения на ISA Server, Kerio WinRoute или др. Также можно сказать, что многие небольшие организации привлекают (за неимением своего) стороннего специалиста для настройки доступа в интернет с возможностью контроля доступа сотрудников (кто-что скачал и т.п.). В таких случаях часто имеет место настройка Squid на базе Linux / FreeBSD.

Удобство работы, простота и доступность Squid привлекает к себе многих, но как разрешить ходить в интернет только определенным сотрудникам, причем, желательно, поудобнее этим процессом управлять?

Вариант 1: настроить Squid на фильтрацию по IP-адресу. В небольшом офисе из 2-5 машин это может быть удобным, но если машин 20 и более? Все равно будет ротация машин (замена на новые, сотрудники могут меняться местами и пр.). При этом неизбежно для одного и того же человека IP-адрес будет меняться. Поэтому это хоть и простой вариант, но не самый удобный.

Вариант 2: уж коль мы вначале статьи решили, что наша сеть с контроллером домена Windows 2003, намного удобнее управлять доступом в интернет, управляя учетными записями пользователей из домена. Проблема в том, что Squid, хоть и поддерживает эту возможность, реализация ее не совсем очевидная, по крайней мере, вы уже должны были не раз и не два встретить на формах кучу вариантов, причем часто в обсуждении пишут о больших сложностях. Особенно, что касается внедрения авторизации через samba. Я сам, пролистав несколько таких руководств с кучей листингов и скриптов, отказался от мысли сразу ломиться в бой. Вместо этого я решил разделить задачу на два этапа, причем максимально проще и без скриптов по 50 строк каждый: 

1 этап: проверка работы авторизации squid в домене;

2 этап: внедрение этого способа в рабочий squid.

Проверка авторизации Squid в домене Windows 2003

Для начала проверим, как вообще работает авторизация Squid в домене Windows. Нам будет нужен файл "squid_ldap_auth". В зависимости от операционной системы прокси-сервера, этот файл может быть в разных местах, у меня в CentOS он находиться по адресу:

/usr/lib/squid/squid_ldap_auth

 Теперь создадим отдельное организационное подразделение в домене Windows 2003:

В русском варианте примерно тоже самое, только вместо "Organization Unit" будет "Подразделение".

Создадим в этом подразделении двух пользователей: SquidWebAccess (пароль "squid") и testuser (пароль "12345"). Права для этих пользователей - минимальные.

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

Пользователь testuser - это имитация реального пользователя.

На этом этапе возникнет вопрос - а с чего это в уже настроенной структуре пользователей домена с отработанными политиками безопасности и пр. делать отдельного пользователя в новом OU, а не использовать текущие учетные данные? Ответ: можно использовать и те учетные записи, которые уже настроены. Но при этом теряется малая часть гибкости: если надо будет запретить пользователю доступ к интернет (за провинность, например), в моем случае не придется отключать его основную учетную запись домена. Я просто отключу учетную запись для доступа в интернет. Можно спорить, что удобнее, что нет. Мне удобнее разделить доступ в интернет от доступа к файлам и пр.

Заходим на прокси-сервер (где Squid) и вводим команду (в одну строку, у меня разделены символом \):

/usr/lib/squid/squid_ldap_auth -v 3 -R -D SquidWebAccess@domain.local -w squid \
-b "ou=InternetUsers,dc=domain,dc=local" -f "sAMAccountName=%s" 192.168.1.2

где

считаем, что домен называется "domain.local"

-D SquidWebAccess@domain.local - полное имя пользователя для возможности Squid сравнить введенные данные пользователя с теми, которые мы задали пользователю testuser

-w squid - пароль пользователя SquidWebAccess

-b "ou=InternetUsers,dc=domain,dc=local" - полный путь до места хранения учетных записей пользователей для доступа в интернет. Заметьте, что использовать свои учетные записи (в т.ч. учетную запись администратора домена) для доступа в интернет не выйдет! Можете это считать дополнительной опцией безопасности.

192.168.1.2 - ip-адрес контроллера домена Windows 2003.

После выполнения команды вводим:

testuser 12345

В ответ должны получить OK. Если нет, то ищем, описать все возможные варианты проблем - задача нереальная.

Если все OK, то переходим ко второму этапу: внедряем авторизацию squid в домене уже в самом прокси-сервере Squid, а не в тестовом варианте.

Авторизация Squid в домене Windows 2003

Для настройки авторизации в Squid, нам нужно изменить только squid.conf.

# LDAP-авторизация
# В одну строку, или разделяйте символом \

auth_param basic program /usr/lib/squid/squid_ldap_auth -v 3 -R -D SquidWebAccess@domain.local -w squid \
  -b "ou=InternetUsers,dc=domain,dc=local" -f "sAMAccountName=%s" 192.168.1.2

auth_param basic children 5
auth_param basic realm Web-Proxy
auth_param basic credentialsttl 1 minute

acl ldap-auth proxy_auth REQUIRED

http_access allow ldap-auth
http_access allow localhost

http_access deny all  

Остальные настройки Squid трогать не надо. Перезапустите Squid:

/sbin/service squid restart
Stopping squid: ........[ OK ]
Starting squid: ........[ OK ]

 Наслаждайтесь :) Про подсчет трафика с учетом такой авторизации напишу позже.

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

Длинные объяснения заканчиваются краткими выводами (которые, вероятно, и стОит прочитать при первом ознакомлении с этой статьёй).

На что тратится время при переборе паролей.

Если с десять лет назад каждый разработчик пытался придумать какой-то свой, оригинальный алгоритм шифрования (но, так как почти никто не был экспертом в области криптографии, подавляющее большинство таких «оригинальных» алгоритмов ломались в момент), то теперь с этим стало гораздо проще. Практически везде используются проверенные и стандартные схемы.

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

Для хэширования ещё совсем недавно массово использовался MD5, но (после обнаружения уязвимостей в алгоритме) его довольно быстро заменил SHA1. С SHA1 в данный момент уже тоже не совсем всё гладко (сложность нахождения коллизии составляет примерно 2^63, а недавно ещё и заявили о снижении этого числа до 2^52), но при использовании его в каком-нибудь «обрамлении» вроде PBKDF2 сложность (а, точнее, легкость) нахождения коллизии уже не так важна.

Один очень важный момент: при проверке паролей определяющей чаще всего является именно скорость хэширования, а не скорость шифрования. Практически везде сейчас используется так называемое «key strengthening», то есть усиление ключа путём добавления сложности на этапе генерации пароль -> ключ. Вместо одного преобразования SHA1 можно выполнить 10000, подавая результат первой итерации как вход на вторую и т.д. Для валидных паролей, которые собственно проверяются один раз, разница незаметна – генерится ключ 0.01 мс или 10 мс совсем не важно. А вот для задачи перебора паролей, когда проверяются миллиарды комбинаций, это уже очень ощутимо. Если, например, какой-то пароль можно подобрать за месяц, то он явно не стойкий. Однако, если использовать схему «усиления ключа» с дополнительными 10000 итераций, то на подбор того же самого пароля уйдёт уже не месяц, а 830 лет, что переводит пароль в разряд довольно устойчивых.

Алгоритм PBKDF2, описанный в RFC 2898, сейчас является одним из самых популярных для «key strengthening» и используется во многих приложениях. Рекомендуемый минимум итераций в нём составляет 1000 (а одна итерация требует выполнения двух SHA1_Transform действий, о которых ниже).

В некоторых случаях для проверки валидности пароля вообще не надо расшифровывать файл. Например, появившееся в WinZip 9 сильное шифрование на основе AES 128 & 256 bit на самом деле до AES доходит только в случае абсолютной правильности проверяемого пароля. Во всех остальных случаях выполняется только PBKDF2, который в свою очередь использует только SHA1. В RAR 3.x до AES доходим после 262144 итераций SHA1. Так что на фоне такого количества SHA1 инициализация и расшифровка нескольких байт с помощью AES занимает мизерные доли процентов от общих вычислений. В MS Office 2007 используется 50 000 итераций SHA1, в WPA, как и в WinZip, PBKDF2, но уже с количеством итераций 4096.

В PDF9 Adobe сильно промахнулся с новым алгоритмом, взяв одну итерацию SHA256 вместо 50-ти MD5 + 20x RC4, что ускорило скорость перебора паролей по сравнению с предыдущей версией практически на два порядка. Но валидация пароля после хэширования не требует никакого шифрования, так что и тут важна только скорость SHA256.

Правильный алгоритм шифрования делает невозможным сокращение пространства перебора для ключей. То есть, чтобы найти, например, 128-ми битный ключ надо перебрать 2^128 == 3.4 * 10^38 вариантов. Если допустить, что один компьютер перебирает один миллиард вариантов в секунду, у нас есть миллиард компьютеров и мы располагаем миллиардом лет, то за это время мы сможем проверить всего лишь 10^9 * 10^9 * 10^9 * 60 с * 60 м * 24 ч * 365.25 д ~= 3.16 * 10^34 вариантов, меньше 1/10000 требуемого диапазона.

Пример неудачного алгоритма шифрования: в классическом zip используются 96-ти битные ключи. Несмотря на прошедшие уже 20 лет с момента создания алгоритма, эти ключи до сих пор невозможно перебрать «в лоб». Однако, имея часть незашифрованного файла, можно провести так называемую plaintext attack, при этом сложность перебора упадёт с 2^96 всего до 2^38, что составляет всего пару часов работы для современного компьютера.

Все «сильные» алгоритмы шифрования (AES, Blowfish, etc) не позволяют провести plaintext атаку и не позволяют сократить пространство перебора. Так что единственная возможность получить доступ к зашифрованным файлам – знать правильный пароль.

Вывод: используемый алгоритм шифрования практически никак не влияет на скорость перебора паролей. Хороший алгоритм просто обеспечивает невозможность подбора ключа «в лоб». А вот уже для перебора паролей главным является именно преобразование пароля в ключ, а за это отвечают алгоритмы хэширования (MD5, SHA1), а не алгоритмы шифрования (AES, Blowfish).

Значение «количество итераций» мало что говорит.

MD5, SHA1 (и его потомки в виде SHA256, 384, 512) очень похожи. На входе есть состояние хэша (128 бит для MD5, 160 бит на SHA1) и блок данных размером в 512 бит (64 байт). На выходе, после операции хэширования, получаем новое состояние хэша. Это сердце алгоритма, функция обычно называется MD5_Transform, SHA1_Transform, etc.

Важно заметить, что размер блока является константой, всегда хэшируются именно 64 байта. Если подать на вход 1 байт, то он будет дополнен до 64 путём добавления нулей, символа-терминатора и 8-ми байтового значения длины блока. То есть, подать отдельно на вход хэш-функции 64 раза по 1 байту или один раз 64 байта – абсолютно одинаково в плане скорости обработки (не считая того, что при подаче 64 байт придётся символ-терминатор и значение длины обрабатывать уже в следущем блоке).

Для некоторых алгоритмов пишется количество итераций как количество вызовов функции по обновлению хэша. Но не всякое обновление ведёт к вызову Transform функции. Данные накапливаются в буфере и отдаются на Transform блоками по 64 байта. Например для RAR 3.x количество итераций равно 262144, но количество обрабатываемых блоков будет равно ((длина_пароля * 2 + 8 + 3) * 262144) / 64. Что, например, для паролей длиной в 4 символа составит 77824 (+ещё 17 дополнительных блоков для создания IV для AES).

Для алгоритма PBKDF2 требуется на каждую итерацию обработать 2 блока плюс ещё 2 для инициализации. Иными словами, для проверки одного пароля WinZip/AES (где количество итераций равно 1000) надо выполнить 2002 операции SHA1_Transform.

В Office 2007 используется 50 000 итераций и обрабатывается блок в 20 байт. Но подаются эти байты каждый раз отдельно, поэтому выходит именно 50 000 вызовов SHA1_Transform, а не 50000*20/64 = 15 625.

Что даёт приведение количества итераций к количеству блоков для Transform? Так как время вычисления хэша не зависит от данных в блоке и является константой, зная время хэширования одного блока и количество блоков, можно легко посчитать общее время хэширования. Также легко оценить, насколько быстрее или медленнее разные алгоритмы генерации паролей относительно друг друга.

Например, на основе рассчётов выше выходит, что скорость перебора паролей WinZip/AES в ~39 раз быстрее, чем 4-х символьных паролей в RAR 3.x. А скорость перебора паролей для Office 2007 в 25 раз ниже, чем для WinZip/AES. Точность этих вычислений, конечно, приблизительная. Для сложных алгоритмов инициализации блока данных (как в RAR 3.x) такая оценка может давать заметную ошибку. Но в большинстве случаев достаточно знать только порядок величины, а не абсолютное значение.

Вывод: Количество «виртуальных» итераций в алгоритме мало что значит. Для оценки скорости надо знать количество 64-х байтных блоков, использованных при хэшировании. Зная это значение, общую скорость обработки легко получить просто умножив это значение на время обработки одного блока данных.

Насколько быстро можно хэшировать?

Теперь нас интересует вопрос, насколько же быстро можно обработать один 64-х байтный блок данных. Операции, используещиеся в Transform функции, самые простейшие – логические OR, XOR, NOT, AND, арифметическое сложение, сдвиги. Все действия производятся над 32-х битными целыми. Один блок данных легко помещается в кэш L1 любого из современных процессоров, так что скорость работы с памятью, её размер, размер L2 или RPM дискового накопителя не играет никакой роли. Иными словами, скорость перебора находится в прямой зависимости от скорости целочисленного ALU и практически никак не зависит от всего остального. У какого же из современных процессоров с этим лучше всего?

Процессоры.

Так как хэширование разных паролей никак не зависит друг от друга, то очень выгодно использовать какой-нибудь SIMD набор инструкций для их параллельной обработки. Лучше всего подходит SSE2 (хотя и от «старого» MMX до сих пор есть польза), позволяющий выполнять какую-либо операцию сразу с четырьмя 32-х битными операндами. В своем первом воплощении в Pentium 4 со скоростью работы SSE2 инструкций было не всё гладко (например, пересылки регистр->регистр стоили 6 тактов, а выполнение OR всего 2), но уже тогда выигрыш от их применения был вполне ощутимым. В данный же момент реализация SSE2 в Intel Core архитектуре просто великолепна: можно выполнить 3 операции за такт, причём результат будет готов уже на следующем такте (latency == 1 такт). То есть, пиковая производительность у Core составляет 12 операций с 32-х битными целыми за такт. Хотя не все операции можно выполнять на этой пиковой скорости.

Несмотря на появление новых ревизий ядра, перехода с 65nm на 45nm и, наконец, выхода Core i7, никаких заметных изменений в целочисленном ALU не произошло. Поэтому Core i7 работает практически также, как и его 65nm предок Core 2. Производительность зависит только от частоты, поэтому, например, Q6600 разогнанный до 3-х Ггц (что является вполне обычной практикой) будет ровно на 3/2.66 = 12.7% быстрее, чем Core i7 920 на штатной частоте (не считая turbo burst). Стоимость же Core i7, включая материнскую плату и память DDR3 заметно выше, чем у «старых» систем на Core 2 65/45nm.

Ситуация с AMD несколько хуже. Даже сейчас существует ещё довольно много систем с процессором Athlon XP. В своё время он очень хорошо конкурировал с P4, но вот SSE2 в нём нет. В архитектуре K8 AMD сделала поддержку SSE2, но в самом примитивном виде: 128-ми битные инструкции разбивались на две половинки и запускались на 64-х битном ALU. Что приводило к тому, что разницы между MMX кодом и SSE2 практически не было.

С появлением K10 (или Phenom) AMD наконец сделала поддержку SSE2 более достойным образом, однако Core 2 она заметно уступает. K10 может выполнить до 2-х операций с 4-мя 32-х битными целыми за такт, а результат операции будет готов только через такт (latency == 2 такта). То есть, пиковая производительность составляет 8 операций с 32-х битными целыми за такт. Что это означает в плане сравнения K10 vs Core 2: процессор от AMD будет в среднем в 1.5 раза медленнее, если мы сможем выстроить инструкции таким образом, чтобы latency не была лимитирующим фактором. В некоторых алгоритмах, учитывая ограниченное количество XMM регистров, сделать это очень непросто, а то и невозможно.

С другой стороны, не все операции Core 2 может выполнять на уровне «три за такт». Сложений можно выполнить только два, а сдвигов вообще один. K10 же умеет сдвигать два XMM регистра за такт, но уже с latency в 3 такта. Поэтому реальное соотношение производительности Core 2 vs K10 плавает где-то в районе 1.25-2x. K10 всегда медленней на задачах, которые зависят только от скорости SSE2 ALU, но может быть быстрее на алгоритмах со множеством чтений из памяти и отсутствием логических операций.

Phenom II, появившийся не так давно, отличается от просто Phenom'а гораздо меньше, чем Core i7 от Core 2 45nm. Но стоит, конечно, дороже.

Важно заметить, что в данный момент использование SSE2 является обязательным при параллельной обработке данных. Логическая операция над 32-х битным регистром или над 128-ми битным xmm регистром, содержащим четыре 32-х битных значения, выполняется за абсолютно одинаковое время. Считать на Core 2 без SSE2 это всё равно что взять GPU и отключить на нём ¾ всех потоковых процессоров.

Также, задача перебора паролей идеально распараллеливается, так как нет никакой зависимости между данными. Поэтому производительность растёт линейно в зависимости от частоты и количества ядер. Нет никакого смысла использовать «быстрый» двухядерник, если есть возможность задействовать «медленный» четырёхядерник. Иными словами, Q6600 на частоте 2.4Ггц будет работать как 4*2.4 = 9.6Ггц, а E8600 3.33 Ггц только как 3.33 * 2 = 6.66Ггц. Разница в скорости в 1.5 раза, а разница в цене примерное такая же, но в другую сторону.

Вывод: Лучшим процессором для перебора паролей в данный момент является Intel Core Quad. По соотношению цена / производительность выгоднее модели Core 2 65/45nm. Стоимость систем на Core i7 выше, а частота ничуть не лучше, чем у «старых» Core 2. Процессоры от AMD заметно отстают на SSE2 целочисленных вычислениях и при этом разница в цене между Core 2 и Phenom ничуть не компенсирует этого отставания. SSE2 обязательно к употреблению, иначе возможности современных процессоров просто не раскрыть.

Так всё-таки насколько быстро можно хэшировать?

Подробные рассчёты затрагивают слишком много деталей и требуют отдельной статьи, поэтому рассмотрим кратко только MD5. MD5_Transform состоит из 64 итераций. В каждой итерации используются похожие операции. Подробное описание можно найти, например тут – http://en.wikipedia.org/wiki/MD5.

Очень грубо скорость по количеству используемых операций можно оценить так:

Ради сравнения – то же самое для AMD K10:

Конечно такая оценка не учитывает много разных факторов, однако подходит чтобы быстро понять, насколько быстро теоретически можно выполнять MD5_Transform. Опытные же результаты, как обычно, выглядят похуже. Но не так уж сильно:

MD5_Transform 72 такта в 64-х битном режиме.

MD5_Transform 90 тактов в 32-х битном режиме.

MD5_Transform в простейшей реализации на SSE2 при обработке всего 4-х блоков за раз 128 тактов.

SHA1_Transform 175 тактов в 32-х битном режиме, 162 такта в 64-х битном.

С SHA256 точного значения нет (так как используется SHA256 значительно реже), но SHA256_Transform займёт как минимум 425 тактов. Присутствие значительного бОльшего количества сдвигов и сложений скорее всего увеличит это значение.

Использование 64-х битного режима позволяет задействовать в два раза больше XMM регистров, что, в свою очередь, помогает решить проблемы с latency. Особенно сильно это влияет на MD5, где операций очень мало, так что постоянно приходится ждать результаты предыдущих вычислений, если обрабатывать всего 4 блока данных за раз.

Теоретические и практические результаты.

Ну и наконец сводная таблица, ради которой всё и затевалось. Сравнение скоростей для различных видов паролей. Были использованы:

• crark http://www.crark.net
• Advanced Archive Password Recovery http://www.elcomsoft.com/archpr.html
• Elcomsoft Wireless Security Auditor http://www.elcomsoft.com/ewsa.html
• Advanced PDF Password Recovery http://www.elcomsoft.com/apdfpr.html
• BarsWF http://3.14.by/en/md5
• Мои эксперименты с GPU, в том числе http://www.golubev.com/rargpu.htm (Хотя ARCHPR на самом деле тоже является «моим экспериментом»).

Скорость замерялась на одном ядре Intel Core 2 Q6600 @ 2.4Ггц, ATI HD4850 на штатной частоте 625Мгц, nVidia GTX 260 /w 192SP тоже на штатной частоте 1.242Ггц.

Как видно, соотношение скоростей на GPU к скорости на CPU довольно однообразное. ATI HD4850 примерно в 20 раз быстрее одного ядра Q6600 на частоте 2.4Ггц, GTX 260 примерно в 12 раз. Значение 37.5 для Office 2007 появилось только из-за неоптимизированного CPU кода (забавно что для Office 2007 используется SSE2, но настолько неудачно, что лучше бы вообще не использовался). Скорость перебора на GPU зависит только от частоты работы ALU (всё как с CPU), скорость памяти и объём ничего не значат. Зная разницу в частоте и количество SP можно довольно точно оценить производительность разных GPU одного семейства.

Сравнивать напрямую по цене CPU и GPU довольно глупо – видеокарта не может работать самостоятельно, да и CPU тоже. Системы с двумя и более процессорами сразу уводят нас на другой уровень цен, в то время как нет никакого экономического смысла рассматривать эти (серверные) процессоры с большим L2 кэшем для задач перебора паролей. С GPU же ограничивающим фактором является количество PCI-E разъёмов на материнской плате. На самых простейших платах он всего один, на большинстве – два. Материнские платы с 4-мя разъёмами уже довольно редки. Причём нужно не только 4 разъёма, но ещё и место под сами карты – занимают-то они обычно 2 слота. 4 раза по 2 слота встречается, судя по всему, только у MSI K9A2 Platinum. Есть 6-ти слотовый P6T6 WS Revolution, но там могут поместиться только «одинарные» карты.

Похоже, собрать систему с 4-мя ATI HD4870x2 невозможно в принципе (неплохое описание всех возникающих проблем тут: http://forums.guru3d.com/showthread.php?p=2862271). Системы с 4-мя двойными nVidia картами существуют (например http://fastra.ua.ac.be/en/specs.html), но проблем и там хватает. Начиная с мощного блока питания и корпуса, куда можно всё нормально поместить и заканчивая установкой драйверов.

В итоге получается такой список с точкой отсчёта производительности на 4-х ядрах Q6600 на частоте 2.4Ггц:

Для систем с медленными GPU (вроде 8600 GT) имеет смысл считать производительность как CPU+GPU (что тут сделано не было). Для быстрых же GPU процессор будет загружен дополнительными рассчётами и синхронизацией задач, так что считать дополнительно на нём просто не имеет смысла. В некоторых случаях четырёхядерного процессора может и не хватить для систем с 8-ю GPU.

Как видно, самым интересным решением в плане цена/производительность является связка из 4-х HD4770. Однако, опять же, требуется материнская плата, где можно разместить 4 такие карты – несмотря на то, что HD4770 одночиповая карта, система охлаждения занимает дополнительный слот.

TACC1441 приведён для примера в качестве «железного» решения. Это плата на основе FPGA, поддерживается ПО от AccessData (http://www.forensic-computers.com/TACC1441.php). Как видно, никакой конкуренции современным GPU он составить не может.

Осталась одна «маленькая» проблема – практическое полное отсутствие ПО для карт ATI. Карты от nVidia поддерживаются в ElcomSoft's Distributed Password Recovery, а вот с ATI пока всё совсем плохо.

Вывод: прирост в производительности от использования одного GPU примерно 4х-5ти кратный по сравнению с современной четырёхядерной системой. Карты от ATI заметно быстрее при той же цене, однако для них практически нет ПО. При росте количества GPU в системе нелинейно растут проблемы – появляется потребность в мощном блоке питания, специальном корпусе, эффективной системе охлаждения и т.д.

А почему такой маленький прирост?!

TACC1441 обещает 60-ти кратный прирост. EDPR декларирует 100x и 200x. Почему же тут получилось «только» 30? Ответ прост: маркетологи и пиарщики тоже работают. Сравнивая неоптимизированный CPU код на системе начального уровня с top решением на 4xGTX295 можно получить совершенно потрясающий результат. Например такой: E2160 1.8Ггц vs 4xGTX295 для документа MS Office 2007 в EDPR == прирост в 229 раз!

Вывод: всегда полезно думать самому.

Какие пароли можно считать стойкими?

Вывод: неутешительный для brute-force атаки. При правильно выбранном пароле из 8-ми символов подобрать его в осмысленное время просто невозможно.