Newsgroup: it.comp.sicurezza.crittografia
Titolo: Portabilità dei file crittati

Ciao a tutti,
sto provando ad usare sia CrossCrypt che TrueCrypt e ho notato con (forse
ingenua) sorpresa che l'uno non riesce a decrittare i file crittati
dall'altro, sebbene utilizzino lo stesso algoritmo (AES-256).
Non conosco altri programmi per la crittazione, ma mi chiedo se in generale
un file crittato sia così indissolubilmente legato al programma che l'ha
creato.
Mi sembra che questo possa creare dei rischi nella possibilità di leggere
fra 2 o 3 anni un archivio creato oggi (XP diventerà obsoleto, chissà se il
programma di crittazione si adeguerà o meno).
Sbaglio qualcosa nel creare gli archivi o la mia è una pretesa
concettualmente errata?
E poi... crittare o crittografare?
crittato o crittografato?
crittazione o crittograf... ?
mannaggia... :-)
Ciao,
XRay
-- 
fatti non foste a viver come bruti,
ma per seguir virtute e canoscenza
Inferno - Canto XXVI

  [X.509 available]
Linux Reg. User: #263663 / Machine: #216144 (ArchLinux /Wombat)
On the Web: 
http://www.quagliata.eu.org
 - My GPG Key:0x5539D8E4
On ICQ: 48618109 - On Jabber: 
qu...@jabber.org/@jabber.linux.it

 crittazione o crittograf... ?
Nessuno dei tanti. :-)
Cifrare, cifrato e cifratura mi sembrano termini più italiani.
Cristiano

 Criptato... Altrimenti cifrato/codificato.
Ma dai... Quelle "p" non ti sembra che stonino? :-)
Cristiano

 Cristiano
Saluti,
Federico


 decifrare tutto e ri-cifrare con il nuovo programma che vorrai utilizzare.
Sempre che questo programma sia poi conpatibile con Windows 2010 o quel che
sarà...


 quel che sarà...
La politica m$ è sempre stata quella di rendere compatibili i nuovi sistemi
operativi con i programmi di 30 anni fa, per cui è verosimile che su Winzozz
2010 ci giri anche il programma che gira su Winzozz 95.
Cristiano

 peccato mortale per la sicurezza della cifratura?
Lo č... o melgio lo ERA...
Enigma, nella seconda guerra, č stato "rotto" proprio grazie a "testi
conosciuti in posizioni conosciute".
Ma oggi come oggi un algoritmo di cifratura non viene neanche
CONSIDERATO se č vulnerabile a quel tipo di attaccco.
Quindi, benchč evitare di avere stringhe fisse sia comunque "meglio", se
usi roba "seria" come AES non č un cosě grave problema. Se non
addiritturra un non problema, del tutto.
Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHdLBIACgkQaJiCLMjyUvuvogCdH4WQZN7xHVxt2mw1TBzmrQHG
Pd0AoOLSQRHABLPbCHyE3N9uCMfBltgM
=fSGH
-----END PGP SIGNATURE-----

 mannaggia... :-)
Crittare e criptare vanno bene entambi.
Crittografare non so se vada bene, ma di certo mi suona "inutilmente
complesso".
Cifrare, anche, ottimo.
Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHdLO4ACgkQaJiCLMjyUvsGYQCePvQmVFnrrTokesCCPnzpUqZ2
oc0AoLQERiShxIvnGLIeeCgFBtitFZY3
=hqUa
-----END PGP SIGNATURE-----

 Cifrare, anche, ottimo..
Ma nel dizionario criptare non esiste, quindi non e' corretto in 
italiano... No?
	Manuel

 italiano... No?
Nel Garzanti esiste.
Anzi la vioce "crittare" è composta solo da "-> criptare".
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHdRGwACgkQaJiCLMjyUvtrtACeKPcunZC5taQU3rk7QXBzJy7i
eEoAoPIH/cIRciCJLtVbTn/sanQzgOAF
=LZlw
-----END PGP SIGNATURE-----

 italiano... No?
Esiste eccome. :)


 2010 ci giri anche il programma che gira su Winzozz 95.
Può anche darsi che MS abbia questa intenzione. Di fatto io ho più di un
programma che al passaggio da win '98 al 2000 (col passaggio
all'architettura NT) non ha più funzionato.
In realtà penso si debba confidare nella buona volontà di chi sviluppa il
software. E pure nella sua esistenza fra qualche anno.


 addiritturra un non problema, del tutto.
In realtà quello che mi stupisce non è tanto questo punto quanto il fatto
che per forzare un file anche enorme, di fatto sia sufficiente analizzare
la sua testata. Non dico che questo sia facile, ma penso che sia
sicuramente più rapido che dovere manipolare un grande file e che quindi in
un certo modo indebolisca la forza della cifratura.


 italiano... No?
