Как бороться с медленным генератором SecureRandom?

Если вы хотите криптографически сильные случайные числа в Java, вы используете SecureRandom. К сожалению, SecureRandomможет быть очень медленным. Если он используется /dev/randomв Linux, он может заблокировать ожидание достаточной энтропии для наращивания. Как избежать штрафа за производительность?

Кто-нибудь использовал Uncommon Maths как решение этой проблемы?

Кто-нибудь может подтвердить, что эта проблема производительности была решена в JDK 6?

Если вам нужны настоящие случайные данные, то, к сожалению, вам придется ждать их. Это включает в себя семя для SecureRandomPRNG. Необычные математики не могут собирать настоящие случайные данные быстрее SecureRandom, хотя могут подключаться к Интернету и загружать начальные данные с определенного веб-сайта. Я думаю, что это вряд ли будет быстрее, чем /dev/randomтам, где это доступно.

Если вы хотите PRNG, сделайте что-то вроде этого:

SecureRandom.getInstance("SHA1PRNG");

Какие строки поддерживаются, зависит от SecureRandomпоставщика SPI, но вы можете перечислить их, используя Security.getProviders()иProvider.getService() .

Солнце любит SHA1PRNG, поэтому оно широко доступно. Это не особенно быстро, как PRNGs, но PRNGs будут просто подсчитывать цифры, а не блокировать физическое измерение энтропии.

Исключением является то, что если вы не позвоните setSeed()до получения данных, то PRNG будет запущен один раз при первом вызове next()или nextBytes(). Обычно это делается с использованием довольно небольшого количества реальных случайных данных из системы. Этот вызов может блокировать, но сделает ваш источник случайных чисел намного более безопасным, чем любой вариант «хеширования текущего времени вместе с PID, добавьте 27 и надейтесь на лучшее». Если все, что вам нужно, это случайные числа для игры, или если вы хотите, чтобы поток повторялся в будущем с использованием того же начального числа для целей тестирования, небезопасное начальное число все еще полезно.

Вы должны быть в состоянии выбрать более быстрый, но немного менее безопасный / dev / urandom в Linux, используя:

-Djava.security.egd=file:/dev/urandom

Однако это не работает с Java 5 и более поздними версиями ( Java Bug 6202721 ). Предложенный обходной путь должен использовать:

-Djava.security.egd=file:/dev/./urandom

(обратите внимание на дополнительное /./)

В Linux реализация по умолчанию для SecureRandomis NativePRNG(исходный код здесь ) имеет тенденцию быть очень медленной. В Windows по умолчаниюSHA1PRNG , которое, как отмечали другие, вы также можете использовать в Linux, если вы укажете это явно.

NativePRNGотличается от AESCounterRNG от SHA1PRNGUncommons Maths тем, что он постоянно получает энтропию от операционной системы (путем чтения из/dev/urandom ). Другие PRNG не приобретают никакой дополнительной энтропии после посева.

AESCounterRNG примерно в 10 раз быстрее, чем SHA1PRNGсам IIRC, в два-три раза быстрее, чемNativePRNG .

Если вам нужен более быстрый PRNG, который приобретает энтропию после инициализации, посмотрите, сможете ли вы найти реализацию Fortuna на Java . Базовый PRNG реализации Fortuna идентичен тому, который используется AESCounterRNG, но есть также сложная система объединения энтропии и автоматического повторного заполнения.

Многие дистрибутивы Linux (в основном на основе Debian) настраивают OpenJDK для использования /dev/randomв качестве энтропии.

/dev/random по определению медленный (и может даже блокировать).

Отсюда у вас есть два варианта, как разблокировать его:

1. Улучшить энтропию, или
2. Уменьшите требования случайности.

Вариант 1. Улучшение энтропии.

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

В Ubuntu / Debian:

apt-get install haveged
update-rc.d haveged defaults
service haveged start

На RHEL / CentOS:

