Some chap disse o seguinte:

Qualquer um que tente gerar números aleatórios por meios determinísticos está, é claro, vivendo em um estado de pecado.

Isso sempre significa que você não pode gerar números aleatórios verdadeiros com apenas um computador. E ele disse que quando os computadores tinham o tamanho equivalente a um único microprocessador Intel 8080 (~ 6000 válvulas). Os computadores ficaram mais complexos, e acredito que a afirmação de von Von Neumann pode não ser mais verdadeira. Considere que um algoritmo implementado apenas por software é impossível. Eles rodam em hardware físico. Os verdadeiros geradores de números aleatórios e suas fontes de entropia também são feitos de hardware.

Este fragmento Java colocado em um loop:

      file.writeByte((byte) (System.nanoTime() & 0xff));

pode criar um arquivo de dados que eu representei como uma imagem:

Você pode ver a estrutura, mas com muita aleatoriedade também. O interessante é que esse arquivo PNG tem 232 KB de tamanho e ainda contém 250.000 pixels em escala de cinza. O nível de compactação PNG foi máximo. Isso é apenas uma taxa de compressão de 7%, ou seja. razoavelmente não compressível. O que também é interessante é que o arquivo é único. Cada geração deste arquivo é um padrão ligeiramente diferente e possui uma compressibilidade semelhante a ~ 7%. Destaco isso porque é fundamental para o meu argumento. Isso é entropia de ~ 7 bits / byte. Isso reduzirá, é claro, com o uso de um algoritmo de compactação mais forte. Mas não reduza a nada próximo de 0 bits / byte. Para obter uma melhor impressão, pegue a imagem acima e substitua o mapa de cores por um aleatório: -

A maior parte da estrutura (na metade superior) desaparece, pois eram apenas sequências de valores semelhantes, mas marginalmente diferentes. Esta é uma verdadeira fonte de entropia criada apenas pela execução de um programa Java em um sistema operacional de múltiplas tomadas? Não é um gerador de números aleatórios uniformemente distribuído, mas a fonte de entropia para um? Uma fonte de entropia construída com software em execução em hardware físico que por acaso é um PC.

Suplementar

Para confirmar que toda imagem gera entropia nova sem um padrão fixo comum a todos, foram geradas 10 imagens consecutivas. Estes foram concatenados e compactados com o arquivador mais forte que consigo compilar (paq8px). Esse processo eliminará todos os dados comuns, incluindo a correlação automática, deixando apenas as alterações / entropia.

O arquivo concatenado compactado para ~ 66%, o que leva a uma taxa de entropia de ~ 5,3 bits / byte ou 10,5Mbits / imagem. Uma quantidade surpreendente de entropia$\smile$

Suplementar 2

Houve comentários negativos de que minha metodologia de teste de entropia por compressão é falha, fornecendo apenas uma estimativa limitada do limite superior. Portanto, agora eu executei o arquivo concatenado através do teste de avaliação de entropia criptográfica oficial do NIST, SP800-90B_EntropyAssessment . Isso é o melhor possível para a medição de entropia sem IDI. Este é o relatório (desculpe, esta pergunta está ficando longa, mas o problema é complexo): -

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
    Correct: 3816
    P_avg (global): 0.00397508
    P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag 

Test: 100% complete
    Correct: 3974
    P_avg (global): 0.00413607
    P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
    Correct: 3913
    P_avg (global): 0.00407383
    P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
    Correct: 3866
    P_avg (global): 0.00402593
    P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735

O resultado é que o NIST acredita que eu gerei 5,6 bits / byte de entropia. Minha estimativa de compressão DIY coloca isso em 5,3 bits / byte, um pouco mais conservador.

-> As evidências parecem apoiar a noção de que um computador executando apenas um software pode gerar entropia real. E que von Neumann estava errado (mas talvez correto para o seu tempo).

Ofereço as seguintes referências que podem apoiar minha reivindicação: -

Existem modelos estocásticos de não determinismo na taxa de execução do programa?

Análise WCET de sistemas probabilísticos rígidos em tempo real

