TCrypto - Commenti sulle decisioni di progettazione che ho preso?

1. Non è necessario un MAC interno. Non mi è chiaro a quale problema ti riferisci. Presumo che il tuo schema funzioni in questo modo: comprimi i dati, quindi applica encrypt-then-MAC ai dati compressi. Se il digest MAC è valido, puoi essere sicuro che dopo la decifrazione elaborerai gli stessi dati inviati dal mittente, quindi non è necessario avere un altro MAC.

2. Dipende dalla variante della modalità CTR che usi e da come viene formato il contatore. Nella forma più semplice, per crittografare un messaggio di n sotto IV v , usiamo v , v +1, v +2, .., v + n -1 come contatori, quindi supponiamo che sia quello che stai facendo (altrimenti, per favore specifica). La generazione di un contatore casuale a 128 bit con /dev/urandom va bene.

3. Sembra che tu stia facendo qualcosa di carino per generare la chiave usata per crittografare ogni messaggio. Non posso commentare in merito, perché non hai fornito informazioni specifiche su ciò che stai facendo.

Se dividi questo in più domande e fornisci ulteriori dettagli, potremmo essere in grado di fornirti risposte migliori.

La compressione e la crittografia sono molto facili da testare e gli errori di solito vengono notati rapidamente. Quindi non c'è bisogno di avere un altro MAC all'interno. Non ho mai visto una tale configurazione, e inoltre sarebbe sufficiente avere solo un CBC o simile per quel caso. Suggerisco semplicemente di mettere una serie di test automatici dopo la procedura di compilazione / installazione.

Per quanto ne so, non c'è differenza nella raccomandazione della scelta IV tra differenti modalità di cifratura. Schneier e Ferguson raccomandano in Crittografia pratica di utilizzare un contatore come IV. L'uso di un valore casuale è altrettanto sicuro finché hai un PRNG prevalentemente funzionante.

Se le chiavi sono veramente uniche per ogni crittografia, non importa affatto come viene scelta la IV. L'IV è specificamente per fare più crittografie con la stessa chiave. Ma probabilmente non puoi fare affidamento su questo, poiché il tempo potrebbe essere costante o ripristinato per qualche motivo. (In generale, non dovresti assumere un orologio funzionante nella tua crittografia :-)) Quindi dovresti comunque usare un IV di conteggio o includere / dev / random nella chiave attuale.

Invece di encrypt-then-mac, è possibile utilizzare un codice cifrato con crittografia e autenticazione combinate, come GCM o CCM. Se ricordo bene, il vantaggio del CTR è solo che la crittografia di un messaggio può essere parallelizzata.

Dichiarazione di non responsabilità: non sono un crittografo.