Newsgroup: it.comp.sicurezza.crittografia
Titolo: crittografia asimmetrica + firma digitale

Ciao a tutti,
volevo capire se c'è qualche differenza in termini di sicurezza tra i
seguenti 3 modi per affrontare il problema (in realtà si tratta per lo
+ di ordinare in modo diverso le operazioni, perdonatemi se dico
bestialità):
1) modo classico: creo firmo digitale crittata con chiave privata, la
allego al messaggio in chiaro, critto tutto con chiave pubblica;
2) creo firma come prima, critto il messaggio con chiave pubblica,
invio separatamente i 2 (non vedo particolari attrattive in questa
alternativa, ma mi è stata presentata);
3) critto messaggio con chiave pubblica, creo firma dal messaggio
crittato utilizzando la chiave privata per la firma, invio i 2
separatamente (soluzione che mi pare attraente dal punto di vista
dell'efficienza, perchè ti permette di scartare a priori il messaggio
nel caso in cui la firma non corrispondesse, in modo da evitare la
decrittazione dello stesso, che in alcuni casi potrebbe essere
computazionalmente onerosa).
Grazie in anticipo per le risposte
Ciao
Giorgio

Personalmente preferisco la tua ipotesi n° 1, vale a dire firmare il
testo in chiaro, allegare la firma al testo e cifrare tutto alla fine,
per questi motivi:
lo scopo primario di un pirata è quello di violare il messaggio cifrato,
per cui più informazioni gli si passano su questo messaggio più si
facilita il suo compito. Violare un'autenticazione digitale è
relativamente più semplice che violare un messaggio cifrato con un
robusto algoritmo: un'autenticazione digitale fornisce informazioni sul
testo cifrato, dato che la somma di controllo è calcolata a partire da
questo. Se invece lo stesso pirata viola un'autenticazione cifrata
basata su un testo in chiaro non avrà informazioni supplementari sul
codice cifrato finale dato che questo è stato generato in un secondo tempo.
-- 
Ciao.
Leo.
Web: 
www.leonardomiliani.com
E-mail: 
leon...@leonardomiliani.com
Scegli software opensource - Choose opensource software

In realtà sono anch'io per la prima ipotesi.
Il punto che mi lascia più perplesso consiste nel fatto che se ho
capito bene è relativamente piuttosto semplice trovare collisioni per
certi algoritmi di digest, per cui se volessi attaccare una
comunicazione effettuata col modo 3) potrei semplicemente generare
messaggi che corrispondano alla firma (decrittabile con chiave
pubblica, quindi praticamente in chiaro); che poi tali messaggi non
abbiano senso, a maggior ragione dopo che vengono passati per la
funzione di decrittaggio poco importa, perchè ho comunque perso la
proprietà di integrità. O forse sbaglio?
Avevo riflettuto anche sulla perdita della proprietà di non ripudio
del messaggio originale, ma di questa per alcuni tipi di comunicazione
si può fare a meno, nel senso che potrebbe non esserci la necessità di
una firma in "senso legale", ma solo di una firma che controlli
l'autenticità.
Mi potete confermare se sto dicendo cose sensate o no?
Ciao
Giorgio

Alcuni algoritmi di digest sono noti per essere molto deboli dal punto
di vista della sicurezza. Ad esempio non è assolutamente consigliabile
usare l'MD5 o l'SHA originale, perché la lunghezza della somma (128 bit)
non fornisce un livello di sicurezza accettabile.
Io uso per fini personali l'HMAC-SHA-256 come firma digitale, basato sul
digest SHA-256 che fornisce un buon livello di protezione (per info:
http://en.wikipedia.org/wiki/HMAC
).
Quindi, se riesci a violare il sistema di autenticazione hai la
possibilità (come dici tu) di creare falsi messaggi perché puoi ricreare
anche la firma di quei messaggi.
Ecco perché i più consigliano di cifrare sia la firma che i dati in un
unico pacchetto in modo tale che la sicurezza di tutto (firma + dati
sensibili) sia ad esclusivo appannaggio dell'algoritmo diciamo
"esterno". In questo caso, di solito, si usa una cifra molto robusta a
chiave simmetrica (tipo un AES a 128 o 256 bit).
Inoltre, considera che se la firma+autenticazione fosse esterna ed
affidata ad un sistema debole, il pirata informatico potrebbe benissimo
alterare il messaggio cifrato (che hai spedito separatamente e quindi è
manipolabile) con byte casuali, ricreare la firma e rispedire il tutto:
in questo caso il ricevente non saprebbe se il messaggio è stato
manipolato perché la firma ed autenticazione sembrano genuine e
corrispondo al messaggio senza senso che ha ricevuto.
Se invece il messaggio è protetto con un algoritmo debole e viene
violato, potrebbe venir ricreata anche una firma "ad hoc" per trarre in
inganno il destinatario.
Ecco perché io preferisco firmare ed autenticare il messaggio prima di
cifrarlo. In questo modo il pirata non può accedere, dall'esterno, a
nessun tipo di informazione che possa aiutarlo a ricostruire oppure a
violare il pacchetto cifrato.
Uno dei cardini di un algoritmo di cifratura è il mescolamento dei byte
per distruggere ogni struttura visibile per cui un pirata che accede ad
un pacchetto cifrato non può sapere se questo contiene solo dati oppure
dati ed autenticazione.
Se vengono alterati byte a caso il destinatario se ne accorge subito
perché ottiene o un errore durante la decifratura oppure un errore
relativo al confronto autenticazione/dati.
Un ultimo appunto.
Tu propendevi per il punto 3) per evitare di decifrare dei dati con un
algoritmo computazionalmente pesante.
Devo però suggerirti che, in genere, gli algoritmi a chiave pubblica,
proprio per la loro pesantezza (per via dei calcoli su numeri con
migliaia di bit) sono in genere utilizzati solo per lo scambio iniziale
della password relativa ad un algoritmo a chiave simmetrica, molto più
efficiente relativamente al rapporto pesantezza di calcolo/protezione
offerta. Considera che un AES a 128 bit offre la protezione che un
sistema RSA offre con chiavi lunghe più di 3200 bit!
Quindi, io cercherei di seguire questo schema:
1)
Alice e Bob aprono un canale cifrato con un algoritmo a chiave pubblica
2)
Alice e Bob si scambiano 2 chiavi: una servirà per l'algoritmo di
cifratura vero e proprio, l'altra servirà per l'algoritmo di
autenticazione e firma;
3)
Alice calcola la firma e l'autenticazione con un buon HMAC
(l'HMAC-SHA256 va già bene) usando l'apposita password che si è
scambiata con Bob;
4)
Alice cifra poi sia la firma/autenticazione sia i dati con un robusto
algoritmo di cifratura (scegli quale vuoi tu, basta che sia ben noto,
opensource e con chiave di _almeno_ 128 bit) e spedisce il tutto a Bob;
5)
Bob prima decifra l'algoritmo con la chiave relativa e poi controlla la
sua autenticità con la seconda password