yum install haveged
systemctl enable haveged
systemctl start haveged

Вариант 2. Снижение требований случайности

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

Чтобы сделать это глобально, отредактируйте файл jre/lib/security/java.securityв используемой по умолчанию установке Java для использования /dev/urandom(из-за другой ошибки его нужно указать как /dev/./urandom).

Как это:

#securerandom.source=file:/dev/random
securerandom.source=file:/dev/./urandom

Тогда вам никогда не придется указывать это в командной строке.

Примечание: если вы занимаетесь криптографией, вам нужна хорошая энтропия. Показательный пример - проблема PRNG для Android снизила безопасность биткойн-кошельков.

У меня была похожая проблема с вызовами SecureRandomблокировки примерно по 25 секунд за раз на безголовом сервере Debian. Я установил havegedдемон, чтобы убедиться, что /dev/randomон обновлен, на серверах без головы вам нужно что-то подобное, чтобы генерировать необходимую энтропию. Мои звонки SecureRandomсейчас, возможно, занимают миллисекунды.

Если вы хотите действительно «криптографически сильную» случайность, то вам нужен сильный источник энтропии. /dev/randomмедленный, потому что он должен ждать системных событий, чтобы собрать энтропию (чтение диска, сетевые пакеты, движение мыши, нажатия клавиш и т. д.).

Более быстрое решение - аппаратный генератор случайных чисел. Возможно, у вас уже есть один встроенный в материнскую плату; Изучите документацию hw_random , чтобы узнать, как выяснить, есть ли она у вас и как ее использовать. В пакет rng-tools входит демон, который будет передавать энтропию, генерируемую оборудованием /dev/random.

Если HRNG не доступен в вашей системе, и вы готовы пожертвовать силой энтропии для повышения производительности, вы захотите получить хороший PRNG с данными из него /dev/randomи позволить PRNG выполнять большую часть работы. Есть несколько утвержденных NIST PRNG, перечисленных в SP800-90, которые легко внедрить.

Используя Java 8, я обнаружил, что в Linux вызов SecureRandom.getInstanceStrong()даст мне NativePRNGBlockingалгоритм. Это часто блокировало бы в течение многих секунд, чтобы генерировать несколько байтов соли.

Я переключился на явный запрос NativePRNGNonBlockingвместо этого, и, как и ожидалось из названия, он больше не заблокирован. Я понятия не имею, каковы последствия этого для безопасности. Предположительно, неблокирующая версия не может гарантировать количество используемой энтропии.

Обновление : Хорошо, я нашел это отличное объяснение .

В двух словах, чтобы избежать блокировки, используйте new SecureRandom(). Это использует /dev/urandom, который не блокирует и в основном так же безопасен, как /dev/random. Из поста: «Единственный раз, когда вы захотите вызвать / dev / random, это когда машина загружается впервые, а энтропия еще не накопилась».

SecureRandom.getInstanceStrong() дает вам самый сильный RNG, но его можно использовать только в ситуациях, когда блокировка не будет влиять на вас.

Существует инструмент (по крайней мере, в Ubuntu), который подает искусственную случайность в вашу систему. Команда просто:

rngd -r /dev/urandom

и вам может понадобиться sudo на передней панели. Если у вас нет пакета rng-tools, вам необходимо установить его. Я попробовал это, и это определенно помогло мне!

Источник: Мэтт против мира

Я столкнулся с той же проблемой . После некоторого поиска в Google с правильными условиями поиска, я наткнулся на эту прекрасную статью о DigitalOcean .

Это потенциальное решение без ущерба для безопасности.

Я просто цитирую соответствующую часть статьи здесь.

Основанный на принципе HAVEGE и ранее основанный на связанной с ним библиотеке, хеджирование позволяет генерировать случайность на основе изменений во времени выполнения кода на процессоре. Поскольку для одного куска кода почти невозможно выполнить одно и то же точное время, даже в одной и той же среде на одном и том же оборудовании, время запуска одной или нескольких программ должно быть подходящим для заполнения случайного источника. Реализация с хэджами отбирает случайный источник вашей системы (обычно / dev / random), используя различия в счетчике меток времени вашего процессора (TSC) после многократного выполнения цикла

