Como lidar com um lento gerador SecureRandom?

Se você quiser números aleatórios criptograficamente fortes em Java, use SecureRandom. Infelizmente, SecureRandompode ser muito lento. Se ele usa /dev/randomno Linux, pode bloquear a espera de entropia suficiente para se acumular. Como você evita a penalidade de desempenho?

Alguém já usou Uncommon Maths como uma solução para este problema?

Alguém pode confirmar que esse problema de desempenho foi resolvido no JDK 6?

Se você quiser dados aleatórios verdadeiros, infelizmente precisará esperar por eles. Isso inclui a semente de um SecureRandomPRNG. O Uncommon Maths não pode reunir dados aleatórios verdadeiros com mais rapidez do que SecureRandom, embora possa se conectar à Internet para baixar dados de sementes de um site específico. Meu palpite é que é improvável que seja mais rápido do /dev/randomque o local disponível.

Se você deseja um PRNG, faça algo assim:

SecureRandom.getInstance("SHA1PRNG");

Quais strings são suportadas dependem do SecureRandomprovedor SPI, mas você pode enumerá-las usando Security.getProviders()e Provider.getService().

A Sun gosta de SHA1PRNG, por isso está amplamente disponível. Não é tão rápido quanto os PRNGs, mas os PRNGs serão apenas trituradores de números, não bloqueando a medição física da entropia.

A exceção é que, se você não ligar setSeed()antes de obter dados, o PRNG se propagará uma vez na primeira vez que você ligar next()ou nextBytes(). Geralmente, isso é feito usando uma quantidade bastante pequena de dados aleatórios verdadeiros do sistema. Essa chamada pode bloquear, mas tornará sua fonte de números aleatórios muito mais segura do que qualquer variante de "hash da hora atual junto com o PID, adicione 27 e espere o melhor". Porém, se tudo o que você precisa é de números aleatórios para um jogo ou se você deseja que o stream possa ser repetido no futuro usando a mesma semente para fins de teste, uma semente insegura ainda será útil.

Você deve poder selecionar o / dev / urandom mais rápido, mas um pouco menos seguro, no Linux usando:

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

No entanto, isso não funciona com o Java 5 e posterior ( Java Bug 6202721 ). A solução alternativa sugerida é usar:

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

(observe o extra /./)

No Linux, a implementação padrão para SecureRandomé NativePRNG(código fonte aqui ), que tende a ser muito lenta. No Windows, o padrão é SHA1PRNGque, como outros apontaram, você também pode usar no Linux se especificá-lo explicitamente.

NativePRNGdifere de SHA1PRNGe Uncommons AESCounterRNG do Maths por receber continuamente entropia do sistema operacional (lendo em /dev/urandom). Os outros PRNGs não adquirem nenhuma entropia adicional após a semeadura.

O AESCounterRNG é cerca de 10x mais rápido que o IIRC SHA1PRNG, ele próprio, duas ou três vezes mais rápido que NativePRNG.

Se você precisar de um PRNG mais rápido que adquira entropia após a inicialização, veja se consegue encontrar uma implementação Java do Fortuna . O PRNG principal de uma implementação Fortuna é idêntico ao usado pelo AESCounterRNG, mas também existe um sistema sofisticado de pool de entropia e nova propagação automática.

Muitas distribuições Linux (principalmente baseadas no Debian) configuram o OpenJDK para uso /dev/randomem entropia.

/dev/random por definição, é lento (e pode até bloquear).

A partir daqui, você tem duas opções para desbloqueá-lo:

1. Melhorar a entropia, ou
2. Reduza os requisitos de aleatoriedade.

Opção 1, melhorar a entropia

Para obter mais entropia /dev/random, tente o daemon protegido . É um daemon que coleta continuamente a entropia HAVEGE e funciona também em um ambiente virtualizado porque não requer nenhum hardware especial, apenas a própria CPU e um relógio.

No Ubuntu / Debian:

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

No RHEL / CentOS:

yum install haveged
systemctl enable haveged
systemctl start haveged

Opção 2. Reduzir os requisitos de aleatoriedade

