Newsgroup: it.comp.sicurezza.crittografia
Titolo: Algoritmo di tipo stream: quale?

Non so perché ma amo più gli algoritmi di cifratura di tipo strem di
quelli a blocchi...
Attualmente sto scrivendo un programma per uso personale basato sull'RC4
per la de/cifratura dei file ma volevo qualcos'altro da aggiungere come
opzione. Fatta salva la presenza dell'irrinunciabile Blowfish, che ho
già provveduto ad inserire, cosa posso implementare? Gli ultimi
algoritmi presentati per le selezioni dell'Ecrypt (Phelix, Salsa20,
ecc..) e di cui ho già chiesto anche qui, sono stati studiati abbastanza
da poterli considerare utilizzabili?
-- 
Ciao.
Leo.
WEB: 
www.leonardomiliani.com
 
E-mail: 
leon...@leonardomiliani.com

 opzione. Fatta salva la presenza dell'irrinunciabile Blowfish, che ho
Piccola precisazione: so che è di tipo a blocchi ma è sicuro ed
efficiente, oltre che abbondantemente studiato, per non usarlo :-)


 studiati abbastanza da poterli considerare utilizzabili?
Secondo me, per definirli "studiati abbastanza" bisognerebbe aspettare il 
termine della selezione (cioè, circa 1 anno e mezzo).
Cristiano 

 termine della selezione (cioè, circa 1 anno e mezzo).
Ok. Approvo. Quindi, come stream cipher, cos'altro posso valutare?


 da poterli considerare utilizzabili?
La selezione mi sembra buona, Phelix e Salsa20 sono relativamente nuovi
ma in fondo ogni algoritmo di crittografia è sempre in fase di studio!
Certamente però varrebbe la pena di avere a disposizione anche l'AES,
il Twofish ed il Serpent, che sono i tre migliori algoritmi emersi dal
contest AES; potresti implementarli in modo contatore (CTR) per cui
diventerebbero all'atto pratico delle stream cipher.
Se poi ti interessa l'RC4 (io ne ho una vera passione) puoi anche
guardare alla RC4-16 in cui le s-box sono di word anzichè di byte (il
keyspace "lievita" a 2*2^16, enorme, anche se la forza di questa
funzione è ancora da dimostrare) o a VMPC che è una variazione sul
tema (è ancora sperimentale) o ad alcuni algoritmi derivati dall'RC4
che ho pubblicato un po di tempo fa
http://giorgiotani.interfree.it/s_kyu.html
 (assoultamente sperimentali
e quindi per nulla maturi, si tratta di algoritmi assai difficili da
analizzare matematicamente, come anche lo stesso RC4).
Una raccomandazione però, se miri ad offrire un prodotto utilizzabile
da chiunque la selezione del tipo di cifratura dovrebbe essere
abbastanza trasparente all'utente medio, quindi dovresti IMHO
concentrarti sul dare una buona implementazione di un algoritmo
standard e piuttosto ben conosciuto e proporla come default; casomai
sarà poi un utente in vena di sperimentazione (o che si rivolge al
programma per un uso più didattico che di sicurezza pura e semplice) a
scegliere possibili variazioni o alternative.

 Ok. Approvo. Quindi, come stream cipher, cos'altro posso valutare?
AES in CTR (anche se io preferisco Serpent in CTR), non č propriamente uno 
stream cipher, ma con un unico algoritmo ci puoi fare tutto (hash, 
espansione delle chiavi, block e stream cipher, autenticazione, ecc).
Cristiano 

 espansione delle chiavi, block e stream cipher, autenticazione, ecc).
Scusa, sono nuovo della materia per cui non capisco molto il significato
di questa affermazione: "AES in CTR".


 
Attualmente programmo per mia sola passione, dato che il mio lavoro è
(purtroppo) di tutt'altra natura. Per cui ora come ore miro più ad unire
la funzione di apprendimento di queste affascinanti funzioni matematiche
con la possibilità di creare un programma che offra la possibilità di
scegliere fra diversi algoritmi, così che sia possibile selezionare il
miglior compromesso fra la velocità e la sicurezza richiesta.


 significato di questa affermazione: "AES in CTR".
Se ne è parlato pochi giorni fa proprio nelle risposte che ti abbiamo dato, 
per cui pensavo che sapessi di che stessimo parlando.
La modalità CTR consente di usare un block cipher per produrre un key stream 
(come fa uno stream cipher); puoi usare, quindi, un block cipher come se 
fosse uno stream cipher. Dà anche un'occhiata qui:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29
ma anche su google (nel link c'è anche il nonce di cui parli nella replica a 
Giorgio).
Cristiano 

 
Sì, a grandi linee ho capito ma non realizzavo bene l'attuazione.
Il link mi è stato di aiuto anche per capire il nonce.


 tools per analizzarle e trarre alcuni spunti.