Existe um algoritmo de software que pode gerar um padrão de caos não determinístico? e a relevância dos efeitos caóticos.

Paralelos com o princípio da incerteza entrópica quântica

Entrada do blog de Aleksey Shipilёv sobre o comportamento caótico do nanoTime (). Seu gráfico de dispersão não é diferente do meu.

Só porque você não pode ver um padrão, não significa que não exista. Só porque um algoritmo de compactação não consegue encontrar um padrão não significa que nenhum padrão existe. Os algoritmos de compressão não são balas de prata que podem medir magicamente a verdadeira entropia de uma fonte; tudo o que eles dão é um limite superior para a quantidade de entropia. (Da mesma forma, o teste NIST também fornece apenas um limite superior.) O caos não é aleatório.

É preciso uma análise e um exame mais detalhados para começar a obter alguma confiança na qualidade da aleatoriedade obtida dessa maneira.

Não são razões para pensar que podemos provavelmente obter uma certa quantidade de aleatoriedade, explorando jitter relógio e a deriva entre dois relógios de hardware , mas é delicado e complicado, então você tem que ter cuidado. Eu não recomendaria tentar implementar o seu próprio. Em vez disso, sugiro que você use uma fonte de entropia de alta qualidade (geralmente implementada na maioria dos sistemas operacionais modernos). Para obter mais detalhes, consulte também a Wikipedia , haveged e /crypto//q/48302/351 (que parece que você já conhece).

Por fim, um comentário no seu abridor:

"Qualquer um que tente gerar números aleatórios por meios determinísticos está, é claro, vivendo em estado de pecado".

Isso sempre significa que você não pode gerar números aleatórios verdadeiros com apenas um computador.

Não, não é assim que geralmente é tomado, e não é o que está dizendo. Está dizendo que você não pode gerar números aleatórios verdadeiros por meios determinísticos . Se você pode fazê-lo em um computador depende se o computador é determinístico ou não. Se o computador é determinístico ou o seu programa usa apenas operações determinísticas, você não pode. No entanto, muitos computadores contêm elementos não determinísticos e, se o seu programa os utiliza, é necessária uma análise mais detalhada antes de decidir se eles podem ser usados ​​para gerar números aleatórios. No seu caso, nanoTime()é não determinístico.

Se você está usando alguma fonte de entropia / aleatoriedade de hardware, não está "tentando gerar aleatoriedade por meios determinísticos " (minha ênfase). Se você não estiver usando nenhuma fonte de entropia / aleatoriedade de hardware, um computador mais poderoso significa que você pode cometer mais pecados por segundo.

Sempre entendi que a citação significa que um algoritmo determinístico tem uma quantidade fixa de entropia e, embora a saída possa parecer "aleatória", não pode conter mais entropia do que as entradas fornecem. Nesta perspectiva, vemos que seu algoritmo contrabandeia na entropia via System.nanoTime()- a maioria das definições de um algoritmo "determinístico" não permitiria chamar essa função.

A citação - enquanto concisa - é essencialmente uma tautologia. Não há nada para refutar e não há evolução possível do hardware que possa torná-lo não mais verdadeiro. Não é sobre hardware, é sobre a definição de um algoritmo determinístico. Ele está simplesmente observando que o determinismo e a aleatoriedade são incompatíveis. Para qualquer algoritmo determinístico, todo o seu comportamento é previsto por suas condições de partida. Se você acha que encontrou uma exceção, está entendendo mal o que significa ser determinista.

É verdade que um processo em execução em um computador compartilhado com uma série complexa de caches e que recebe várias entradas de rede e hardware tem acesso a muito mais entropia do que um processo executado em hardware simples, isolado e dedicado. Mas se esse processo acessa essa entropia, não é mais determinístico e, portanto, a cotação não se aplica.

Qualquer um que tente gerar números aleatórios por meios determinísticos está, é claro, vivendo em um estado de pecado.

Quando você interpreta "viver em estado de pecado" como "fazer um disparate", isso é perfeitamente correto.

