La crittografia di un CRC con il testo normale è ok?

1

Utilizziamo encrypt-then-mac per la crittografia autenticata e recentemente aggiunto un CRC32 al testo in chiaro. Ci sono problemi di sicurezza con l'utilizzo di un meccanismo di hash non autenticato (ad esempio, CRC32) per il rilevamento degli errori (ad esempio assicurando che il messaggio non sia stato alterato e sia stato decrittografato con la chiave corretta)?

Quindi il formato sarebbe ( || è concatenazione):

encrypt(msg||crc32(msg))||mac(ciphertext)

Ciò si traduce in una riduzione della sicurezza, simile all'utilizzo di encrypt-and-mac o mac-then-encrypt?

    
posta thecoop 19.05.2016 - 17:58
fonte

2 risposte

4

Non lo farei e non capisco quale problema stai cercando di risolvere (a meno che non si tratti di una questione puramente accademica).

Encrypt-then-MAC dove definiamo ciphertext=encrypt(K_enc, msg) e inviando ciphertext||MAC(K_mac, ciphertext) rileverà eventuali errori di trasmissione o manomissioni dannose da parte di qualcuno che non conosce la chiave MAC segreta K_mac con una probabilità schiacciante; ad esempio, se hai utilizzato un MAC a 80 bit, la probabilità di alterare un messaggio e ottenere il passaggio da MAC è 1 in 2 ^ 80 ~ 8 x 10 ^ -25 che è trascurabile. Ad esempio, se qualcuno generava messaggi falsi miliardi ogni secondo, ci vorrebbero circa 3,2 milioni di anni prima che avessero una probabilità dell'8% di un singolo falso di successo (o circa 26 milioni di anni prima di avere il 50% possibilità di un singolo falso di successo).

Quindi, l'80+ bit MAC offre una protezione efficace contro falsi o errori di trasmissione di per sé.

Nel frattempo, l'hash CRC32 non crittografato a 32 bit non crittografato non fornisce alcun controllo di integrità aggiuntivo contro qualcuno che manomette deliberatamente un messaggio in chiaro che possono indovinare, almeno con i codici di flusso (o cifrari a blocchi che agiscono come un codice di flusso come CTR o il one-time-pad) dove XORing una modifica al testo cifrato modifica gli stessi bit nel testo in chiaro. Ad esempio, poiché i CRC32 non implicano alcun segreto, possono indovinare il messaggio originale m , calcolare il suo CRC32, prendere il loro messaggio alterato m' e calcolarlo è CRC32 e quindi modificare il testo cifrato in transito a c' = c XOR (m || CRC32(m)) XOR (m' || CRC32(m')) . Certo, il MAC con chiave fornito dalla crittografia autenticata impedisce questo attacco. Tuttavia, se si è verificata una cattiva implementazione che ha fornito informazioni (tramite un messaggio di errore o una modifica dei tempi) di una differenza tra l'errore MAC e il CRC32 in errore o quando il MAC fallisce e il CRC32 passa, si indebolirebbe la sicurezza di il tuo sistema (e gli hacker potrebbero sfruttarlo).

L'unica protezione che il CRC32 potrebbe proteggere è il danneggiamento accidentale della memoria nel computer tra il calcolo della CRC32 del messaggio in chiaro e la crittografia di tale messaggio sebbene la possibilità che ciò accada sia anche trascurabilmente piccola.

In breve, se questo è implementato male (ad esempio, l'utente malintenzionato può capire che il CRC non è riuscito / passato anche quando il MAC ha avuto esito negativo), questo può perdere informazioni. Se questo viene implementato perfettamente, non fornirebbe alcuna sicurezza aggiuntiva dato che il MAC con chiave è la parte che ostacolerebbe un tamperer dedicato.

    
risposta data 19.05.2016 - 19:29
fonte
0

Ciò non danneggerà la crittografia, ma in realtà non aggiunge nulla.

Quello che hai descritto è solo crittografia. Hai solo cambiato il carico utile rendendolo un po 'più grande. Questo è altrettanto sicuro.

Tuttavia un Mac contiene anche un controllo che se è stato alterato nella trasmissione in entrambe le parti (messaggio crittografato o mac) non verrebbe confermato dall'altra parte. Non ottieni nulla da questo e rende l'usabilità ancora peggiore poiché ora devono rimuovere anche gli ultimi 32 caratteri dal payload.

    
risposta data 19.05.2016 - 18:10
fonte

Leggi altre domande sui tag