Newsgroup: it.comp.sicurezza.crittografia
Titolo: Info crittografia

Salva a tutti,
Volevo porvi qualche quesito sulla crittografia, in quanto la sto
affrontando su un progetto al lavoro e mi sono venuti alcuni dubbi.
Nelle domande mi riferisco agli algoritmi attuali , tipo DES 3DES AES
BLOWFISH etc. etc.
1 ) Dato un valore da criptare, se cripto il valore in due tempi diversi
con la stessa chiave, il valore criptato cambia ?
2 ) La lunghezza del campo criptato presumo sia funzione della chiave,
e' un multiplo ? o puo' variare a seconda del dato da criptare
Vi ringrazio in anticipo


Di niente, ma vedi di usare il linguaggio specifico della materia
scientifica di cui parli, altrimenti si stenta a capire il significato delle
tue frasi.

 e' un multiplo ? o puo' variare a seconda del dato da criptare
La cifratura a blocchi avviene su appunto blochi di una data dimensione
(generalmente 64 o 128 bit, 128 nelle cifre più recenti) ma l'ampiezza
del blocco non c'entra con le dimensioni della chiave.
Un input da cifrare a blocchi dovrà subire un processo chiamato
padding che serve a renderlo multiplo della lunghezza del blocco della
cifratura utilizzata (esistono vari schemi con diverse dimostrazioni di
sicurezza), di conseguenza l'output avrà la stessa lunghezza
dell'input+padding, che sarà multipla delle dimensioni dei blocchi.
La cifratura a stream può essere vista come una cifratura sull'intero
input oppure come una cifratura su "blocchi" di 1 singolo bit, quindi
l'output avrà le stesse dimensioni dell'input, che non avrà bisogno
del padding.
Anche in questo caso la dimensione della chiave non entra in questo
tipo di discorso.
La divisione tra questi due tipi di cifre non è molto rigorosa, ad
esempio per le cifre a blocchi è molto usato il modo CTR (counter) che
trasforma una cifra a blocchi in una cifra a stream.
Anche in questo caso per valutare la dimensione dell'output è
necessario unire la teoria alla pratica: oltre alle valutazioni esposte
in precedenza sarà necessario aggiungere alla lunghezza dell'output
tutte quelle informazioni utilizzate dall'implementazione del sistema
crittografico, ad esempio:
- di solito prima dell'output cifrato viene salvato il seed ricordato
in precedenza (senza, non sarebbe possibile derivare la chiave K' e di
conseguenza decifrate l'output) che di solito è nel range dei 64-256
bit;
- spesso viene usato anche un campo per validare la chiave (un valore
noto da decifrare per vedere se la chiave derivata è corretta) di
solito bastano 16-32 bit;
- è buona cosa anche disporre di un campo di autenticazione
dell'output per verificare che sia integro e non, magari,
intenzionalmente alterato, ad es tramite una cifratura che comprenda
l'autenticazione o tramite un HMAC o almeno un hash o un checksum se i
requisiti di questo controllo sono meno stringenti; la dimensione di
questo campo può variare molto a seconda degli algoritmi usari (es 512
bit con Whirlpool o SHA512, 160 bit con SHA1, 128 con l'MD5, 32 bit con
il classico CRC32 ecc...)

 Vi ringrazio in anticipo
Sempre io, grazie infinite per la risposta e scusate per la poca
chiarezza. Ma non e' il mio campo la crittografia.
Mi occupo di informatica, e il problema mio nasce dalla richiesta del
cliente di cifrare alcuni campi di una base dati. Per far funzionare
tutto il castello di carte pero' , e' necessario che il campo cifrato
sia univoco e che sia sempre cifrato nello stesso modo per poter
permettere di fare data mining e minchiate varie. Ovvero, spero di non
scrivere una cazzata, che F(x) = y sempre.
Da quel poco che so di cifratura questo non dovrebbe essere garantito,
ma qualcuno afferma il contrario e non riesco a trovare informazioni.
Dalle rispote che mi avete dato, e che leggero con piu' attenzione, mi
sembra di aver capito che non e' assolutamente detto che F(x) = y
sempre , fermo restando naturalmente che la chiave sia la stessa.
Grazie di nuovo

 scrivere una cazzata, che F(x) = y sempre.
Se il campo è breve, più corto della ampiezza del blocco (64 o 128
bit), puoi usare il modo ECB (applichi la cifratura direttamente sui
dati), se è più lungo del blocco ti conviene orientarti su modi
sicuri che non prevedano l'uso di un salt:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
è un ottimo articolo per farsi una idea di quale modo d'uso scegliere,
comunque in genere il riutilizzo di una chiave è sempre un problema
difficile da gestire.
Per evitare il problema alla radice magari potresti, in un secondo
campo, scrivere il salt da usare per decifrare ciascun record (il salt
è un parametro che ha bisogno di essere univoco ma non segreto), in
questo modo quando l'applicazione punta ad un dato record si va a
pescare il salt e la chiave o password e si deriva la chiave specifica
per quel dato record.
Tecnicamente, dato che appunto il salt non ha bisogno di essere
segreto, la soluzione sarebbe sicura e consentirebbe di evitare il
riutilizzo della chiave, ma non conoscendo l'applicazione che stai
sviluppando non ti posso dire se sia una strada praticabile o no.
In ogni caso per puntare ai record credo sarebbe meglio un campo
univoco non cifrato, magari un contatore o generato da una funzione di
indicizzazione del database, piuttosto che fare le ricerce sul campo
del valore cifrato stesso, anche perchè in caso di modifiche al record
nel campo cifrato non sarebbe una brutta idea cifrarlo ogni volta
generando un seed diverso (che andrebbe a sostituire quello collegato
al record, consentendo di decifrare il campo).

 qualsiasi cifrario).
