Guid sale - stringa vs byte []

In poche parole, vuoi massimizzare la quantità di entropia per una determinata lunghezza di dati, quando esegui la maggior parte delle attività crittografiche.

Hai (al massimo) 16 byte di entropia nel tuo GUID - probabilmente meno (alcuni dei bit sono deterministici), ma possiamo ignorare quel dettaglio per la discussione corrente. Quando si usa la rappresentazione del byte [] del GUID come sale, si hanno 16 byte di dati. Questo è al massimo 16 byte di entropia / 16 byte di dati = 1 byte di entropia per byte di dati, assumendo un GUID completamente casuale. Supponiamo ora di utilizzare la rappresentazione della stringa. Sono 36 byte di dati, ma ancora al massimo 16 byte di entropia. Ciò si traduce in meno della metà dell'entropia per byte di dati (circa un rapporto di entropia / dati di 0,44 rispetto al byte compatto []), che è problematico per alcuni algoritmi di hashing.

Quando potrebbe apparire?

Per fare un esempio forzato (appena in cima alla mia testa - in realtà non raccomanderei di farlo), considera bcrypt. bcrypt è un algoritmo di hashing della password che, per ragioni tecniche, limita la password a 72 byte . Comprende il proprio sale, ma supponiamo, a ragion veduta, che non ti fidi del suo sale (di nuovo, questo non è un consiglio, solo un esempio).

Quindi, decidi di prefisso la password dell'utente con un GUID, prima di inserirla in bcrypt. Se hai utilizzato la versione byte [], questo riduce il limite superiore effettivo della lunghezza della password di 16 byte. Quindi, l'utente può fornire una password di 56 byte, al massimo. Va bene - è ancora più di 50 caratteri ASCII, che è una lunghezza comune che le persone usano quando hanno un gestore di password e sono un po 'paranoici.

Ora, supponiamo che tu abbia usato la versione della stringa. Hai ancora la stessa quantità di entropia, ma ora mangi più di 36 byte che l'utente potrebbe aver utilizzato per estrarre la password. Al momento sono bloccati con una password da 36 byte al massimo.

E questo è solo un esempio fuori dalla mia testa; Sono sicuro che ci sono altri casi in cui l'utilizzo della versione di stringa potrebbe farti male.

Il sale non riguarda realmente l'entropia. Ciò che i sali devono raggiungere è unicità : per quanto possibile, è necessario cercare di non riutilizzare mai un valore salt (anche se si cambia la password per lo stesso utente). GUID sono carini per quello. La casualità è un buon metodo per raggiungere quel tipo di unicità con una probabilità schiacciante (è "bello" perché non ha bisogno di alcun tipo di directory mondiale).

Per unicità, GUID-encoded-as-bytes e GUID-encoded-as-string sono completamente equivalenti poiché la conversione tra le due codifiche funziona in entrambi i modi: due GUID codificati come sequenze distinte di i byte saranno anche codificati come stringhe distinte e viceversa. Non importa che una codifica abbia "più entropia per carattere" o una qualsiasi di queste nozioni, perché l'entropia è irrilevante per i sali. (Oppure, detto altrimenti, quando la concentrazione di entropia è importante per un sale, allora non è un sale, ma qualcos'altro.)

Tuttavia , gli algoritmi di hashing della password e i formati di file esistenti possono essere schizzinosi a proposito dei sali. Ad esempio, l'articolo che specifica bcrypt (*) dice che il sale ha lunghezza esattamente 128 bit, quindi, presumibilmente, se si tenta di alimentare un'implementazione di bcrypt con stringhe di 36 caratteri, possono accadere cose brutte (ad esempio l'implementazione utilizza solo i primi 16 caratteri, ignorando il resto). L'unicità del GUID è garantita solo quando viene utilizzato il GUID complete , nella codifica che hai scelto.

In una nota più pratica, dato che entrambe le codifiche raggiungono la stessa unicità, si può anche preferire usare il più breve dei due, per risparmiare spazio nel database. Fai attenzione, tuttavia, a una cattiva gestione dei dati binari (ad esempio usando byte come se fossero una stringa che termina con il primo byte del valore 0). Viceversa, poiché la maggior parte degli algoritmi di hashing delle password prevede bytes per il sale, è necessario fare attenzione a specificare una codifica univoca se si desidera memorizzare i sali come stringhe di caratteri .

^{(*) Mentre l'articolo specifica bcrypt, gli autori di bcrypt tendono a considerare che la specifica real bcrypt è l'implementazione di riferimento; in questo senso, la lunghezza del sale accettabile reale per bcrypt è "qualunque sia l'implementazione di riferimento che accetta di usare".}