Algumas questões sobre os parâmetros do kernel.random. *

Question

Estou tentando entender os parâmetros do kernel do Linux que estão sob /proc/sys/kernel/random/ , mas tenho alguns problemas. Você poderia me ajudar a descobrir algumas coisas?

1. Qual é o parâmetro boot_id usado? Eu encontrei apenas informações geradas na inicialização, mas não consegui descobrir o motivo.
2. Eu sei que o tamanho do pool de entropia é constante (4096bits) e não pode ser alterado. Por que o número é tão pequeno? Não poderia ser, digamos, 1048576 ou mais? Talvez não seja bom ter muitos bits de entropia disponíveis?
3. É semelhante à segunda questão, mas diz respeito ao parâmetro entropy_avail - qual é o propósito de não preencher todo o conjunto de entropia? Quando eu verificar o parâmetro, ele oscila em torno de 1000 bits, mas o tamanho do pool é 4096. Quando entropy_avail atinge o limite definido em write_wakeup_threshold , ele cai um pouco (geralmente 100) e aumenta novamente até o ponto especificado no parâmetro write_wakeup_threshold . Então, por que precisamos deste 4096 em poolsize de entropia?
4. Existe algum motivo para aumentar ou diminuir o valor dos parâmetros read_wakeup_threshold e write_wakeup_threshold ? O primeiro apenas adormece o processo que deseja entropia do dispositivo /dev/random , mas qual é a diferença quando eu configuro isso para 64, 128 ou 256? Apenas fica por um período de tempo um pouco mais longo, ou talvez haja algo mais?

Answer 1

O parâmetro de ID de inicialização não é relevante para as estatísticas de entropia. Ele identifica apenas a inicialização atual, o que é útil se você quiser saber se o computador foi reinicializado ou algo assim.

O pool de entropia armazena dados aleatórios de uma maneira definida pela implementação, projetada para ser tratada como uma caixa preta. Em geral, é legal ter tantos bits de entropia quanto possível, se você confiar em ter uma fonte de entropia; ter muito, no entanto, é um desperdício. Se seu servidor faz muita criptografia (gerando chaves de sessão TLS, por exemplo, ou gerando freqüentemente chaves RSA ou até mesmo tokens de segurança) ou precisa de números aleatórios strongs o tempo todo por algum outro motivo, você quer muita entropia e até dispositivos pode obter esse problema gigabit fluxos dele (de uma fonte física).

Geralmente, o tamanho do pool pode ser alterado, ecoando um novo tamanho no arquivo de tamanho do pool. O kernel armazenará a entropia que ela adquire de várias fontes (o tempo relativo dos eventos é uma maneira popular), bem como a entropia que ela adquire de entrada para /dev/random (via RNDADDENTROPY ioctl; simplesmente gravar nesse dispositivo altera os dados, mas não adiciona bits nominais de entropia). Se você tivesse uma fonte de entropia de hardware que você estava subutilizando, você realmente deseja que esse parâmetro não seja infinito.

O limite de ativação de gravação raramente é usado, mas é bom para o sequenciamento; o ganho de desempenho que ele fornece deve ser mínimo. O que ele faz é ativar o bloqueio de dispositivos para gravar no pool de entropia (ou seja, fontes que usarão o ioctl mencionado anteriormente para adicionar entropia ao pool) quando o pool ficar baixo. Não terá necessariamente o efeito de adicionar entropia, obviamente.

O limiar de leitura-ativação é o oposto; esse é o número de bits de entropia necessários para estar disponível (ou seja, o número indicado em entropy_avail) antes de permitirmos que qualquer coisa leia% em /dev/random . /dev/urandom ignora esse parâmetro (já que leituras dele não são bloqueadas e não esperam a entropia, permitindo que dados pseudo-aleatórios sejam lidos).