Se, por algum motivo, a solução acima não ajudar ou você não se importar com a aleatoriedade criptograficamente forte, você pode alternar para o /dev/urandomque é garantido para não bloquear.

Para fazer isso globalmente, edite o arquivo jre/lib/security/java.securityem sua instalação Java padrão para usar /dev/urandom(devido a outro bug, ele precisa ser especificado como /dev/./urandom).

Como isso:

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

Então você nunca precisará especificá-lo na linha de comando.

Nota: Se você faz criptografia, precisa de uma boa entropia. Caso em questão - o problema do PRNG no Android reduziu a segurança das carteiras Bitcoin.

Eu tive um problema semelhante com as chamadas para SecureRandombloqueio por cerca de 25 segundos por vez em um servidor Debian decapitado. Eu instalei o havegeddaemon para garantir a /dev/randommanutenção, em servidores sem cabeça, você precisa de algo assim para gerar a entropia necessária. Minhas ligações para SecureRandomagora talvez levem milissegundos.

Se você deseja uma aleatoriedade verdadeiramente "criptograficamente forte", precisará de uma fonte de entropia forte. /dev/randomé lento porque precisa aguardar os eventos do sistema para coletar entropia (leituras de disco, pacotes de rede, movimento do mouse, pressionamentos de teclas etc.).

Uma solução mais rápida é um gerador de números aleatórios de hardware. Você já pode ter um embutido na sua placa-mãe; consulte a documentação do hw_random para obter instruções sobre como descobrir se você a possui e como usá-la. O pacote rng-tools inclui um daemon que alimentará a entropia gerada por hardware /dev/random.

Se um HRNG não estiver disponível no seu sistema e você estiver disposto a sacrificar a força da entropia para obter desempenho, deseje gerar um bom PRNG com dados de /dev/randome deixar que o PRNG faça a maior parte do trabalho. Existem vários PRNGs aprovados pelo NIST listados no SP800-90 que são fáceis de implementar.

Usando o Java 8, descobri que na chamada do Linux SecureRandom.getInstanceStrong()me daria o NativePRNGBlockingalgoritmo. Isso geralmente bloqueia por muitos segundos para gerar alguns bytes de sal.

Em NativePRNGNonBlockingvez disso, mudei para pedir explicitamente e, como esperado, o nome não está mais bloqueado. Não tenho ideia de quais são as implicações de segurança disso. Presumivelmente, a versão sem bloqueio não pode garantir a quantidade de entropia usada.

Atualização : Ok, achei esta excelente explicação .

Em poucas palavras, para evitar o bloqueio, use new SecureRandom(). Isso usa /dev/urandom, o que não bloqueia e é basicamente tão seguro quanto /dev/random. Da postagem: "A única vez em que você deseja chamar / dev / random é quando a máquina é inicializada pela primeira vez e a entropia ainda não foi acumulada".

SecureRandom.getInstanceStrong() fornece o RNG mais forte, mas é seguro apenas para uso em situações em que muitos bloqueios não afetam você.

Existe uma ferramenta (pelo menos no Ubuntu) que alimenta aleatoriedade artificial em seu sistema. O comando é simplesmente:

rngd -r /dev/urandom

e você pode precisar de um sudo na frente. Se você não possui o pacote rng-tools, será necessário instalá-lo. Eu tentei isso, e definitivamente me ajudou!

Fonte: mundo vs matt

Eu enfrentei o mesmo problema . Depois de pesquisar no Google com os termos de pesquisa certos, me deparei com este belo artigo no DigitalOcean .

haveged é uma solução potencial sem comprometer a segurança.

Estou apenas citando a parte relevante do artigo aqui.

Com base no princípio HAVEGE e anteriormente em sua biblioteca associada, o Haveged permite gerar aleatoriedade com base em variações no tempo de execução do código em um processador. Como é quase impossível que um pedaço de código leve o mesmo tempo exato para ser executado, mesmo no mesmo ambiente no mesmo hardware, o tempo de execução de um ou vários programas deve ser adequado para propagar uma fonte aleatória. A implementação simplificada semeia a fonte aleatória do seu sistema (geralmente / dev / random) usando diferenças no contador de carimbo de data / hora (TSC) do seu processador depois de executar um loop repetidamente

