Il capolinea di Truecrypt

A Giugno ero a dieta: di Internet, poco letto, niente scritto. L’avrete capito, era una dieta per l’aumento della produttività.

Il caso vuole che sia in quei giorni che si è discusso su internet di quel che è successo a Truecrypt: ho perso l’opportunità di aprire il becco a riguardo, e vorrei rimediare ora, rispondendo in particolare alla segnalazione della notizia che era stata data su Hacking Italia.

Truecrypt ascesa e caduta

Truecrypt ha ottenuto una certa popolarità da tre anni a questa parte per il suo essere disponibile su Linux, Mac e Windows e consentire così di avere accesso su tutte e tre le piattaforme ad una stessa risorsa di crittografia. Con Truecrypt si potevano creare dei volumi cifrati su Linux, trasferirli e leggerli su Windows: una risorsa interessante, specialmente per chi non ha a disposizione LUKS o il succedaneo File Vault 2, e disdegna PGP.

Una risorsa bella che è oramai da considerare come persa.

A Giugno 2014 infatti è stato pubblicato un aggiornamento di Truecrypt, la versione 7.2. Particolarità: accoglie gli utenti dicendo loro che Truecrypt non è sicuro, li invita ad abbandonare il programma e non consente di fare alcunché se non esportare i dati.

Grandi discussioni sono nate su cosa potesse essere successo: minacce agli autori (ignoti), furto d’identità? Nulla di tutto questo, sembrerebbe. Probabilmente la stanchezza ha avuto la meglio su un gruppo oramai logoro. Uno degli autori (o almeno supposto autore) ha dichiarato che non è consigliabile creare un nuovo programma a partire dal codice di Truecrypt: “da tempo volevamo riscrivere Truecrypt da capo”.

I commenti

Riprendendo quindi i commenti su Hacking Italia.

  1. Non è corretto dire, come ha fatto RG nel titolo, che “Truecrypt non è sicuro”. Nessuno ha potuto provarlo, sino ad ora. Certo non è consigliabile continuare ad usarlo.
  2. Nicola Losito ha osservato: “con buona pace del “codice aperto” …”. Sappiamo bene che il codice aperto non è garanzia di sicurezza. L’assenza di codice aperto, però, è garanzia di insicurezza. Il codice aperto è prerequisito per la sicurezza.
  3. Il passo ulteriore è il controllo. Non a caso era nato un gruppo per controllare Truecrypt. dataghoul dice che non aveva segnalato problemi di rilievo, ma bisogna tenere presente che la loro missione non era ancora conclusa: solo una prima parte dello studio era stata completata.

6 Commenti

  1. Non sò cosa sia Truecrypt e non mi interessa approfondire, ma non posso non reagire alla tua affermazione quando dici :

    “Sappiamo bene che il codice aperto non è garanzia di sicurezza. L’assenza di codice aperto, però, è garanzia di insicurezza. Il codice aperto è prerequisito per la sicurezza.”

    Puoi darmi qualche esempio concreto per i due casi ?

    Ciao.

  2. Thierry, te ne do solo uno [che basta ed avanza]: Heartbleed. Le cause di questo bug sono nel codice, aperto, disponibile da tempo immemore. Se questo codice non fosse stato disponibile chissà per quanti anni ancora non sarebbe venuto fuori…

  3. A me sembra piuttosto il contrario, Heartbleed sconfessa di per se quanto affermato più sopra !

    Se poi consideriamo che anche il nostro OS può essere considerato come un programma chiuso mi sembra una netta contraddizione !

    E cosa dici di tutti quei programmi che usano dei protocolli di trasmissione proprietari che servono ad esempio ad aprire a distanza le paratie di una diga o una valvola in una centrale nucleare o il posizionamento di un satellite di osservazione o di telecomunicazioni. Rendere open source questi programmi, protocolli e normative non mi sembra una buona idea.

    A proposito, se non erro il protocollo che hai usato per consultare questo sito, il TCP/IP, non è open source, o sbaglio ?
    Idem per HTTP, HTTPS e compagnia bella quindi anche Bluetooth e tutto quanto ha bisogno un router e una scheda di rete per la codifica e decodifica.

    E che ne dici dei DLL contenuti più o meno in tutti i programmi che hanno a che fare con Microsoft ?

    È un pò come dire che sei un ecologista e che non inquini perché non hai la macchina dimenticando che le scarpe che hai acquistato al mercato sono state fabbricate in Tailandia, sono state trasportate via mare o aereo, poi per camion, infine sono state acquistate in un negozio che si riscalda a nafta, e questo è valido anche per camicia, pantaloni, mutande e calzini.

    Ciao.

  4. Hai ragione, ho fatto un pò di confusione, lo dimostra la mia precedente risposta che parla di “Open source” mentre tu parli di “Codice aperto”.

    Il protocollo TCI/IP è stato sviluppato come standard aperto, vale a dire che chiunque può prenderlo così com’è e usarlo, ma non mi risulta che ti sia permesso modificarlo come standard.

    Altra cosa è l’Open source e le sue varie licenze (FreeBSD, NetBSD, openBSD, BSD, per citarne solo alcune), che puoi prendere, usare e modificare come ti pare e magari anche fare accettare il codice che hai scritto al detentore del progetto che lo integrerà nella licenza base o una sua variante.

    Personalmente sono contro l’Open source, prevalentemente per ragioni di ordine economico e che proprio per questo non creano codice più sicuro.

    Alla base di prodotti “sicuri” c’è sempre un team molto competente, una base utenti che ne faccia parte per garantire alle informazioni di risalire la gerarchia e migliorare e correggere il codice in un processo continuo.
    Il grande pericolo del codice “Open source” è la mancanza di fondi che porta inesorabilmente a una mancanza di risorse, in casi estremi alla fuga delle vere menti pensanti e di riflesso al decadimento del codice.

    Al limite si potrà pensare che sul lungo periodo vi sono maggiori probabilità di codice sano in un progetto “open source”.
    La mia convinzione resta che la qualità del lavoro di chi è correttamente retribuito e motivato produce una migliore qualità di codice.

    Ciao.

Lascia un commento

I campi richiesti sono evidenziati con *.