A aleatoriedade de von Neumann no pecado não é mais aplicável?
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:
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.
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⌣⌣
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): -
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.
Eu acho que você está confundindo "Não consigo ver um padrão" / aleatoriedade cotidiana com aleatoriedade matemática / estocástica.
@ Rafael eu não. Algoritmos de compressão matemática fazem. E qual é o sentido dos sistemas operacionais em tempo real se todo o software é sempre determinístico? Estou apenas perguntando sobre o determinismo em termos de bits.
— Paul Uszak 27/03
Você está em conflito "em um computador" e "com meios determinísticos".
Seu problema fundamental aqui é que você começa com "Eu não entendo como esse padrão é gerado" e conclui "ninguém pode entender como esse padrão é gerado". Isso não está certo e, dado o seu perfil SE, você certamente está familiarizado o suficiente com a criptografia para saber que ela não segue. É fácil criar um sistema que você não pode quebrar, mas o verdadeiro desafio é criar um sistema que outras pessoas também não possam quebrar.
Eu acho que a maioria das definições de "determinístico" excluiria algoritmos que chamam System.nanoTime().
— bmm6o
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.
Para expandir o ponto do algoritmo de compactação, o PNG, como a maioria dos algoritmos de compactação, procura padrões nos dados. Um algoritmo que procura por padrões nas alterações nos dados provavelmente comprimirá bem a imagem de exemplo.
@ Marcos - na verdade, PNG não analisar os padrões de mudanças (ele usa compressão deflate aplicada à diferença entre o valor de pixel real ea saída de um de uma série de heurísticas de previsão que são baseados nos tipos de mudança já vistos na imagem) , no entanto, a análise realizada é bastante simplista, pois foi projetada para poder ser executada com eficiência em dispositivos incorporados durante os anos 90. Uma pergunta mais interessante seria a precisão de um algoritmo de compactação com perdas, por exemplo, qual é o erro RMS do JPEG ou algum tipo de compactação fractal aplicada à imagem?
@Jules: O que importa não é que o PNG seja simplista, mas que ele foi projetado para comprimir os tipos de padrões que provavelmente apareceriam em muitos tipos de imagens. Se você tirar uma foto típica, por exemplo, 123x234 pixels e alterá-la para 234x123, mantendo os pixels na mesma ordem (a primeira linha da nova imagem continha 123 pixels da linha superior da antiga, mais 111 pixels da segunda linha, a próxima linha da nova imagem continha os últimos 12 pixels da segunda linha original, toda a terceira linha original e 99 da quarta, etc. PNG seria ...
... provavelmente não compactará a imagem resultante tão bem quanto a original, pois não haveria mais a mesma relação espacial entre as linhas, apesar do fato de a segunda imagem conter exatamente os mesmos pixels, na mesma ordem exata, como o primeiro.
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.
Após a reflexão (não do tipo Java), não tenho certeza de que nanoTime () seja necessário. Este era apenas um cronômetro ersatz para rastrear o progresso do loop ao seu redor. Se o nanoTime () for removido, acredito que a taxa de execução do próprio loop (sem chamadas diretas ao hardware) também não seria determinística, pois é um software que ainda interage com o ambiente do computador. Esta é toda a base da programação em tempo real no kit incorporado. Estou bastante convencido de que a citação de von Neumann não é mais aplicável a um computador moderno.
@PaulUszak Quantas vezes tenho que dizer isso? Von Neumann diz que você não pode gerar números aleatórios deterministicamente. Você continua dizendo que Von Neumann está errado porque você poderia usar o não-determinismo. É como se você estivesse repetidamente afirmando que a afirmação "leva muito tempo para caminhar de Paris a Berlim" não se aplica ao mundo moderno porque você pode voar entre essas duas cidades. E daí? A citação é sobre caminhar e isso ainda leva muito tempo. A citação de Von Neumann é sobre sistemas determinísticos, e eles ainda não podem operar aleatoriamente.
@PaulUszak É literalmente impossível. Se você acha que possui um algoritmo determinístico cujo comportamento não é determinado por suas entradas, é apenas uma questão de identificar onde a entropia é introduzida.
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.
@PaulUszak Claro, um PRNG determinístico não pode ser usado como OTP. Mas o OTP é um caso muito especial, pois, por definição, requer uma chave verdadeiramente aleatória. AFAIK, para qualquer outra coisa, basta um PRNG seguro semeado aleatoriamente (a semente deve ter, por exemplo, 128 ou 256 bits de entropia, dependendo do nível de segurança necessário).
"Quando você realmente precisa de algo aleatório" → Você basicamente nunca precisa de uma aleatoriedade verdadeira. Em vez disso, você precisa de uma falta de correlação. A verdadeira aleatoriedade é uma garantia forte, mas basicamente todos os casos são igualmente satisfeitos por um CSPRNG moderno e uma semente imprevisível.
@maaartinus Você não está me entendendo direito. Estou dizendo que você não precisa de verdadeiras sementes aleatórias, só precisa de sementes não correlatas imprevisíveis.
— Veedrac 29/03/19
Como exemplo, eu criei um arquivo de texto com 1 milhão de números sequenciais. gzipsó conseguiu obter 63% de compactação, embora quase não haja entropia. Só conseguia detectar as repetições como999919999299993...
— Barmar 30/03
@PaulUszak Esse era o meu ponto - a taxa de compactação não é um bom indicador de entropia, indica se o algoritmo de compactação específico é capaz de detectar o tipo de padrão que seus dados contêm.
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.
"encontre o programa determinístico mais curto que produz a mesma sequência de bytes" - esse é o ponto principal do meu argumento, ponto de exclamação. Você não pode repetir esta imagem. É único o tempo todo. 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. Não pode ser codificado.
— Paul Uszak 29/03
A complexidade de @PaulUszak Kolmogorov mede a "aleatoriedade" de um valor específico , como a primeira imagem que você postou; ou a segunda imagem que você postou; ou um instantâneo desta página HTML; etc. Se você se importa com o processo que gerou uma imagem (determinística ou não), outras medidas, como informações de Shannon, seriam mais adequadas; Acabei de ver que nenhuma outra resposta mencionou a complexidade de Kolmogorov. Ambos são métodos úteis, pois nos dizem coisas diferentes.
— Warbo 29/03/19
@PaulUszak Considere o teste que você fez compactando essas imagens como arquivos PNG e comparando o tamanho do arquivo. Ao descompactar um PNG, você recebe exatamente a mesma imagem em que começou; é determinístico; você não obtém uma imagem aleatória diferente. Isso torna seu teste de compressão inútil? De modo nenhum! A complexidade de Kolmogorov é como uma versão extrema do seu teste PNG: em vez de compactar em um arquivo PNG, compactamos em um programa de computador (determinístico). Eles podem ficar muito pequenos, enquanto ainda conseguem reproduzir todos os dados originais.
— Warbo 29/03
@PaulUszak Com base no seu comentário, parece que você já percebe tudo o que é necessário para provar a citação: você não usou meios determinísticos para criar o padrão, porque depende da entropia que você ou o mundo exterior (hardware e servidores de rede) de onde você está transmitindo, o conteúdo do fluxo etc.) foi introduzido no seu sistema. Se a verificação ou não dos últimos oito bits de medições de tempo em nanossegundos, feita em loop, é uma boa maneira de entender que a entropia é uma pergunta separada, na qual muitas respostas estão sendo desligadas, mas é um tópico separado.
— Mtraceur # 29/18
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ê parece ter o conjunto errado de testes. Todos os seus testes são testes de aprovação / reprovação aleatórios. Eles não medem a entropia, que é o cerne desta questão. A compactação é uma medida de entropia totalmente válida para dados não IID (consulte Medidas de entropia NIST). Na verdade, é um dos poucos que pode ser razoavelmente implementado sem doutores em programação e matemática. Embora você esteja certo sobre o dente de serra. É assim, mas os dentes não são deterministicamente aleatórios, nem regulares como você mostrou. Daí a entropia.
@PaulUszak Essa medida faz sentido se depender do algoritmo de compactação?
— kutschkem
@kutschkemVamos uma das medidas de entropia padrão no NIST SP 800-90B. Também é fácil de fazer. De que outra forma você pode medir entropia sem IDI? E algos de compressão são assintóticos para um limite inferior, daí a divisão por 2. A fórmula de Shannon não funciona aqui.
— Paul Uszak 28/03
@PaulUszak - para fins de criptografia, devemos assumir que o método de geração é conhecido por um invasor. Conhecer o método pelo qual esses dados foram gerados quase certamente permite escrever um algoritmo de compactação para ele que seja melhor que PNG ou qualquer outra abordagem que o teste NIST faça, os quais não assumem nada (ou, no caso de PNG, nada que esteja realmente correto) sobre a fonte dos dados.
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.
— Cort Ammon - Restabelecer Monica
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.
Err, você tem certeza de que entendeu essa citação? Você parece estar se contradizendo ..?
Eu sou? Você pode esclarecer? Eu pretendia dizer que, se você deseja tratar algo como aleatório, gerá-lo deterministicamente não faz sentido, mesmo que alguém não consiga ver a diferença.
@PaulUszak Você afirma que, porque algo lhe parece estocástico, é aleatório. Mas, de fato, apenas porque algo parece estocástico não significa que é aleatório - poderia muito bem ser um processo determinístico suficientemente complexo.
— Gilles 'SO- stop be evil' '' -
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?
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:
Você precisa provar isso por meios determinísticos.
O que nos interessa é: o seu algo é certamente totalmente determinístico ?
..e é óbvio que não é.
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.
NNUMAUMASS
Algo como isso era exatamente o meu ponto atrás "[você] poderia construir uma muito melhor [Compressão] algoritmo"
Não fique fixo no valor exato de 5,3. Independentemente de quão melhor você possa fazer algo de compressão (você não pode, como eu usei um dos melhores do mundo - paq8px), o que permanece incompressível é pura entropia. Essa é uma das principais definições de aleatoriedade. Ou você está sugerindo que qualquer coisa pode ser compactada para zero bytes? Os criadores de pombos discordariam.
O 0xff existe porque você não pode criar uma boa imagem usando números inteiros de 64 bits. E se você usa 0x01, tem que mexer com o manuseio de bits que eu não poderia me incomodar. Isso é tudo. A entropia do NIST e minhas próprias medidas sugerem entropia em bits mais altos de qualquer maneira (~ 5 deles).
+1, e esta me parece a melhor resposta até agora: a única fonte de entropia na situação em questão é precisamente as inconsistências em quanto tempo passa entre cada leitura do relógio ! E isso vem de uma mistura de detalhes, como o agendador do sistema operacional e como o hardware funciona e detalhes como o que o usuário fez naquele sistema até aquele momento que, por sua vez, afeta indiretamente coisas como o que mais precisava de agendamento ou quanto tempo o disco os acessos ocorreram devido à fragmentação ao longo do tempo ou o que estava em swap / memória / cache ou que atividade de rede / etc estava em andamento.
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.
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
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 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) .