Re: [sikurezza] Re: Inforequest

On Thu, Mar 02, 2000 at 05:42:07PM +0100, James WorK wrote:
> >Un primo test molto semplice potrebbe essere quello di comprimere l'oggetto
> >da analizzare e vedere l'idnice di compressione risultante; se tale indice
> >risultasse molto basso il test sarebbe positivo altrimenti, se tale indice
> >risultasse altro, il test indicherebbe che l'oggetto criptato presenta molte
> >"ripetizioni" tali da agevolare attacchi di criptoanalisi.
> 
> Vero. D'altronde č pur vero che gli algoritmi di compressione sono tanti ed 
> ottengono risultati differenti. Poi ci sono tutta una serie di 
> applicazioni, chiamate "fractal archivers" che usano approcci completamente 
> diversi. Una serie di dati apparentemente "DASH (+ bianco non si puņ)" puņ 
> essere generata da funzioni molto semplici e quindi la sua entropia interna 
> č comunque molto bassa, nonostante l'apparenza.

Si, puo' essere un buon test per scoprire delle vulnerabilita' "assolutamente
banali" quello di tentare di comprimere l'output di un algoritmo di cifratura.
Ovviamente e' tutto tranne che sufficiente. Una cosa molto importante e'
la distribuzione dell'output ed la valutazione dell'avalanche effect.
In generale per ottenere buoni risultati la cosa migliore da fare e' non
cercare di reinventare l'acqua calda. In parole povere conviene pensare
al block cipher (se e' uno stream cipher cambia tutto) come ad una rete
di sostituzioni e permutazioni. I principi di Shannon sono alla base di tutto.
Confusion e Diffusion. Solitamente "Confusion" si ottiene utilizzando una
funzione non lineare (una Sbox? O qualcosa di matematico come fa IDEA) e
la permutazione invece e' lineare. Reiterando R volte la trasformazione lineare
e quella non lineare si ottiene (se l'algoritmo e' ben disegnato) che ogni
bit della chiave e del plaintext avranno un effetto su tutti i bit dell'output
dei block cipher (il che significa che variando un bit della chiave o del
testo in chiaro l'output dovra' avere in media il 50% di bit modificati se
confrontato all'output in cui tali alterazioni non sono state provocate).
Se si usa una struttura chiamata "Feistel Network" si ha in automatico
la possibilita' di utilizzare lo stesso algoritmo sia per cifrare che per
decifrare. Il DES, Blowfish e tanti altri sono proprio delle Feistel Networks.
La Feistel Networks funziona cosi':

L[i] = R[i-1]
R[i] = L[i-1] xor F(R[i-1], K[i])

In pratica ogni "round" del nostro algoritmo ha come input i precedenti
output (la prima volta ha come input il plaintext stesso). la F() e'
una funzione che puo' essere non lineare e complicatissima, in ogni caso
il nostro algoritmo sara' invertibile. L[0] ed R[0] sono infatti le due
meta' (destra e sinistra) del plaintext. mentre K[x] non e' altro che
materiale che proviene dalla chiave (puo' essere ad esempio la chiave
shiftata, ma attenti alle "weak keys"). Il tutto e' molto semplice ed
efficace e la sicurezza di un tale algoritmo risiede specialmente nel
disegno della funzione F(), nel numero di rounds che effettuiamo ed anche
nel modo in cui otteniamo K[i] da K.

Queste sono appena le basi, perche' disegnare un block cipher e metterlo
in una applicazione quando ce ne sono di ottimi testati dalla comunita'?
Serve essere un crittografo, serve aver sottoposto per anni il proprio
algoritmo alla comunita' per essere certi che questo offra un grado di
sicurezza adeguato. Nel disegno si deve tener conto di attacchi quali
la crittografia lineare e differenziale.
Se non vi fidate di un algoritmo free e pensare che tutto il modo stia
cospirando contro di voi prendete un algoritmo classico, modificate
la sbox (fatela randomica) e aumentate il numero di rounds: otterrete
un algoritmo molto forte. Se avete tanta memoria e non ve ne frega nulla
che l'algoritmo giri su una smart card aumentate la dimensione della Sbox.

Ciao,
antirez

-- 
Salvatore Sanfilippo, Open Source Developer, Linuxcare Italia spa
+39.049.8024648 tel, +39.049.8036484 fax
antirez@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.