Esiste, esiste; purtroppo. :-(
Cristiano

 Esiste, esiste; purtroppo. :-(
pterodattilo, ptialina, eptano... :PPP


 all'architettura NT) non ha piů funzionato.
Beh comunque nel 2010 potrai sempre eseguirlo con un emulatore,
WindowsXP, quindi il contenuto del file č difficile che te lo perdi del
tutto ;-)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHfFrIACgkQaJiCLMjyUvvlGQCeOMmhikF4fdrkxcO+TTZeBmnL
03oAnjfQTzHEOEC0+9iSYsIbtDkAT7EO
=72ID
-----END PGP SIGNATURE-----

 un certo modo indebolisca la forza della cifratura.
In realtŕ la differenza in lunghezza tra quei 4 caratteri e l'intero
file č trascurabile rispetto alla sicurezza che un algoritmo come AES
offre: se il file fosse di 4Gb poter attaccare "quei 4 byte" invece che
l'intero file sarebbe un decremento di "soli" 32 bit di sicurezza.
Il margine di sicurezza di AES č ben maggiore, per fortuna 0=)
(il che, ripeto, non significa che lasciare appigli sia furbo, perň se
un file da proteggere non avesse struttura alcuna non avrebbe neanche
utilitŕ alcuna, sarebbe un file casuale ^_^)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHfF7IACgkQaJiCLMjyUvu9AQCePnEqcPrsrn0jJ3fU0WFfsMxw
O70AoPjzYCGnyZRIYZuJxFMeKg41jXX3
=zsY1
-----END PGP SIGNATURE-----


 
E tutto sommato è probabile che nel 2010 il mio file cifrato con l'AES-256
nel 2005 sarà decifrabile con il software di un telefonino (o di quel che
sarà...) in un paio di minuti.
Ma il punto non è tanto questo, quanto il fatto che mi sembra che in
quell'header venga introdotta artificialmente una pericolosa (per qanto
utile) complicazione.


 
Perchè, scusa? Se ho ben capito (e non è detto...) il file viene cifrato
usando l'algoritmo puro e semplice, ma poi ad esso viene anteposto un
header che consente a TrueCrypt (o quel che è) di verificarne le proprietà,
tra cui il fatto che il file sia stato generato da TrueCrypt e (orrore!)
che la password fornita sia quella giusta.
Tra l'altro questo sistema permette a TC di capire velocemente con quale
algoritmo è stato cifrato il file. Ne ha infatti a disposizione una decina
e li prova sull'header uno dopo l'altro per verificare qual è quello giusto
(in pratica va avanti fino a che non trova la famosa stringa TRUE
correttamente codificata).
Quello che pensavo era che un file "semplicemente" cifrato con AES (per
es.) non dotato di alcun header di questo tipo fosse più sicuro perchè solo
alla fine dell'intero processo di decifratura si può verificarne il buon
esito.
Immagino quindi che questo sistema sarebbe sì più scomodo (ad es. se
sbaglio pwd l'eventuale programma opererebbe la decifrazione lo stesso,
restituendomi un file non decifrato correttamente), ma anche più sicuro
perchè pure chi volesse attaccarlo dovrebbe ad ogni tentativo smazzarsi
tutto il file, verificarlo, fare un nuovo tentativo su tutto il file,
ri-verificarlo ecc.
Capisco che questa scomodità sarebbe fastidiosa, ma trattandosi di
sicurezza non è un prezzo che varrebbe la pena di pagare?
O mi sfugge ancora qualcosa?


 O mi sfugge ancora qualcosa?
Secondo me ti sfuggono due cose:
1) qualche bit noto non ti consente di effettuare alcun tipo di analisi e
quindi nemmeno ti consente di decifrare un file;
2) la password "modificata" viene salvata per l'autenticazione del file, non
per verificare che quella fornita sia quella giusta.
Cristiano

 sarà...) in un paio di minuti.
No, questo NON è probabile.
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHhDBAACgkQaJiCLMjyUvundQCfXypsPHokUwpzKnnycJOynMaS
+RsAn1rK4eomYHiezZ8aAX6B+qebNjR1
=zjGH
-----END PGP SIGNATURE-----

 restituendomi un file non decifrato correttamente)
