Quali sono alcuni esempi della versatilità di un codice a blocchi rispetto a un codice di flusso?

0

Capisco che un codice a blocchi può essere fatto per agire come un codice di flusso al costo di "perdere la versatilità" del codice a blocchi per motivi di prestazioni. Non capisco cosa potrei perdere.

Ad esempio, la modalità AES GCM è un codice a blocchi che funge da codice di flusso, tuttavia ottengo

  • Integrità (il messaggio non può essere modificato senza che io lo sappia)
  • Streaming (non è necessario caricare l'intero oggetto nella RAM per la crittografia / decrittografia).
  • altre funzionalità ...

Domanda

  1. Cosa dovrei perdere quando AES è in modalità "blocco" o "stream"? ... (questa domanda non dovrebbe essere specifica AES, ma è ciò che conosco)

  2. Quali sono alcuni esempi reali di un codice a blocchi utilizzato laddove un codice di flusso non è l'ideale?

posta random65537 28.03.2014 - 20:50
fonte

2 risposte

3

Una cifratura a blocchi è una permutazione pseudo-casuale indicizzata dalla chiave nello spazio dei blocchi: per una data chiave < em> K , AES esegue il mapping di blocchi da 128 bit a blocchi da 128 bit, in modo che nessun due valori di blocco di ingresso distinti siano mappati sullo stesso valore di blocco di uscita. La conoscenza di K consente anche un calcolo efficiente della permutazione inversa.

Un codice a blocchi può essere utilizzato come elemento di costruzione per vari processi, inclusi (ma non limitati a):

  • crittografia simmetrica di messaggi lunghi arbitrari, utilizzando varie modalità di funzionamento ;
  • funzioni di hash, ad es. con Merkle-Damgård o alcuni altre costruzioni ;
  • MAC algoritmi, con (per esempio) CBC-MAC;
  • generazione di identificatori unici, pseudo-casuali e verificabili (la mia crittografia dei valori successivi di un contatore in un determinato intervallo).

Una crittografia stream è un algoritmo specializzato che copre solo la "crittografia simmetrica di arbitrariamente" messaggi lunghi "use case. La speranza è che limitando noi stessi a quell'uso singolo, possiamo progettare un algoritmo più efficiente. Il concorso eSTREAM ha portato a un portafoglio di cifrari stream apparentemente sicuri, che in effetti sono più veloci della crittografia basata su AES su un numero di architetture (ad esempio su una CPU Core2 x86 a 2,4 GHz, posso fare AES a 160 MByte / s, mentre il codice di flusso Sosemanuk raggiunge 700 MByte / s sullo stesso hardware).

Si noti, tuttavia, che "solo la crittografia simmetrica" è restrittiva: in molte situazioni in cui è auspicabile la crittografia simmetrica, si dovrebbero aggiungere anche verifiche di integrità, ad esempio una sorta di MAC. I ciprogrammi di flusso non eseguono il MAC, mentre ci sono modalità di crittografia autenticate che consentono di trasformare un cifrario a blocchi sia in crittografia che a MAC, con un sovraccarico relativamente piccolo rispetto alla crittografia non crittografata (a proposito, esiste un concorso in corso per nuovi AE modalità, che hanno ricevuto non meno di 57 sottomissioni, quindi dovremmo avere in futuro alcuni modi di esposizione ancora migliori).

È stato anche sottolineato che esistono contesti di crittografia in cui è auspicabile l'accesso casuale (ad esempio, la crittografia del disco rigido) e si ottiene con un cifrario a blocchi in modalità CTR, ma non necessariamente con una cifratura di flusso dedicata.

Per riassumere , dovresti prendere in considerazione l'uso di una codifica di streaming in un nuovo protocollo solo se hai un problema di prestazioni da risolvere e il problema in questione si trova all'interno dell'ambito limitato dei codici di flusso . Questo non succede spesso. Un esempio è quando hai bisogno di gigabyte di byte pseudo-casuali (in pratica, quando ho bisogno di byte casuali in grandi quantità, uso Sosemanuk inizializzato con una chiave e IV da /dev/urandom ).

    
risposta data 28.03.2014 - 21:44
fonte
0

La maggior parte dei codici di flusso sono cifrari a blocchi con una sorta di modalità operativa utilizzata per modificare la crittografia del blocco "successivo".

Spesso i dati del blocco precedente vengono usati per modificare l'output del blocco "next", che alla tua seconda domanda renderà impossibile decodificare il blocco successivo se perdi quello precedente. Ad esempio, in una trasmissione di rete è possibile che perderete un pacchetto.

    
risposta data 28.03.2014 - 22:10
fonte

Leggi altre domande sui tag