Esiste una modalità contatore di crittografia in cui la chiave viene modificata per ogni blocco di dati?

Esistono alcuni codici che fanno ciò, in particolare E0 , un codice di flusso a 128 bit basato su quattro LFSR utilizzati nelle versioni precedenti del protocollo Bluetooth. Poiché sono state rilevate vulnerabilità in E0, è stato ideato uno schema per ridurre l'impatto sulla sicurezza denominato E0 a due livelli. Normalmente, il cifrario codifica 2745 bit (un frame Bluetooth) alla volta. Con E0 a due livelli, ogni 128 bit del keystream viene utilizzato per seminare un'altra istanza di E0 che genera solo 2745 bit di keystream da quella chiave.

Sinotichequestanonèunamodalitàspecialedicrittografia,mal'usodiveristreamcipher.Questadifferenzaèminore,poichélamodalitàcontatoreèsemplicementeunmodoperconvertireuncodiceablocchiinuncodicediflusso.Lamaggiorpartedeicodiciablocchi(emolticodicidiflusso)hannouna pianificazione principale , che è una fase di configurazione costosa ogni volta che viene utilizzata una nuova chiave , rendendo poco pratico il passaggio frequente delle chiavi. Il codice di flusso E0 non ha un programma di chiavi complicato. La chiave a 128 bit viene utilizzata direttamente come stato interno della cifra (in particolare, viene suddivisa in 25, 31, 33 e 39 bit, ciascuno dei quali viene utilizzato come stato iniziale per ciascuno dei quattro LFSR della cifra). Ciò gli consente di cambiare frequentemente le chiavi senza un impatto significativo sulle prestazioni.

Si noti che E0, anche E0 a due livelli, è non un cifrario particolarmente sicuro. La chiave deve essere cambiata molto regolarmente o gli attacchi con testo in chiaro possono consentire il recupero delle chiavi. Questi punti deboli derivano da entrambi i problemi nella progettazione di E0 a due livelli, nonché dal fatto che E0 è costituito da LFSR, che sono algoritmi non crittografici. L'utilizzo di AES in modalità CTR sarà molto più sicuro di qualsiasi altro tipo di E0.

Probabilmente non ci sono modalità standardizzate. I cifrari a blocchi sono normalmente modellati come una famiglia di funzioni biiettive (permutazioni). Si suppone che una funzione casuale scelta da questa famiglia sia indistinguibile da una permutazione casuale effettiva. ( Anche se è noto l'intero set di funzioni .) Un insieme di funzioni (matematiche) con questa proprietà è chiamato una permutazione pseudocasuale (PRP).

Quando si seleziona la funzione da utilizzare in un PRP, è necessario utilizzare una distribuzione uniforme per scegliere quella funzione specifica. E in genere gli algoritmi di crittografia a blocchi richiedono che la tua chiave venga scelta casualmente da una grande distribuzione uniforme.

Se la chiave di un codice di blocco non viene scelta in questo modo, potrebbe esserci un comportamento non casuale rilevabile. E se hai due chiavi correlate (come K ₂ = K ₁ + 1) allora potresti essere vulnerabile a un "attacco chiave correlato". I cifrari a blocchi non sono in genere progettati per essere usati in questo modo. ^*

Potresti provare qualche relazione chiave più complicata, ma se le chiavi non sono derivate usando una funzione crittografica (che appare casuale per tutti gli scopi pratici) quindi potrebbe esserci un problema. Oppure si potrebbe generare una nuova chiave a 128 bit per ogni blocco da 128 bit, ma non si guadagna molto. ^**

_{^{* Vedi: "modello standard" vs "modello ideale" di cifrari a blocchi. Ci sono anche codici a blocchi modificabili, ma al di fuori della Skein e della crittografia del disco probabilmente non vengono utilizzati molto spesso.
** Se si dispone di un generatore di numeri casuali riproducibile sicuro, si ha qualcosa che può essere trasformato banalmente in un codice di flusso. Inoltre, le implementazioni di algoritmi che utilizzano l'espansione chiave come ottimizzazione comportano un sovraccarico aggiuntivo se le chiavi vengono sostituite per ciascun blocco.}}

La tua modalità proposta è:

$$ C_i = E_ {E_k (\ mathrm {IV} || i)} (P_i) $$

... dove $ E_k (m) $ è l'applicazione a codice a blocchi con chiave $ k $ inserire il blocco $ m $ , $ i $ è il contatore dei blocchi e $ C_i $ e $ P_i $ sono $ i $ th testo cifrato e blocchi di testo in chiaro rispettivamente.

A me questo somiglia alle modalità per modificabile block ciphers (TBC) , un tipo esteso di crittografia a blocchi che, oltre agli input di chiavi e messaggi convenzionali, accetta anche un argomento tweak per crittografia. (Vedi il Q & collegato.)

Nel documento di Liskov, Rivest e Wagner che ha introdotto la nozione di tweakable cifra di blocco, troviamo questa modalità:

Comespiegalalegenda,ivalori $ Z_i $ che vengono usati come tweaks per il cifrario sono le concatenazioni IV / contatore. Nella metà sinistra del diagramma, i blocchi di messaggi diversi da quello precedente vengono crittografati applicando direttamente il TBC. (Il resto del diagramma mostra l'ultimo blocco di messaggi crittografato da un tipo di cifrario di flusso e il calcolo di un tag di autenticazione.)

Potremmo prendere la tua idea di ricavare una chiave per ogni blocco di messaggi crittografando un IV e un contatore di blocchi con una chiave master e pensare di rifarlo in una costruzione di un TBC $ E ^ T_k $ da un codice a blocchi convenzionale $ E'_k $ :

$$ E ^ T_k (m) = E '_ {E'_k (T)} (m) $$

Non so se si tratta di un TBC sicuro, ma il documento offre questa costruzione che non ha bisogno di ridefinire il codice a blocchi sottostante (un'operazione costosa con molti codici):

$$ E ^ T_k (m) = E'_k (T \ oplus E'_k (m)) $$

Rifacendo la tua modalità per usare quella costruzione avremmo qualcosa del tipo:

$$ C_i = E'_k (IV || i \ oplus E'_k (P_i)) $$

E mi sembra che qualsiasi attacco di testo in chiaro sulla riservatezza di questa modalità più semplice implicherebbe un attacco corrispondente a TAE, quindi la sicurezza di TAE implicherebbe la riservatezza di questa modalità.

Probabilmente dovrebbe essere ovvio che dovresti essere pazzo per implementare tutto ciò da solo.