Newsgroup: it.comp.sicurezza.crittografia
Titolo: pareri algoritmo cifratura

Ciao a tutti,
innanzitutto, premetto che sono un novello di questa affascinante.
scienza, percui perdonatemi se scrivo delle eresie.
Ho creato un programmino in C che si occupa di cifare dei
file di testo o altro aventi una dimensione max. di 30 000 000
bytes (in realta' e' pensato per codificare file molto piu' piccoli
tipo email ecc..)
Funziona cosi': il programma risiede in un cd pieno, contenente
10 chiavi da 60mb circa l'una composte da numeri casuali
(ovviamente queste chiavi devono rimanere segrete).
Ho scelto questa dimensione perche' il programma consente di
essere distribuito tramite la consegna di un cd.
Per codificare o decodificare, questo programma ha bisogno di
una password.
Questa password serve a determinare in maniera univoca,
il n° di file di chiave (da 0 a 9) e la porzione di esso che va a cifrare
il file originale mediante XOR.
Questa chiave pensavo di renderla pubblica.
Applicando al file cifrato la stessa chiave, si ottiene il file originale
e viceversa.
Quello che mi domando io e' quale livello di sicurezza offre questo
procedimento.
Secondo le mie previsioni, e' piuttosto alto, essendo la chiave molto
piu' grande (600mb circa ) del file da cifrare (max.30mb circa ma
mediamente pochi Kb).
Siete dello stesso parere?
ciao
 

 Siete dello stesso parere?
Una delle regole della crittografia è quella di evitare soluzione "fai-da-
te", come ad esempio questa...Perchè non utilizzare un AES (se vuoi una 
soluzione a chiave privata) o RSA (se vuoi una soluzione a chiave 
pubblica)?
Il primo tipo di attacco che mi viene in mente è un attacco know 
plaintext, alla fine questo algoritmo non aggiunge niente a un semplice 
XOR, visto che (se ho ben capito) la chiave utilizzata per cifrare sarà 
più o meno sempre la solita.
A me sembra che tu stia reinventando (MALE!) la ruota.
-- 
"Le opinioni dei fanatici prescindono dai fatti"
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"
Linux Registered User: 461615
http://lmainardi.blogspot.com

 A me sembra che tu stia reinventando (MALE!) la ruota.
Forse mi sono spiegato male: un conto e' la chiave principale, un conto
e' la chiave che effettivamente viene usata.
Quella principale e' sempre la stessa (600mb da custodire con segretezza),
quella usata e' solo una porzione *non sequenziale* della chiave principale
(in pratica non e' un semplice pezzo di chiave principale).
Il punto e' proprio che la chiave usata non sara' mai la stessa perche'
1) viene scelta in base alla password che ovviamente cambia ogni volta
2) viene scelta in base alle dimensioni del file da criptare, che ovviamente
cambia di volta in volta
3) e' molto piu' grande del testo da criptare (mediamente 1:100000) che
mi garantisce un riutilizzo della stessa per diverso tempo.
Nella mia ignoranza mi sono affidato al concetto espresso dal cifrario di
Vernam: cioe' la non riutilizzabilita' della chiave.
In pratica ogni file criptato, avendo una sua password ed una sua lunghezza
che non saranno mai uguali tra file e file, avra' una chiave sempre diversa.
Sara' sicuramente vera l'affermazione che fai riguardo ai sistemi fai da te:
purtroppo il mio carattere, molto diffidente, mi porta ad essere piu' sicuro
del mio operato piuttosto che di quello di altri.
Premesso che sto realizzando questo solamente per diletto personale, non
ho alcuna necessita' reale di comunicazioni riservate. Avevo solamente la
voglia di sperimentare un sistema di crittografia, grezzo ma efficace.
ciao e grazie.

 del mio operato piuttosto che di quello di altri.
E invece fai male :-)
Essere diffidenti e' la regola in un ng di crittografia :-) ma bisogna anche 
capire i propri limiti: costruire algoritmi sicuri richiede conoscenze 
estremamente avanzate di matematica, informatica, teoria dell'informazione 
ecc. e stai sicuro che un sistema del genere che proponi tu e' gia' stato 
proposto da qualcuno, analizzato, attaccato e reso obsoleto (come quasi 
tutto quello a cui noi comuni mortali possiamo pensare :-)
Pleg 

La sicurezza dipende dalla bontà dei dati random sul CD, ed essendo un
sistema tipo-OTP, anche dalla sicurezza con cui la chiave (il CD)
viene maneggiata (distribuita, conservata ecc).
Un altro fattore da tenere in considerazione, come altri poster hanno
evidenziato, è che non si tratta di un OTP (cifrario di Vernham) vero
e proprio, ma di un cifrario in cui porzioni della chiave possono
essere riutilizzati.
Se ho capito bene la chiave secondaria (la password) determina quali
byte di chiave primaria (il CD) vengono utilizzati; aumentando la
quantità di dati cifrati aumenterà la possibilità di riutilizzo del
materiale della chiave primaria.
Se la chiave viene riutilizzata non siamo più di fronte ad un OTP,
intrinsecamente sicuro, ma davanti ad un sistema la cui sicurezza
dipenderà dalla quantità di materiale cifrato e dalla bontà
dell'algoritmo che sulla base della password determina i dati da usare
come chiave.
Ma se quell'algoritmo è sicuro, allora potresti direttamente usarlo
per generare uno stream random e liberarti dal peso della gestione
della chiave su CD.
E se invece non è sicuro, molto meglio liberarsene ed usare un
semplice puntatore che dica all'applicazione quale porzione di chiave
leggere, in modo da eliminare la possibilità di riutilizzo della
chiave.
Inoltre devi tenere presente che ci sono diversi scenari di attacco,
quindi un algoritmo che come l'OTP è matematicamente sicuro nel
mantenere la privacy del messaggio, non è assolutamente sicuro in
altri scenari.
Ad esempio l'OTP non modifica l'ordine dei byte del messaggio e non
prevede alcun tipo di autenticazione, per cui è piuttosto semplice
attaccarlo cambiando in modo malevolo il messaggio se anche solo se ne
ha una vaga idea, un esempio molto banale: una disposizione di
pagamento potrebbe agevolmente passare da "Pagare 1000 euro" a "Pagare
9000 euro" senza che il sistema rilevi nulla di anomalo (ne un output
decifrato in maniera illeggibile, nè il fallimento di un controllo di
autenticazione).
Insomma, il sistema non solo deve essere sicuro ma anche coprire le
esigenze del tuo modello di rischio, altrimenti meglio affidarsi a
soluzioni pronte (anche "semilavorate" ad es partire implementando un
algoritmo noto, o usando una libreria di crittografia già testata) che
di solito, oltre ad evere passato una grande mole di test teorici e
pratici, sono realizzati con parecchi diversi modelli di rischio in
mente e quindi tendono ad essere soluzioni più generali ai problemi
particolari dell'utente.