-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rispondo un po' a tutti.

Premetto che la mia non voleva essere una critica a Truecrypt, ma in
effetti l'analisi che ho linkato non mi pare del tutto "aria fritta"
(anche se, come ho detto subito, c'e' della paranoia) e credo non sia
fuori luogo discutere del problema, che obiettivamente c'e'.

(*) Premettiamo anche un problema spinoso: la complessita' del software
ha raggiunto livelli tali che e' sempre piu' difficile fare una review
approfondita di un codice, e ci sono sempre piu' finestre per inserire
codice malevolo occultato cosi' bene da passare inosservato ad
un'analisi non paranoicamente minuziosa. Era gia' possibile nel 2003
(vedi [1]) figuriamoci oggi.


On 04/04/2011 03:35 PM, Panagiotis Atmatzidis wrote:
> Ma non e' vero link[2].  Schneier parla spesso e volentieri di 
> TrueCrypt. Ed e' proprio lui che ha spiegato che per essere al 100% 
> sicuri che la 'plausible deniiability' esista, deve esistere un 
> intero sistema nella partizione di truecrypt cosiche non
> interferisce con il 'sistema esterno'. Direi che Schneier e' "valido"
> come Cryptographer.

Indubbiamente. Ma lui e soci non hanno mai fatto, che mi risulti, una
review approfondita del codice alla ricerca di backdoor. Loro hanno
cercato *vulnerabilita'* da poter sfruttare per il loro attacco, una
cosa molto diversa e molto mirata. Vedi anche (*)

(diciamo anche che l'attacco di Schneier e soci a Truecrypt non mi pare
questa cosa cosi' sofisticata e sorprendente, non ci vuole un genio a
capire che se apri un documento hidden con word c'e' il rischio che una
copia venga salvata altrove... Onestamente mi pare quasi piu' un
lavoretto affidato a qualche giovane laureando/ricercatore in cui
Schneier ha fatto poco oltre che mettere il nome. Impressione mia
personale, chiariamo)

> Questo "argomento" (thorough code review) esiste dal 1984 [1] per 
> qualsiasi tipo di programma che non hai scritto tu, da solo. Ne meno
>  per il tuo compiler (CC) puo essere al 100% sicuro che non includa 
> una backdoor ogni volta che crea un executable.

E questo e' un punto estremamente importante senza dubbio. Ma
accantonando per un attimo la possibilita' di una backdoor nel
compilatore, qui si parla possibilita' di backdoor volutamente occultate
nel codice stesso di Truecrypt.


On 04/04/2011 11:56 PM, webwizard wrote:
> - "Truecrypt developers working for free". Embè ? Allora anche
> quelli che lavorano su GIMP sono una massa di idioti ?

No, nessuno ha detto questo, ma almeno si sa chi sono. Ed e' loro
interesse farlo sapere, se non altro per una questione di visibilita'.
E' indubbio che maggiore e' la complessita' del progetto e lo sforzo per
realizzarlo, e minori sono le possibilita' che gli sviluppatori lavorino
gratis. E truecrypt come progetto e' abbastanza impressionante se ci
metti che sviluppano contemporaneamente per N sistemi operativi diversi.
Inoltre GIMP ha una intera community dietro, gli sviluppatori di
Truecrypt da quel poco che se ne sa sono molto pochi (due i nick
"noti"). Non e' una prova di nulla, ovvio, ma un piccolo tarlo in piu'
nell'insieme.

> - "Truecrypt open source code has never been reviewed". Sarà anche 
> vero, ma un software con dentro una backdoor difficilmente si lascia 
> in vista, casomai a qualcuno saltasse il ticchio di farla, 
> l'analisi.

Vedi (*). Probabilmente per un servizio di intelligence determinato e'
piu' conveniente convincere la gente a usare un software open source
(col rischio che la backdoor venga trovata) che un software closed
source (col rischio che la gente non lo usi).

> - "Truecrypt developers identity hidden". Dato che la criptazione è 
> comunque un argomento un po' scottante, non mi stupisco di questa 
> decisione, visto soprattutto come reagiscono i governi (specialmente 
> quello americano) a fenomeni come Wikileaks.

Questo mi pare sensato, ma fino a un certo punto: la sola cifratura (o
sviluppo di sw di cifratura) non e' di per se' foriera di guai in
nessuna democrazia 1.0, altrimenti anche gli sviluppatori di LUKS
sarebbero anonimi.