Questo non č "piů scomodo", č praticamente INACCETTABILE dal punto di
ista dell'utente.
Inaccettabile, sopratutto, perché su un piatto della bilancia hai il
dubbio di distruggere il contenuto del disco solo per aver sbagliato un
carattere della password, mentre sull'altro piatto della bilancia hai un
incremento in sicurezza totalmente irrisorio.
quello del "known plaintext" era sicuramente un grosos problema nella
seconda guerra mondiale, ma oggi come oggi perfino con il superatissimo
DES hai bisogno NON di 4 byte, ma di PARECCHI dati in chiaro, per
ricavare la chiave.
Con parecchi intendo che l'attacco known plaintext migliore richiede
qualcosa tipo 2^40 coppie testo cifrato - testo in chiaro.
(40 lo ricordo a mente con poca precisione, consideralo un limite inferiore)
Capirai quidni che, servendo 2^46 byte codificati per trovaer la chiave,
averne "4 in piů" o "4 in meno" non cambia veramente nulla.
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHhDW4ACgkQaJiCLMjyUvt1PwCfUrrZBu1l2eoY08Oc4PDEur25
7K8AnRpL9IV5dGAflLQSrz4N6Gb/lCco
=57zw
-----END PGP SIGNATURE-----

 
Questo mi conforta a riguardo della sicurezza della cifratura (ma come fate
ad essere così sicuri?), ma aumenta l'esigenza di portabilità nel tempo.


 quindi nemmeno ti consente di decifrare un file;
Ma il punto è che io non conosco genericamente alcuni bit all'interno del
file cifrato. Io so con certezza che i primi 512 byte del file (l'haeder)
possono essere "ritagliati" dal file e analizzati separatamente. Se riesco
a decifrare questi, con la stessa identica chiave (qualunque essa sia,
modificata o non modificata) posso decifrare il file principale.
Il mio dubbio è che attacare un file piccolo sia più semplice che
attaccarne uno grosso.


 
Ma quello che avevo in mente io non è tanto l'attacco al known plaintext
che effettivamente mi rendo conto essere troppo poco per essere utile.
Quello che immaginavo è la semplificazione del lavoro di un software che
applica per es. un attacco brute-force.
Il mio problema evidentemente è che non so come funzionino questi attacchi,
ma immagino una cosa del genere (e correggimi dove sbaglio):
1. tentativo di decifratura del file applicando una chiave
2. verifica del risultato (è un file decifrato?)
3. eventuale altro tentativo
4. altra verifica
e così via fino ad ottenere un file decifrato.
Immaginavo che applicare una procedura del genere su un pezzo del file
(l'header, che sono i famosi 4 byte della stringa TRUE più altri 508 con
altre informazioni), sia molto più rapido, a causa dei tempi tecnici di
manipolazione del file, che applicarla su 4Gb di dati.
Provo a esprimere la mia perplessità in un altro modo: è più semplice (o
meno difficile) attaccare un file da 4Gb o uno da 512 byte? Il punto è quel
famoso header è proprio anteposto al file cifrato, quindi facilmente
isolabile e trattabile come un file a sè, criptato con *la stessa chiave*
del file pricipale.


 ad essere così sicuri?), ma aumenta l'esigenza di portabilità nel tempo.
Semplicemente "essere sicuro per 20 anni" (o forse erano 40?) era uno
dei requisiti fondamentali del processo di standardizzaizone AES... e
tutti i crittografi che ci hanno partecipato sono stati d'accordo sul
fatto che Rijndael lo soddisfaceva ^_^
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHi2i0ACgkQaJiCLMjyUvv1XACgwGkKmTZLJJK6QzUFaiT2aeJg
NakAoNZ9zP+1/1RXgya29kQs9EoqUZow
=fdLq
-----END PGP SIGNATURE-----

 manipolazione del file, che applicarla su 4Gb di dati.
Dato che decodificare 2 blocchi ci vuole esattamente il doppio del tempo
che decodificarne uno, si può tranquillamente dire che decodificare 4Gb
prende 2^32 volte che decodificare 4 byte.
Proprio per questo dicevo che questo fatto aggiunge 32 "miseri" bit di
sicurezza.
Resta comunque il fatto che NON HAI bisogno di decodificare 4Gb di dati
per capire che il contenuto è un disco FAT, header o meno.
La struttura STESSA del file system (partition table, cartella root,
etc. etc.) basta e avanza per riconoscere una "chiave buona" con il
primo blocco o poco piò. A prescindere da eventuale "struttura in più"
messa da loro.
Insomma il file "plaintext" DEVE avere una struttura, altrimenti non ha
senso come file in sé.
Per questo dico che "pretendere" che il plaintext non abbia struttura
riconoscibile è folle ^_^
PS: il mio esempio parla di un disco FAT, ma ogni titpo di file a una
"sua" struttura, se fosse un file di testo basterebbe confrontare con un
dizionario, e così via... le immagini hanno il loro headr etc. etc.
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHi3RoACgkQaJiCLMjyUvvSEQCdHwzqfAAiM+ct9tofZWk59ykg
j2wAoPDfHI0ez5xTlZk4Z9zQXRJf+VIP
=Ta/U
-----END PGP SIGNATURE-----

 attaccarne uno grosso.
