Newsgroup: it.comp.sicurezza.crittografia
Titolo: File crittato solo a blocchi: è sicuro?

Salve,
sto realizzando un'applicazione in Java RMI per la chat e l'invio di
messaggi di posta elettronica. Sulla rete non mando le informazioni in
chiaro ma crittate. Per i testi (contenuto delle mail, dei messaggi di
chat, degli oggetti delle mail) le operazioni di
crittazione/decrittazione sono alquanto veloci, viste le (relativamente)
ridotte dimensioni degli array di bytes in ingresso equivalenti; i
problemi sorgono per le operazioni relativve al crittaggio
(decrittaggio) degli array di bytes risultanti i files allegati: la
complessità dele operazioni di crittaggio dipende dalla dimensione
d'ingresso in modo drastico e per scompattare e ricompattare un file di
1MB ci vuole 1/2h di CPU circa. PIUTTOSTO CHE CRITTARE TUTTI I BLOCCHI
COSTITUENTI L'ARRAY DI BYTES DI UN FILE, POSSO CRITTARE SOLO
PARZIALMENTE I BYTES DEL FILE? IL FILE RISULTANTE GARANTISCE COMUNQUE
SICUREZZA DI INUTILIZZO PER TERZE PERSONE O PUO' ESSERE, IN QUESTO
SENSO, CRITICABILE?
A naso direi di si, ma è così?
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 A naso direi di si, ma è così?
Non ho capito bene che vuoi fare: crittare solo "parti" dei file? Che
algoritmo di cifratura usi?
Saluti,
Federico
PS: Non urlare. ;-)
-- 
On the web:  
http://www.quaqo.org
 - OpenPGP KeyID: 0x5539D8E4
Jabber: 
qu...@jabber.org
 - MSN: 
qu...@msn.com
 - ICQ: 48618109
Linux User: #263663 / Machine: #216144 (Arch Linux  / Noodle)

 PS: Non urlare. ;-)
-- 


 E' sicuro un file crittato così?
A intuito sì (non conosco javax.security.*), a patto che il numero da 64 
byte (512 bit, vero?) che critti sia inferiore al modulo dell'RSA (è 
consigliabile usare un modulo da almeno 1024 bit).
Per essere sicuri, però, bisognerebbe capire *esattamente* come li critti.
In ogni caso, adesso si spiega la lentezza di cui parli; se ti è possibile, 
conviene che utilizzi un algoritmo simmetrico (tipo l'AES); la velocità 
potrebbe aumentare anche di 1000 volte (dipende dalle implementazioni).
Cristiano 

 Cristiano


 come possono dire che estensione abbia il file?
I file JPEG sono salvati a blocchi; forse è questo il motivo che potrebbe 
permettere una ricostruzione parziale del file.
Cristiano 

 caso, l'idea dello xor è accettabile, ma la decifratura come funziona?
Per la "cifratura" sul sender, farei lo xor tra blocchi (320 Kb) di
bytes del file
da inviare, con un impronta di bytes, anch'essa di 320 Kb. 
Invierei file crittato e impronta (crittata) al receiver.
Per la decifratura, farei lo xor, ancora, tra i blocchi di 320 Kb e
l'impronta, chiaramente
 decifrata. Il risultato dovrebbe dare i blocchi di bytes dell'array di
bytes da ricostruire sul receiver.
Non so quanto possa essere affidabile un'impronta di 320 Kb da attacchi
bruti.
Però, pensandoci, avrei 2^2560000 possibili soluzioni da testare.. ad
avercelo
tutto questo tempo.. Sceglierei un'impronta di simili dimensioni perché
ho riscontrato essere quella la soglia al di là del quale la macchina va
in crisi nelle relative operazioni di crittaggio-decrittaggio..


 avercelo tutto questo tempo..
Ad avercelo... :-) Ma dipende come ricavi l'impronta.
Cristiano 

 


 classe BitSet? E quando finisco?
