Strumenti per sviluppatori · Generatore UUID
Math.random vs crypto.getRandomValues: come funziona ogni generatore
· Come funziona
uuid crittografia API del browser
Entrambi restituiscono numeri che sembrano casuali, ma uno è una piccola macchina a stati deterministica e l'altro è alimentato dal sistema operativo. Ecco cosa fa ciascuno sotto il cofano e perché gli UUID devono utilizzare il secondo.
Lo snippet del forum che crea un UUID da Math.random: perché sembra a posto e supera ogni test casuale
Una risposta del forum offre una rapida UUID factory in otto righe: raccogli i valori da Math.random e formattali nel layout 8-4-4-4-12. Il codice sembra a posto e supera ogni test casuale. Ogni identificatore appare diverso e un breve campione non mostra alcun modello visivo evidente. Questa non è la proprietà di cui ha bisogno un identificatore sensibile alla sicurezza. JavaScript specifica Math.random come origine pseudo-casuale ma non richiede resistenza crittografica alla previsione. I suoi lavori appropriati includono simulazioni, giochi e mescolate. Una volta che un identificatore può influenzare l’accesso, la scoperta di oggetti o un’altra decisione avversaria, l’apparenza non è più una prova. Il contratto documentato del generatore conta più di una pagina di output apparentemente plausibile.
Inside Math.random: un algoritmo pseudo-casuale con uno stato interno fisso, progettato per la velocità e la diffusione statistica, non per la segretezza
Poiché Math.random non è specificato come generatore crittografico, i suoi output non devono essere trattati come prova che i valori futuri sono nascosti a un osservatore. crypto.getRandomValues ha un contratto di piattaforma diverso: riempie un array tipizzato di numeri interi con valori crittograficamente forti. La specifica Web Crypto lascia il generatore esatto all'agente utente, quindi il codice dell'applicazione non dovrebbe rivendicare un particolare algoritmo, dimensione del seme o dispositivo entropico. ToolAcre necessita solo del limite supportato: il browser fornisce byte casuali sicuri, JavaScript riceve l'Uint8Array riempito e il codice UUID imposta i campi versione e variante. Questa affermazione è utile e trasferibile su browser le cui implementazioni interne differiscono.
Perché l’osservazione dei risultati può rivelare lo stato: come uno stato piccolo significhi che una serie di valori può consentire a qualcuno di prevedere quelli successivi
Il codice dell'applicazione riceve valori crittograficamente avanzati da getRandomValues anziché implementare o esporre uno stato JavaScript PRNG. La differenza di sicurezza si manifesta nei sistemi reali. Un identificatore creato da Math.random non è adatto ovunque la previsione avrebbe conseguenze perché un utente malintenzionato con la capacità di leggere la rete (o qualsiasi sistema in cui sono visibili gli UUID precedenti) può prevedere quello successivo. Un UUID v4 da crypto.getRandomValues non è di per sé un token di autenticazione (sono comunque necessari scadenza, hashing e limitazione della velocità), ma il generatore è progettato per resistere alla previsione. ToolAcre rifiuta di generare un identificatore se la sua fonte sicura è assente, anziché eseguire il downgrade silenzioso a una formula prevedibile. Math.random è stato fornito con sottili bug di distribuzione nei principali motori. Una sequenza di output può apparire varia senza fornire l'imprevedibilità contraddittoria richiesta per i ruoli portatori di segreti.
All'interno di crypto.getRandomValues: il browser richiede CSPRNG del sistema operativo, che mescola hardware ed entropia di sistema ed è progettato per essere imprevedibile
Gli algoritmi specifici del motore e il loro comportamento statistico possono cambiare; né l'ispezione visiva né un test di distribuzione casuale aggiorna Math.random in una fonte crittografica. I calcoli delle collisioni presuppongono anche risultati indipendenti dallo spazio indicato. Se un generatore ripete lo stato, viene seminato in modo errato o viene sostituito con un dispositivo deterministico, tale presupposto è fallito e la formula non descrive più l'implementazione. Entrambe le API possono produrre stringhe dall'aspetto ugualmente irregolare. Il modello di minaccia li separa: i valori che devono resistere alla previsione utilizzano crypto.getRandomValues, mentre le simulazioni e gli mescolamenti non contraddittori possono utilizzare Math.random. La scelta deriva dalla conseguenza della previsione, non dalla punteggiatura o dall'apparente varietà di un campione.
Esempio pratico: generazione dello stesso numero di identificatori con ciascun metodo e confronto di ciò che un osservatore potrebbe dedurre
Il generatore ToolAcre UUID utilizza esclusivamente crypto.getRandomValues; non utilizza mai Math.random perché il costo di un prevedibile UUID è sempre superiore al costo di un generatore leggermente più lento. La differenza crittografica è misurabile attraverso un modello di minaccia. Un utente malintenzionato che desidera falsificare gli UUID deve indovinare direttamente l'identificatore o interrompere il generatore di numeri casuali. L'ipotesi diretta non è il confronto quantificato in questo articolo; la conclusione supportata è che Web Crypto è destinato alla casualità crittografica mentre Math.random non lo è. A CSPRNG e Math.random espongono contratti diversi: il primo è progettato per casualità sensibile alla sicurezza, mentre il secondo non promette tale promessa. Un sistema che utilizza Math.random per gli identificatori ha perso la proprietà crittografica; la sicurezza ora dipende dal mantenimento segreto della sequenza degli UUID generati. Se anche un solo UUID perde, l'intera generazione futura è compromessa.
Bug storici della distribuzione: un promemoria del fatto che i motori hanno fornito implementazioni Math.random con output visibilmente irregolare, descritti qualitativamente
Se l'applicazione memorizza gli UUID in un registro, un database o una cronologia del controllo della versione, la perdita è quasi inevitabile. La libreria ToolAcre impone l'uso di crypto.getRandomValues e rifiuta di generare un UUID se il contesto protetto (HTTPS o localhost) non è disponibile. Questa decisione progettuale impedisce il silenzioso fallback a Math.random che ha afflitto molte implementazioni eseguite manualmente. In Node.js, la libreria utilizza il modulo crittografico; nei browser utilizza Web Crypto API. Entrambi i percorsi supportati richiedono una casualità crittograficamente forte dalla piattaforma. L'implementazione non fa alcuna richiesta di prestazioni perché motore, dispositivo e carico di lavoro determinano i tempi; il contratto di sicurezza è la proprietà decisiva per gli identificatori. Il motivo per cui lo standard del settore si è basato su crypto.getRandomValues è una breve storia di uso improprio di UUID. I primi sistemi utilizzavano l'ora di sistema, le interfacce di rete e gli orologi hardware per generare identificatori.
Ciò che questo non copre è la qualità statistica di entrambi i generatori per le simulazioni, che è una questione diversa dall’imprevedibilità
Le versioni UUID basate sul tempo, basate sui nodi e casuali risolvono diversi problemi di allocazione; uno non dovrebbe essere presentato come una riparazione lineare per ogni progetto precedente. Per la versione 4, RFC 9562 definisce i campi casuali e discute separatamente l'imprevedibilità. Una migrazione da Math.random modifica quindi la qualità dei valori appena generati senza modificare la forma testuale UUID. Gli identificatori esistenti rimangono chiavi del database; rigenerarli interromperebbe i riferimenti. I nuovi valori possono utilizzare Web Crypto immediatamente, mentre l'autorizzazione deve continuare a considerare ogni UUID vecchio o nuovo come un identificatore anziché una prova di autorizzazione. Documentare il limite in modo che gli operatori di emergenza sappiano quale generatore ha prodotto ciascuna popolazione.
Conclusione: scegli il generatore in base alla minaccia, non all'apparenza: il generatore ToolAcre UUID utilizza esclusivamente CSPRNG, mai Math.random()
La convalida dovrebbe distinguere tra ID legacy (non adatti alla segretezza) e nuovi (supportati da CSPRNG). La documentazione dovrebbe tenere conto della transizione. Il generatore ToolAcre produce solo UUID crypto.getRandomValues; non tenta di convalidare o rigenerare identificatori da altre fonti. Il generatore ToolAcre dimostra le migliori pratiche rifiutandosi di eseguire il downgrade a una fonte casuale più debole. Se crypto.getRandomValues non è disponibile, lo strumento segnala un errore invece di utilizzare silenziosamente Math.random. Questo principio di progettazione si applica a qualsiasi sistema critico per la sicurezza: fallire rumorosamente piuttosto che avere successo in silenzio con una debole garanzia di sicurezza. Uno sviluppatore che vede "generazione UUID non riuscita: crittografia API non disponibile" deve risolvere il problema di fondo (aggiornare a HTTPS, correggere il contesto protetto o fornire un fallback adeguato). Uno sviluppatore che riceve silenziosamente UUID creati da Math.random non ha alcuna indicazione che il sistema sia compromesso. La biblioteca ToolAcre dà priorità all'onestà rispetto alla comodità.