Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, funikov, Вы писали: F>>Я бы заценил, если бы было обоснование что время подбора 1000(например) придуманных людьми паролей вашим методом существенно меньше чем обычным перебором. Нудиратор меня не покорил. __>Для проведения хорошего теста нужен набор паролей, которому можно доверять. Поэтому я вчера достал базу паролей, которые недавно сперли из вконтакта. Пытаться проверять все подряд пароли — нужно многое дописывать, ни цифер, ни регистра алгоритм пока не понимает. для паролей же типа qwerty или asdcxz нужны другие деревья, перебор с текущими деревьями будет скорее всего медленнее брутфорса и пробовать даже не стоит. в реале стоит запускать параллельно несколько экземляров брутфорса с разными деревьями. одни — русские, второй — русские набранные в другой раскладке, третьи — ... __>Зато прямо сейчас можно оценить насколько эффективен будет алгоритм на классе паролей, созданных из маленьких русских букв. (да, это не есть широкой класс, но любой другой пароль тоже в некоем классе находится, их немного, и там же картина, скорее всего, не отличаться принципиально). Для чистоты эксперимента я стал подряд просматривать все пароли, которые попадают в этот класс, не выкидывая какие-либо, не добавляя свои, не меняя регистр и символы в них вообще. Любой человек это может проделать и получит набор паролей именно в том же порядке, в котором они приведены в таблице. __>Таблица — <пароль> <миллионов итераций этим алгоритмом> <миллионов итерация брутфорсом 32 символьным (без ё)> <отношение второго к первому> __>во втором столбце после некот паролей написано — "посчит" — значит, кол-во итерация точно, иначе — оценка с погрешностью (обычно процентов 20)
__>не знаю я, как сделать красиво табличку, пусть будет так. __>
Ну ок, вы выделили один класс, почти убедили что для этого класса этот подход ок. А как насчет других классов? Как часто этот и другие классы встречаются в спертой базе паролей? Еще интересно что будет стоить неудача при подборе пароля неподходящей стратегией.
Re: Зацените идею существенного ускорения брутфорса
О!!! Два самых популярных слова на КУ — БОЯН и ЛОПАТА добрались до алгоритмов.
Критиков нафиг.
Как минимум это интересно. Меня, например, не настолько интересует брутефорс, чтобы я искал
специализированные алгоритмы и всматривался в них.
А хорошо изложенный материал да ещё с готовыми исходниками почитать всегда интересно.
Комментарии по алгоритму пока не пишу, надо смотреть код.
Пока ИМХО, основанное на интуиции.
1. Учить надо на базе паролей, а не на "Войне и Мир". Или в первую очередь на базе паролей, а потом на "Войне и Мир".
2. Деление по алфавиту кажется злом, лучше сразу закладываться на весь допустимый набор символов.
3. Подпорки для анализа пробелов, цифр, спец. символов имхо тоже зло. Объективный фактор только один — частота.
4. Позиционность. Или я чего-то не понимаю или она у вас есть. А слово на х"№, простите, часто встречается в паролях в абсолютно разной позиции.
Насчёт полезности и сомнительности.
Во первых можно найти применение в других алгоритмах, кроме брутефорса.
Во вторых позволяет по другому оценить стойкость своих паролей и алгоритмов аутентификации вообще.
Так что польза есть.
Re[4]: Зацените идею существенного ускорения брутфорса
От:
Аноним
Дата:
05.08.09 08:06
Оценка:
Всё это очень замечательно в теории, а что на практике? На днях "добрые" люди выложили в открытый доступ несколько тысяч пар логин:пароль не то из вконтактика, не то из одноклассников. Как оно на них работает?
Re[5]: Зацените идею существенного ускорения брутфорса
Здравствуйте, Аноним, Вы писали:
А>Всё это очень замечательно в теории, а что на практике? На днях "добрые" люди выложили в открытый доступ несколько тысяч пар логин:пароль не то из вконтактика, не то из одноклассников. Как оно на них работает?
нормально см. мой предыдущий пост
Re: Зацените идею существенного ускорения брутфорса
От:
Аноним
Дата:
05.08.09 19:41
Оценка:
Вообще, очевидно, что архивация-деархивация здесь избыточна, так как перебрать пароли, упорядоченные по вероятностям, можно и без всяких архиваций-деархиваций.
Но вы со своей архивацией сделали такую странную нетривиальную вещь, что я немного сломал себе мозг, рассуждая о том, как это на самом деле работает.
Ведь алгоритм Хаффмана генерирует префиксные коды.
А перебираете вы все коды подряд до N бит, которых, очевидно, больше, чем префиксных до этих же N bit.
Очевидно, здесь должна быть (двукратная?) избыточность, но как именно она должна проявляться, что-то я на ночь глядя не могу сообразить.
Генерируемые пароли будут повторяться?
Кстати, такой вопрос: как вычислить вероятность пароля, зная вероятности его компонентов?
Кто сказал, что деархивация бинарного кода кодом Хаффмана упорядочивает пароли правильно?
Re[2]: Зацените идею существенного ускорения брутфорса
Здравствуйте, Аноним, Вы писали:
А>Вообще, очевидно, что архивация-деархивация здесь избыточна, так как перебрать пароли, упорядоченные по вероятностям, можно и без всяких архиваций-деархиваций.
возможно, можно. но как? я не знаю как еще. откуда мы знаем какой пароль имеет большую вероятность? анализ вероятности его частей? а как мы учтем вероятность сочитаниях этих частей? а как еще и длинну сюду приплетем?
А>Но вы со своей архивацией сделали такую странную нетривиальную вещь, что я немного сломал себе мозг, рассуждая о том, как это на самом деле работает. А>Ведь алгоритм Хаффмана генерирует префиксные коды. А>А перебираете вы все коды подряд до N бит, которых, очевидно, больше, чем префиксных до этих же N bit. А>Очевидно, здесь должна быть (двукратная?) избыточность, но как именно она должна проявляться, что-то я на ночь глядя не могу сообразить.
да, примерно двухкратная избыточность. Допустим генерируем пароль на основе
010101
01010 это, допустим, "ка"
1 — это не лист дерева, листья внизу, нам нужны биты еще. то есть информации недостаточно для генерации пароля. Эта информация примерно означает "ка[н или п или т]" и мы такой пароль __пропускаем__ за недостаточностью информации. То есть никакой избыточности реально нет. Это "холостая" итерация. в коде так и делается. потом у нас все равно эти биты появятся и мы обязательно проверим и "кан" и "кап" и "кат".
А>Генерируемые пароли будут повторяться?
нет. Теоретически — нет (это все разные обходы деревьев, повторяющихся листьев нет -> пароли разные при разных обходах), практически — такое возможно только из-за ошибок реализации. В коде есть закоментенные куски, где я запоминал все пароли, затем сортировал их в лексикографическом порядке, потом, в конце, печатал. такой вид паролей позволяет оценить, насколько "плотно" они идут и нет ли среди них повторов.
А>Кстати, такой вопрос: как вычислить вероятность пароля, зная вероятности его компонентов?
вот-вот Это все к вопросу о "перебрать пароли, упорядоченные по вероятностям, можно и без всяких архиваций-деархиваций". одних вероятностей компонентов мало, нужно учитывать кол-во этих компонентов и вероятности сочетания их. в общем, никак.
А>Кто сказал, что деархивация бинарного кода кодом Хаффмана упорядочивает пароли правильно?
Все это исходит из того, что более вероятные пароли содержат меньше информации и ужимаются сильнее менее вероятных.
Re[2]: Зацените идею существенного ускорения брутфорса
Здравствуйте, Шебеко Евгений, Вы писали: ШЕ>1. Учить надо на базе паролей, а не на "Войне и Мир". Или в первую очередь на базе паролей, а потом на "Войне и Мир".
нет. паролей мало и часто с цифрами или уже слепленные в слова. Даже в таком случае — их сначала надо их разбить на классы, а не просто пускать по всем паролям
ШЕ>2. Деление по алфавиту кажется злом, лучше сразу закладываться на весь допустимый набор символов.
вот допустим мы хорошо научились подбирать пароли из английских слов. можно "натренировать" чтобы одновременно подбирались также пароли набранные русскими словами в англ раскладке, символы-то те же вроде? но место этого он будет плохо подбирать и то и другое. сначала нужно определиться в каком классе находится пароль и отдельно пускать проверку того и того — с разными деревьями.
вот классы которые я могу выделить на небольшом анализе первых 242 паролей в "всем известной базе". 242 — мало, и анализ очень поверхностный, но, поверьте, это очень муторно
английские -
мал 12 5%
с больш 1 0.5%
с цифр 6 2.5%
цифр+больш 1 0.5%
сумма 20 8.2%
клава-фигурные
сумма 30 12%
прочие
сумма 33 14%
русские
англ раскладка 9 3.7%
раскладка+цифры 4 1.6%
раск+цифр+рег 1 0.5%
мал 17 7%
с цифрами 12 5%
цифр+регистр 3 1.2%
регистр 4 1.6%
сумма 50 20%
транслит
мал 12 5%
больш 4 1.6%
+спецсимв 2 0.8%
+раскл+цифры 3 1.2%
+цифры 27 11% (3 под вопросом)
сумма 48 20%
цифрами
сумма 61 25% (1 под вопросом и непонятно где боты)
общ сумма 242
ШЕ>3. Подпорки для анализа пробелов, цифр, спец. символов имхо тоже зло. Объективный фактор только один — частота.
Да и мне подпорки не нравиятся, но если просто в лоб — то частота чего? насколько часто после буквы "а" идет цифра "1"? Это ничем нам не поможет. вот, скажем, насколько часто после слова идет цифра. Это да, но это опять подпорки.
ШЕ>4. Позиционность. Или я чего-то не понимаю или она у вас есть. А слово на х"№, простите, часто встречается в паролях в абсолютно разной позиции.
слепление слов, учет "корректности конца слова" и прочее — в конкретно этой реализации не производится. это опять же муторные подпорки.
Re[3]: Зацените идею существенного ускорения брутфорса
ШЕ>>1. Учить надо на базе паролей, а не на "Войне и Мир". Или в первую очередь на базе паролей, а потом на "Войне и Мир". __>нет. паролей мало и часто с цифрами или уже слепленные в слова. Даже в таком случае — их сначала надо их разбить на классы, а не просто пускать по всем паролям
Да, ладно забыли. Это мои интуитивные идеи. Они скорее всего неверные.
Код смотрел вполне читаемо, на выходных постараюсь его осознать.
Тогда можно будет давать более взвешенные комментарии.
Re[2]: Зацените идею существенного ускорения брутфорса
Здравствуйте, Аноним, Вы писали:
А>Вообще, очевидно, что архивация-деархивация здесь избыточна, так как перебрать пароли, упорядоченные по вероятностям, можно и без всяких архиваций-деархиваций.
Так проще.
А>Ведь алгоритм Хаффмана генерирует префиксные коды.
А>А перебираете вы все коды подряд до N бит, которых, очевидно, больше, чем префиксных до этих же N bit.
А>Очевидно, здесь должна быть (двукратная?) избыточность, но как именно она должна проявляться, что-то я на ночь глядя не могу сообразить.
В N битах получится N/8 ASCII символов или -N/log2(average_prob) символов модели.
А>Генерируемые пароли будут повторяться?
Нет.
А>Кто сказал, что деархивация бинарного кода кодом Хаффмана упорядочивает пароли правильно?
Она их упорядочивает по степени вероятности появления в исходной модели. Это правильное упорядочение, если мы считаем, что наша модель правильна.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Зацените идею существенного ускорения брутфорса
От:
Аноним
Дата:
08.08.09 06:23
Оценка:
А>>Вообще, очевидно, что архивация-деархивация здесь избыточна, так как перебрать пароли, упорядоченные по вероятностям, можно и без всяких архиваций-деархиваций.
T>Так проще.
Проще по сравнению с каким алгоритмом?
T>В N битах получится N/8 ASCII символов или -N/log2(average_prob) символов модели.
Это не из той оперы. Модель здесь не влияет. Количество всех возможных префиксных кодов, составленных из N bit равно половине всех возможных кодов из N bit.
В реальности избыточность будет еще несколько больше, ибо размер словаря, скорее всего, не будет кратен степени двойки.
А>>Генерируемые пароли будут повторяться?
T>Нет.
Таки да, но автор убирает повторяющиеся пароли (убирая пароли, у которых последний символ не раскодируется).
А>>Кто сказал, что деархивация бинарного кода кодом Хаффмана упорядочивает пароли правильно?
T>Она их упорядочивает по степени вероятности появления в исходной модели. Это правильное упорядочение, если мы считаем, что наша модель правильна.
Символ Частота Код
пробел 7 111
a 4 010
e 4 000
f 3 1101
h 2 1010
i 2 1000
m 2 0111
n 2 0010
s 2 1011
t 2 0110
l 1 11001
o 1 00110
p 1 10011
r 1 11000
u 1 00111
x 1 10010
Например, пробел имеет частоту 7 и код 111, буква a имеет частоту 4 и код 010.
В порядке перебора всех бинарных кодов код 010 будет идти перед кодом 111, что неверно.
Код Символ Частота
000 e 4
001
010 a 4
011
100
101
110
111 пробел 7
Что и требовалось доказать.
(Кстати зацените избыточность перебора: чтобы извлечь три символа, мы перебрали восемь кодов.)
Re[4]: Зацените идею существенного ускорения брутфорса
Здравствуйте, Аноним, Вы писали: А>В реальности избыточность будет еще несколько больше, ибо размер словаря, скорее всего, не будет кратен степени двойки. А>>>Генерируемые пароли будут повторяться? T>>Нет. А>Таки да, но автор убирает повторяющиеся пароли (убирая пароли, у которых последний символ не раскодируется).
Это "холостая" избыточность, "внутренняя" — издержки генерации. Выдаваемые алгоритмом пароли не повторяются, самое главное, что долгая операция вычисления хэша или попытки раскодировать с таким паролем никогда не будет вызвана для одинаковых паролей.
А>Да как бы нет. Простейший контрпример (взят из «Википедии»): А>Например, пробел имеет частоту 7 и код 111, буква a имеет частоту 4 и код 010. А>В порядке перебора всех бинарных кодов код 010 будет идти перед кодом 111, что неверно.
кстати, клевая идея! можно переупорядочить все ветки так, чтобы левые, кодируемые нулем, были всегда тяжелее правых.
Re[5]: Зацените идею существенного ускорения брутфорса
Здравствуйте, __kot2, Вы писали: А>>Да как бы нет. Простейший контрпример (взят из «Википедии»): А>>Например, пробел имеет частоту 7 и код 111, буква a имеет частоту 4 и код 010. А>>В порядке перебора всех бинарных кодов код 010 будет идти перед кодом 111, что неверно. __>кстати, клевая идея! можно переупорядочить все ветки так, чтобы левые, кодируемые нулем, были всегда тяжелее правых.
попробовал эту идею. интересно, что она ни дала выигрыша __ни на одну итерацию__. Вообще никакого. одинаково что так, что по-старому. А вот если наоборот поганить жизнь алгоритму — переупорядочивать ветки в обратном порядке, то скорость сильно падает — раза в два примерно.
Re[6]: Зацените идею существенного ускорения брутфорса
Здравствуйте, __kot2, Вы писали: __>попробовал эту идею. интересно, что она ни дала выигрыша __ни на одну итерацию__. Вообще никакого. одинаково что так, что по-старому. А вот если наоборот поганить жизнь алгоритму — переупорядочивать ветки в обратном порядке, то скорость сильно падает — раза в два примерно.
кстати, интересно, что практически двойная случайность построение деревьев случайно оказалось таким, что ветка b всегда оказывается тяжелее a, и в переборе ветка b случайно проверяется ранее a в общем — да, важный момент.
Re: Зацените идею существенного ускорения брутфорса
Здравствуйте, __kot2, Вы писали:
__>Появилась интересная идея полного перебора паролей, но не в лексикографическом, а в другом порядке. Хочу услышать чужие комментарии по этой теме.
Ну все... с этого дня все свои пароли начинаю с комбинации Ыь...
А вот зайца кому, зайца-выбегайца?!
Re[4]: Зацените идею существенного ускорения брутфорса
Здравствуйте, Аноним, Вы писали:
А>>>Вообще, очевидно, что архивация-деархивация здесь избыточна, так как перебрать пароли, упорядоченные по вероятностям, можно и без всяких архиваций-деархиваций.
T>>Так проще.
А>Проще по сравнению с каким алгоритмом?
Прошу прощения, действительно, есть алгоритм проще. Надо просто считать текущую длину в битах текущего набора символов в текущей модели.
T>>В N битах получится N/8 ASCII символов или -N/log2(average_prob) символов модели. А>Это не из той оперы. Модель здесь не влияет. Количество всех возможных префиксных кодов, составленных из N bit равно половине всех возможных кодов из N bit.
Прошу доказательства.
А>В реальности избыточность будет еще несколько больше, ибо размер словаря, скорее всего, не будет кратен степени двойки.
А и не надо. Есть арифметическое кодирование.
А>>>Генерируемые пароли будут повторяться? T>>Нет. А>Таки да, но автор убирает повторяющиеся пароли (убирая пароли, у которых последний символ не раскодируется).
Опять же, потребую доказательства.
А>>>Кто сказал, что деархивация бинарного кода кодом Хаффмана упорядочивает пароли правильно? T>>Она их упорядочивает по степени вероятности появления в исходной модели. Это правильное упорядочение, если мы считаем, что наша модель правильна. А>Да как бы нет. Простейший контрпример (взят из «Википедии»):
А>
А>Например, пробел имеет частоту 7 и код 111, буква a имеет частоту 4 и код 010.
А>В порядке перебора всех бинарных кодов код 010 будет идти перед кодом 111, что неверно.
А>
А>Код Символ Частота
А>000 e 4
А>001
А>010 a 4
А>011
А>100
А>101
А>110
А>111 пробел 7
А>
А>Что и требовалось доказать.
Исправляется тривиально: меняем все единички на нолики и всё в порядке.
Дополню: для кодирования Хаффмана что пробел, что "e" в этой модели эквивалентны. Если ты возьмешь арифметическое кодирование, то все указанные тобой проблемы исчезнут.
А>(Кстати зацените избыточность перебора: чтобы извлечь три символа, мы перебрали восемь кодов.)
Если не раскодировать, а просто использовать предсказания по модели — можно и высшего порядка, — то таких проблем не будет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Зацените идею существенного ускорения брутфорса
Здравствуйте, thesz, Вы писали:
А>>>>Генерируемые пароли будут повторяться? T>>>Нет. А>>Таки да, но автор убирает повторяющиеся пароли (убирая пароли, у которых последний символ не раскодируется). T>Опять же, потребую доказательства.
я действительно отбрасываю некоторые пароли, потому как не все битовые последовательности доходят до листьев. я вот только понять не могу, почему на это внимание обращается.
T>Если не раскодировать, а просто использовать предсказания по модели — можно и высшего порядка, — то таких проблем не будет.
а можно поподробнее, что за идея?
Re[6]: Зацените идею существенного ускорения брутфорса
T>>Если не раскодировать, а просто использовать предсказания по модели — можно и высшего порядка, — то таких проблем не будет. __>а можно поподробнее, что за идея?
У тебя есть модель, которая предсказывает вероятность появления очередного символа a = P(a,c) по его контексту c (предыдущим символам c[j], 0 <= j < N, N — порядок модели).
Твой вариант с Хаффманом имеет порядок модели 0, кстати. PPM* (Prediction by Partial Matching разных разновидностей, на RSDN есть эксперт Bulat Ziganshin) может работать с моделями бОльших порядков, соответственно, более точными.
К тому же Хаффман даёт приближённое предсказание — для текста "aaaaaaab" длина кодовой последовательности будет 1 и для 'a', и для 'b'. Тогда как их можно закодировать 0.1926 битов и 3 бита соответственно (0.1926*7+3)=4.35 бит, практически пять битов, а не восемь.
По вероятности появления символа мы можем оценить занимаемую им длину битовой последовательности: Li=-log2(P(ai,ci)). Таким образом, мы можем посчитать суммарную длину сгенерированного пароля без процесса кодирования или декодирования.
Вот строки для модели порядка 0 по тексту "aaaaaaab" с длиной между 3 и 4 битами:
[(3.0,"b"),(3.192645077942396,"ab"),(3.192645077942396,"ba")
,(3.3852901558847917,"aab"),(3.3852901558847917,"aba"),(3.3852901558847917,"baa")
,(3.5779352338271875,"aaba"),(3.5779352338271875,"abaa")
,(3.5779352338271875,"baaa"),(3.577935233827188,"aaab"),(3.7705803117695833,"aabaa"),(3.7705803117695833,"abaaa")
,(3.7705803117695833,"baaaa"),(3.7705803117695837,"aaaab")
,(3.7705803117695837,"aaaba"),(3.963225389711979,"aabaaa")
,(3.963225389711979,"abaaaa"),(3.963225389711979,"baaaaa")
,(3.9632253897119796,"aaaaab"),(3.9632253897119796,"aaaaba")
,(3.9632253897119796,"aaabaa")]
Надеюсь, развлёк.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Зацените идею существенного ускорения брутфорса
Здравствуйте, thesz, Вы писали: T>По вероятности появления символа мы можем оценить занимаемую им длину битовой последовательности: Li=-log2(P(ai,ci)). Таким образом, мы можем посчитать суммарную длину сгенерированного пароля без процесса кодирования или декодирования.
мощно
Re[4]: Зацените идею существенного ускорения брутфорса
Ну наконец-то рассмотрел во всех подробностях и с отладчиком.
Теперь можно умничать
1. Ограниченность применения.
Ну все уже обсосали.
Эффективно можно применять только для подбора несуществующих слов.
Только на одном языке, в одном регистре, без цифр, спец. символов и т.д.
Ну ок, давайте рассматривать в этом контексте.
Действительно достаточно паролей, попадающих под эти условия.
2. Ошибка в сборе статистики.
У нас есть деревья 3х уровней: 0,1,2
Пароли подбираются как:
мама мыла раму
0122 2222 2222
А "Война и мир" анализируется как:
мама мыла раму
0120B1201B2012
По логике надо так:
мама мыла раму
0122B0122B0122
[code]
3. Критерий оценки алгоритма.
Могу предложить следующий критерий.
Из того же словаря анализировать частоты целых слов.
Если отсортировать эти слова по частоте, то
в идеале мы должны получить такой же порядок как при переборе.
Чем ближе мы к этому идеалу, тем лучше алгоритм.
4. Причём тут Хаффман?
Странное ощущение, что алгоритм Хаффмана не нужен, возникало не только у меня.
В попытках от него избавится, всё же должен признать, что это оригинальное решение и,
наверное, даже самое лучшее.
Но не единственное.
Можно найти другую меру оценки "одинаковости" пароля.
Например, можно по сумме нормированных частот.
Наша норма будет М.
Частоты преобразуем вот так:
k=М-k/SUM(k)*М
if(k==0)k=1;
К примеру М=30
tree0
a=3000 a=23
b=5000 --> b=18
c=4000 c=20
.....
tree2(aa)
a=0 a=30
b=10 --> b=20
c=20 c=10
tree2(ab)
a=10 a=1
b=0 --> b=30
c=0 c=30
Все элементы всех tree2 сортируем:
aba=1
aac=10
aab=20
aaa=30
abb=30
abc=30
У вас в переборе вы при переходе на "следующий уровень" инкрементируете к-во бит.
А тут прибавляете к числу min(k) из всех деревьев.
Только развёртывать слово надо с конца:
Допустим мы на некотором уровне N=100
Перебираем наши элементы tree2.
Далее спускаемся к началу пока не упрёмся в 0.
Будет проблема, что с некоторыми комбинациями мы будем проскакивать начало, ну значит за такое N,
такое слово собрать нельзя.
Уменьшая М, можно сжимать критерий оценки -> увеличивать скорость
Re[5]: Зацените идею существенного ускорения брутфорса
Здравствуйте, Шебеко Евгений, Вы писали: ШЕ>1. Ограниченность применения. ШЕ>Ну все уже обсосали. ШЕ>Эффективно можно применять только для подбора несуществующих слов.
ну, существующие тоже неплохо находит. хотя да, тут словарь эффективнее.
ШЕ>Только на одном языке, в одном регистре, без цифр, спец. символов и т.д. ШЕ>Ну ок, давайте рассматривать в этом контексте. ШЕ>Действительно достаточно паролей, попадающих под эти условия.
ШЕ>2. Ошибка в сборе статистики. ШЕ>У нас есть деревья 3х уровней: 0,1,2
да, есть такое стыки слов существенно увеличивают сложность пароля. я думаю это решится если добавить символ пробела и невидимый символ разрыва слов.
ШЕ>3. Критерий оценки алгоритма.
клевая идея. можно добавить вычисление этой эффективности.
ШЕ>4. Причём тут Хаффман? ШЕ>Странное ощущение, что алгоритм Хаффмана не нужен, возникало не только у меня.
да, например мне нравится идея арифметического кодирования. А если брать другие алгоритмы сжатия без потерь — там в основном расчет на сжатие повторов, чего в словах особо то и нет.
мне еще очень нравится идея расширить буквенный алфивит слогами. буквенно-слоговый алфавит сделать или что-то в этом районе. слога брать из букваря за 1ый класс
ШЕ>Можно найти другую меру оценки "одинаковости" пароля. ШЕ>Например, можно по сумме нормированных частот.
да, вариант. но, насколько я понял, его минус — нужно в памяти хранить кучу еще не обработанных до конца паролей.
см. мой предыдущий пост