Lo scenario Wikileaks e' totalmente diverso, volendo fare un paragone
azzardato un esempio piu' calzante potrebbe essere la storia di Phil
Zimmermann con PGP, ma e' dal '95 ormai che NSA e soci hanno capito
che impedire lo sviluppo e la diffusione dei software di crittografia e'
come combattere contro i mulini a vento... suppongo abbiano cambiato
strategia, no?

> - "Truecrypt license contains distribution restrictions". Non è né
> il primo né l'ultimo freeware con restrizioni nella distribuzione.
> Cosa c'entri con la CIA non mi è chiaro.

In effetti niente, ma e' opinione di molti che la licenza sia una delle
piu' "brutte" nel panorama open source (vedi [2]). Non c'entra nulla col
discorso backdoor in effetti. Forse faceva calderone :)

> - "Censorship at Truecrypt forums". Questa è la migliore. Cito 
> testualmente:
> 
> "As per Truecrypt forum rule 3 you are not allowed to discuss about 
> other encryption software, as per Truecrypt forum rule 8 you can’t 
> discuss Truecrypt forks, as per Truecrypt forum rule 9 you can’t 
> discuss software that decrypts Truecrypt."

http://forums.truecrypt.org/viewtopic.php?t=20244

"During the past five years, the forum rules have been updated a few
times. It is possible that you've never read the rules or that you
aren't aware of the updates."

http://forums.truecrypt.org/viewtopic.php?t=1651

Last Updated: December 17, 2010

[3] August 14th, 2010

> ed ecco le regole 3 e 8 del forum:

E' stato tutto messo nella regola n.1 (il che e' indicativo direi):

"Posts meeting any of the following criteria are not allowed and will be
deleted by the moderators or forum administrators without any notice:

   1. Off-topic or spam; for example, discussion of any third-party
encryption software, TrueCrypt "forks" and unofficial TrueCrypt
modifications"

Inoltre: non e' possibile postare nel forum da un account che sia stato
registrato con una casella email diversa da quella fornita dal provider
in uso. Per "combattere lo spam" dicono. Pessimo.

Tutto si puo' dire meno che in quel forum regni la trasparenza,
obiettivamente :|


On 04/06/2011 12:06 AM, Massimiliano Sala wrote:
> Ma scusate, se un'organizzazione X complessa e resourceful volesse 
> dare un giocattolo che critta, allo scopo di farlo usare agli idioti 
> e decrittare a volonta', che senso avrebbe mettere una trapdoor e 
> dare il sorgente? E' vero che non e' banale scovarla in un codice 
> lungo, ma e' possibile, basta un laureando in gamba che se lo scava 
> (e mi verrebbe voglia di farlo fare..) per avere una probabilita'
> non trascurabile di trovarla. E nel momento che e' trovata cade tutto
> il discorso, nessuno lo userebbe piu'.

Vedi (*). Non sono affatto sicuro che non sia possibile scrivere una
backdoor cosi' talmente ben nascosta da risultare quasi invisibile (o
quantomeno invisibile agli occhi di una code review meno che
iper-professionale).


> Se invece io fossi X farei una cosa molto piu' elegante, ovvero 
> prenderei un crittosistema famoso e lo modificherei leggermente con 
> la scusa di irrubostirlo

Qui non sono affatto d'accordo. E' praticamente la prima regola in
crittografia il fatto che l'algoritmo debba essere noto e testato
approfonditamente, PER ANNI, dalla community accademica. Sarei pronto a
scommettere qualsiasi cosa che se domani l'NSA o chicchesia se ne
uscisse con una proposta di versione "irrobustita" di AES passerebbero
anni prima di vederlo usato su larga scala, e nel frattempo sarebbe
sventrato da matematici e crittanalisti vari (che sono pagati per fare
queste ricerche e pubblicare kg e kg di paper coi risultati, al
contrario degli sviluppatori che nel 99% dei casi non sarebbero pagati
per fare una review del codice di un prodotto open source).

Conclusione: piu' elegante si', ma decisamente piu' rischioso e meno
efficiente nascondere una backdoor nell'algoritmo piuttosto che nel codice.


