Генерация ключей gpg на Cails live cd – почему так быстро?

Я просто использовал gpg2 --gen-key для генерации пары ключей RSA 2048 бит в ОС, работающей на реальном компакт-диске (Tails). Это произошло гораздо быстрее, чем я ожидал. Когда я делаю это раньше на обычной машине, это занимает немного времени, и мне обычно нужно подождать и кратко сделать что-то еще. Я думаю, это потому, что требуется некоторое время для создания необходимого количества случайности.

Имеет ли живой компакт-диск какой-то необычный процесс, так что процесс загрузки генерирует более чем случайную случайность? Или возможно, что вместо этого используется /dev/urandom ? Насколько мне известно, gpg использует /dev/random поэтому для генерации ключей может потребоваться некоторое время.

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

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

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

Энтропия («случайность») накапливается в ядре. Если ядро ​​накопило достаточную энтропию до начала GPG, GPG сразу же получит от нее выгоду.

Обработка Linux энтропией несколько нарушена. Linux имеет два устройства: /dev/random и /dev/urandom . /dev/random блоки до тех пор, пока это требуется для накопления достаточной энтропии. /dev/urandom всегда возвращает данные без блокировки. В принципе, это было бы хорошо. Проблема в том, что энтропийный расчет Linux чрезвычайно консервативен: он предполагает, что энтропия истощается, что справедливо только в высоко теоретическом смысле. Таким образом, /dev/random имеет тенденцию блокироваться, когда это не должно.

В обычной системе вы должны просто использовать /dev/urandom – хотя некоторое программное обеспечение, включая gpg, не дает вам выбора . Однако на live CD сразу после загрузки может быть очень мало энтропии, если на вашем компьютере нет аппаратного RNG (например, инструкция RdRand на последних процессорах Intel), и Linux ее поддерживает. Поэтому в этом случае вам нужно использовать /dev/random и ждать, если необходимо. Взаимодействие с пользователем (например, перемещение мыши) будет способствовать этой энтропии.

См. Также Добавление «случайной числовой энтропии» для ключей GPG? и можете ли вы объяснить оценку энтропии, используемую в random.c

Опять же, вам не нужно беспокоиться: GPG + Linux очень консервативен, когда дело доходит до оценки энтропии. Если GPG быстро генерирует ключ, либо вы уже достаточно взаимодействовали с компьютером, чтобы обеспечить достаточную энтропию, или ваш компьютер имеет поддерживаемый аппаратный RNG.

Я нашел ответ: Tails поставляется в комплекте с генератором случайных чисел «hasged». http://www.reddit.com/r/tails/comments/2oxr7n/how_does_tails_generate_gpg_keys_so_fast/

Я отредактировал заголовок вопроса, чтобы понять, что это относится к Tails.

Ниже приведено обсуждение того, является ли алгоритм HAVEGED хорошим: https://crypto.stackexchange.com/questions/8083/quality-of-randomness-on-a-linux-system-with-haveged

Консервативный подход, используемый gpg при использовании /dev/random может быть чрезмерным во многих ситуациях по сравнению с использованием /dev/urandom но с конкретной точки зрения среды компакт-диска, используемой для генерации ключа gpg без ограничений по времени, ненужным.

Поэтому мне кажется, что самое простое решение – убить обработанный процесс в Tails, подождать, пока / proc / sys / kernel / random / entropy_avail закончится, а затем дайте gpg просто делать то, что он обычно делает.