[e-privacy] Luks e Tomb era Chip TPM?

[ono-sendai]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15/02/2012 01:29, Tommaso Gagliardoni wrote:

> Gli attacchi piu' recenti ad AES funzionano sia sulla versione da 128
> bit che su quella da 256 bit [6] . Comunque no, niente di praticamente
> utilizzabile.

Gia' gia',poi nsa a parte, usando aes si puo' stare tranquilli che qualsiasi
vulnerabilita' seria esca fuori fara' un gran casino e si sapra' subito :)

> Di sicuro truecrypt "puzza", ma tieni conto che TOMB non ha certamente
> avuto tutto il review process che gli altri software hanno avuto...
> Insomma dipende dal tradeoff tra sicurezza e semplicita' che vuoi
> raggiungere, se dici che TOMB e' molto intuitivo da usare ci credo.

Si infatti e' un progetto relativamente giovane,però usando api ben testate ed
essendo il codice ben documentato e scritto bene penso sia sicuramente
enormemente piu' "tranquillo" rispetto a truecrypt. Infatti alla fine io lo
consigliavo come alternativa a quest'ultimo.

>> Bhe',anche se la master key non sta mai in chiaro, penso che
>> aggiungendo uno strato di protezione non si perda nulla anzi. ... 
>> Mmm..su questo non sono daccordo. Una feature non e' mai inutile
>> (se non ha effetti collaterali che in questo caso non vedo),
> 
> Questo ahime' non e' corretto, come qualsiasi crittografo potrebbe
> confermare :) a volte succede che mettendo insieme "pezzi" che di per
> se' sono sicuri, si ottiene qualcosa che sicuro non e', a causa di
> effetti imprevedibili che spesso non sono evidenti. 

Daccordissimo sulla filosofia kiss, pero' in questo caso si parla di aggiungere
un fattore di autenticazione (chiave + pass). Inoltre lo fa usando roba gia'
testatissima: gpg simmetrico + luks,quindi penso che i margini per creare
insicurezza con quest'approccio siano prossimi allo zero (imho)

>> "This feature lets you keep in mind a certain picture rather than a

...

> Questo e' un mucchio bullshit :P
> 
>  - come mai dovrebbe essere piu' difficile ricordarsi la posizione nel
> filesystem di un keyfile piuttosto che di una particolare immagine
> (che e' anch'essa un file)?

Su questo non sono daccordo. Perche' la mente umana funziona in molti modi
diversi...io per esempio ho molta memoria visiva :) ... e poi bho',che problema
da questa cosa?Mentre magari per alcuni quell'affermazione puo' essere
vera,quindi io la vedo come un qualcosa in piu',che per alcuni potra' essere
inutile(e quindi non la usano),ma per altri no.

>  - perche' dover comunicare al destinatario dell'informazione SIA
> l'immagine SIA la password per sbloccare il keyfile, piuttosto che non
> solo una semplice password? E' vero che comunicando solo un'immagine
> non si risulta "suspicious", ma poi dovrai comunque comunicare anche
> la relativa password!

Bhe' appunto e' come scrivi tu...comunicando solo un'immagine non si e' sospetti
e magari (salvo fondatissimi dubbi sul sogetto che trasporta l'immagine) non si
correla subito la password all'immagine e quindi al keyfile. Cosa diversa
sarebbe avere un file gpg che contiene la chiave. Anche qui penso che sia un
qualcosa in piu' che puo' aumentare il livello di sicurezza complessivo,mentre
non trovo motivi per cui questa feature possa essere fonte di vulnerabilita' (a
meno che non si cada in un falso senso di sicurezza). E mi rendo conto che
questo mio approccio non e' molto scientifico :P


> Poi questo scenario non e' molto chiaro: lo scopo della cifratura del
> filesystem e' di proteggere le MIE informazioni da TUTTI gli altri,
> non di COMUNICARLE a un destinatario in maniera sicura. Per quello
> c'e' solo una soluzione: la cifratura asimmetrica.

Daccordissimo sulla cifratura asimmetrica..ma io penso che li piu' che di
comunicazione si parli di trasporto (per esempio attraversare una frontiera).

> Di nuovo, mi dispiace di dover essere cosi' categorico, ma sul
> serio... non ha senso. Non ho dubbi pero' sul fatto che il software in
> questione sia davvero ben scritto perche' conosco di fama gli
> sviluppatori, e di sicuro si tratta di un esercizio di stile davvero
> notevole. Bisogna considerarlo tale pero'.

Naa tranquillo ci sta essere decisi,magari pero' senza definire merda alcune
cose (imho :) ). Alla fine mi sa che non ci troviamo sull'utilita' di alcune
feature,ma penso che almeno concordiamo sul fatto che Tomb sia piu'
consigliabile rispetto a truecrypt :)

>> Su questa cosa ho trovato questo [4] ... sembra che la cosa sia
>> work in progress
> 
> Nono, e' una feature presente da tempo [7], io stesso la uso, e'
> comoda in diverse situazioni!

Si anche io sapevo degli 8 keyslot, il link che ti ho passato era una
discussione sul fatto che poteva comportare dei rischi e quindi si discuteva sul
se/come implementare la cosa in Tomb.


> Allora, l'idea e' che se hai una partizione che usi, ad esempio, come
> /tmp (ovvero ci finiscono dati temporanei che non vengono riusati tra
> un reboot e l'altro) sarebbe una buona idea fare in modo che quello
> che ci finisce dentro venga distrutto ad ogni reboot, cosi' non lasci
> tracce della tua attivita'. L'idea banale e' quella di avere uno
> script che cancella in modo sicuro ("wipe") la partizione ogni volta
> che spegni il pc. Lentissimo. Allora quello che si fa e' questo:

...

> Cryptsetup automatizza il processo, basta che metti in /etc/crypttab
> /dev/urandom come keyfile e specifichi l'opzione "tmp" o "swap" (man
> crypttab). Non usare /dev/random perche' potrebbe rallentare
> indefinitamente l'avvio del pc.


Non sapevo questa cosa...molto utile,grazie :)


> Non esiste ancora che io sappia, e questa e' una cosa che mi fa
> letteralmente incazzare, che non esista una soluzione simile nel
> ventunesimo secolo :| servirebbe, si', e servirebbe anche una feature
> tipo "hidden OS" di truecrypt ma per bootare linux!

Gia' gia',sopratutto viste alcune leggi vigenti in alcuni paesi (tipo
Inghilterra),dove se non si fornisce la chiave di decifratura ci si becca 5 anni
di default :| ... e anche visto che la tortura in genere e' piu' forte di ogni
tipo di crittografia :P



> Sempre e comunque :) ma una discussione paranoica ogni tanto su
> e-privacy non fa male :P

Assolutamente! :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk870LsACgkQQjFWA2nxf+Jb8QCfQyZbAspdi3tt8WpRgkMFZ6Bq
XhAAoJI/W5l2Pf56P9dOxk4SwlSUXHf7
=TK+X
-----END PGP SIGNATURE-----