Как установить hasged

Следуйте инструкциям в этой статье. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Я разместил это здесь

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

На странице «Необычные математики», на которую вы ссылались, явно упоминается, что они не обращаются к источнику случайности.

Вы можете попробовать разные провайдеры JCE, такие как BouncyCastle, чтобы увидеть, если их реализация SecureRandom .

Краткий поиск также обнаруживает патчи для Linux, которые заменяют реализацию по умолчанию на Fortuna. Я не знаю больше об этом, но вы можете расследовать.

Я должен также упомянуть, что, хотя очень плохо использовать плохо реализованный SecureRandomалгоритм и / или источник случайности, вы можете свернуть свой собственный JCE-провайдер с пользовательской реализацией SecureRandomSpi. Вам нужно будет пройти через Sun процесс, чтобы подписать вашего провайдера, но на самом деле это довольно просто; им просто нужно, чтобы вы отправили им по факсу форму, подтверждающую, что вы знаете об ограничениях на экспорт криптобиблиотек в США.

Используйте безопасный случайный случай в качестве источника инициализации для рекуррентного алгоритма; тогда вы могли бы использовать твистер Mersenne для массовых работ вместо того, что использовался в UncommonMath, который существовал некоторое время и оказался лучше, чем другие prng

http://en.wikipedia.org/wiki/Mersenne_twister

Обязательно обновляйте время от времени безопасное случайное число, используемое для инициализации, например, вы можете создать одно безопасное случайное случайное число для каждого клиента, используя один псевдослучайный генератор mersenne twister для каждого клиента, получая достаточно высокую степень рандомизации.

Согласно документации , различные алгоритмы, используемые SecureRandom, в порядке предпочтения:

• В большинстве * систем NIX
  1. NativePRNG
  2. SHA1PRNG
  3. NativePRNGBlocking
  4. NativePRNGNonBlocking
• В системах Windows
  1. SHA1PRNG
  2. Окна-ПСЧ

Поскольку вы спрашивали о Linux, я игнорирую реализацию Windows, а также SunPKCS11, который действительно доступен только в Solaris, если вы не установили его самостоятельно - и тогда вы не будете спрашивать этого.

Согласно той же документации, эти алгоритмы

SHA1PRNG
Первоначальное в настоящее время выполняется с помощью комбинации системных атрибутов и устройства сбора энтропии java.security.

NativePRNG
nextBytes() использует /dev/urandom
generateSeed()использует/dev/random

NativePRNGB блокировка
nextBytes() и generateSeed()использование/dev/random

NativePRNGNonBlocking
nextBytes() иgenerateSeed() использование/dev/urandom

Это означает, что если вы используете SecureRandom random = new SecureRandom(), он идет вниз по этому списку, пока не найдет тот, который работает, который обычно будет NativePRNG. И это означает, что он берет /dev/randomначало (или использует это, если вы явно генерируете семена), а затем использует/dev/urandom берет начало для получения следующих байтов, целых, двойных, логических значений, что у вас есть.

Так как /dev/randomэто блокировка (она блокирует, пока у нее не будет достаточно энтропии в пуле энтропии), это может снизить производительность.

Одним из решений этого является использование чего-то вроде hasged для генерации достаточного количества энтропии, /dev/urandomвместо этого используется другое решение . Хотя вы можете установить это для всего jvm, лучшим решением будет сделать это для этого конкретного случая SecureRandom, используя SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking"). Обратите внимание, что этот метод может генерировать исключение NoSuchAlgorithmException, если NativePRNGNonBlocking, поэтому будьте готовы к откату до значения по умолчанию.