On 04/06/2011 05:39 PM, Enrico Ardizzoni wrote:
> Non è detto che gli eseguibili (Win e Mac in particolare) che tutti 
> noi di norma scarichiamo e utilizziamo siano stati compilati dagli 
> stessi sorgenti resi pubblici. Mi sembra un dubbio legittimo...

Ottima osservazione, e qui rimando a [3]:

"Compiling Truecrypt source code increasingly difficult

Very few people compile the Windows binaries from source; it is
exceedingly difficult to generate binaries from source that match the
binaries provided by Truecrypt (due to compiler options, etc.)"

Non so quanto sia facile per quanto riguarda Linux, non ho provato a
compilarlo onestamente.


On 04/06/2011 07:57 PM, Marco A. Calamari wrote:
> Tutto vero, e sono d'accordo sulle conclusioni. L'affidabilita' 
> dell'articolo e' apparentemente minore di quella del soggetto che 
> tratta.

Concordo, l'articolo potrebbe averlo scritto un binbominkia qualsiasi.
Ma cio' non toglie che alcuni dei dubbi sollevati non sono del tutto
campati per aria e mi pareva doveroso farne una riflessione.


> Mi chiedo pero' ... perche' non c'e' un prodotto di crittazione
> disco sviluppato in maniera adamantina come ad esempio Tor o
> Freenet?

Esattamente quello che volevo dire. Personalmente continuo a fidarmi
molto di piu' di cryptsetup/LUKS per quanto riguarda la sola cifratura.
Il problema e' nella parte di plausible deniability.


On 04/06/2011 01:08 AM, Emanuele Pucciarelli wrote:
> Su questo punto ci sono stati dei progressi, apparentemente:
> 
> http://www.dwheeler.com/trusting-trust/

Molto interessante, l'argomento e' senz'altro meritevole di attenzione.


- --

[1]: http://kerneltrap.org/node/1584

"Andreas Dilger pointed out that had the change gone undetected "it
might have taken a good while to find"."


[2] http://bugs.gentoo.org/show_bug.cgi?id=241650

"What our legal counsel discovered was truly horrifying: not only was
the license non-free, it almost certainly opens the user and the
distributor to serious risk of legal action from the copyright holder,
even if all conditions of the license are met."


[3]
http://www.privacylover.com/encryption/analysis-is-there-a-backdoor-in-truecrypt-is-truecrypt-a-cia-honeypot/

- -- 
Tommaso Gagliardoni
GnuPG Key ID: 51D8DEB8
Fingerprint: DC10 0D2F 8F07 238D C5DB  63B8 0AEF 48C5 51D8 DEB8
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNnabtAAoJEArvSMVR2N64yyQP/Atn9w7Pdf3po+F7k3WUPle0
lMZ2DN/K6IYM9JgH53iVKbW/+G2rhvz9A20xWMN/i+OiNo9WrlXrt5NuvDh+LV6s
9Ykn7y2oJKSaM1GoxCXGVs1YH+UVsMdgPzMp8BicyPJz5BbXtiBYwBUzT38soBwl
ckKYK6mr3Id1e4591phy9tcAo1thL+BYk6iO2lqV5RJXroWuKtWgcFhwsO+yLuYr
YFfYVkNpqCvRWFWaKKHAx46Ds7Cuw6FQvyC9C1SKGw8R7ghrzyaiF3piFHY6fYpl
BaBQ9KXjNiyYcYpUPAt6Crcm3GG/3eKvXDGlfCf7v/iZ6zkaosPXSY2WjXJwYIdB
329kkurt2NsJp0/wur4rKiKlAbsH8NTgT68cUi+pOYTH3jqCgUEHMbFATHae+Z44
3xRHyj7X71A0vWnCqGn3E9rb05H8AY0qh2UoI1p9aYpTqR53+YM2qwVy1e8hv4FQ
p692HnNt6NqUcXohvWZTCmKbv8kotOnaF27XSKviRaV+fZ1IBhPeWpdwtJhb/IpQ
ZL2Z9hUTxjP+aEmux7KH5wZm8A2+5bhIrNcgh9HbQ8xqF5hK52Dd3YMuGAgQnlaH
wkt3t3nx8YmJrP0X7qakk92cu8myuxSMm6lXVQVtWiRbR8/9nMdmyuW6b1N96Ndt
PLy/1oHI8KPTE3Yq1Bvd
=9/i5
-----END PGP SIGNATURE-----
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

Rispondere a