3

concordo com o ponto central, e queria acrescentar o outro lado dele: nem todo rng precisa ser seguro, mas todo rng precisa ser honesto sobre o que é.

eu mantenho um app de sorteio — número, dado, cara ou coroa. ele usa o Random() comum do dart, que é pseudoaleatório e previsível pra quem quiser prever. e está certo assim: é entretenimento, ninguém está protegendo carteira com aquilo. o que eu não faço é escrever "verdadeiramente aleatório" ou "criptograficamente seguro" na descrição da loja, porque aí eu estaria vendendo uma garantia que o código não dá.

em dart a separação é a mesma que você mostra no js: Random() é o previsível, Random.secure() puxa do csprng do sistema. no meu caso a decisão que importou não foi qual dos dois usar, foi descrever direito qual deles está ali.

pra gerador de senha, concordo integralmente: ali só o seguro serve.

Carregando publicação patrocinada...
1

Eu concordo 100%.

Uma aplicação que não seja focada em segurança da informação, não precisa ter PRNG confiável.

A mihna crítica é principalmente à turma que fica usando PRNG vulnerável pra criar "gerador de senhas".

4

faz sentido, e o caso que eu acho mais difícil de classificar fica bem no meio dos dois: sorteio e rifa.

no papel é entretenimento, mas o resultado é disputado. se quem roda o sorteio usa prng previsível e a semente dá pra inferir, dá pra prever ou reproduzir o resultado. o meu app cai exatamente aí: tem sorteio sem repetição, que acaba sendo usado pra rifa e giveaway. entre amigos tanto faz; com prêmio envolvido começa a incomodar.

a regra que eu uso hoje: se o resultado interessa a alguém além de quem apertou o botão, parou de ser entretenimento — e aí vale o secure mesmo sendo "só um sorteio". não tenho certeza de que seja a linha certa.

e sobre o pessoal do gerador de senha, parte do problema é que o caminho errado é o mais curto: Math.random() e Random() aparecem primeiro e têm o nome mais óbvio, enquanto crypto.getRandomValues() e Random.secure() você só usa se já souber que existem.