O que você fez foi usar um método bastante lento System.nanoTime()para gerar uma aleatoriedade bastante fraca. Você mediu alguns

... taxa de entropia de ~ 5,3 bits / byte ...

mas este é apenas o limite superior. Tudo o que você pode obter é um limite superior. A entropia real pode ter ordens de magnitude menores.

Tente preencher a matriz usando um hash criptográfico como MD5. Calcule uma sequência como md5(0), md5(1), ...(de cada valor obtido um ou mais bytes, isso não importa). Você não terá nenhuma compactação (sim, o MD5 está quebrado, mas ainda é bom o suficiente para produzir dados incompressíveis).

Podemos dizer que não há entropia, mas você mede 8 bits / byte.

Quando você realmente precisa de algo aleatório, não apenas precisa usar uma fonte de HW, mas também precisa conhecer um limite inferior certo de quanta entropia ela realmente produz. Embora provavelmente haja alguma aleatoriedade nanoTime(), não conheço nenhum limite inferior não trivial.

Quando você precisa de aleatoriedade para criptografia, precisa realmente recorrer a algo fornecido pelo seu sistema operacional, seu idioma ou uma boa biblioteca. Esses provedores coletam entropia de várias fontes e / ou HW dedicado e muito trabalho foi colocado nessas estimativas de entropia.

Note que você normalmente não precisa de nenhuma entropia. Um bom PRNG (determinístico) inicializado com alguns bytes aleatórios é utilizável para criptografia e, portanto, também para todo o resto.

Eu pensei em me aproximar do significado de "aleatório". A maioria das respostas aqui está falando sobre a saída de processos aleatórios , em comparação com a saída de processos determinísticos. Esse é um significado perfeitamente bom de "aleatório", mas não é o único.

Um problema com a saída de processos aleatórios é que eles são difíceis de distinguir das saídas de processos determinísticos: eles não contêm um "registro" de quão aleatória sua fonte era. Um exemplo extremo disso é uma famosa história em quadrinhos do XKCD, em que um gerador de números aleatórios sempre retorna 4, com um comentário de código afirmando que é aleatório porque veio de uma rolagem de dados.

Uma abordagem alternativa para definir "aleatoriedade", chamada complexidade de Kolmogorov , baseia-se nos próprios dados, independentemente de como foram gerados. A complexidade de Kolmogorov de alguns dados (por exemplo, uma sequência de números) é a duração do programa de computador mais curto que gera esses dados: os dados são "mais aleatórios" se tiver uma complexidade maior de Kolmogorov.

Seu uso de algoritmos de compactação como PNG e a comparação do comprimento antes e depois da compactação são semelhantes à idéia da complexidade de Kolmogorov. No entanto, a complexidade de Kolmogorov permite que os dados sejam codificados como um programa em qualquer linguagem de programação completa de Turing, em vez de um formato limitado como PNG; "descomprimir" essas codificações (programas) é executado executando-as, o que pode levar uma quantidade arbitrária de tempo e memória (por exemplo, mais do que está disponível em nosso universo insignificante).

O teorema de Rice nos diz que, em geral, não podemos distinguir entre programas que se repetem para sempre e programas que produzem nossos dados. Portanto, é muito difícil encontrar a complexidade de Kolmogorov de alguns dados: se escrevermos um programa que gera esses dados, pode haver realmente um programa mais curto (ou seja, uma complexidade menor), mas não o localizamos porque não conseguimos distingui-lo de um loop infinito. A complexidade de Kolmogorov é, portanto, incontestável, embora se soubéssemos os números do Busy-Beaver , poderíamos calculá-los usando aqueles para limitar a quantidade de tempo que verificamos em cada programa.

No caso de seus dados de exemplo, para encontrar a complexidade de Kolmogorov (isto é, "aleatoriedade intrínseca"), precisaríamos encontrar o programa determinístico mais curto que produza a mesma sequência de bytes e tomar seu comprimento.

Agora podemos responder à sua pergunta do ponto de vista da complexidade de Kolmogorov, e descobrimos que a citação está correta: não podemos gerar números aleatórios (alta complexidade de Kolmogorov) por meios determinísticos.

