"at random"?

at random: without method or conscious decision : he opened the book at random.

New Oxford American Dictionary

A poche ore dalla notizia che Colossus è stato rimesso in funzione rimbalza sulla rete un inquietante tanto provocatorio articolo di Schneier, relativamente all'algoritmo di generazione di numeri pseudocasuali DUAL_EC_DRGB.
Che questo algoritmo avesse qualche problemuccio, questo è noto dal 2006 (qui e qui) mentre ad Agosto due ricercatori, Ferguson e Shumow, hanno reso noto uno studio che dimostra delle "incongruenze" nella specifica pubblica dell'algoritmo stesso.
DUAL_EC_DRGB si basa su un algoritmo a curve ellittiche, ed è stato presentato in una pubblicazione del NIST della serie 800 assieme ad altri tre. L'inserimento di tale algoritmo, a quanto sostiene Schneieir, deriva dalla sponsorizzazione dell'NSA, e da quanto detto sopra, vi sono sospetti sul fatto che tale sponsorizzazione non sia del tutto disinteressata.

Il perchè deriverebbe dall'esito del lavoro di Shumow e Ferguson: l'algoritmo DUAL_EC_DRGB utilizza delle costanti, tuttavia non viene spiegato come queste siano state scelte; tali costanti, per caratteristiche delle funzioni matematiche utilizzate, sono in relazione con un altro gruppo di numeri, ad oggi non noti.
E' un pò come se si utilizzassero le funzioni matematiche di RSA per generare numeri casuali, e nell'implementazione suggerita fossero indicati i parametri di una chiave pubblica: matematicamente sappiamo che a questi numeri sono associati degli altri che costituiscono la chiave privata.
Ora, Shumow e Ferguson non sono riusciti a determinare tali numeri, tuttavia hanno dimostrato che esistono. Nè sanno dire se chi ha scelto i parametri suggeriti per la generazione di numeri casuali (la scelta potrebbe essere stata a sua volta casuale) conosce a sua volta quelli segreti, ma è assodato che chi riuscisse a determinarli (problema assai complesso!) sarebbe in grado, per design dell'algoritmo, di predire i numeri generati.
Se Schneier ha ragione, l'NSA ha spinto fortemente per includere questo algoritmo, un errore di design assume quindi una valenza diversa.
Nè il problema può essere sottovalutato per il fatto che le costanti indicate nel documento del NIST sono indicate come opzionali: tipicamente, le implementazioni tendono ad affidarsi, perchè non dovrebbero?, agli standard anche in questi particolari, dando per scontato, di nuovo perchè non dovrebbero?, che tali "magic number" siano migliori piuttosto che altri.
D'altro canto, dato che tali sviluppi richiedono competenze molto verticali, e dato l'impatto che un errore software avrebbe su prodotti basati su di essi, ridurre al minimo le funzionalità a fronte di una soluzione consolidata sarebbe una buona politica.

Schneier continua con altre considerazioni: l'algoritmo non comporta dei vantaggi in termini prestazionali (è addirittura più lento degli altri di tre ordini di grandezza...).

Al di là dei (ragionevoli) dubbi, ipotizzando la buona fede degli autori, il problema sostanziale resta comunque che tale algoritmo ha una grossa debolezza strutturale: a meno di implementazioni che prevedano la generazione da parte dell'utente (ovvero dell'applicazione installata sul suo PC) dei numeretti magici, gli utenti stessi non potranno fidarsi che, per esempio, un qualunque applicativo che usi tale algoritmo non si basi su costanti, anche diverse da quelle suggerite nel documento NIST, generate da terzi che detengono anche i magic number.

La soluzione? Se usare DUAL_EC_DRGB è proprio necessario, meglio sarebbe generare "random" i parametri incriminati. Lascio a voi ogni ulteriore commento.