Diamo un'occhiata a come potrebbe accadere una cosa del genere:
Un esempio classico è il DRBG dual-EC che impiega un RNG back-doored per creare un attacco generale contro TLS. L'altra metà di questo attacco oltre il vulnerabile RNG è un meccanismo per rivelare all'attaccante lo stato dell'RNG al momento dell'uso per consentire all'aggressore di prevedere il rimanente contenuto "casuale" prodotto da il RNG della vittima.
Pertanto, in TLS è implementata una funzione non standard denominata Casuale esteso , attraverso il quale un server TLS scarica una serie di output del suo RNG nella negoziazione TLS, che viene rivelata a chiunque orecchi la conversazione. Infatti, è stato calcolato che questa funzione migliora l'attacco Dual EC di un fattore 64000X.
Quindi un sistema che utilizza un RNG diverso per il componente "Extended Random" rispetto alla derivazione della chiave sarebbe significativamente (64000x) meglio protetto da questo attacco.
Ma non completamente immune. L'RNG è di per sé vulnerabile, anche se si mantiene separata la casualità "di alto valore". Una seconda istanza RNG è utile, ma non infallibile.
L'obiettivo di un tale sistema è di proteggere dall'ignoto, quindi misurare la sua utilità è al massimo difficile. E altre protezioni potrebbero funzionare meglio.
Ad esempio, i valori casuali XORed con qualsiasi cosa sono ancora casuali. Pertanto, se l'applicazione esegue più RNG e XOR come output, la qualità della casualità ottenuta è uguale alla massima qualità di tutti gli RNG di input. Quindi, se un'applicazione XORs un intero elenco di RNG di qualità variabile, quindi se uno qualsiasi degli RNG è sicuro, anche l'output sarà sicuro.
Quindi quanto sarebbe buona questa tecnica nella protezione da minacce sconosciute? Non lo sappiamo Ma quello che possiamo dire è che proteggerebbe contro le minacce conosciute come la doppia backdoor EC sopra menzionata.