E' un codice un po complesso perchè ho realizzato il tutto in funzione
della cifratura a cascata (che era uno degli obiettivi dello studio).
In pratica uso array bidimensionali per salvare gli stati interni di
fino a 8 funzioni tipo RC4 in parallelo. Se vuoi estrapolarne esempi
più astratti di codice, basta che consideri solo la prima dimensione
dell'array per salvare lo stato interno di una singola funzione
RC4-like.
Comunque come avevo premesso, si tratta di concetti molto sperimentali
e la natura estremamente non lineare dell'RC4 non aiuta certo a
comprendere quale sia il potenziale di sicurezza di quelle funzioni
derivate, quindi sono cifre che io stesso non consiglierei per un uso
reale fino a che non ci siano strumenti matematici per comprenderle
meglio.

 
Ok. Lo terrò, per ora, come "curiosità".


 l'algoritmo come lo recupera?
Il nonce in genere viene trasmesso in chiaro all'inizio del file o
pacchetto criptato, infatti non c'è necessità che il nonce rimanga
segreto, è semplicemente un valore che ha bisogno di essere univoco
(essere generato randomicamente gli da anche questa caratteristica) per
rendere non fattibile la precomputazione degli stati iniziali della
funzione, mentre è la passwod (e/o eventualmente il keyfile) ad essere
l'elemento segreto della cifratura.
Rendere il nonce segreto in partica lo trasformerebbe in una chiave,
che andrebbe salvata e gestita a parte (non è semplice ricordare n bit
random...) ma a questo punto saremmo al punto di partenza perchè se
salviamo il nonce da qualche parte non potremmo ragionevolmente
impedire all'utente poco accorto (o seccato perchè ha cifrato 1000
file e si trova a dovere gestire 1000 diversi file che contengono i
1000 nonce) di riutilizzare un nonce già usato...
Per generare un buon nonce è necessario campionare una quantità
sufficiente di entropia ed elaborarla con vari metodi per
"distribuirla" uniformamente sui vari bit del nonce che si va a
generare (in genere si fa un hash dei valori entropici campionati, a
volte si attuano varie tecniche di whitening e così via, anche per
questo argomento ti rimando a pubblicazioni specifiche).
Mouse, tastiera e contatore dei cicli della CPU (inteso come contatore
tra due eventi non rigidamente correlati, ad esempio il tempo che
intercorre tra la pressione di due tasti o tra i movimenti del mouse)
sono buone sorgenti campionabili praticamente con qualisiasi
linguaggio, per campionare eventi tipo disco o rete o interrupt vari
invece di solito o ci si interfaccia ad alto livello a quello che il
s.o. riporta o si devono scrivere dei moduli che girino ad es a livello
del kernel in Linux per intercettare direttamente a tali eventi.
Quasi tutti i sistemi operativi hanno meccanismi di generazioni di
numeri casuali basati su questi sistemi di campionamento e
distribuzione dell'entropia (non sempre esenti da critiche da parte
della comunità dei crittografi) ma comunque anche esse sono sorgenti
di entropia che possono essere "agganciate" con le opportune chiamate
al sistema ed usate insieme ad altre sorgenti magari campionate
direttamente dal programma.
Una volta collezionata una quantità sufficiente di entropia (anche qui
ci sono valutazioni abbastanza complesse per stimare quanta entropia
porti un dato evento) e "spalmata" negli n bit di nonce che si intende
usare, il gioco è fatto.
Un meccanismo simile viene utilizzato per comporre le chiavi, ma in
questo caso c'è in più la costrizione che la chiave deve rimanere
segreta, quindi:
- non va assolutamente trasmessa in chiaro come invece si può fare con
il nonce;
- le sorgenti da cui si campiona l'entropia non devono poter essere
osservate o influenzate da un ipotetico attaccante, che potrebbe usare
questa conoscenza per ricostruire o indebolire la chiave.

 l'algoritmo come lo recupera?
Il nonce *deve* essere noto a chi decifra. Il suo scopo (quando viene 
concatenato alla chiave utente di cifratura/decifratura) è di rendere non 
fattibile l'attacco dizionario (come ti ha spiegato Giorgio), per cui non 
c'è bisogno che sia segreto, serve solo a rendere non fattibile il tentativo 
di provare solo le chiavi mnemoniche utilizzate da un utente che non volesse 
usare chiavi casuali (come, invece, andrebbe fatto).
Cristiano 

 già provveduto ad inserire, cosa posso implementare? 
Blowfish sembra buono finora.