Por que não? Vamos imaginar que escrevemos um pequeno programa de computador e o usamos para gerar uma sequência de números aleatórios. Uma das seguintes situações deve ser aplicada:

• Geramos uma grande quantidade de produção. No entanto, como sabemos que essa saída é gerada por um pequeno programa, a saída (por definição) tem baixa complexidade de Kolmogorov e, portanto, não é "aleatória" nesse sentido.
• Geramos tão poucos números que anotá-los levaria aproximadamente os mesmos bits, ou até menos, do que escrever nosso programa de geração curta. Nesse caso, os números são relativamente incompressíveis, o que indica que são bastante aleatórios no sentido de Kolmogorov. No entanto, uma vez que a quantidade de saída é comparável ao que nós colocamos na (o código-fonte para o programa), é justo dizer que o programa não "gerar" a aleatoriedade, que fez ao escolher esse programa. Afinal, nesse caso, nosso programa de geração também pode ter sido apenas uma lista desses números exatos (por exemplo print([...])).

Em ambos os casos, não estamos "gerando" mais aleatoriedade do que inserimos (a "aleatoriedade" do código-fonte do programa de geração). Podemos tentar contornar isso usando um programa de geração mais longo, para evitar que a saída tenha um gerador curto, mas existem apenas duas maneiras de fazer isso:

• Sistematicamente "incha" o código de alguma forma. No entanto, Kolmogorov complexidade não se preocupa com o programa específico que temos utilizado para gerar os dados: ela só se preocupa com o que a geração de programa é o menor. O inchaço sistemático não adiciona complexidade à Kolmogorov, porque esses padrões no código podem ser gerados com uma quantidade muito pequena de código. Por exemplo, se pegarmos run(shortGenerator)e adicionarmos uma carga sistemática de inchaço sistemático run(bloatedGenerator), um pequeno gerador ainda existe na forma run(addBloat(shortGenerator)).
• Adicione inchaço de forma não sistemática , ou seja, sem nenhum padrão, para que uma addBloatfunção acabe sendo tão inchada quanto o próprio código. No entanto, ser tão desprovido de padrões é exatamente o que torna algo aleatório (alta complexidade de Kolmogorov). Daí inchaço do programa gerador desta forma não aumentar a aleatoriedade (Kolmogorov complexidade) da saída, mas também aumenta a quantidade de aleatoriedade (Complexidade de Kolmogorov) que temos para oferecer na forma de código fonte. Portanto, ainda somos nós que estamos fornecendo a "aleatoriedade" e não o programa. No exemplo acima de apenas escrever print([...]), adicionar inchaço não sistemático é equivalente a apenas escrever mais números "aleatórios" nessa lista codificada.

A compressão não é um teste preciso de aleatoriedade, e nem está olhando para uma imagem e dizendo "isso parece aleatório".

A aleatoriedade é testada por métodos empíricos . De fato, existem conjuntos de software / algoritmos especialmente projetados para testar a aleatoriedade, por exemplo, TestU01 e os testes de Diehard .

Além disso, sua imagem é de fato uma sequência de números 1D mapeada em um espaço e, portanto, não é uma boa representação de certos padrões que podem aparecer.

Se você examinasse sua imagem pixel por pixel, provavelmente encontrará muitos padrões curtos de valor crescente antes de uma queda repentina. Se você fosse criar um gráfico com o valor x sendo o número da amostra e o valor y sendo o valor obtido da função 'aleatória', provavelmente descobriria que seus dados se parecem com uma onda de dente de serra:

Este é o padrão feito por valores que aumentam sob aritmética modular (cujo cálculo é um exemplo de: tempo aumentando a uma taxa quase constante e & 0xFFagindo como mod 256).

Você está confundindo o conceito de números aleatórios de "números que parecem ser aleatórios".

Para entender a citação de von Neumann, precisamos entender o que significa "gerar números aleatórios". A resposta do Warbo vincula um excelente XKCD a esse fim:

