Occorre essere molto chiari su una cosa: sono un grosso fan della privacy, di ogni tipo. E sono un grosso avversario di operazioni come quella che sta facendo NSA , ovvero creare un sistema di sorveglianza di massa. Posso capire il governo cinese che attacca singoli bersagli per carpirne i segreti: questo e' normale spionaggio, ma la sorveglianza di massa e' una cosa diversa.
So che questa cosa sta dando agio ad un certo dibattito, quei dibattiti ove sedicenti intellettuali parlano di "fine del secolo della privacy" o altre stronzate. A queste stronzate rispondo normalmente con un pugno nello stomaco. Eccolo:
Anna Frank scrisse il suo diario mentre si nascondeva. I nazisti impiegarono diverso tempo per trovarla, e questo le diede, appunto, il tempo di scrivere il proprio diario, che va dal 1942 al 1944 . Circa due anni. La domanda che vi pongo e': nel mondo di NSA, quanto tempo durerebbe Anna Frank? Calcolando il tempo per la scansione su una normale infrastruttura MapReduce e il tempo di intervento della polizia, statisticamente parlando, nel mondo di NSA Anna Frank sopravviverebbe 9'08". Nove minuti, otto secondi.
Nove virgola zero otto. Nemmeno il tempo di scrivere UNA SOLA pagina del suo diario. Questo e' quello che ha costruito il Generale Alexander.
Adesso mi direte che voi non avete nulla da nascondere, che non fate niente di male. Perche', Anna Frank invece? Se avete qualcosa da nascondere non lo decidete voi: lo decide il governo. E quando qualcuno mi dice che serve contro il 9/11, io rispondo normalmente con questo numero: 9'08" . Il tempo quadratico medio di sopravvivenza di Anna Frank se NSA la cerca e lei si trova in Europa.
Detto questo, andiamo al punto: dopo la rivelazione sulla costruzione del piu' forsennato archivio Gestapo della storia (1) , tutti hanno preso la stessa, identica, forsennata decisione: crittografiamo.
Non e' evidentemente bastato Heartbleed per far capire il pericolo, e questo e' perche' si trattava di un baco: le persone si fidano della crittazione. E qui avrete una domanda: e perche' non dovrebbero?
Eh, lo vediamo subito.
Prendete questa vecchia tecnica di attacco alla crittazione a blocchi , per andare sul tema "dischi cifrati":
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.7749&rep=rep1&type=pdf
che non diventa meno efficace cambiando spesso chiavi,a meno di non creare chiavi particolari:
https://eprint.iacr.org/2007/227.pdf
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.148.7749&rep=rep1&type=pdf
che non diventa meno efficace cambiando spesso chiavi,a meno di non creare chiavi particolari:
https://eprint.iacr.org/2007/227.pdf
Se mi rispondete che DES e' vecchio:
http://eprint.iacr.org/2009/374.pdf
e
http://eprint.iacr.org/2012/280.pdf
(le tecniche chosen-text sono quelle che rendono pericoloso avere enormi quantita' di dati di cui una parte, anche molto piccola, nota a priori).
Come vedete, si tratta di una tecnica di attacco che consiste nel costruire una funzione statistica di trasformazione del segnale, che lavori tra input ed output. Tale trasformazione si basa sulla conoscenza statistica di alcuni dei pattern contenuti nel messaggio, e come vedete DIPENDE MOLTO DALLA QUANTITA' DI DATI DA ESAMINARE. (figura 1 nel primo link).
In tutti i casi, per esempio nell'ultimo: the best practical single-key attack on AES-256 is a SQUARE attack on 6 rounds which requires 6*2^32 chosen plaintexts and has time complexity of 2^44
In tutti i casi, per esempio nell'ultimo: the best practical single-key attack on AES-256 is a SQUARE attack on 6 rounds which requires 6*2^32 chosen plaintexts and has time complexity of 2^44
In un petabyte di dati, 2^32 chosen texts li trovate.
E' interessante anche questo:
http://eprint.iacr.org/2014/216.pdf
Per quanto riguarda RSA, potete trovare interessante questo:
http://eprint.iacr.org/2014/035.pdf
In senso puramente teorico, del resto, era assai noto che la forza di una crittazione dipenda dalla dimensione della chiave confrontata con la lunghezza del messaggio. Idealmente, la chiave dovrebbe essere lunga quanto il messaggio, se non di piu'.
Ma le cose stanno andando esattamente nella direzione opposta. La decisione di google e di tutti gli altri stakeholder di "crittare il traffico" ha generato quantita' mai viste prima di traffico criptato. La catastrofica quantita' di traffico, che si misura in exabyte, petabyte, e presto zettabyte, sta diventando miliardi di miliardi piu' grande della lunghezza media delle chiavi.
Di fronte a petabyte o zettabyte di traffico,
chiavi lunghe pochi KB possono diventare letteralmente trasparenti ad attacchi
come quello descritto nel link.
nel momento in cui un google, un facebook ed una Microsoft criptano il loro traffico interno, e nel farlo useranno chiavi della dimensione di KB, stanno di fatto rendendo trasparente la crittazione. E come leggete nell'articolo, cambiare spesso le chiavi serve a poco.
Questo problema tocca l'utente medio quando usa software come TrueCrypt o altri: criptare l'intera partizione del disco non produce sicurezza, anzi la indebolisce contro attacchi di tipo statistico: e' noto il metadato dei file, come la tabella di allocazione, sono noti centinaia di MB del sistema operativo, dal momento che Windows lo comprate in negozio. In queste condizioni la costruzione di una funzione statistica di canale e' estremamente piu' semplice. Se criptate l'intero disco, di cui la maggior parte vuoto - contenente quindi solo metadati del filesystem, mi fate solo ridere. Leggete attentamente il documento che ho linkato, e capirete quanto piu' facile sia la vita dell'attaccante.
La crittazione e' sicura per file che abbiano dimensioni paragonabili alla chiave. Oltre, tutte le vostre chiacchiere su ipotesi di Riemann e fattorizzazione sono pura fuffa.
Il secondo punto sta nei randomizzatori. La crittazione a chiave pubblica/privata dipende in maniera fortissima dai randomizzatori. Ma per quanto randomico sia il randomizzatore del vostro computer, si tratta comunque di una macchina deterministica. E' noto all'accademia che quando si generano numeri casuali con macchine deterministiche, la congruenza e' solo una questione di scala.
Numeri apparentemente casuali, se raccolti in quantita' sufficienti, mostrano chiaramente patterni di congruenza.
Ora stiamo andando a criptare quantita' di dati enorme. La soluzione al problema della randomicita' e' stata quindi affidata a randomizzatori "fisici", credendo che trattandosi di dispositivi fisici che producono casualita', allora si esca dall'inevitabile congruenza dei numeri pseudocasuali generati da macchine deterministiche.
Se i randomizzatori sono di cattiva qualita', quel che ottenete sono attacchi come questi:
http://eprint.iacr.org/2013/599.pdf
che, come vedete, traggono vantaggio dalla GRANDE quantita' di chiavi in possesso.
Se i randomizzatori sono di cattiva qualita', quel che ottenete sono attacchi come questi:
http://eprint.iacr.org/2013/599.pdf
che, come vedete, traggono vantaggio dalla GRANDE quantita' di chiavi in possesso.
Beh, se credete a questi dispositivi ho brutte notizie per voi: http://perso.univ-rennes1.fr/david.lubicz/articles/gda.pdf
Come vedete, anche in questo caso si tratta di attacchi che dipendono moltissimo dalla quantita' di dati in gioco.
La decisione dei grandi OTT di "crittare tutto" va a indebolire due concetti che stanno alla base della crittazione: il primo e' la lunghezza della chiave, il secondo e' la bonta' dei randomizzatori.
c'e' ancora poca letteratura esplicitamente orientata verso la crittazione del Big Data: come materia il Big Data esiste da pochissimo, quindi non troverete molto. Ma esistono fondatissime ragioni teoriche per dubitarne.
La decisione degli OTT di "criptare tutto" e' sicuramente la cosa migliore che potessero fare, e la migliore pratica possibile. Ma non ha condotto gli utenti in un porto sicuro: li ha condotti in un porto SCONOSCIUTO.
non sto puntando il dito su Microsoft o Google o Facebook: dal loro punto di vista, "crittazione" era la risposta migliore. Tuttavia, portando la mole di traffico sino al petabyte, e presto allo zettabyte, si sono infilati in una zona "grigia" della crittografia, una zona poco esplorata, in una condizione per la quale le conoscenze TEORICHE sulla crittografia (lunghezza chiavi, randomizzazione, etc) suggeriscono di NON FIDARSI.
Per questa ragione ho parlato di security by isolation, e di steganografia: buttare tutto il mondo sulla crittografia come se fosse la soluzione a tutti i mali E' SBAGLIATO.
Occorre esplorare ANCHE altre strade.
La mia personale visione a riguardo e':
Occorre esplorare ANCHE altre strade.
La mia personale visione a riguardo e':
- Piccole quantita' di dati molto segreti: la crittografia in generale va bene se il contenuto e' di dimensioni paragonabili alla chiave, e meglio ancora se la chiave e' generata one-purpose. Una chiave per documento (e non una chiave per utente! )
- Grandi quantita' di dati molto segreti: in questo caso la strategia migliore e'"security by isolation", ovvero metterli in un supporto raggiungibile solo da alcuni, fisicamente e telematicamente.
- Dati segreti in movimento: steganografia. Il dato non e' difficile da leggere, ma difficile da trovare sul supporto.
il punto ultimo forse vi sembrera' strano, ma vorrei ricondurmi all'inizio del post. Il Diario di Anna Frank non e' sopravvissuto perche' illeggibile o protetto. La protezione salto' (furono trovati e deportati) e il testo era leggibilissimo.
Il Diario di Anna Frank sopravvisse perche'non fu trovato: i vicini lo prelevarono e lo nascosero altrove. Se e' sopravvissuto non lo dobbiamo ne' alla separazione fisica ne' alla crittazione: lo dobbiamo alla steganografia, una forma primitiva, con cui si nascose il testo.
(1) Himmler introdusse un nuovissimo sistema di archivi a schede rotanti per la Gestapo , piu' o meno allo scopo di effettuare sorveglianza di massa. Agli americani e' sempre piaciuto riciclare tecnologie naziste, partendo dalla missilistica, all'aereonautica, ed evidentemente anche alla polizia segreta.