A razão para desconfiar do RdRand é fácil de entender, e eu compartilho dela: trata-se de uma instrução interna dos chips da Intel (Ivy Bridge em diante) que retorna números aleatórios – como aqueles necessários para gerar chaves criptográficas, hashes de sessões e outras ações que a NSA teria interesse potencial em quebrar e – se acreditarmos nos vazamentos de Robert Snowden – infiltrou ao menos um grande fabricante norte-americano de chips para comprometer. O risco aumenta em ambientes virtualizados, comuns "na nuvem", porque aí a máquina virtual também pode comprometer a aleatoriedade.
A desconfiança do RdRand se amplia porque desenvolvedores da Intel de fato tentaram influenciar o desenvolvimento do kernel para que o RdRand fosse a única fonte de entropia para o /dev/random, o que seria uma péssima ideia mesmo que desconsideremos a hipótese de que o chip ou a VM possam estar intencionalmente comprometidos.
Mas buscar fontes de entropia é complicado. Eu faço sorteios com base em uma fonte externa que capta ruído eletromagnético na atmosfera, por exemplo, os quais geralmente são ainda menos previsíveis que os bons algoritmos do ramo. O kernel Linux usa uma composição de múltiplas fontes, incluindo informações fora do seu controle direto sobre o sistema em execução (o que é bom) e recursos específicos do hardware, como o RdRand – que, sozinho, seria uma má ideia.
Mas combinar fontes de entropia aumenta a imprevisibilidade, mesmo que uma das fontes possa estar comprometida. Em uma discussão a respeito no Slashdot, o mantenedor do /dev/random do kernel, Theodore Ts'o, explicou com um exemplo, para não ter de entrar na teoria: usar uma fonte de entropia controlada diretamente pela NSA, ou pelos seus concorrentes na China ou Rússia, é muito ruim se ocorrer isoladamente. Mas se as combinarmos – e assumindo que elas não confiam uma na outra –, teremos uma boa fonte de entropia, formada pela combinação de 3 ruins.
O que acontece no /dev/random, naturalmente, é similar – e prevê até mesmo a possibilidade de a CPU detectar que o resultado do RdRand está sendo combinado a algum outro valor. E desativar o uso do RdRand é bem simples: é uma das opções de configuração do kernel.
Não que o estilo da resposta me agrade, mas ao menos foi eficaz: logo em seguida o autor cancelou sua petição.