md5 в частности и хэширование вообще

gonza

Новичок
Автор оригинала: Tor
примерное время сортировки массива в студию, пожалуйста
При генерации шестизнаков и размере чанка в два гектара время генерации отсортированного множества хешей равно
(2048 * 512 * время генерации 2^48 хэшей)/число исполнителей.
Добавить сюда время сброса чанков на ленту.
Время можно получить обозримое - зависит от вычислительных мощностей. Простой алгоритм позволяет распараллелить на два, с ухищрениями - на любое число. Увеличим чанк - уменьшим время.
 

Tor

Новичок
сортировка от размера поледующего размера сохраняемой области не зависит

есть знающие люди? сортировку распараллелить можно?
 

gonza

Новичок
время генерации отсортированного множества хешей

Тут нужны читающие люди. Алгоритм генерации разжевать?
 

Tor

Новичок
Алгоритм генерации
отсортированного множества хешей
не сочтите за труд

-~{}~ 08.02.07 14:23:

(2048 * 512 * время генерации 2^48 хэшей)
и перевести в понятные большинству временные отрезки тоже
пожалуйста
 

gonza

Новичок
Простой алгоритм

На пальцАх...
Генерим первые хэши(по возрастанию паролей) до заполнения чанка.
Затем продолжаем генерить хэши, если попадается хэш меньше наибольшего в чанке - наибольший выбрасываем, вместо него вставляем текущий.
После полного прохода(2^48 хэшей) получаем чанк заполненный от минимального значения хэша(указанного в начале генерации чанка) подряд по возрастанию до заполнения чанка.
Наибольший хэш чанка+1 используем как минимальное значение для генерации следующего чанка.

В подробностях...
Код:
function make_chunk(min_hash){

	i=0;
	max_hash = 00 00 00 ... ;

//инициализация чанка

	while(i<chunk_size){

		if( (hash = next_hash()) >= min_hash) {
			insert(hash);
			if(hash > max_hash) max_hash = hash;
			i++;
		}

	}

	while( hash = next_hash() )

		if( hash <= max_hash) max_hash = smart_insert(hash);
		
	}
	save_chunk();
	return max_hash+1;
}

//тело  
	chunk_count = число чанков;
	min_hash = 00 00 00 ...;

	while(chunk_count--) min_hash = make_chunk(min_hash);
insert вставляет хэш в первое свободное место в чанке

smart_insert
если вставляемый хэш == наибольшему, возвращает его(в реализации с сохранением паролей сохраняет пароль соотв. вставляемому хэшу)
иначе текущий наибольший хэш отбрасывается, вместо него вставляемый. возвращаем наибольший хэш в чанке.

Таким образом для получения одного чанка необходимо сгенерить хэши от всех паролей(2^48 в нашем случае)

чанков при размере 2GB у нас 2048Pb/2Gb == 2048 *1024Gb/2Gb == 2048 * 512 - такое количество раз нам надо пройтись по всем паролям


Усложняем

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

Совсем усложняем

Запускаем первый процесс..
Функция smart_insert модифицирована - она не отбрасывает наибольший хэш при вставке а передает соседу. Сосед генерит соседний чанк. Это для генераторов по возрастанию. По убыванию передается наименьший хэш.
Передается функции smart_insert соседа. Если она видит что хэш ей не подходит - передает следующему соседу(слева/справа в зависимости от направления генерации)
Если соседа нет хэш отбрасывается...

Каждый следующий процесс сможет стартовать только после получения хэша от предыдущего соседа, так как это значение используется для стартового нижнего/верхнего порога. То есть после инициализации чанка предыдушим соседом, это недолго...
Первый процесс использует минимальное значение 00 00, максимальное ff ff ff

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

ps скобочку в коде не закрыл... подправил...
 

gonza

Новичок
Автор оригинала: Tor
на второй вопрос не ответил
Таким образом для получения одного чанка необходимо сгенерить хэши от всех паролей(2^48 в нашем случае)

чанков при размере 2GB у нас 2048Pb/2Gb == 2048 *1024Gb/2Gb == 2048 * 512 - такое количество раз нам надо пройтись по всем паролям


(2048 * 512 * время генерации 2^48 хэшей)
Что непонятно?
 