SecureRandom random;
try {
    random = SecureRandom.getInstance("NativePRNGNonBlocking");
} catch (NoSuchAlgorithmException nsae) {
    random = new SecureRandom();
}

Также обратите внимание, что в других системах * nix /dev/urandomможет вести себя по-разному .

/dev/urandomДостаточно ли случайно?

Обычная мудрость гласит, что /dev/randomэто достаточно случайно. Однако некоторые голоса отличаются. В «Правильном способе использования SecureRandom» и «Мифах о / dev / urandom» утверждается, что /dev/urandom/это так же хорошо.

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

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

Мой опыт был только с медленной инициализацией PRNG, а не с генерацией случайных данных после этого. Попробуйте более активную стратегию инициализации. Поскольку создавать их дорого, относитесь к ним как к одиночке и используйте один и тот же экземпляр. Если для одного экземпляра слишком много конфликтов потоков, объедините их в пул или сделайте их локальными.

Не идите на компромисс по генерации случайных чисел. Слабость там ставит под угрозу всю вашу безопасность.

Я не вижу много генераторов на основе атомного распада COTS, но есть несколько планов для них, если вам действительно нужно много случайных данных. Один сайт, на котором всегда есть интересные вещи, включая HotBits, это Fourmilab Джона Уокера.

Похоже, вы должны быть более четкими в своих требованиях к ГСЧ. Самое сильное криптографическое требование ГСЧ (насколько я понимаю) должно заключаться в том, что даже если вы знаете алгоритм, используемый для их генерации, и знаете все ранее сгенерированные случайные числа, вы не сможете получить какую-либо полезную информацию о любом из случайных чисел, сгенерированных в будущее, не тратя непрактичное количество вычислительной мощности.

Если вам не нужна эта полная гарантия случайности, вероятно, существуют соответствующие компромиссы производительности. Я склонен согласиться с ответом Дэна Дайера об AESCounterRNG от Uncommons-Maths или Fortuna (одним из его авторов является Брюс Шнайер, эксперт по криптографии). Я никогда не использовал ни один, но идеи кажутся авторитетными на первый взгляд.

Я думаю, что в что если бы вы могли генерировать начальное случайное начальное число периодически (например, один раз в день или час или что-то еще), вы могли бы использовать быстрый потоковый шифр для генерации случайных чисел из последовательных фрагментов потока (если потоковый шифр использует XOR, тогда просто передать поток нулей или получить биты XOR напрямую). ECRYPT's eStreamПроект содержит много полезной информации, включая показатели производительности. Это не будет поддерживать энтропию между моментами времени, когда вы его пополняете, поэтому, если кто-то знает одно из случайных чисел и алгоритм, который вы использовали, технически, возможно, с большой вычислительной мощностью, сломать потоковый шифр и угадать его внутреннее состояние, чтобы иметь возможность предсказывать будущие случайные числа. Но вам придется решить, достаточно ли этого риска и его последствий, чтобы оправдать затраты на поддержание энтропии.

Изменить: вот некоторые заметки о криптографии курса по ГСЧ, которые я нашел в сети, которые выглядят очень актуальными для этой темы.

Если ваше оборудование поддерживает это, попробуйте использовать Java RdRand Utility, автором которой я являюсь.

Он основан на RDRANDинструкциях Intel и примерно в 10 раз быстрее, чем SecureRandomпроблемы с пропускной способностью при реализации больших объемов.

Обратите внимание, что эта реализация работает только на тех CPU, которые предоставляют инструкцию (т.е. когда установлен rdrandфлаг процессора). Вам нужно явно создать его экземпляр с помощью RdRandRandom()конструктора; никаких конкретных Providerне было реализовано.

Еще нужно обратить внимание на свойство securerandom.source в файле lib / security / java.security.

Использование / dev / urandom может быть выигрыш в производительности, а не / dev / random. Помните, что если важно качество случайных чисел, не идите на компромисс, который нарушает безопасность.