Торвальдс заодно с АНБ

до первого зафиксированного момента использования подбираемого ключа.

И как же это фиксируется?

ключи SSH например, генерируются при первом старте системы, после инсталляции. Так что период 5-10 лет брать не нужно. Если рассматривать ключ от SSL сертификата, то можно предположить, что он сгенерирован в день отправки запроса на сертификат, ну или за 1-2 недели до этого максимум, а этот момент можно установить точно, либо запросив соответствующий CA, либо из перехваченного трафика. И можно перебирать все значения времени в обратном порядке

из перехваченного и записанного трафика

ключи SSH например, генерируются при первом старте системы, после инсталляции.

С чего это?

из перехваченного и записанного трафика

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

С чего это?

а когда их ещё создавать? Ну можно ещё потом вручную, но обычно init скрипт генерирует ключи, когда видит их отсутствие в /etc/ssh/

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

Ну если именно за тобой следят в течение долгого времени, то и весь твой трафик писать будет не проблематично.

Хотя вон в документах Сноудена было что Британия чуть ли не весь проходящий через страну трафик за последние 3 дня сохряняет, так что не надо надеятся, что заранее собирать никто не будет :)

у серверов мышки не бывает обычно, и дёргать нечего :)

You should never create keys or even use GnuPG on a remote system // http://www.gnupg.org/faq/GnuPG-FAQ.html#it-really-takes-long-when-i-work-on-a...

Генерь ключи локально, и если они так уж нужны на твоём сервере — залей туда уже готовые.

Не узнаю ЛОР. Вторая страница, а никто Розенталем не грозился.

Это я, а если всем миром, то быстрее. И желательно еще его не обновлять. Супер-стабильный релиз.

Вторая страница, а никто Розенталем не грозился

К 3й мне подарили ebook с DRM. Поправил.

для этого IP пакеты сначала должны приходить

В идеально спокойной сети гоняются тысячи служебных пакетов. Поснифай ради интереса

приблизительно знать диапазоны значений, которые добавляются в пул рандома

приблизительно

Вот это плохо сочетается с криптографией

В идеально спокойной сети гоняются тысячи служебных пакетов. Поснифай ради интереса

и что, сетевая карта дёргает прерывания на не предназначенные ей пакеты? И какие-такие служебные пакеты должны приходить в идеально спокойной сети? Разве что ARP запросы

Разве что ARP запросы

Да, чем они плохи. Там могут еще и другие служебные вещи летать подобного рода.

и что, сетевая карта дёргает прерывания на не предназначенные ей пакеты?

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

Именно. А ты на это «ничего не означает» полагаешься в вопросах безопасности

а есть что-то, на что можно полагаться? Ну рассказывай, а то я-то не в курсе...

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

тебе ключ зачем нужен? Данные шифровать? Так, что-бы их НИКТО не прочитал кроме адресата? Или для прикола? Если для прикола, то да, можешь генерить как хочешь.

Но я-бы рекомендовал начать с более простых вещей,

И до них дойдёт.

слово «начать» тебе непонятно? Просто иначе до тебя ничего не дойдёт. Это как изучать преобразования Лапласа не зная про таблицу умножения.

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

угу. И какой в этом смысл, расскажешь?

Доказать может быть практически даже невозможно. Например, попробуй докажи предсказуемость знаков числа . Ты конечно, можешь догадаться, что это знаки пи, но без такой догадки не докажешь.

легко докажу: просто ПРЕДСКАЖУ. Напишу программу, которая считает знаки числа пи, и буду их тебе называть. Ну и будем делать ставки: если я ошибусь, то я тебе N баксов, а если угадаю — ты мне. Очевидно, ты очень быстро станешь нищим, ибо число пи я могу вычислить с любой нужной(в данном случае) точностью.

Но в данном случае Линус Торвальдс прав - даже если там есть предсказуемость, в Linux эта инструкция используется как один из источников энтропии, а не единственный, если я правильно понял.

ты всё правильно понял: естественно, это один из дополнительных источников энтропии. И по твоему для этого нужно такой жёлтый бред в заголовке писать?

Стандартный генератор ПСЧ, который изучен Кнутом ещё полвека назад, даёт вполне предсказуемые последовательности. Ну и что? Достаточно провести над ним несложные преобразования, и последовательность станет непредсказуемой (например можно посолить неизвестной солью, и взять md5. Давай, рассказывай, как ты такое будешь предсказывать?). Если вместо стандартного генератора ПСЧ взять RDRAND, то результат получится ещё лучше. Даже если эта ваша RDRAND не вполне идеальна.

тебе ключ зачем нужен? Данные шифровать?

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

Ещё раз - на большом кластере ( хотя бы десятки тысяч узлов ) непрерывно генерить ключи. Не ПОДБИРАТЬ, глухой ты наш, а генерить. Любые ключи. И сохранять. Через пару лет собрать открытые ключи из CA и посмотреть, а не нагенерили ли мы случайно закрытый ключ для этого открытого. Не подобрали, [censored], а СЛУЧАЙНО сгенерили.

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

Спасибо, твоё мнение очень важно для меня. Зафрендил

С ним понятно, но напрямую не очень логично его дергать, лучше читать /dev/random или /dev/urandom

конечно лучше. Кто спорит?

Фишка в том, что без RDRAND используется хорошо изученный генератор ПСЧ, который предсказуем, а вот RDRAND _может_ быть предсказуема, да и то, только неким гипотетическим ZOG'ом(в отличие от ПСЧ, которую может угадать даже emulek).