Quando falamos sobre números aleatórios, não estamos falando sobre os próprios valores. Obviamente, um 4 não é mais aleatório que um 3. Estamos falando da capacidade de uma capacidade de terceiros prever esse valor melhor que o acaso. Um número aleatório é aquele que não é previsível. Às vezes, adicionaremos condições a isso. Um gerador de números pseudo-aleatórios criptograficamente seguros (CSPRNG) gera números que não podem ser previstos com mais probabilidade do que a chance aleatória se um invasor não conhece a semente / chave, mas se estamos falando de números verdadeiramente aleatórios (não pseudo-aleatórios), geralmente é definido como um número que não é previsível, mesmo com o conhecimento completo do sistema, incluindo quaisquer chaves.

Agora, seu exemplo, como muitos apontaram, não é determinístico. O programa não especifica de que valor sai System.nanoTime(). Portanto, não está na mesma classe que o uso de um CSPRNG para gerar números pseudo-aleatórios. O primeiro pode ser não determinístico, enquanto o segundo é determinístico se o valor da chave for determinístico. O primeiro contém operações que não estão definidas para ter valores determinísticos.

No entanto, você notará que eu disse que isso pode ser não determinístico. Esteja ciente de que System.nanoTime()não foi projetado para fornecer valores para essa finalidade. Pode ou não ser suficientemente não determinístico. Um aplicativo pode ajustar o relógio do sistema para que System.nanoTime()todas as chamadas ocorram em múltiplos de 256 nanossegundos (ou fechar). Ou você pode estar trabalhando em Javascript, onde as recentes explorações do Spectre levaram os principais navegadores a diminuir intencionalmente a resolução de seus temporizadores. Nesses casos, seus "números aleatórios" podem se tornar altamente previsíveis em ambientes para os quais você não planejou.

• Então, gerar números aleatórios com processos determinísticos ... pecado.
• Gerando números aleatórios com hardware aleatório dedicado ... não pecado.
• Gerando números aleatórios com aspectos não determinísticos de computadores ... talvez pecado.

Tudo depende do que você pretende. Se você está criptografando suas cartas de amor para Bob Esponja para que sua irmã não possa lê-las, as demandas impostas aos seus chamados números aleatórios são bem baixas. System.nanoTime()usado como você provavelmente é bom o suficiente. Se você estiver protegendo segredos nucleares contra um Estado estrangeiro avançado que os esteja buscando ativamente, considere o uso de hardware projetado para enfrentar o desafio.

Eu não acho que você tenha entendido a afirmação. O ponto é que, se houver um procedimento determinístico para gerar uma série de números "aleatórios" (ou qualquer coisa, na verdade), encontrar o padrão é apenas a tarefa de encontrar esse procedimento!

Portanto, sempre existe um método determinístico para prever o próximo número inteiro. É exatamente isso que não esperamos que aconteça se assumirmos a aleatoriedade!

Qualquer deterministicidade suficientemente complexa é indistinguível de estocástica.

- Da página de usuário de Wrzlprmft

Portanto, mesmo que algo pareça aleatório, por que diabos o modelaríamos como 'aleatório' se tivermos um procedimento determinístico para gerá-lo?

Este, penso eu, é o principal problema. Você demonstrou apenas alguma forma de indistinguibilidade do PRNG e 'verdadeira aleatoriedade'.

No entanto, que esses conceitos sejam iguais não se segue. Em particular, aleatoriedade é um conceito matemático, teórico . Já mostramos acima que, em teoria, considerar PRNG como 'verdadeira aleatoriedade' leva a uma contradição. Portanto, eles não podem ser iguais.

Eu acho que outros já apontaram, mas não foi isso que enfatiza, então deixe-me acrescentar à discussão.

Como outros já apontaram, há a questão de medir a entropia. Algoritmos de compressão podem lhe dizer algo, mas são independentes de fonte. Como você sabe mais sobre como os dados foram gerados, você provavelmente poderia construir um algoritmo muito melhor para compactá-lo, e isso significa que a verdadeira entropia é muito menor.

