Newsgroup: it.comp.sicurezza.crittografia
Titolo: [ANN] TrueCrypt 4.1


______________________|________________________________________________
GnuPG RSAv4 4096 - Fingerprint:FA68CF697EA63865AAFA805F68703AD40609D743

 Volevo avvertire che è appena uscito TrueCrypt 4.1.
Direi che, con la localizzazione, c'è già chi ha fatto il lavoro;
anche se, con quanto fatto, non sono pienamente d'accordo (il termine
"volume", che io avrei tradotto con "unità"; i termini lasciati in
maiuscolo, in stile sàssone, che in italiano sarebbe meglio scrivere in
minuscolo; i plurali inglesi, con la "s" finale, che in italiano
andrebbero lasciati senza).
Nel complesso, però, pur risultando ancora in fase di completamento, mi
sembra davvero un buon lavoro.
Il fatto che non si riesca a contattare l'autore della traduzione (tal
"Luciano Zanin") in modo semplice, mancando il riferimento mail, sia sul
sito, sia nel file (per esplicita imposizione di "TC Foundation"), non
mi piace per nulla.
Ciao,
un TJL73 e la notevole carenza di tempo libero...
-- 
"Voi potete comperare il lavoro di un uomo, la sua esperienza,
 i suoi consigli, ma non potete comperare l'entusiasmo, l'iniziativa,
 la devozione del cuore, della mente e dell'animo; queste cose le
 dovete meritare con la vostra lealta` verso di lui."         -- Platone

 modalità CBC in favore della LRW. 
C'è una cosa che non mi sconfinfera...
Nella documentazione ("TrueCrypt User Guide.pdf"), a pagina 83, dove si
parla di history, viene descritto il tipo di vulnerabilità che affligge
le versioni di TrueCrypt fino alla v4.0 e c'è scritto:
,-----
| This affects volumes created by all versions of TrueCrypt prior to 4.1,
| except volumes encrypted with AES-Blowfish or AES-Blowfish-Serpent.
`-----
Ora, ciò che mi domando è: ma se le cascate AES-BF e AES-BF-S non erano
affette da questa vulnerabilità, perché sono state rimosse, nella nuova
versione?
Anche se la risposta fosse legata al fatto che non è possibile applicare
il metodo LWR a cascate miste (ossìa con block size non omogenei), come
avviene tra /AES e Serpent/ e /Blowfish/, dove i primi due hanno un
block size di 128 bit, mentre il terzo ne ha uno da 64 bit, come si
evince dalla documentazione, a pagina 47 (il PDF della v4.0, a pagina
46, riportava un block size di 128;64;128, per la cascata AES-BF-S) o,
forse, per lo stesso motivo, a causa della non omogeneità delle chiavi
(256;448;256), non capisco perché non lasciarle com'erano prima, in CBC.
Dato che il Blowfish (da solo) è supportato e ad esso viene applicato il
metodo LRW, suppongo che sia solo un problema di "cascata non omogenea"
e non di incompatibilità con quell'algoritmo.
Tutto questo, l'ho "dedotto" dalla documentazione, dato che non ho avuto
occasione di poter leggere ulteriori dettagli in merito alla LRW e in
quella di TC41 non è riportata alcuna informazione interessante (o,
meglio, io non ne ho trovate, di esplicite).
Qualcuno può confermarmi queste deduzioni?
Inoltre, se realmente le cascate AES-BF[-S] non erano interessate da
questa vulnerabilità, come mai sono state escluse dagli algoritmi
disponibili?  Se non fosse stato possibile applicare il metodo LRW,
perché non è stato applicato ancora l'Inner-CBC, come nelle versioni
precedenti?  Era anch'esso vulnerabile, nonostante quanto scritto nella
documentazione?
Tanto, non credo che il metodo CBC sia stato eliminato completamente,
dato che il supporto viene ancora dato in lettura per compatibilità con
i vecchi archivi.
Idee?
Ciao,
un TJL73 ben confuso...
-- 
"Si possono vedere lati positivi, anche nelle situazioni negative
 ed è possibile utilizzare tutto ciò, come esperienza per il futuro."
                                                         -- Ayrton Senna

viene abbandonata la cifratura in modalità CBC in favore della LRW. 
Umpf. Però non c'è la novità che aspettavo. 
imo TC ha ancora un difetto. "umount on powersave"
La sospensione nei notebook è molto usata (da me) e spesso invitabile,
all'1% di batteria dovrebbe essere automatica. Se c'è un OTFE con un
volume montato, la sicurezza dei dati va a farsi benedire, perchè la
chiave va a finire sul disco con un po' di pazienza è possibile
ricavarla.
Fino alla versione 4.0 TC non teneva conto di questo problema, e
difatti io continuavo ad usare il pgpdisk 6.5.8ckt
Alla versione 4.0 hanno introdotto (vedi Settings - Preferences) il
"Auto-dismount" "Entering power saving mode". Che non è attivo di
default come imo dovrebbe essere (l'utente medio questo non lo sa).
Cosa fa l'"auto dismount" (vedere sorgente Mount.c)?
Ho provato ad interpretare il sorgente. Non sono un programmatore e
posso sbagliarmi.
Quando riceve una richiesta di sospensione chiama la funzione di
DismountAll, ma senza forzare l'unmount, qundi se ci sono file aperti
non risce a smontare il volume e quindi lascia che il sistema vada in
sospensione provocando una possibile falla di sicurezza. Ma, ma se è
checkata la casella "Force dismount even if there are opened files" la
funzione DismountAll smonta brutalmente il volume. Questo può anche
andare bene, ma insomma se ci sono file aperti in cui sto lavorando
quando capita la sospensione e sono dati importanti, e sono sempre
dati importanti se sono crittografati, ecco mi pare che sia un
comportamento poco gentile da parte di TrueCrypt.
La soluzione sarebbe fare come fa PGPDisk, cioè non forzare l'umount,
ma semplicente quando riceve la richiesta di sospensione
PBT_APMQUERYSUSPEND cercare di smontare "gentilmente" i volumi, e nel
caso non vi riuscisse perchè ci sono file aperti, mandare una
MessageBox all'utente e negare a windows la possibilità della
sospensione mandando un BROADCAST_QUERY_DENY. Così l'utente ha il
tempo di chiudere le sue belle applicazioni e lasciare il filesystem
integero.
Io ho mandato un "patch" (macchè patch sono quattro righe di codice!)
un mese fa agli sviluppatori di Truecrypt ma non mi hanno risposto ed
il forum è giù. Io non ho avuto la possibilità di fare la modifica da
solo perchè non ho gli strumenti che servono per la compilazione (se
qualcuno ha "visual studio .NET" + "2003 SP1 DDK" me lo dica che gli
mando la roba da compilare!)
Nel frattempo è uscita la versione 4.1 e il comportamento durante la
sospensione non è cambiato. Probabilemente sono stati impegnati a
cambiare tutta la parte di codici LRW e non hanno avuto tempo. Spero
nella versione 4.2!
ciao!