Hermite-SVP

Os valores de Média Final dos FQs de cada AC, não são suficientes para definirmos qual gerador utilizar, ou se o uso de um AC como gerador é vantajoso ou não em relação a uma outra alternativa.

Nossa análise avança com o objetivo de fornecer um diagnóstico ou um indicador que possa sinalizar qual o melhor gerador utilizar e, para isso, é preciso estimar as vantagens e gastos relacionados à produção dos bits de cada gerador.

Nessa análise é preciso chamar a atenção para o fato de que só usaremos a avaliação do NIST onde os 15 testes tenham sido aprovados para usarmos o parâmetro Média Final como uma métrica relativa válida.

É preciso saber o custo de processamento de cada AC, isto é, quanto custa a geração de bits e, para isso, devemos considerar o número de operações executadas pelos programas que implementam cada tipo de AC. Segundo [CORMEN 2009] o tempo de execução (custo) de um algoritmo, com uma particular entrada, corresponde ao número de operações primitivas ou passos executados.

Neste trabalho simplificamos a contagem dos passos da seguinte forma: cada linha de código-fonte de cada algoritmo foi quebrada em suas operações básicas (aritméticas, lógicas e de atribuição) e cada uma destas operações foi considerada como tendo um mesmo custo temporal unitário. Entendemos que o erro causado por tal simplificação é pequeno, já que os processadores modernos têm sido capazes de realizar muitas operações aritméticas (incluindo multiplicações) e lógicas em apenas um ciclo de máquina. Além disso, na comparação entre diferentes ACs, os códigos são muito semelhantes entre si e as linhas têm praticamente um mesmo conteúdo em cada um deles. Um erro maior deverá surgir na comparação entre ACs e o LRNG, visto que as linhas dos respectivos códigos-fonte têm menos similaridades, mesmo que sejam códigos escritos em uma mesma linguagem de programação. Ainda assim, devido à maior eficiência dos processadores modernos, entendemos que o nível de tal erro seja reduzido. Obviamente, o tempo real de execução vai depender muito de otimizações feitas no nível do compilador e no nível do processador. Estamos considerando que todos os programas estarão sujeitos às mesmas otimizações. Além disso, praticamente todos os tipos de CPU utilizam recursos de cache que agilizam a re-execução de instruções executadas recentemente, o que também afeta o tempo de execução de cada operação. A simplificação adotada nesta avaliação incorre em outros tipos de imprecisão e precisa ser melhorada em trabalhos futuros.

Em resumo: cada operação em cada linha do código-fonte de cada gerador avaliado é considerada como tendo um custo unitário e o custo total é a soma de todas as operações no núcleo principal dos programas, isto é, naquela parte que efetivamente gera os bits desejados. Não são contadas as operações em linhas antes ou depois deste núcleo, já que são executadas poucas vezes e seu impacto no tempo total de execução é desprezível.

Portanto, apesar de considerarmos que os resultados de comparação de custos entre os PRNGs analisados estão bem próximos dos custos reais, eles devem ser tomados com a devida cautela como indicadores das diferenças entre tais algoritmos. Um importante trabalho futuro a ser desenvolvido é aquele de fazer uma contagem mais precisa das operações efetivamente executadas (diferenciando adequadamente os tempos de operações lógicas, aritméticas e de atribuição) em cada linha de cada código, de maneira a oferecer uma comparação e um veredicto mais confiáveis sobre a relação entre todos os geradores analisados.

Acreditamos que a relação custo/benefício possa ser mais interessante para comparação dos ACs entre si e entre eles e o LRNG. Assim, utilizaremos como custo o número total de operações executadas para produção dos bits e como benefício, a Média Final de cada gerador analisado. Na Tabela 5.5 é apresentado o número de operações necessárias, para produção dos bits referentes a cada tipo de AC.

Tabela 5.5 - Número de operações necessárias para gerar um bit

Como ressaltado anteriormente, restringimos a comparação aos blocos principais de código dos geradores que são responsáveis pela produção do grande volume de bits demandado pela aplicação. Ou seja, avaliamos as operações que atualizam o estado e produzem novos bits no AC. No caso do LRNG, consideramos as operações do algoritmo SHA-1 que produzem, a partir de sementes aleatórias, os bits disponibilizados para a interface /dev/urandom.

As listagens completas dos programas utilizados na geração dos bits aleatórios e avaliados aqui podem ser encontradas na plataforma GitHub (https://github.com/regras/ca_prng).

Como a cada iteração dos algoritmos pode ser produzida uma quantidade diferente de bits, iniciamos um estudo para encontrar equilíbrio entre os parâmetros. A ideia foi buscar a quantidade de iterações necessárias em cada um dos ACs de modo a gerar um número de bits similar aos gerados com o SHA-1. Deve ser observado que o SHA-1 no LRNG disponibiliza a cada iteração na saída do gerador apenas metade de seus 160 bits.

Pode-se observar na Figura 5.1 a relação de bits produzidos pelo SHA-1, por operações executadas; da forma como este algoritmo é usado no LRNG, a cada 10.428 operações são produzidos no mínimo 8 e no máximo 80 bits. Uma discussão detalhada pode ser encontrada no artigo de Gutterman et al. [GUTTERMAN 2006].

Figura 5.1 Geração de bits do LRNG - SHA-1

Um AC unidimensional que produza bits somente a partir de uma coluna, gasta um bom tempo para produzir todos os demais bits de seu estado e não os aproveita como bits aleatórios. Isso gera um grande desperdício e torna difícil a competição entre um AC e um SHA-1. Uma forma de contornar este problema é aproveitar não apenas um, mas uma certa fração de todos os bits produzidos pelo AC a cada iteração.

Para que os ACs utilizados possam competir em número de operações, realizamos testes utilizando 25% e 50% das colunas para coleta dos bits.

Observamos na Figura 5.2 um exemplo de como conseguimos equiparar a relação de bits produzidos pelo número de operações realizadas. Na coleta de 50% dos bits produzidos a cada execução de um AC de tamanho 64 bidimensional conseguimos extrair 32 bits. Logo, foi preciso executar 3 vezes o AC para conseguirmos obter 96 bits, valor mínimo para se alcançar (ou ultrapassar) dos 80 bits gerados de uma vez pelo SHA-1. A Tabela 5.6 mostra os resultados para todas as configurações de tamanhos do AC bidimensional de 64 e 128 células.

Também é possível verificar que o número de operações para alcançar os 80 bits com o SHA-1 é de 10.428, enquanto o número de operações com o AC bidimensional no tamanho 64 (4x16) é de 6.288, menor que o SHA-1.

Figura 5.2 Geração de bits pelo AC bidimensional raio um coleta de 50%

Desse modo, enquanto o custo é determinado pelo número de operações necessárias para produzir 80 bits, o benefício é estimado pela qualidade da sequência aleatória expressa pela métrica Média Final descrita anteriormente. Sendo assim, a relação custo/benefício R é dada pela Eq. (5.1).

R = Operações Executadas / Média Final (5.1)