Stringa casuale contro hash (stringa casuale)?

Question

Stringa casuale contro hash (stringa casuale)?

#1 da (5 voti)

6

Sto implementando un servizio token una tantum. Ognuno di questi token di una volta rappresenta alcuni dati / azioni sul lato server ad esso associati (ad esempio un'azione di conferma dell'email), in modo che il mio servizio Web possa verificare e intervenire quando li riceve senza sessione. (dall'interno del link di conferma di una email, da una scansione del codice qr ...)

Questi token dovrebbero essere molto difficili da indovinare o falsificare. Quindi penso che una lunga stringa casuale (da / dev / urandom) dovrebbe essere abbastanza buona. Ma dal link :

A counterpart to /dev/random is /dev/urandom ("unlimited"[5]/non-blocking random source[4]) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. While /dev/urandom is still intended as a pseudorandom number generator suitable for most cryptographic purposes, some people claim /dev/urandom as not recommended[who?] for the generation of long-term cryptographic keys. However this is in general not the case because once the entropy pool is unpredictable it doesn't leak security by a reduced number of bits.

E ho anche letto del codice nella sessione link

def _urandom():
    if hasattr(os, 'urandom'):
        return os.urandom(30)
    return text_type(random()).encode('ascii')

def generate_key(salt=None):
    if salt is None:
        salt = repr(salt).encode('ascii')
    return sha1(b''.join([
        salt,
        str(time()).encode('ascii'),
        _urandom()
    ])).hexdigest()

Quindi la mia domanda è: tale hash(time()+urandom()) genera più stringhe "casuali" del puro urandom() ? Qual è lo scopo di utilizzare una funzione di hash qui?

random hash

posta jayven 03.01.2016 - 09:04

fonte

1 risposta

Leggi altre domande sui tag random hash

Terminologia per gli attacchi di estrazione della libreria condivisa di un'applicazione e utilizzo stand-alone I captcha di riconoscimento di foto sono un modo affidabile per distinguere gli umani dai robot?

score 5 · Accepted Answer

I dati casuali reali sono imprevedibili al 100%. Interfacce come urandom forniscono inoltre una distribuzione uniforme in aggiunta a questo, cioè ottieni non solo valori casuali imprevedibili ma tutti i valori hanno la stessa probabilità. Se hai già una sorgente di casualità di così alta qualità allora l'hashing non lo migliorerà più, cioè hash(time()+urandom()) non sarà migliore di urandom() da solo.

Ma l'esempio di codice è riconducibile alla semplice funzione random() se urandom() non è disponibile. Solitamente si tratta solo di un generatore di numeri pseudo-casuali veloce in cui i valori sono in qualche modo prevedibili se si conoscono abbastanza valori precedenti. In tal modo l'operazione di hash l'output insieme a un sale e il tempo potrebbe essere un tentativo di rendere l'uscita meno prevedibile di fronte solo a un generatore di numeri pseudo casuali. E anche se non aggiunge davvero più casualità all'output, rende più difficile tornare al valore pseudo random originale e quindi rende più difficile l'uso di attacchi contro il generatore di numeri pseudo casuali sottostante. Per dati casuali reali non è necessario un tale tipo di protezione perché i dati di input sono già completamente imprevedibili e non è possibile calcolare il valore casuale successivo se sono noti quelli precedenti.