Além disso, você está entendendo um pouco o significado das frases "no computador" e "determinista". Você certamente pode executar operações não determinísticas no computador.

Além disso, na verdade, você acabou de fazer isso , mas não é tão aparente à primeira vista.

Um algoritmo determinístico típico para uma geração aleatória de números é ie. PRNG como gerador congruencial linear. Eles são stateful. Estado interno significa menos entropia, já que o próximo estado é determinado pelo anterior. Não vou me aprofundar nisso, provavelmente é óbvio para você. O ponto importante é que o algoritmo totalmente determinístico depende apenas do estado anterior, seja qual for.

Agora olhe para o seu algoritmo. No que é baseado? Quanto você tem? É determinístico?

  file.writeByte((byte) (System.nanoTime() & 0xff));

Vamos ignorar file.writee todos os problemas dos buffers de descarga, aguardando a E / S (você tentou adicionar um ruído pesado nos cabos do disco rígido por um momento? Não? Ei, você poderia fazê-lo. Ei, não é determinístico! :)) e vamos nos concentrar na fonte, é mais importante.

O tempo é algum tipo de estado. Varia, mas a maioria é a mesma coisa. É por isso que você tentou contorná-lo e levou o & 0xFF para abandonar a maior parte do estado. Mas você não descartou tudo, algum estado da leitura anterior pode vazar para a próxima, portanto, certamente não é totalmente não-determinístico *)

Mas não estamos interessados ​​nisso. Para "provar" que a citação está errada:

Qualquer um que tente gerar números aleatórios por meios determinísticos está, é claro, vivendo em um estado de pecado.

Você precisa provar isso por meios determinísticos.
O que nos interessa é: o seu algo é certamente totalmente determinístico ?

..e é óbvio que não é.

  System.nanoTime() & 0xff

Essa é uma medida de tempo. Tempo e medição . A parte de medição pode torná-la determinística, se o valor estiver em cache. Presumo que não, caso contrário, essa função não faria sentido. Então, se for lido em tempo real a partir da fonte, teremos valor baseado em tempo. Como ( suponho novamente ) que você não executou isso em um hardware dedicado para uma única tarefa, às vezes é possível que haja troca de contexto. Mesmo se você tivesse um hardware dedicado para uma única tarefa, a medição do tempo ainda pode não ser determinística, devido às variações de temperatura / umidade na fonte de tempo, nos tempos de relógio do barramento, etc.

Eu concordo totalmente que estou exagerando aqui. Os desvios não serão tão grandes para causar muito impacto (embora nanotimepossam ser reais ). Mais importante, nanotimepretende ser rápido. Não lê da fonte em tempo real. É baseado na instrução interna do processador / contagem de ciclos. Isso é realmente determinístico, se você garantir que nenhuma alternância de contexto.

Meu argumento é que pode ser realmente muito difícil executar um algoritmo determinístico verdadeiramente 100% se você o basear no prazo, e você não tem o direito de refutar essa citação, a menos que possua meios totalmente determinísticos.

*) Curiosamente, você provavelmente poderia aumentar a aleatoriedade real se seguir o caminho mais hardcore. Faça & 0x01, pouco a pouco, e aguarde um tempo perceptível antes de ler cada bit. A geração de dados dessa maneira seria ridiculamente longa, mas eu na verdade argumentaria que isso poderia ser considerado quase verdadeiramente aleatório; o IIF está sendo executado em não RTOS e também o IFF a cada 'tempo perceptível' é alto o suficiente para garantir que os dados subjacentes O SO foi dormir ou alternou com o contexto para outra tarefa.

Acho que a resposta que você precisa começa com este comentário que você mesmo fez em resposta a outra resposta:

O padrão é resultado da interação de Java, JVM, SO, CPU + caches, disco rígido, a música Trance que eu estava transmitindo que consome ciclos de CPU / RAM e tudo mais. O padrão simplesmente surge da linha de código Java dentro de um loop for / next. Uma parte significativa da entropia vem dos circuitos de hardware subjacentes.

