У проекті, над яким я працюю, програма запускається за допомогою команди, аналогічної цій:
java -Djava.security.egd=file:/dev/urandom -jar app.jarЯ ніколи раніше не бачив такого java.security.egdваріанту. Шукаючи трохи, здається, він використовується для налаштування генерації випадкових чисел у додатку Java.
Це право? Коли передбачається застосувати?
Відповіді:
Програми Java можуть і повинні використовувати клас java.security.SecureRandom для створення криптографічно сильних випадкових значень за допомогою криптографічно сильного генератора псевдовипадкових чисел ( CSPRNG ). Стандартні реалізації JDK класу java.util.Random не вважаються криптографічно сильними.
У операційних систем /dev/random, схожих на Unix , є спеціальний файл, який подає псевдовипадкові числа, що отримують доступ до екологічного шуму, зібраного з драйверів пристроїв та інших джерел. Однак він блокує, якщо доступна менша ентропія, ніж вимагається ; /dev/urandomзазвичай ніколи не блокується, навіть якщо насіння генератора псевдовипадкових чисел не було повністю ініціалізовано ентропією з моменту завантаження. Є ще 3-й спеціальний файл, /dev/arandomякий блокується після завантаження, поки насіння не буде надійно ініціалізовано з достатньою ентропією, а потім ніколи не блокується знову.
За замовчуванням JVM виводить клас SecureRandom за допомогою /dev/random, тому ваш код Java може блокуватись несподівано . Параметр -Djava.security.egd=file:/dev/./urandomвиклику командного рядка, який використовується для запуску процесу Java, вказує /dev/urandomзамість цього JVM .
/./Здається, що додаткове змушує 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
EDIT 04/2020:
У коментарі згадується зміна поведінки класу SecureRandom в Java 8.
SHA1PRNG та NativePRNG були зафіксовані для належного дотримання властивостей джерела насіння SecureRandom у файлі java.security. (Незрозуміле рішення за допомогою файлу: /// 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 все ще читається
У Linux та macOS, якщо для пристрою збирання ентропії в java.security встановлено
file:/dev/urandomабоfile:/dev/random, тоді NativePRNG віддається перевагу SHA1PRNG. В іншому випадку кращим є SHA1PRNG.
Щоб уточнити, як нові механізми DRBG грають разом з попередніми PRNG, я запускаю кілька тестів на macOS (Darwin) з AdoptOpenJDK (build 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/urandomвибору NativePRNG, що подається під /dev/urandomчас /dev/./urandomвибору SHA1PRNG (також подається /dev/urandom) при використанні Java 8. Від Java 9 далі DRBG має перевагу, коли /dev/./urandomвказано джерело.
Це більше не потрібно, якщо ви використовуєте JDK 8 або вище
Проблема виправлена Java, і ось декілька посилань
Структура
SHA1PRNG та NativePRNG були зафіксовані для належного дотримання властивостей джерела насіння SecureRandom у файлі java.security. (Незрозуміле рішення за допомогою файлу: /// 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 році.