Предсказывать случайные числа это предсказать какое число будет после X основываясь на знаниях о Х, а как узнать Х непонятно.

ну обычно в качестве X0 берётся время. Узнать время может быть несложно. Ну можно скажем atime исполняемого файла посмотреть. Ну и вообще, алгоритм-то нам известен. А значит и X0 тоже как-то узнать можно. Откуда, зная алгоритм, можно узнать и нужное X.

Ты когда рандомом пользуешься он тебе разные значения выдает или постоянно одно и то же (Х)?

одно и тоже. Сам попробуй:

$ RANDOM=17
$ echo $RANDOM 
23575
$ RANDOM=17
$ echo $RANDOM 
23575
$ RANDOM=17
$ echo $RANDOM 
23575

т.е. если RANDOM сбросить (help unset), то она всегда будет одно и тоже печатать.

$ RANDOM=17
$ echo $RANDOM 
17
$ echo $RANDOM 
17
$ echo $RANDOM 
17

Over9000 миллиардов лет чем-то лучше 100500 миллиардов

Линк на статистику подтверждающую это высказывание фстудию.

возьми, и посчитай.

Hint: man bc, обычный калькулятор ТАКИЕ числа не берёт.

Школоло?

ты?

Во-первых, жили как-то до ivy bridge и рандом юзали,

плохо жили. Попробуй скачать хотя-бы мегабайт энтропии из /dev/random. Сомневаюсь, что доживёшь.

во-вторых, ты так и не понял мою позицию по данному вопросу.

ты её и не обозначил. А вот обзываться ты умеешь, да.

2^2048 - это десятичное число, длиной под ~620 знаков (по моим грубым прикидкам).

ещё один не осиливший калькулятор. Лови:

2^2048
32317006071311007300714876688669951960444102669715484032130345427524\
65513886789089319720141152291346368871796092189801949411955915049092\
10950881523864482831206308773673009960917501977503896521067960576383\
84067568276792218642619756161838094338476170470581645852036305042887\
57589154106580860755239912393038552191433338966834242068497478656456\
94948561760353263220580778056593310261927084603141502585928641771167\
25943603718461857357598351152301645904403697613233287231227125684710\
82020972515710172693132346967854258065669793504599726835299863821552\
51663894373355436021354332296046453184786049521481935558536110595962\
30656

Т.е. если на отрезве 0 до 2^2048 чисел будет 2^2000 или даже 2^1900 простых чисел, тебя это устроит?

меня — устроит. Пусть даже если всего 2^1000. Один хрен — не доживёшь ты.

К тому же реализация алгоритма перевода сгенерированного числа в пароль неизвестна

это азы, детка. Ликбез тут: http://ru.wikipedia.org/wiki/Принцип_Керкгоффса (правило №2)

с таким подходом лучше сразу удавиться

ну так кто тебе мешает это сделать?

я же предпочту если и подмешивать rdrand, то точно не под конец тупым ксором, а лучше ну его нафиг вообще

ещё один не осиливший калькулятор.

специальная, точная версия. Если мои грубые прикидки неустраиваеют

>>> len(str(2**2048)) 617

617 => ~620

О, да, а мне бы очень хотелось увидеть боевичок в стиле «Торвальдс против АНБ»

А взять и проверить? Мало, чтоль, методов анализа случайных последовательностей?

Логично, что туде зашьют что-то, что проходит известные тесты.

А вообще, /dev/random для криптографических целей будет использовать только идиот, так что все и так неплохо.

Логично, что туде зашьют что-то, что проходит известные тесты.

Придумать нечто, что проходит все известные тесты и при этом даёт достаточный процент контроля выдаваемых значений — достаточно нетривиальная задача.

/dev/random для криптографических целей будет использовать только идиот

расскажи мне, умный ты наш, что вместо /dev/random юзать? Свой кривой велосипед лучше, да?

легко докажу: просто ПРЕДСКАЖУ. Напишу программу, которая считает знаки числа пи, и буду их тебе называть. Ну и будем делать ставки: если я ошибусь, то я тебе N баксов, а если угадаю — ты мне. Очевидно, ты очень быстро станешь нищим, ибо число пи я могу вычислить с любой нужной(в данном случае) точностью.

Для этого тебе надо сначала ДОГАДАТЬСЯ, что речь идет о числе пи. Без этого ты такой программы не напишешь.

Если вместо стандартного генератора ПСЧ взять RDRAND, то результат получится ещё лучше. Даже если эта ваша RDRAND не вполне идеальна.

О чем и речь.

Придумать нечто, что проходит все известные тесты и при этом даёт достаточный процент контроля выдаваемых значений — достаточно нетривиальная задача.

Да придумывать ничего не надо. Любой хороший криптографический ГПСЧ удовлетворяет этим тестам. А неизвестный инициализирующий вектор делает для стороннего исследователя его неотличимым от ъ-рандома.

расскажи мне, умный ты наш, что вместо /dev/random юзать?

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

Любой хороший криптографический ГПСЧ удовлетворяет этим тестам. А неизвестный инициализирующий вектор делает для стороннего исследователя его неотличимым от ъ-рандома.

Но не будем же мы строго одну последовательность всегда после инициализации выдавать? Следовательно, только часть инициализирующего вектора должна быть жёстко забита, что уже усложняет использование.

Бред всё это и истерия. Если генератор случайных чисел генерит неслучайные числа, то это ставит под угрозу всю финансовую систему всего мира. Т.к. рано или поздно хакеры всё равно разгадают закон, по которому генерируется неслучайные числа. И переведут себе пару сотен миллиардов долларов. ZOG этого не переживет и не допустит.