Você já percebeu isso, eu acho: você não usou meios determinísticos para criar o padrão.

Você usou um computador, cuja parte não desprezível é determinística, mas a entropia veio de fontes externas não determinísticas (ou pelo menos não determinísticas para todas as intenções e propósitos práticos no momento): você ou o mundo externo interagindo com o computador (e em menor grau, quaisquer imperfeições físicas no hardware do computador que possam afetar o tempo das coisas).

A propósito, isso é uma grande parte de como os sistemas operacionais modernos propagam seus geradores de números aleatórios disponíveis para os programas: aproveitando a entropia nas interações com seu hardware e o usuário que esperamos que não seja previsível para um invasor.

A propósito, a entropia do mundo externo é na verdade um problema que deve ser tratado até hoje em criptografia de outra maneira bem codificada: computadores com comportamento previsívelna inicialização e durante o tempo de execução, como aqueles com armazenamento somente leitura ou inicializados pela rede e que possuem um ambiente de rede previsível (não conectado a uma rede ou a carga de trabalho na rede é baixa o suficiente para que tudo seja entregue dentro da rede) uma quantidade confiável de tempo), e que executam o mesmo conjunto limitado de software com comportamento aproximadamente consistente, podem superestimar a entropia que estão recebendo desses componentes supostamente imprevisíveis e acabar gerando números muito mais previsíveis do que em uma estação de trabalho típica que faz todo tipo de outras coisas para você (streaming de música, sincronização com o dropbox, o que for) em segundo plano.

Eu acho que a maioria das respostas está se concentrando em verificar se a verificação dos últimos oito bits de medição de tempo em nanossegundos em um loop é uma boa maneira de obter essa entropia. Essa é uma pergunta muito importante a ser respondida corretamente antes de você usar o método no seu exemplo como um esquema de geração de números aleatórios na prática , mas é uma pergunta separada da que eu acho que você está perguntando.

Para adicionar respostas anteriores, aqui está uma maneira fácil de pensar sobre essa pergunta.

É tudo sobre a diferença entre aleatório e determinístico . Iremos a Von Neumann e o que ele estava dizendo depois.

Números aleatórios

Um verdadeiro gerador de números aleatórios não teria um padrão, nem mesmo oculto em segundo plano, que poderíamos usar para prever o próximo número, dada a sequência até agora. Em um mundo ideal, você poderia saber tudo o que há para saber no universo físico e sobre o sistema, nanossegundo por nanossegundo, e ainda assim seria inútil tentar prever o próximo número produzido.

Esse é um caso ideal - em termos práticos, chegamos lá ao misturar muitas fontes que não são "aproximações ruins" para aleatórias, ou são realmente aleatórias, ou que matematicamente misturam as coisas o suficiente para que você possa matematicamente provar que elas se aproximam de imprevisibilidade e falta de viés para quaisquer números ou padrões específicos.

• Fontes "boas" são coisas semelhantes a esperar por um processo de decaimento radioativo ou outro processo quântico inerentemente imprevisível. Saída de um semicondutor sensível ao calor. Ruído aleatório em um diodo ou outro material elétrico. Contando fótons do sol.

• Misturado a isso, também podemos adicionar alguns que consideramos "ruins" que ajudam, pois não têm nenhuma conexão com eles: Aguardando o próximo clique de mouse ou pacote de rede. Última parte do microtime na próxima gravação do arquivo. Saída de uma função gerador de número pseudo-aleatório "conhecido, mas matematicamente bastante aleatório". Entropia anterior de usos anteriores de números aleatórios.

O objetivo aqui é obter um número que ainda não pode ser previsto , qualquer que seja o universo que você conhece , e é estatisticamente mais provável que isso, sem padrão matemático detectável, viés ou previsibilidade e sem correlação com um evento que poderia ser monitorado e usado para previsão. (Ou, se estiver correlacionado com um evento, é feito de uma maneira que torna a conexão incrivelmente tênue, como "dígito em nanossegundos apenas após o último clique do mouse")

Números determinísticos

