Názory k článku
Nová analýza bezpečnosti TrueCryptu

"Zaujalo mě, že linuxová verze TrueCryptu používá pro šifrování a dešifrování funkce kernelu, ne vlastní implementace algoritmů jako ve Windows
...
Docela mě to děsí"

Da sa to vypnut. Na karte system integration v preferences.

> Docela mě to děsí

A pročpak vás to děsí? Nedůvěřujete test vektorům, které si v kernelu můžete zapnout (tedy algoritmy projdou selftestem)? A u ipsec to neděsí, kde se používá to stejné kernel crypto API?

Ano, by default Truecrypt na Linuxu používá dm-crypt jako backend.

Víte, co děsí mne? Lidi, kteří nečtou články, zato se bezhlavě vrhají do diskusí :-(

No vidíte. A mě přesně v tom článku, který jsem nečetl, zaujalo, že autor nemůže najít, kde se to větví na interní implementaci a kernel crypto.

Takže vám prozadím tajemnství, že je to přesně tam, kde se volá dmsetup a vytváří se dm-crypt mapování.

[OT] hlavně aby dm-crypt už uměl ten discard..

ja selftest nemam :(

dmesg:
...
alg: No test for xts(twofish) (xts(twofish-asm))
...

odpovim si sam:

http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg06278.html

Je fajn, že taková studie vznikla, ať už jí napsal kdokoliv. Jen houšť...

Máte zkušenosti s provozem TrueCryptu s Windows 7?
Nestalo se, že by při aktualizaci zmizla data?

Skusenosti mam, sifrujem nim systemovy disk aj vsetky datove. Pouzival som aj raid na doske (nejaka lacna intel sunka) a fungovalo to aj s nim. Zatial bez jedineho problemu, ci uz pri updatoch alebo padoch systemu kvoli blbemu softveru.

Win 7 na notebooku bez problemov
na desktope taktiez...

win 2008 testovane len velmi mlo aj ked zatial bez poroblemov...

Ja mel na sterym booku (IBM T60) problem s hibernaci, ale to vyresila verze 7.0a. TC se hadal s driverem od SATA radice.

Ted mam TC v kombinaci s AES-NI a SSDckem a jsem zvedavej jestli to SSDcko znicim kvuli omezeni wear levelingu nebo ne.

Tvrzeni ze kaskady sifer jsou bezpecnejsi nez jejich jednotlive komponenty je pri nejmensim sporne, rozhodne je pridana bezpecnost realne nizsi, nez by se na prvni pohled zdalo. Navic se da pochybovat o praktickem smyslu one pridane bezpecnosti at uz je jakakoli.

Nicmene, moznost ze by dve nesouvisejici sifry s vhodnymy klici byli vzajemnou inverzi je prakticky nemozna. Kazda blokova sifra v zavislosti na klici implementuje nejakou relativne malou podmnozinu vsech moznych prostych funkci z bloku na blok a zdaleko ne vsechny (uz jenom proto, ze prostor klicu typicke blokove sifry je vyrazne mensi nez prostor vsech onech prostych funkci). Proto je silne nepravdepodobne, aby tohle nastalo. Vetsina modernich sifer je explicitne navrhovana tak, aby za zadnych okolnosti nebyly svoji vlastni inverzi, takze pripad kdy by se pouzila stejna sifra vicekrat by timto rozhodne netrpel (ovsem tim odpada i posledni argument proc je to z praktickeho hlediska uzitecne delat: obrana pred prolomenim jedne ze sifer).

Proti bruteforce pravdepodobne naozaj nepojde o pridanu bezpecnost. Velky zmysel vsak vidim v tom, ze ak sa nahodou najde nejaka matematicka diera v niektorej zo sifier, data zostanu stale v bezpeci. Taktiez je mozne, ze na AES uz niekde v NSA maju nadratovane nejake vysoko vykonne superpocitace s milionmi procesorov, kedze ide o najpouzivanejsiu sifru (len moja spekulacia). Aj z tohoto hladiska je pouzitie viacerych sifrovacich algoritmov v kaskade lepsia moznost.

Otazka je vzdy polozena takto - jake naklady (vykon) jsem schopen/ochoten investovat do bezpecnosti, a jaka rizika mi hrozi.

IMO pro 99% useru je naprosto vyhovujici jakekoli sifrovani a poskytuje jim temer 100% bezpecnost - specielne pokud se budem bavit o smiracich od PCR, tak i xorovani disku = data jsou v bezpeci ;D.

Pokud je mi znamo, tak jediny zpusob jak napadnout AES je bruteforce => zalezi prakticky vyhradne na delce hesla.

Kedysi som cital, ze faktorizaciu velkych cisel je mozne znacne urychlit pomocou TWINKLE. A toto je tusim mantrou bezpecnosti pri RSA ako aj AES.

AES nema s faktorizaciou a velkymi cislami podla mna vobec nic spolocne.

to fakt nema

Ve verzi 6.2 pridali detekci maximalni velikosti sifrovane partisny podle jedne linuxi 32bit funkce a protoze vracela nizky limit, znemoznili pripojit >2TB partisny na 64bit linuxech, prestoze 6.1 s tim nemely zadny problem.

Nevite jestli je tohle uz v 7.0 opravene? Musim drzet starsi verzi truecryptu jen proto, abych vubec ten datovy svazek pripojil...

za offsetem 512 zadne nuly nejsou

aha, tak ty nuly jsou v reserved oblasti hidden volume, ovsem zasifrovane. Tedy, na bezpecnost to nema zadny vliv. Teoreticky by to snad nejaky vliv mohlo mit, protoze mate blok zasifrovanych dat, o kterych vite, ze jsou to nuly. U prolamovani dobreho sifrovaciho algoritmu by vsak toto nemelo hrat absolutne zadnou roli.

AFAIK tam žádné nuly nejsou. Jsou tam náhodná data, protože tam ještě nebylo nic zapsáno.

no nemotaji se tu dve veci nahodou? nuly maji byt v hlavicce, ktera je asi nesifrovana, tak se to k uhodnuti klice neda pouzit

kdyz zkusite desifrujete hlavicku hidden volume pomoci toho jejich toolu, zjistite, ze jsou v ni nuly. Zduraznuji, jsou tam nuly, ale po desifrovani! Kdyz hidden volume neobsahuje, je tam jen nahodne smeni. V kazdem pripade, nerozsifrovany disk je k nerozeznani od nahody.

Vim ze to neni primo k tematu, ale hledam uz dlouho odpoved...

Vi nekdo, jak namountovat TC container tak, aby byl pristupny jen pro jednu aplikaci ?

Priklad: existuje myFile.exe, ktery v start-up sekci pripoji TC container tak, aby byl viditelny jen pro myFile.exe

diky

Dost jezdim a disk mi zatim teda nikde nekopirovali. Pouze jednou brali z klavesnice stery asi na kokain a mozna vybusiny. Takze doporucuju si pri praci dobre umyvat ruce.