[Soci SLIP] Crittografia... :-)

[Massimo Nuvoli]

Martedì sera ero decisamente fuso, parlando di https mi sono
avventurato in discorsi che, francamente, non avevo preparato per cui
qualcosa non è venuto fuori come dovuto.

Quando ho parlato di "insicurezza" della crittografia citando gli
algoritmi non ho centrato bene le cose, ora mi sono documentato e
chiarisco quanto detto.

A parte la spiegazione tecnica il problema di tutti i sistemi di
sicurezza è: "per quanto tempo riesco a proteggere un dato?".

Gli algoritmi, tutti, sono bucabili, ma ci vuole o potenza di calcolo
enorme o tanto tempo (fattore COSTO e/o fattore TEMPO).

Quindi un dato protetto con crittografia può essere rivelato con TEMPO
breve e COSTO altissimo, oppure con TEMPO lunghissimo (secoli) e COSTO
bassissimo, con tutte le sfumature intermedie.

Un dato, vedi ad esempio il codice della carta di credito, dopo
qualche anno non ha più utilità di essere rilevato, e tante altre
informazioni sono utili solo se decifrate in tempi molto brevi.

Questo deve spingere tutti ad utilizzare sistemi di crittografia "AL
PASSO CON I TEMPI" e qui vi spiego cosa significa:

Algoritmo DES, ritenuto sicuro fino a qualche anno fa, qualcuno ha
pensato, mah, proviamo a bucarlo:

1998 DES viene "bucato" in 56 ore da un supercomputer
1999 "bucato" in 22 ore

Una stima reputa che con un sistema dedicato da 1 milione di dollari
un dato possa essere rilevato in meno di un ora.

Altro caso, il 3DES, che è molto utilizzato nelle attuali
implementazioni è soggetto allo stesso "pericolo" di essere bucabile
del DES, ma la lunghezza della chiave e difficoltà attuali rendono
praticamente impossibile farlo.... (che casualmente è la stessa frase
utilizzata da un ricercatore all'inizio degli anni '90 parlando del
DES...)

Aggiungo una cosa importante, anche questa me la sono fumata l'altra
sera: DES e 3DES sono algoritmi di crittografia "simmetrici" ovvero un
dato viene "crittografato" e "decrittografato" usando la stessa chiave.

Altra cosa, sono gli algoritmi "asimmetrici", per crittografare il
dato viene usata una chiave, per decrittografarlo un'altra. Https
utilizza un sistema di questo tipo, che di per se è più sicuro MA,
come sempre c'è un MA, nelle implementazioni reali è attaccabilissimo
nella fase iniziale di "scambio delle chiavi", https usa questa
tecnica e per questo è vulnerabile alla "sostituzione di identità" e
non tanto all'attacco del dato stesso mentre viene trasferito!!

Ma guardiamo indietro, ecco perchè ho introdotto questo elemento
l'altra sera:

DES viene introdotto nel 1970, adottato largamente nel 1976
(addirittura standardizzato in ANSI).

Nel 1999 si decide che il DES non è più sicuro (vedi sopra) per cui si
passa a 3DES. Nel 2001 dal DES si passa all'attuale AES che dovrà,
secondo gli esperti "reggere" per non più di 10/20 anni.

Tutto questo non significa che i dati non sono sicuri, significa
semplicemente che quando usiamo questi strumenti non abbiamo "LA
SICUREZZA" in assoluto ma "UNA SICUREZZA" ed è bene conoscerne i limiti.

Altro problema, non sappiamo cosa succede nei software proprietari, il
cui codice NON è visibile, ma si teme che le implementazioni siano
viziate da difetti voluti per consentire, quando necessario, la
visualizzazione da parte di terzi.

Da tempo nel nostro ambiente (Software Libero) si cerca di spingere il
più possibile verso implementazioni "aperte" degli algoritmi, questo
perchè eventuali bachi voluti sarebbero rilevabili e correggibili.

Per concludere, negli anni passati un attacco ad https (tipicamente di
tipo intrusivo) era difficile da praticare, anche oggi non è uno
scherzo ma sicuramente è fattibile con pochi comandi e un po' di
pazienza, e con buona probabilità di riuscita.

Tornando ad HTTPS le cose importanti sono:

1) verificare sempre se il nome del sito e il nome riportato sul
certificato sono uguali, se ci sono differenze non va bene
2) verificare sempre chi ha emesso il certificato del sito, e se la
data del certificato è coerente con quella attuale
3) quando vi vengono chieste informazioni "delicate" non basta
controllare come i dati viaggiano sulla rete (DEVE DEVE DEVE essere
https), anche il server che gestisce questi dati deve essere il più
possibile sicuro!!! Questo significa controllare "A CHI" state per
dare i vostri importantissimi dati.

e chiudo con il pistolotto di questi tempi:

1) nessuno vi chiede dati delicati via email o via web, chi lo fa vi
vuole fregare, siate diffidenti.
2) non usate MAI i link che sono scritti nella posta elettronica per
entrare in un sistema della banca o altro. Se usate il remote-banking,
utilizzate il solito metodo che adottate normalmente, o meglio,
scrivete a manina l'indirizzo del sito (https://www....)
3) quando siete in un sito in https e vi chiedono dati delicati, quali
la carta di credito o altro, cercate per quanto possibile di
controllare a chi state dando queste informazioni, dopo aver
controllato con cura se https è a posto.

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  250 bytes
Descrizione: OpenPGP digital signature
Url:         http://mailman.pinerolo.linux.it/pipermail/soci/attachments/20060323/28f02dbf/signature.bin