Sì, ma di una quantità "insignificante".
Sopratuto per il fatto che nel 99% dei casi PUOI comunque attaccare il
file piccolo e basta 0=)
PS con insignificante intendo non che "4 miliardi di volte in più" sia
poco, ma che se una cosa non è sicura a "X" bit di sicurezza non è bene
considerarla sicura neanche a "X+32", quindi...
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHi3fMACgkQaJiCLMjyUvswfgCfZEZAILkXM+BsVB2s3YmJ09CJ
SpkAoMdVC90o9Mv1Bx8lzl+Cf+3M8uXv
=FgQt
-----END PGP SIGNATURE-----

 Diciamo che "n bit di sicurezza" significa bene o male che l'attaccante
Nota: sono stravoltemente stanco, sto per andare a letto, non rispondo
di quello che ho scritto e sono fiducioso di venir corretto da altri
frequentatori del grupop in caso di castronerìe ;-)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHi3lYACgkQaJiCLMjyUvuWlgCg2qGbKNlVLcu/rvUQ9b6tQIjH
OlYAn2HXxTQ5IdnRmKVfB5pKSwRDhG+A
=bsCm
-----END PGP SIGNATURE-----

 attaccarne uno grosso.
... Se il programma è scritto bene, la differenza di tempo necessaria per
attaccare un file da 512 byte o uno da 512 Gbyte è trascurabile rispetto
all'immenso lavoro richiesto per provare tutte le chiavi possibili; parliamo
di 2^100, 2^200, mille mila... numeri che fanno girare la testa! :-) Sono
necessari decenni per provare tutte quelle chiavi. Che vuoi che siano i
pochi minuti o le poche ore di differenza necessarie per "maneggiare" un
file qualche miliardo di volte più grande?
Certamente 512 byte *noti* non sono pochissimi, ma non rappresentano nemmeno
una piccolissima frazione di quello che serve per fare un'analisi (lineare o
peggio ancora differenziale). Poi, di questi 512 byte quanti sono quelli
noti? Solo i 4 di "TRUE"? Altri 10? Altri 100? Pochi, troppo pochi se il
programma è scritto bene.
Cristiano

 manomissione.
Leggendo qui:
http://truecrypt.sourceforge.net/faq.php
c'è scritto chiaramente che né la password né il suo hash vengono salvati su
disco.
Per verificare che la password sia giusta, viene usato un sistema, secondo
me, un po' bizzarro (spiegato a pag. 27 dell'"User Guide"). Con tutti i
metodi che ci sono, non riesco a capire come possa essere stato usato un
sistema così "stravagante".
Già che ci sono vorrei fare anche qualche altra considerazione, senza alcuna
pretesa... Solo qualche considerazione.
Un'altra scelta che non è il massimo riguarda l'algoritmo di derivazione
della chiave: viene usato il PKCS #5 V2.0 anziché il più recente, versatile
e robusto AES Key Wrap. Per un programma che implementa l'AES, sembrerebbe
naturale la scelta del secondo metodo.
Non ultimo il metodo (che non esito a definire molto folcloristico) della
cifratura multipla con algoritmi diversi.
L'ultima nota va senz'altro alla presenza della sola modalità CBC che va
bene per tutto, ma l'utente potrebbere voler scegliere il più semplice ECB o
il CTR o gli altri 15, 20 modi con e senza autenticazione.
Il programma sarà affidabile, ben fatto e sicuramente andrà bene per il
99,9% degli utenti, ma non riesco a nascondere un minimo di perplessità.
Cristiano

 pretesa... Solo qualche considerazione.
Non nascondo che alcuni elementi da te citati lo fanno anche a me
sembrare un "programma dilettantistico" da certi punti di vista (in
ordine: la cifratura multipla, il non uso del modo CTR, il non uso del
AES key wrap).
Ognuno ha le sue "fisse" (la tua è l'aes key wrap, la mia è il ctr mode,
che imho è TROPPO più robusto e comodo del CBC&soci per NON usarlo), ma
è sopratutto la cifratura multipla "puzza tantissimo" di "snake oil",
come cosa in sé. Ed è un peccato...
Riguardo a quello che definisci "stravagante" metodo per verificare la
chiave non l'ho letto, quindi non saprei ^_^
un Lapo che, grazie alla nuova GUI, trova Crossrypt sempre più comodo =)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkHjfBcACgkQaJiCLMjyUvtQKwCeM0z5zy9AYdNeTsr6X/Z9pbLW
/I4An08GkMzm1AL+Q7nqzF27Np7mPS1D
=T2Ws
-----END PGP SIGNATURE-----