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

[ono-sendai]

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

On 14/02/2012 14:10, Tommaso Gagliardoni wrote:

Mi permetto di cambiare ogetto al thread visto che non si sta piu' parlando di
chip TPM :) ... spero che ne nasca una discussione interessante e proficua :)

> Occhio che quel benchmark non tiene conto del fatto che ora cryptsetup sfrutta
> il multicore. Al giorno d'oggi penso che l'unico modo per "colpire" il limite di
> I/O dato dall'uso di cifratura AES con un processore decente sia utilizzare un
> RAID di dischi SSD (o da 10k giri). Certo, puoi sentirlo in applicazioni
> enterprise che facciano massiccio uso dei dischi E del processore in
> contemporanea, ma davvero, in genere non me ne preoccuperei.

Si questo e' verissimo,il collo di bottiglia sta nell'io,comunque quei benchmark
erano solo per ribadire che forse usando serpent o altri algoritmi "pesanti" si
potrebbe avvertire un calo di prestazioni. Comunque sono dell'idea che se si
vuole utilizzare la crittografia (per l'intero disco o per dei contenitori) e'
sempre meglio sacrificare la velocita' invece che la sicurezza.

>> (anche se aes sembra soffrire di attacchi teorici con quella
>> dimensione della chiave)
> 
> Che tipo di attacchi?

Io ne avevo letto in questo [0] (imho splendido) libro di Schneier (che fra le
altre cose è uno dei designer di twofish). Qui [1] e qui [2] ci sono due suoi
post a riguardo. Questi attacchi sono solo a livello teorico e non hanno
(ancora?) applicazioni pratiche da quello che ho capito.


> File contenitori LUKS facilmente trasportabili li puoi creare a mano nei modi
> standard (dd e loop).

Anche questo e' vero,ma penso che per un utente poco esperto imho sia piu'
semplice usare tomb e avere un uguale grado di sicurezza. Dopotutto Simone
parlava di truecrypt ed a me e' subito venuto in mente tomb per la sua
semplicita' d'uso (oltre che non ha quegli aloni di mistero di cui sopra :P )

> Poi non ho capito che tipo di vantaggio si ha nel cifrare con gpg il keyfile, se
> non che cosi' facendo e' piu' facile perderlo e dire addio a tutti i dati
> cifrati. Gli header LUKS non salvano le password in chiaro, la master key e'
> gia' cifrata di suo, quindi non vedo come mai cifrare a sua volta il keyfile.

Bhe',anche se la master key non sta mai in chiaro, penso che aggiungendo uno
strato di protezione non si perda nulla anzi.Sul sito di tomb non ho trovato
nulla a riguardo,ma penso che qui [3] ci sia una spiegazione plausibile (ovvero
aggiungere uno strato di protezione). Comunque,forse qualcuno degli sviluppatori
legge questa lista e sapra' darti una risposta sicuramente piu' esaustiva della mia.

> Nascondere il keyfile in un'immagine steganografata e' completamente inutile: 

Mmm..su questo non sono daccordo. Una feature non e' mai inutile (se non ha
effetti collaterali che in questo caso non vedo), potrebbero esserci un sacco di
scenari in cui questa cosa torna utile. Giusto per fare un esempio riporto
quanto scritto sul sito di Tomb:

"This feature lets you keep in mind a certain picture rather than a position in
a filesystem, much easy to remember. It also helps in hiding well the key and
eventually communicating it without being suspicious, as it is very difficult to
detect the presence of a key inside an image without knowing the password you
used to seal it."
...
"When transporting delicate information the risk of interception is high: even
using encryption, if the courier is captured then the key can be found on him
and the password can be obtained under torture. The solution we propose is that
of separating keys from storage, so that a courier alone cannot be the single
point of failure: hence separation between keys and data."


> Infine, con questo metodo perdi altre features carine che cryptsetup ha, tipo
> passphrase multiple per accedere al contenuto,

Su questa cosa ho trovato questo [4] ... sembra che la cosa sia work in progress


> integrazione con mkfs e mkswap per creare al boot filesystem temporanei usando /dev/urandom etc.

Questo mi interessa molto, anche se non ho ben capito cosa intendi :P . Cioe' tu
dici di creare al boot un filesystem temporaneo gia' cifrato,come faresti? (hai
qualche link?). Inoltre,visto che ci siamo...un'idea che mi e' sempre
piaciuta,ma che non ho mai capito come realizzare, sono le partizioni nascoste
di truecrypt,qualcuno conosce un modo per fare questa cosa con dmcrypt+luks?

E comunque [5] :D

[0] http://www.schneier.com/book-ce.html
[1] http://www.schneier.com/blog/archives/2011/08/new_attack_on_a_1.html
[2] http://www.schneier.com/blog/archives/2009/07/another_new_aes.html
[3] http://en.gentoo-wiki.com/wiki/DM-Crypt_with_LUKS#GPG-protected_keys
[4] https://github.com/dyne/Tomb/issues/67
[5] http://xkcd.com/538/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk86s/wACgkQQjFWA2nxf+Jh5QCfcQeeQLfLergJyH14xBOXP7n9
UR8An0T0w0uJc+BXRaJ748e2vdMmLq2R
=dLSH
-----END PGP SIGNATURE-----