Como instalar haveged

Siga as etapas deste artigo. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

Eu publiquei aqui

O problema que você referenciou /dev/randomnão está no SecureRandomalgoritmo, mas na fonte de aleatoriedade que ele usa. Os dois são ortogonais. Você deve descobrir qual dos dois está atrasando você.

A página incomum de matemática que você vinculou menciona explicitamente que eles não estão abordando a fonte da aleatoriedade.

Você pode experimentar diferentes provedores JCE, como o BouncyCastle, para verificar se a implementação deles SecureRandomé mais rápida.

Uma breve pesquisa também revela patches do Linux que substituem a implementação padrão pelo Fortuna. Não sei muito mais sobre isso, mas você pode investigar.

Também devo mencionar que, embora seja muito perigoso usar um SecureRandomalgoritmo mal implementado e / ou uma fonte aleatória, você pode rolar seu próprio provedor JCE com uma implementação customizada de SecureRandomSpi. Você precisará passar por um processo com a Sun para assinar seu provedor, mas na verdade é bastante direto; eles só precisam que você envie por fax um formulário informando que você conhece as restrições de exportação dos EUA em bibliotecas de criptografia.

Use o aleatório seguro como fonte de inicialização para um algoritmo recorrente; você poderia usar um twister de Mersenne para o trabalho em massa, em vez daquele no UncommonMath, que já existe há algum tempo e provou ser melhor do que outros

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

Atualize de vez em quando o aleatório seguro usado para a inicialização; por exemplo, você pode ter um aleatório seguro gerado por cliente, usando um gerador pseudo-aleatório mersenne twister por cliente, obtendo um grau de randomização alto o suficiente

De acordo com a documentação , os diferentes algoritmos usados ​​pelo SecureRandom são, em ordem de preferência:

• Na maioria dos sistemas * NIX
  1. NativePRNG
  2. SHA1PRNG
  3. NativePRNGBlocking
  4. NativePRNGNonBlocking
• Em sistemas Windows
  1. SHA1PRNG
  2. Windows-PRNG

Desde que você perguntou sobre o Linux, estou ignorando a implementação do Windows, e também o SunPKCS11, que só está realmente disponível no Solaris, a menos que você o tenha instalado - e você não perguntaria isso.

De acordo com a mesma documentação, o que esses algoritmos usam são

SHA1PRNG
A propagação inicial é atualmente feita por meio de uma combinação de atributos do sistema e o dispositivo de coleta de entropia java.security.

NativePRNG
nextBytes() usa /dev/urandom
generateSeed()usos/dev/random

NativePRNGBlocking
nextBytes() e generateSeed()uso/dev/random

NativePRNGNonBlocking
nextBytes() e generateSeed()uso/dev/urandom

Isso significa que, se você usar SecureRandom random = new SecureRandom(), ele desce essa lista até encontrar uma que funcione, que normalmente será NativePRNG. E isso significa que ele se propaga a partir de /dev/random(ou usa isso se você gerar explicitamente uma semente), e então usa /dev/urandompara obter os próximos bytes, ints, double, booleanos, o que você tem.

Como /dev/randomestá bloqueando (ele bloqueia até ter entropia suficiente no pool de entropia), isso pode impedir o desempenho.

Uma solução para isso é usar algo como Haveged para gerar entropia suficiente, outra solução está sendo usada /dev/urandom. Embora você possa definir isso para toda a jvm, uma solução melhor é fazer isso para essa instância específica do SecureRandomusando SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking"). Observe que esse método pode gerar uma NoSuchAlgorithmException se NativePRNGNonBlocking, portanto, esteja preparado para retornar ao padrão.

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

Observe também que em outros sistemas * nix, /dev/urandompode se comportar de maneira diferente .

É /dev/urandomaleatório o suficiente?