Tor

Новичок
и перевести в понятные большинству временные отрезки
что не понятно?
мне интересно, сколько лет займет твоя генерация?
сколько места при этом займет?
 

gonza

Новичок
Автор оригинала: Tor
мне интересно, сколько лет займет твоя генерация?
сколько места при этом займет?
Не тупи...

Для генерации одного чанка необходимо место для того что бы хранить его деревом :
http://www.williamspublishing.com/Books/sci_DataStructs.html

Время вычисления md5хэша, там же инкрементный подбор паролей
http://wasm.ru/comment.php?artcode=cycle_pwd
*время генерации 2^48 хэшей* зависит от числа машин в твоем распоряжении(да, это тоже распараллеливается!!!)

Общий объем базы уже озвучивался - с него вообще-то наше с тобой общение и началось...
 

Wicked

Новичок
еще один любитель работать со сферическими конями в вакууме... шикарно...

а получается, что md5 надо сгенерировать всего лишь
(2 ** 48) * 512 * 2048 раз, что на 1000 машинах, в условиях идеального распараллеливания, при скорости каждой машины в 1млн хэшей в секунду, займет всего то каких-то жалких 9359 лет.

gonza, садись, два.

-~{}~ 09.02.07 11:34:

gonza
Кстати, а такой матерый криптоаналитик, как ты, слышал хоть раз про rainbow tables? :)

-~{}~ 09.02.07 11:42:

И вообще, какие еще 2048Pb ?

rainbow table в комфортных условиях потребуют 3.5Тб, что достижимо для одного сервера. Правда генериться они будут довольно долго - наверное лет 10 на одной современной машине.
 

ilkz

Новичок
Подкину еще одну пищу для разговора. Все приведенные вами расчеты справедливы для полупроводниковых систем, у которых время дискретизации не превышает наносекунд.

Но в последнее время активно муссируется идея создания квантовых вычислительных систем. В одной из прошлогодних "Компьютерр" (в районе февраля-декабря) даже приводились расчеты вычислительной мощности таких систем. ЦИфры впечатляли - прирост производительности измерялся десятками порядков.

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

phprus

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

Wicked
rainbow table в комфортных условиях потребуют 3.5Тб
Это как и что вы собрались там хранить? Надо же хранить строки + md5 код от них, а большую часть места занимают именно строки, так что даже оценка в 2048Pb очень сильно занижена.
 

phprus

Moderator
Команда форума
Wicked
Ознакомился.
Похоже что ваша оценка в 3.5Тб является правильной.
 

gonza

Новичок
Автор оригинала: Wicked
еще один любитель работать со сферическими конями в вакууме... шикарно...

а получается, что md5 надо сгенерировать всего лишь
(2 ** 48) * 512 * 2048 раз, что на 1000 машинах, в условиях идеального распараллеливания, при скорости каждой машины в 1млн хэшей в секунду, займет всего то каких-то жалких 9359 лет.
Да не люблю я работать с конями.. Если ты внимательно перечитаешь, может поймешь таки что я вначале показал создателю треда что его мысль реализуема не более чем на шестисимвольных паролях
Потом высказал мысль что можно использовать ленты - Тора это сильно обидело... Тебя обидела мысль генерить хеши многократно - не обижайся. Я эти мысли высказывал не как агитацию проекта. Просто показываю что технически это осуществимо на данный момент развития индустрии.
1000 машин - это мало. Ботнеты по 100k уже никого не удивляют, а примерно 13-15 ботнетов даст миллион машин(с учетом того что часть машин может быть в нескольких ботнетах) Десяток ботнетов можно найти(выйти на людей имеющих к ним отношение) одним запросом в поисковике...
В общем злые вы и обидчивые :D Это все от слабости...


rainbow table - не знал - сейчас читаю, вникаю... Спасибо..

-~{}~ 09.02.07 12:54:

Автор оригинала: phprus
Надо же хранить строки + md5 код от них, а большую часть места занимают именно строки, так что даже оценка в 2048Pb очень сильно занижена.
эээ.. Вообщето речь шла строго о шести символьных паролях, так что хэш таки поболее будет. А оценка да, занижена. Гдето в полтора раза...
 
Сверху