uh? e perchč? Quale dei tre algoritmi citati dall'autore del thread
dovrebbe dare risultati diversi?
Mi sono appena scritto un piccolo programma che cifra una stringa usando
aes256 e blowfish (algoritmi predefiniti non scritti da me) e il risultato
č, come mi asppettavo, costante nel tempo. E' errata l'implementazione
degli algoritmi? Oppure gli algoritmi di cifratura si comportano come tutti
gli altri algoritmi deterministici? Stesso input  --> stesso risultato?
Oppure gli algoritmi di cifratura citati sono non deterministici? In questo
caso perň non mi spiego, almeno, perchč i miei risultati sono costanti nel
tempo.
grazie, giubbe

 gli altri algoritmi deterministici? Stesso input  --> stesso risultato?
E' corretto, se chiave, algoritmo e input non cambiano l'output rimane
identico.
Il fatto è che questo porta ad una serie di problemi per alcuni tipi
di algoritmo o modi d'uso (es CTR): immaginiamo di cifrare l'input Pa
con una cifra stream o con una cifra a blocchi usata in modo CTR,
avremo che l' i-esimo output di Ca sarà Pa[i] xor l'output [i] della
funzione e inizializzata dalla chiave K, quindi Ca[i] = Pa[i] xor eK[i]
La sicurezza di questo tipo di cifratura risiede nel fatto che eK è un
flusso di dati pseudocasuali senza proprietà statistiche che possano
essere sfruttate per separare Pa da eK.
Se usiamo la stessa chiave e la stessa cifra per cifrare l'input Pb
avremo che Cb[i]=Pb[i] xor eK[i], dove eK è esattamente lo stesso
flusso pseudocasuale dell'esempio precedente.
Se l'attaccante volesse decifrare Ca e Cb non dovrà fare altro che
combinare in modo lineare i due stream cifrati, in questo modo i due
stream di output della funzione si eliderebbero e l'attaccante
rimarrebbe con la combinazione di Pa e Pb; ad es:
Ca[i]-Cb[i]=Pa[i]-Pb[i]+eK[i]-eK[i]=Pa[i]-Pb[i]
Questa combinazione a differenza di P*[i] xor eK[i] non è sicura in
quanto sia Pa che Pb non hanno le caratteristiche statistiche
dell'output della funzione crittografica eK, quindi esistono metodi
matematici computabili in un tempo ragionevole per recuperare in tutto
o in parte Pa e Pb.
Per evitare che questo accada quindi di solito si utilizzano funzioni
di derivazione della chiave (kdf) che prendono come input la chiave
(elemento segreto) e un valore non segreto univoco (contatore, numero
pseudocasuale), in questo modo la chiave realmente applicata
all'algoritmo è ogni volta diversa anche se l'utente non vuole o non
può modificarla.
In questo senso, di solito ogni volta che si cifra qualcosa comunemente
si ottiene un risultato diverso e statisticamente non correlato al
precedente, anche utilizzando la stessa chiave, intesa come chiave
fornita dall'utente e che poi deve passare per il kdf insieme ad un
valore univoco generato al momento.

 di algoritmo o modi d'uso (es CTR)[...]
ok, grazie. Quello che mi dici è anche il motivo per il quale si usa il
salt, giusto?
bye

 salt, giusto?
Esatto, salt, nonce, IV sono usati spesso in modo intercambiabile.
Il semplice attacco descritto è uno dei motivi per cui si usa questa
strategia; un altro buon motivo per il salting anche se non si usano
cifre sensibili a questo attacco è per evitare che, specie se
l'elemento segreto è una password e quindi soggetta ad attachi a
dizionario (non vengono provate tutte le chiavi, ma solo quelle di
senso compiuto, presenti nel dizionario), l'attaccante possa
precomputare le chiavi da testare: con un salt anche solo di 64 bit
l'attaccante sarebbe costretto a precomputare (e salvare da qualche
parte) 2^64 dizionari da diverse migliaia di password, rendendo di
fatto questo tipo di attacco non pratico.
Per questo motivo in pratica tutti i sistemi crittografici più maturi
disponibili non prescindono da questo passo estremamente importante del
derivare la chiave a partire e dall'elemento segreto e da un valore
univoco di ampiezza sufficiente.

 qualsiasi cifrario).
1) Che cos'è la crittoresistenza? La resistenza alla crittoanalisi?
2) Perché dici che cambia? Cambia se utilizzo determinate modalità degli
algoritmi (es. CTR, CBC a VI casuale, ecc...). Ma se io utilizzo un
algoritmo in modalità ECB, quella più semplice da implementare, ottengo
sempre lo stesso testo cifrato partendo dalla stessa combinazione testo
in chiaro + chiave.
-- 
Ciao.
Leo.
Web: 
www.leonardomiliani.com
E-mail: 
leon...@leonardomiliani.com
Scegli software opensource - Choose opensource software

 univoco di ampiezza sufficiente.
Grazie. Sei stato molto esaustivo e paziente.
bye

 in chiaro + chiave.
Ho inteso quella che mi è apparsa come una descrizione confusa, come
richiesta di chiarimenti riguardo ad una sovracifratura.
Ho inteso male?
