È possibile utilizzare le funzioni hash con la modalità CTR o OFB?

6

Ho scritto una classe che crittografa e decodifica con cifrari a blocchi. Voglio usare la Counter Mode (CTR / CM). Sappiamo che Counter Mode genera un keytream basato sui contatori, quindi XOR il keystream con testo in chiaro per produrre testo cifrato. Quindi, è possibile decifrare finché è in grado di riprodurre il keystream, cioè, riprodurre il contatore e ottenere la chiave giusta.

Ho osservato che il metodo decrypt di un cifrario non è necessario in modalità CTR, dal momento che per riprodurre il keystream abbiamo solo bisogno di crittografare nuovamente i blocchi contatore.

Quindi, perché non posso sostituire il cifrario ordinario con una funzione hash (quindi rendere la parte fondamentale del contatore) o una funzione HMAC (che accetta una chiave)? Le funzioni hash non sono così pseudocasuali se confrontate con le cifre nella generazione di keystream, o c'è un motivo in più?

p.s .: Questa domanda funziona anche con la modalità OFB - l'hashing di una IV con o senza un tasto genera ancora qualcosa che assomiglia a un keystream.

p.s.2: un esempio:

1) Costruiamo un contatore di 16 byte:

aPADDING00000000
aPADDING00000001
aPADDING00000002

Qui otteniamo 3 blocchi.

2) Quindi utilizzare HMAC di MD5 per generare il keystream:

key = 'This is a key.'
stream[0] = HMAC('This is a key.','aPADDING00000000').hexdigest()
stream[1] = HMAC('This is a key.','aPADDING00000001').hexdigest()
stream[2] = HMAC('This is a key.','aPADDING00000002').hexdigest()

# now stream is:
# ['73f2e665c30aaec5bbead51166aaa85f',
#  '91392d0755638fbce5c689f96b02494f',
#  '1d18a81751179858d151dd86179385f9']

stream_str = "".join(stream).decode('hex') # stream_str = '73f2 ... 85f9'.decode('hex')

3) Ora stream_str sembra molto simile a un keytream. Per crittografare:

plaintext = 'This is a plaintext that has length of 48 bytes.'
ciphertext = stream_xor(plaintext,stream_str) # stream_xor XORs the two inputs bit by bit.

o, per decifrare:

decrypted = stream_xor(ciphertext,stream_str) # ciphertext produced before. 
    
posta Lucifer Orichalcum 17.07.2012 - 17:07
fonte

5 risposte

2

Angelo Rosiello e Roberto Carrozzo hanno proposto questo schema esatto (hash basato su OFB) in un documento del 2005 intitolato "ARC: un cifrario a flusso sincrono dalle funzioni di hash" e ha dimostrato che è sicuro fintantoché viene utilizzata una strong funzione di hash crittografica e la funzione di hash è pseudo-casuale.

Ma la domanda è: perché usare una funzione di hash invece di un codice a blocchi? I codici a blocchi come AES si sono dimostrati più resistenti nel tempo all'attacco rispetto alle funzioni di hash. AES è generalmente più veloce di un HMAC SHA256. Che vantaggio c'è di usare HMAC per questo?

    
risposta data 14.08.2012 - 22:24
fonte
2

So why can't I replace the ordinary cipher with a hash function(thus make key part of the counter) or a HMAC function(which accepts a key)? Are hash functions not-so-pseudorandom when compared to ciphers in keystream generation, or there's more reason?

In teoria, CTR può funzionare con qualsiasi PRF sicuro. Con una dimensione di blocco di 16 byte, un codice a blocchi (modellato come PRP) funziona come un PRF che può essere usato come uno, ma qualsiasi PRF funzionerà. HMAC è un PRF basato su hash, quindi funziona in modalità CTR.

(Penso che OFB abbia la stessa proprietà di lavorare con qualsiasi PRF sicuro. Sembrerebbe sicuramente avere un senso, ma non vedo alcun riferimento esplicito che lo confermi.)

    
risposta data 14.08.2012 - 23:20
fonte
1

Puoi, comunque, perché vorresti? Il point of block e stream ciphers è quello di aumentare la forza dei protocolli di crittografia quando i dati dovrebbero essere decifrati. Se si utilizza un metodo di hash, non è possibile decrittografare i dati in quanto gli hash sono a senso unico.

Se stai cercando di creare dati chiave invece di crittografare i dati, allora sì, potresti farlo in questo modo, tuttavia stai reinventando la ruota.

    
risposta data 17.07.2012 - 18:06
fonte
1

Vedi NIST SP800-90A che descrive alcuni generatori di numeri pseudo casuali , in particolare Hash_DRBG e HMAC_DRBG, che sono basati su hash in modo simile a quello che suggerisci. La parte difficile è progettare il sistema in modo tale che la sicurezza possa in qualche modo essere provata (cioè ridotta a un'ipotesi "ragionevole" sulla funzione stessa dell'hash).

Un buon motivo per usarli è nei sistemi embedded con dimensioni del codice limitate e che hanno già un'implementazione di una funzione hash per altri usi.

Un buon motivo non per usarli è che tendono ad essere molto più lenti dei cifrari a blocchi e, ancor più, dei codici a flusso specializzati.

    
risposta data 15.08.2012 - 13:35
fonte
1

È possibile utilizzare una funzione di hash o HMAC in una costruzione in modalità CTR per creare un codice di flusso sicuro. Questo non funziona con le funzioni hash che cercano solo di fornire la collisione e la resistenza pre-immagine, ma richiede alcune proprietà di pseudo casualità. Fortunatamente le funzioni hash più moderne hanno questa proprietà.

Come esempio pratico puoi consultare la Salsa20 codifica stream, che è essenzialmente una funzione hash in modalità CTR .

Con OFB devi stare attento. Devi mescolare la chiave su ogni passaggio e non solo sul primo. In particolare $ C_i = Hash (C_ {i-1}) $ è banalmente vulnerabile a un attacco di testo in chiaro noto. Se impari parte del keystream, puoi prevedere l'intero keytream dopo quel punto.

Ci sono alcune domande correlate su crypto.SE:

risposta data 15.08.2012 - 14:19
fonte

Leggi altre domande sui tag