1. абсолютно верно. но требуется поддержка со стороны сервиса, а не все этим обеспокоены. вот такие «бестолковые» статьи, возможно, кого-то и подтолкнут.
2. вот с этим сложность. да, есть много замечательных программок-запоминалок, однако собрав все пароли в одном месте возникает другая опасность — кража хранилища вместе с мастер-пассвордом, например трояном. записывать на бумажке — тоже едва ли вариант.
+ все больше людей пользуются мобильными «помощниками» (планшеты, телефоны), набрать на которых 20+ случайных символов не так-то легко.
вероятностью коллизии для MD5, по крайней мере, можно пренебречь, запас большой. пока этим любят пугать, но даже, в сущности, при вероятности коллизии 2^-50 необходимы сотни вычисительных лет.
чисто ради интереса сливаю дамп. уверен что можно снести 60% за пол дня без видеокарт если применять частотный анализ. если что интересное выйдет напишу топик.
ага, а модельные тесты и диаграммы «неотставания» джавы обычно делаются на каких-то совсем простых примерах, где в действительности можно просто «научить» VM справляться с ними по-особому. когда сам экспериментировал с джава-кодом получал более чем десятикратное отставание, но задача была связана с очень активным использованием памяти, а на джаве я вряд ли пишу хорошо, но вот так.
да, перебирал на одной машине (причем лет 5 назад было, так что мощности соответствующие), а проценты от слитой, например с форума базы хешей. причем половина паролей подбирались буквально за пару минут.
в свое время, когда занимался UDC тоже использовал статистические методы. Считал декомпозицию паролей из большой базы (20 миллионов) на комбинации символов, идущие подряд, в зависимости от позиций, грубо — в начале, в середине, в конце.
затем перебирал словарь_начальных_комбинаций x словарь_средних_комбинаций^n x словарь_конечных_комбинаций. какие-то оптимизации, чтобы выкидывать повторные проверки не проводил, но в целом это позволяло «восстанавливать» до 75% паролей меньше чем за час.
не так: ntohl это network-to-host, перевод BigEndian в платформенный (обычно Little Endian) формат.
а есть еще и htonl (host-to-network), обратное преобразование. Так что «функционал» один и тот же, вопрос в красоте и удобстве, ну и, соответственно, в потерях скорости. А они есть даже относительно ntohl, и просто огромны относительно специфичных для платформы функций _byteswap_ulong, bswap,…
почти верно, циклы развернет, переменные заменит на константы и получится что-то вроде кода макроса htonl для конструктора или оператора присваивания и ntohl для оператора получения числового значения. Пока поленился лезть в асм, но на практике скорость выполнения в 2 раза хуже чем для конструкции out[u] = htonl(in[u]); (5.7с против 3.2)
или VS 2010 не такой уж современный компилятор?
идея понятна, реализация красивая, но скорость будет выше при использовании в нужных местах кучи макросов проверок и ntoh/hton-функций. конечно, если это критично.
Вопрос производительности все-таки не стоит забывать, да и операция «перестановки» байт в действительности редко вызывается, а вот всякие сравнения с таким operator const T() будут работать долго (а нужны часто). Не скажу, что совсем плохое решение, но специфическое.
2. вот с этим сложность. да, есть много замечательных программок-запоминалок, однако собрав все пароли в одном месте возникает другая опасность — кража хранилища вместе с мастер-пассвордом, например трояном. записывать на бумажке — тоже едва ли вариант.
+ все больше людей пользуются мобильными «помощниками» (планшеты, телефоны), набрать на которых 20+ случайных символов не так-то легко.
затем перебирал словарь_начальных_комбинаций x словарь_средних_комбинаций^n x словарь_конечных_комбинаций. какие-то оптимизации, чтобы выкидывать повторные проверки не проводил, но в целом это позволяло «восстанавливать» до 75% паролей меньше чем за час.
вот так получается с исправлением.
33296167; Time 1: 1841ms (BigEndian)
33296167; Time 2: 3276ms (htonl)
33296167; Time 3: 858ms (_byteswap_ulong)
неплохо, получается что вызов библиотечной функции и правда съедает много времени.
только для бенчмаркинга это совершенно не годится, здесь разница между версиями в 7 раз, когда на нормальной машине всего в 2.
а есть еще и htonl (host-to-network), обратное преобразование. Так что «функционал» один и тот же, вопрос в красоте и удобстве, ну и, соответственно, в потерях скорости. А они есть даже относительно ntohl, и просто огромны относительно специфичных для платформы функций _byteswap_ulong, bswap,…
соответственно авторская реализация: 5.2с
ntohl: 3.2
_byteswap_ulong: 0.8
под linux ntohl будет близок к _byteswap_ulong.
или VS 2010 не такой уж современный компилятор?
(580) (10) (38)(38) (46) (48)(48) (57) (46) (57) (1358)
а как хранить эти дескрипторы? на CUDA есть большая ограниченность в использовании любых сложных структур.
но, как бы честнее сказать, при написании кода я столкнулся с непреодолимыми трудностями (лень).