В проекте, над которым я работаю, приложение запускается с помощью команды, подобной этой:
java -Djava.security.egd=file:/dev/urandom -jar app.jarЯ никогда не видел java.security.egdвариант раньше. Поиски, кажется, используются для настройки генерации случайных чисел в приложении Java.
Это правильно? Когда предполагается применять?
Ответы:
Java-приложения могут и должны использовать класс java.security.SecureRandom для создания криптографически сильных случайных значений с помощью криптографически сильного генератора псевдослучайных чисел ( CSPRNG ). Стандартные реализации JDK класса java.util.Random не считаются криптографически стойкими.
Unix-подобные операционные системы имеют /dev/randomспециальный файл, который обслуживает псевдослучайные числа, получая доступ к окружающему шуму, полученному от драйверов устройств и других источников. Однако он блокируется, если энтропии меньше, чем требуется ; /dev/urandomобычно никогда не блокируется, даже если начальное число генератора псевдослучайных чисел не было полностью инициализировано энтропией с момента загрузки. Есть еще 3-й специальный файл, /dev/arandomкоторый блокируется после загрузки, пока начальное число не будет безопасно инициализировано с достаточной энтропией, а затем никогда не блокируется снова.
По умолчанию JVM использует класс SecureRandom/dev/random , поэтому ваш код Java может неожиданно блокироваться . Опция -Djava.security.egd=file:/dev/./urandomв вызове командной строки, используемая для запуска процесса Java, указывает JVM использовать /dev/urandomвместо этого.
Дополнительное, /./кажется, заставляет JVM использовать алгоритм SHA1PRNG, который использует SHA-1 в качестве основы PRNG (Генератор псевдослучайных чисел). Он сильнее, чем алгоритм NativePRNG, используемый, когда /dev/urandomон указан.
Наконец, существует миф, что /dev/urandomэто генератор псевдослучайных чисел, PRNG, в то время /dev/randomкак это «истинный» генератор случайных чисел . Это просто не так, как /dev/randomи /dev/urandomпитаются тем же CSPRNG (криптографически безопасный генератор псевдослучайных чисел). Только поведение, когда их соответствующий пул исчерпывает энтропию, согласно некоторой оценке, отличается: /dev/randomблокирует, в то время /dev/urandomкак нет.
Как насчет энтропии на исходе? Это не важно
Оказывается, что «смотреть случайным образом» является основным требованием для многих наших криптографических блоков. И если вы берете вывод криптографического хэша, он должен быть неотличим от случайной строки, чтобы шифры могли его принять. Это причина использования алгоритма SHA1PRNG, поскольку он использует хеш-функцию и счетчик вместе с начальным числом.
Когда предполагается применять?
Всегда, я бы сказал.
Источники:
https://gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom
РЕДАКТИРОВАТЬ 04/2020:
Комментарий упоминает об изменении поведения класса SecureRandom в Java 8.
SHA1PRNG и NativePRNG были исправлены для правильного соблюдения свойств исходного кода SecureRandom в файле java.security. (Запутанный обходной путь с использованием file: /// dev / urandom и file: / dev /./ urandom больше не требуется.)
На это уже указывали тесты, указанные в разделе «Источники» выше. /./Требуется дополнительное, чтобы изменить алгоритм, используемый SecureRanom в Java 8, с NativePRNG на SHA1PRNG.
Тем не менее, у меня есть некоторые новости, которыми я хотел бы поделиться. Согласно JEP-273 , начиная с Java 9, класс SecureRandom реализует три механизма детерминированного генератора случайных битов (DRBG) , описанных в NIST 800-90Ar1 . Эти механизмы реализуют современные сильные алгоритмы, такие как SHA-512 и AES-256.
В JDK было два вида реализаций SecureRandom :
/dev/{u}randomв Unix или использование CryptoAPI в Windows. Последние выпуски Linux и Windows уже поддерживают DRBG, но более старые выпуски и встроенные системы могут этого не делать .Между тем, в Руководстве разработчика по Java 13 Security все еще говорится
В Linux и macOS, если устройство сбора энтропии в java.security установлено на
file:/dev/urandomилиfile:/dev/random, то NativePRNG предпочтительнее, чем SHA1PRNG. В противном случае SHA1PRNG является предпочтительным.
Чтобы выяснить, как новые механизмы DRBG взаимодействуют с предыдущими PRNG, я запустил некоторые тесты на macOS (Darwin) с AdoptOpenJDK (сборка 13.0.2 + 8). Вот результаты:
file: / dev / random
Порядок предпочтений для провайдеров:
SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNGfile: / dev / urandom
Порядок предпочтений для провайдеров:
SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNGfile: / dev /./ urandom
Порядок предпочтений для провайдеров:
SecureRandom.DRBG
SecureRandom.SHA1PRNG
SecureRandom.NativePRNGВывод:
Я бы порекомендовал использовать -Djava.security.egd=file:/dev/./urandomего, чтобы убедиться в использовании самой мощной из доступных реализаций SecureRandom независимо от используемой платформы, избегая при этом неожиданной блокировки кода.
/dev/urandomselects NativePRNG, передаваемых при /dev/urandomодновременном /dev/./urandomподборе SHA1PRNG (также передается /dev/urandom) при использовании Java 8. Начиная с Java 9, DRBG имеет приоритет, когда /dev/./urandomуказан источник.
Это больше не требуется, если вы используете JDK 8 или выше
Проблема была исправлена Java и вот несколько ссылок
Контур
SHA1PRNG и NativePRNG были исправлены для правильного соблюдения свойств исходного кода SecureRandom в файле java.security. (Запутанный обходной путь с использованием file: /// dev / urandom и file: / dev /./ urandom больше не требуется.)
Для получения дополнительной информации (поиск случайных на странице):
https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html
https://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html
Это связано с различием Linux /dev/randomи /dev/urandomгенератора случайных чисел.
По этой ссылке
Java Bug 6202721 утверждает, что java.security.SecureRandom использует / dev / random, а не / dev / urandom, даже если указан / dev / urandom, потому что в то время (около 2004 года) / dev / urandom не работал должным образом. Ошибка никогда не была устранена, поскольку / dev / urandom работает довольно хорошо. Таким образом, вы должны притворяться, скрывая настройки, используя /dev/./urandom, чтобы принудительно использовать SHA1PRNG, а не / dev / random.
Ответить на ваш вопрос
Когда предполагается применять?
Основываясь на приведенной выше ссылке, это нечто уникальное для версий Java 5 и последующих, возникших из-за проблем с / dev / urandom в системах Linux еще в 2004 году.