Я был в середине написания разбивки, что пошло не так, но ты меня опередил.

В основном, они имеют класс LinuxSecureRandom, который предполагается переопределить стандартную SecureRandom. Этот класс читает / DEV / urandom и должны обеспечить криптографически безопасные случайные значения.

Они также семена генератора с использованием SecureRandom # setSeed с данными тянули из random.org. С их таможенной SecureRandom, это безопасно, потому что он смешивает энтропию с помощью XOR, так что даже если данные random.org является хитроумным это не приведет к снижению безопасности. Это просто дополнительный бонус.

НО! На некоторых устройствах при некоторых обстоятельствах, класс LinuxSecureRandom не получает зарегистрированный. Это, вероятно, потому, что / DEV / urandom не существует или не могут быть доступны по какой-то причине. Вместо того, чтобы кричать кровавое убийство, как любые разумные реализации будут, они просто игнорируют, что и возвращаться к использованию стандартного SecureRandom.

Если выше случается, есть проблема, потому что реализация по умолчанию SecureRandom # setSeed не смешивается. Если вы установите семя, он заменяет энтропию полностью. Так что теперь энтропия исходит исключительно из random.org.
И последняя ошибка: они были с использованием HTTP вместо HTTPS, чтобы сделать WebService вызов random.org. 4 января, random.org начал исполнение HTTPS и возвращение 301 перемещена ошибки для HTTP - см https://www.random.org/news/. Таким образом, с этой даты, энтропия фактически было сообщение об ошибке (превращена в байтах) вместо ожидаемого 256-разрядное число. Используя это семя, SecureRandom будет генерировать секретный ключ для адреса 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F 100% времени. Уч. Это примерно в то время, что решения первого появляется, поэтому график матчей.

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