Il problema dello xor l'ho banalmente risolto, basta fare b^c con b e
c due byte per avere b xor c. Resta un problema sostanziale: mi è stato
detto che eseguire due
volte lo xor (una volta per la "cifratura", un'altra per la
"decifratura"), anche se
l'impronta è lunga (320 Kb), è un sistema attaccabile, visto che si
potrebbero compiere degli studi sulle
occorrenze dei caratteri più frequenti e in qualche modo xorare sulla
base di essi il contenuto "crittato". A questo
punto non so più cosa fare, mi dico: "per Pietro e Pietro, mi tengo a
Pietro mio", cioè,
se devo fare qualcosa di veloce ma non efficace, critto tutto quanto
l'array
di bytes e chi si è visto si è visto.. Tu cosa mi consigli di fare?
Peccato però, perchè lo xor di
blocchi di file sarebbe stata una scheggia in termini di velocità di
calcolo.. :'-\


 calcolo.. :'-\
Ci credo! :-) Lo xor è un'istruzione direttamente implementata dalla CPU,
l'RSA è incredibilmente più complesso di un semplice xor.
Cristiano 

 trasmetti C_i, C_{i+1} e X_j e incrementi i di 2 e j di 1. E` così?
impronta è sempre la stessa ad ogni xor sul blocco dell'array di byte da
inviare
 C_i = Pub(M_i)
 C_{i+1} = M_{i+1} ^ impronta
 X = Pub(impronta)


 X = Pub(impronta)
Se l'attaccante ha a disposizione solo le C e la X e non ha la possibilità 
di farsi cifrare un M fittizio, direi che è accettabile, ma c'è il problema 
di cui parlavi, cioè è possibile analizzare le frequenze delle C_{i+1}, per 
cui disponendo di molte C_{i+1} *potrebbe* essere possibile intuire M, 
sempre che M abbia una distribuzione di bit sufficientemente strutturata (se 
M fosse un file di bit casuali, l'attaccante non potrebbe capirci nulla).
Cristiano 

 Cristiano


 ha scritto nel messaggio 
news:8aad864612b02588dde...@mygate.mailgate.org...

Che vuoi che ti dica? :) Quello che t'ho già detto: se non hai modo di usare 
né un block cipher né uno stream cipher, la cosa "regolare" che rimane è 
usare l'RSA per tutti i blocchi (come dicevi anche tu prima).
La velocità non sarà mai quella di un algoritmo simmetrico, ma la mezz'ora 
di CPU di cui parlavi tu per 1 MByte mi sembra un po' eccessiva. 
L'implementazione mia dell'RSA (che sfrutta la libreria MIRACL) cifra a 
22200 bit/s e decifra a 16500 bit/s (con modulo da 1 kb e P4 1,5 GHz), per 
cui 1 Mbyte verrebbe cifrato in poco più di 6 minuti e decifrato in poco più 
di 8; non sarebbe una scheggia, ma forse potrebbero anche essere tempi 
accettabili.
Com'è possibile che non hai nient'altro a disposizione?
Cristiano 

 Com'è possibile che non hai nient'altro a disposizione?
Hai ragione a meravigliarti, il fatto è che non ho nessuno..
Volevo chiederti ancora però, se davvero procedessi come avevi pensato
tu, cioè
usando per il k-simo xor un'impronta diversa da quella usata al passo
k-1-esimo,
il sistema sarebbe ancora poco sicuro contro attacchi portati a termine
su studi della casistica delle occorrenze più comuni? Se no, a questo
punto
il problema sarebbe spostato: servirebbe piazzare una fuziona
(economica)
tale, data l'impronta originaria, di farla variare di passo in passo.  
Ma val davvero la pena giocare giocare questa carta? l'attacante famoso,
verrebbe in un certo senso "murato"?
grazie Cristiano per il tuo sostegno, Delio


 grazie Cristiano per il tuo sostegno, Delio
Figurati, è un piacere! :)
Purtoppo, non partecipando nessun'altro alla discussione, tocca che ti basi 
solo su quello che ti dice uno solo (che sarebbi io); mi rendo conto che non 
è molto.
Cristiano 

 
Pìuttosto di fare S=S+1, se facessi S=S+S[i] con S[i] i-esimo elemento
e lo incremebtassi i secondo una qualche funzione, guadagnerei in
sicurezza?


 sicurezza?
S[i] potrebbe essere l'uscita del generatore deterministico di cui parlavo. 
In tal caso non c'è bisogno di fare S=S+S[i], basta che utilizzi un S[i] che 
sembri casuale. Per la sicurezza, vale quello che t'ho già detto.
Cristiano