A sabedoria convencional diz que apenas /dev/randomé aleatória o suficiente. No entanto, algumas vozes diferem. Em "A maneira correta de usar o SecureRandom" e "Mitos sobre / dev / urandom" , argumenta-se que isso /dev/urandom/é igualmente bom.

Os usuários na pilha de Segurança da informação concordam com isso . Basicamente, se você precisar perguntar, tudo /dev/urandombem para o seu propósito.

Eu mesmo não enfrentei esse problema, mas geraria um encadeamento no início do programa que imediatamente tenta gerar uma semente e depois morre. O método que você chama de randoms se unirá a esse encadeamento se estiver ativo; portanto, a primeira chamada será bloqueada apenas se ocorrer muito cedo na execução do programa.

Minha experiência foi apenas com a lenta inicialização do PRNG, não com a geração de dados aleatórios depois disso. Tente uma estratégia de inicialização mais ávida. Como sua criação é cara, trate-a como um singleton e reutilize a mesma instância. Se houver muita contenção de encadeamentos em uma instância, agrupe-os ou torne-os encadeados locais.

Não comprometa a geração aleatória de números. Uma fraqueza compromete toda a sua segurança.

Não vejo muitos geradores baseados em decaimento atômico do COTS, mas existem vários planos para eles, se você realmente precisa de muitos dados aleatórios. Um site que sempre tem coisas interessantes para se olhar, incluindo o HotBits, é o Fourmilab de John Walker.

Parece que você deve ser mais claro sobre seus requisitos de RNG. O requisito de RNG criptográfico mais forte (como eu o entendo) seria que, mesmo que você conheça o algoritmo usado para gerá-los e conheça todos os números aleatórios gerados anteriormente, não poderá obter informações úteis sobre nenhum dos números aleatórios gerados no futuro, sem gastar uma quantidade impraticável de poder de computação.

Se você não precisar dessa garantia completa de aleatoriedade, provavelmente haverá trocas de desempenho apropriadas. Eu tenderia a concordar com a resposta de Dan Dyer sobre o AESCounterRNG da Uncommons-Maths ou Fortuna (um de seus autores é Bruce Schneier, especialista em criptografia). Eu também nunca usei, mas as idéias parecem respeitáveis ​​à primeira vista.

Eu pensaria que se você pudesse gerar uma semente aleatória inicial periodicamente (por exemplo, uma vez por dia ou hora ou qualquer outra coisa), poderia usar uma cifra de fluxo rápido para gerar números aleatórios a partir de pedaços sucessivos do fluxo (se a cifra de fluxo usar XOR, apenas passe um fluxo de nulos ou pegue os bits XOR diretamente). EStream do ECRYPTO projeto possui muitas informações boas, incluindo benchmarks de desempenho. Isso não manteria a entropia entre os pontos no tempo em que você o reabasteceria; portanto, se alguém conhecesse um dos números aleatórios e o algoritmo usado, tecnicamente seria possível, com muita capacidade de computação, interromper a cifra do fluxo e adivinhe seu estado interno para poder prever números aleatórios futuros. Mas você teria que decidir se esse risco e suas conseqüências são suficientes para justificar o custo de manutenção da entropia.

Edit: aqui estão algumas notas de curso criptográficas sobre RNG que encontrei na rede que parecem muito relevantes para este tópico.

Se o seu hardware suportar, tente usar o Java RdRand Utility, do qual sou o autor.

Ele é baseado nas RDRANDinstruções da Intel e é cerca de 10 vezes mais rápido do que SecureRandome sem problemas de largura de banda para a implementação de grandes volumes.

Observe que essa implementação funciona apenas nas CPUs que fornecem a instrução (ou seja, quando o rdrandsinalizador do processador está definido). Você precisa instanciar explicitamente isso através do RdRandRandom()construtor; nenhum específico Providerfoi implementado.

Outra coisa a se observar é a propriedade securerandom.source no arquivo lib / security / java.security

Pode haver um benefício no desempenho ao usar / dev / urandom em vez de / dev / random. Lembre-se de que se a qualidade dos números aleatórios for importante, não comprometa a segurança.