Os matemáticos podem provar coisas sobre fórmulas e funções. Portanto, é possível provar que uma função, quando chamada repetidamente, não fornece nenhum viés ou preferência a nenhum padrão, além do padrão simples "essas são as saídas dessa função se chamadas repetidamente".

Por exemplo, se você escolher um número, digamos entre 1 e 10 milhões, escrever em binário e "hash" repetidamente, obterá uma sequência de dígitos bastante aleatória. É quase aleatório - mas na verdade não é aleatório. Você pode prever, considerando o algoritmo e qualquer estado, qual será o próximo número.

Chamamos isso de "pseudo-aleatório" porque parece e parece ser principalmente aleatório, mesmo que não seja.

Aqui está um bom exemplo. Pense nesta sequência de "números aleatórios" de 3 dígitos: 983, 367, 336, 244, 065, 664, 308, 602, 139, 494, 639, 522, 473, 719, 070, 217. Digamos que eu lhe digo Eu posso gerar um milhão de números da mesma maneira. Você pode passar para um estatístico que confirmará (digamos) que eles são distribuídos igualmente ou o que quer que seja. Não há um padrão previsível óbviob. Eles parecem bem aleatórios, certo? Mas agora eu lhe digo que eles são realmente

o 500º + dígito de Pi, agrupado em 3s.

De repente, por mais aleatório que seja

dígitos do Pi

pode ser, você pode prever imediatamente que os próximos 2 números serão 986 e 094.

Para ser claro, não sei exatamente o quão aleatório o

dígitos do Pi

são. Será estudado e a resposta bem conhecida. Mas o ponto é o seguinte: em princípio, a mesma conclusão é verdadeira para qualquer fonte produzida após um processo determinístico .

Entre

Entre os dois, há toda uma gama de "coisas que parecem aleatórias e geralmente são aleatórias até certo ponto". Quanto mais aleatoriedade e quase aleatoriedade uma pessoa puder se misturar, menor a probabilidade de que a saída seja capaz de ter qualquer padrão detectado ou qualquer saída prevista, matematicamente.

Voltar para von Neumann e sua pergunta

Como você pode ver, os resultados determinísticos podem parecer aleatórios, mas podem, estatisticamente, ser distribuídos aleatoriamente. Eles podem até usar dados "secretos" ou de mudança rápida que não temos nenhuma esperança realista de saber. Mas, desde que sejam determinísticos, os números ainda podem nunca ser verdadeiramente aleatórios . Eles só podem ser "próximos o suficiente para aleatoriamente, e estamos felizes em esquecer a diferença".

Esse é o significado da citação que você deu. Um processo determinístico simplesmente não pode fornecer números aleatórios. Só pode fornecer números que parecem ser e se comportam de maneira semelhante a números aleatórios.

Agora, podemos reformular sua pergunta da seguinte forma: "A saída do meu computador (ou de qualquer outro moderno) pode parecer e se comportar totalmente aleatoriamente, isso significa que a citação de von Neumann está desatualizada e incorreta?"

O problema ainda é o seguinte: Mesmo que a saída do computador possa parecer e se comportar aleatoriamente, ela ainda pode não ser verdadeiramente aleatória . Se é calculado apenas deterministicamente, isso significa que não há nada que não tenha sido causa-efeito predeterminável sobre obter o próximo número (é isso que "determinístico" significa nesse sentido). Começamos com alguns dados existentes (conhecidos), aplicamos um processo conhecido (complexo ou confuso ou o que for) e obtemos o que parece ser um novo "número aleatório". Mas não é aleatório, porque o processo foi determinístico.

Se você disser que seu método incluirá um gerador aleatório de hardware real, para corrigi-lo (como um número aleatório gerado a partir de decaimento radioativo ou ruído em um semicondutor), sua resposta poderá agora ser aleatória - mas seu método por definição não é mais determinístico , precisamente porque você não pode mais prever as saídas (ou efeitos) dadas as entradas / dados iniciais (causas) .

Von Neumann vence nos dois sentidos, quase por definição!