Math.random vs crypto.getRandomValues - Quale usare?

JavaScript offre due modi comuni per numeri casuali nel browser: Math.random e crypto.getRandomValues. In demo sembrano simili, ma non sono intercambiabili. Math.random e un PRNG veloce per lavoro non di sicurezza. crypto.getRandomValues e un CSPRNG per segreti, token e tutto cio che un attaccante non deve prevedere. Questa guida spiega la differenza, quando Math.random e rischioso, il bias da modulo e come generare interi e decimali sicuri nel browser.

Cosa fa davvero Math.random

Math.random restituisce un float nell intervallo semi-aperto [0, 1). I motori usano un algoritmo deterministico con seed del runtime. E veloce e sufficiente quando serve varieta - particelle, etichette di test o un consiglio del giorno.

Non e pensato per essere segreto. In ambienti datati seed o stato interno potevano essere dedotti da abbastanza output. Anche con seed moderni piu robusti, Math.random resta l API sbagliata per la sicurezza perche la piattaforma non promette robustezza crittografica e molti tutorial lo avvolgono con trucchi interi distorti.

• Buono per: animazioni UI, giochi, demo shuffle, campionamento non sensibile
• Cattivo per: password, token di reset, lotterie, nonce crypto, chiavi API
• Restituisce float in [0, 1) - non interi e non un API di sicurezza

Cosa fa crypto.getRandomValues

crypto.getRandomValues fa parte della Web Crypto API. Passi un typed array (per esempio Uint32Array) e il browser lo riempie con valori crittograficamente forti dall entropia del sistema operativo. E la stessa classe di casualita usata per TLS e altre funzioni di sicurezza.

Perche i valori sono difficili da prevedere, vanno bene per generare segreti lato client senza inviarli al server. E il motivo per cui generatori di password e numeri privacy-first preferiscono Web Crypto nel browser.

• Crittograficamente sicuro (CSPRNG) nel contratto Web Crypto
• Funziona offline dopo il caricamento della pagina
• Ideale per tool client-side che non devono caricare segreti

Bias da modulo - il bug silenzioso negli interi casuali

Uno snippet comune e value = randomUint32 % n. Se n non divide uniformemente lo spazio a 32 bit, alcuni resti compaiono piu spesso. Il bias e piccolo per n grandi rispetto a 2^32, ma e reale - per range piccoli in raffle, dadi o tool "scegli un vincitore" conviene evitarlo.

Quando servono numeri casuali unici

Sicurezza ed equita sono compiti diversi. Una raffle senza ripetizione vincitori richiede campionamento senza reinserimento in un range min-max inclusivo. Una password richiede alta entropia con reinserimento su un set di caratteri. Entrambi devono partire da casualita crypto - l unicita da sola non rende Math.random sicuro.

Per range interi inclusivi, il numero di valori unici non puo superare (max - min + 1). Per i decimali, "unico" di solito e il modello sbagliato; genera in modo indipendente o passa a interi.

Generare numeri casuali sicuri nel browser

Non serve implementare rejection sampling per l uso quotidiano. Apri un generatore client-side che gia usa Web Crypto, imposta il range e copia il risultato.

• Random Number Generator - interi o decimali sicuri, liste bulk, estrazioni uniche opzionali - crypto.getRandomValues nel browser.
• Password Generator - password forti con lunghezza e charset - stessa base Web Crypto.
• UUID Generator - UUID v4 / v7, ULID e NanoID per identificatori che non devono collidere.

Checklist pratica

1. Chiediti: qualcuno potrebbe ottenere accesso, denaro o vantaggio ingiusto prevedendo il prossimo valore?
2. Se si, usa crypto.getRandomValues (o un tool costruito su di esso) - mai Math.random.
3. Se mappi bit casuali a un range, usa rejection sampling invece del modulo grezzo.
4. Per password e token, preferisci un generatore dedicato con pool ampio e lunghezza sufficiente.
5. Genera lato client quando il segreto non deve finire nei log del server.

Domande frequenti

Math.random va mai bene?

Si - per casualita non di sicurezza. Varieta visiva, giochi senza soldi veri e dati demo vanno bene. Appena il numero e un segreto o deve essere equo contro un attaccante motivato, passa a Web Crypto.

crypto.getRandomValues e piu lento?

E piu lento di Math.random, ma per password, migliaia di numeri da lotteria o ID di test la differenza nel browser e irrilevante. Contano correttezza e imprevedibilita, non micro-benchmark.

Serve un server per un generatore sicuro?

No. Il browser espone gia un CSPRNG. I tool client-side possono generare valori in locale cosi i segreti non lasciano il dispositivo. E il modello di ToolsMinify.

E Node.js crypto.randomInt?

Sul server usa il modulo crypto della piattaforma (per esempio crypto.randomInt) invece di Math.random. Stessa regola: casualita sensibile alla sicurezza richiede un API CSPRNG.