Názory k článku TrueCrypt: profesionální ochrana dat zdarma
-
Mikuláš Patočka (neregistrovaný)protože člověk nikdy neví, co ve swapu skončí, může se do něj dostat cokoli s čím uživatel pracuje. Na Linux jde swap zakázat, jde to nějak i na Windows?
Další nebezpečí je v tom, že člověk si třeba WWW prohlížečem na šifrovaném disku otevře soubor a WWW prohlížeč název souboru iniciativně uloží do historie stránek, která je však na nešifrovaném disku --- existuje někde seznam programů, které je možno na šifrovaném disku používat bez nebezpečí, že budou informace vynášet mimo ten disk? -
Jiri J. (neregistrovaný)Windows to defaultne hází někam do "oblasti rezervované by OS" - což je neznámo kde ... jinak WinXP _vždy_ swapuje, swap mu nejde zakázat, dokonce pokud to uděláte, bude si swapovat, kde se mu zachce (z pohledu struktury disku - od začátku na konec), jde ale určit specifická partition, kde má swapovat... ale vypnout? Je to přece Windows.. :-)
-
JohnBlbec (neregistrovaný)presnejsi je, ze volba na vypnuti swapu tam je, nicmene jak bylo napsano o par prispevku vyse, stejne to swap nevypne a xp si swapuji vesele dale. naivne jsem si myslel, ze kdyz k 1GB ram prikoupim jeste dalsi 1GB, tak nebudu swapovat, protoze jsem mel vzdy ten druhy 1GB volny - jak jsem se mylil. co z toho plyne? => windows xp neumi ani vypnout swap ani pouzit ram na 1GB :o(
-
tomino (neregistrovaný)blbost!!!!
winXP dokaze vypnut swap suubor!!! len Ty to nevies nastavit!!!
system properties->advanced->performance options (advanced)->virtualmemory (change) - a tu zapinas a vypinas swap subory, mozes urcit i na ktorom odiely kolko budes/nebudes mat..
mam 2GB pamate, funguje to ok i pri 1Gb pamate.. -
JohnBlbec (neregistrovaný)zase nejakej chytrak, kterej si mysli, ze jenom on to v nastaveni nasel. samozrejme to tam mam vyple, ale kazdou chvili swapuje stejne a neni schopny zaplnit 2GB ram. zkuste si radeji precist neco o tom, ze holt tenhle nedostatek spatne spravy pameti resi udajne az visty, ale nemuzu to potrvdit - nemam je...
-
Lukas Pravda (neregistrovaný)Ahoj,
1. To, ze se ti pamet zda zaplnena, neznamena, ze opravdu je. :)
2. To, ze neco hrabe na disk, neznamena, ze jde o swapovani. Pokud je to nejak excesivini zalezitost, doporucuju Process explorer od Marka Rusinoviche (~MS). Ten Vam spolehlive ukaze odkud vitr vane. (Neni neobvykle, ze programy samotne maji vehementni potrebu si neco ukladat do tempu. (At uz se rozhodnou pouzit systemovy temp nebo svuj vlastni.)
Pagefile samzorejme vypnout jde a kdyz je vypnuty, tak je vypnuty a nepouziva se.
Zdravim
Lukas -
JohnBlbec (neregistrovaný)rad bych souhlasil, lec zkusenosti mi to proste nedovoli. timhle bych debatu ukocnil, protoze mame oba odlisne nazory - ja tvrdim, ze sprava pameti ve windows xp je mizerna a tvrdim to z pohledu vyvojare i uzivatele a taky si stojim za tim, ze si xp strankuji i kdyz je vyply swap :o(
-
Lukas Pravda (neregistrovaný)Mno ja bych to urcite neukoncoval, protoze tohle rozhodne neni o nazoru. Rad se dozvim neco, co treba nevim. Jak to muzu zreplikovat a jak se muzu presvedcit o tom, ze si moje xp odsypavaji neco do pagefilu, i kdyz jsem jim pagefajl zakazal?
Mozna to chce asi nejake vyjasneni v terminech neb jsme se ochomytli kolem nedorozumeni... Souhlasime v tom, ze to ze strankovana pamet nemusi byt nutne v pagefajlu, ale muze bez problemu vegetovat v normalni ram, ze ano? :) -
JohnBlbec (neregistrovaný)pro zacatek zkuste zaplnit pamet ram nad 2GB. mne se to nepovedlo a to jsem spustil opravdu mnoho programu (visual studio 2005, office, autocad, photoshop, ...). uzivana ram se drzi stale kolem 1GB a kazdou chvili pri praci zacne hrabat disk a to tak, ze vas odstrihne na 5s (nekdy i vice) od prace (zatuhne i kurzor) a pritom nedelam zadne operace, ktere by praci s diskem vyuzivaly. vlastne to nekdy necham jenom tak netecne stat. myslim, ze se vam to povede take...
-
Zero (neregistrovaný)jj uplne suhlasim mam 2GB RAM a tiez hned po zapnuti je swap zaplneny na 200MB, pri vypnutom swape my stale este hrabe po disku... Kde je potom problem v tom ze to nefunguje. Ja nechcem vyuzivat pomalsi disk ale rychlejsiu RAM. Proste nad 1GB RAM to XP nevie vyuzit a stale si vytvara swap hoci len malicky a veselo swapuje dalej (to je asi tych neuveritelnych 200MB co nemoze dat do RAMky).
-
JohnBlbec (neregistrovaný)ano, tohle je fungujici reseni, ale pripadne mi to jako takova berlicka. system by mel umet vyuzit pamet, kterou mu tam strcim a kterou je cpu schopne adresovat, ale ja stejne prevazne pouzivam linux, takze me to az tak netlaci a nebyt klientu, kteri maji xp, tak bych tady snad ani nereagoval...
-
_Teddy_ (neregistrovaný)Existuju programy, ktore sa pod windows ani nespustia (!) ak nemate definovany swap. Bez ohladu na to, kolko mate operacnej pamate (v mojom pripade xw8400 s 16GB RAM). Nemam chut diskutovat na temu preco je to tak, a ze je to blbost. Ja som len uzivatel, a chcem aby mi program vyuzil vsetku pamat, co mam, a podla moznosti co najmenej pouzival disk. A jeden zo sposobov ako to urobit a zaroven prakticky zrusit swap je presmerowat swap na virtualny disk. A na dalsi ram-disk mam presmerovane pracovne subory. Tymito dvoma pomerne jednoduchymi konfiguracnymi trikmi som dosiahol 2-nasobne zrychlenie narocnych simulacnych vypoctov.
A teraz skuste k tomu napisat tentokrat nieco inteligentne, najlepsie daky vas originalny napad... -
Tap (neregistrovaný)
Ve Windows jde zapnout, aby se při restartu (vypnutí) swap soubor promazal.
To je sice hezké, ale moc bezpečné mi to nepřijde. Kde máte zaručeno, že se skutečně přepíšou všechny sektory, kde se swap soubor rozprostírá? A s příslušným vybavením se dá údajně dostat i k několika předchozím vrstvám magnetického záznamu na pevném disku.
-
Fik (neregistrovaný)http://www.truecrypt.org/third-party-projects
TCTEMP
Description: TCTEMP automates the process of using TrueCrypt to on-the-fly encrypt the Windows paging (swap) file, temporary files, and print spooler files. -
Pro uložení kryptograficky citlivých dat používá TrueCrypt neswapovatelnou paměť (proto jak na Windows, tak pod Linuxem potřebuje práva roota). Co se týče možnosti odswapování rozšifrovaných souborů vizte výše odkazovaný TrueCrypt Third-Party Project TCTEMP. -
Lukas Pravda (neregistrovaný)Ahoj, i na na windows jde pagefile vypnout... zalezi to ale na nekolika okolnostech. V zasade to chce mit dostatek ram (pro moji beznou praci je 1.5GB ok) a aplikace, ktere explicitne pagefile nevyzaduji. (Moc takovych, ktere by na nem opravdu trvaly neni, ale napriklad photoshop na tom trva (aspon kdysi verze 5)...)
-
Mikuláš Patočka (neregistrovaný)A dalším velkým problémem je adresář /tmp, kam spousta programů píše (třeba Acrobat Reader) --- čili si otevřete dokument ze šifrované USB klíčenky a máte ho rozšifrovaný na disku, ani nevíte jak. Po zavření ho Acrobat smaže, ale tím hůř --- sektory obsahující data tam zůstanou a nevíte, kde jsou. To by fakt chtělo udělat audit programů, co se na šifrovaném disku používat smí a co ne, a jak to nastavit, aby to ta data neroznášelo.
-
jar (neregistrovaný)Takhle se chová taky winRAR. Když máte soubor, kde se bez hesla nedá přečíst ani vnitřní struktura, v grafice winRARu ho otevřete a chcete jeho obsah rozbalit, udělá si kompletní "zálohu" do tmp a nesmaže ji ani po ukončení, což je příšerný. V Linuxu je jen konzolová verze, která to snad nedělá, ledaže by se podobně choval např. Ark, nebo jiný nástroj pro zacházení s archivy.
-
Michal Vyskočil (neregistrovaný)Jasne, ale stejne osobne ve vetsine pripadu swap nepotrebuji, takze ho explicitne zapinam az pri hratkach s qemu, ci podobnymi aplikacemi a v tom pripade vesmes stejne neuspavam/nehibernuji, takze _me_ osobne prijde praktictejsi swap vypnout, nez sifrovat.
Ostatne ja nemam ani sifrovany home (jsem malo paranoidni), takze v teto diskusi stejne nemam co delat :-) -
Tom (neregistrovaný)Když ho nepotřebujete, a tedy nepoužíváte, proč ta formulace "vypnout swap"? Dle ní jsem usoudil, že swap používáte, a kvůli bezpečnosti šifrování jej chcete vypnout, což je zbytečné, jelikož swap lze šifrovat také.
Pokud swap nepoužíváte vůbec, pak bych očekával formulaci "nezapínat swap", "nechat swap vypnutý" nebo něco podobného. To by dávalo smysl. To, co jste uvedl, smysl nedává - jak chcete vypnout vypnutý swap? -
Co použít tmpfs a mít tak
/tmpjen v paměti?Uznávám, není to dokonalé, protože ta paměť pak po uvolnění může být přidělena libovolnému programu, ale po tvrdém resetu tam ty data zaručeně nejsou a pokud máte spuštěn nějaký zlovolný program, který bude čmuchat v prázdné paměti, tak tohle asi nebude váš největší bezpečnostní problém.
-
anonymnínejsem nejaky super odbornik, ale hardwerak sem :-)
a nejvetsi problem je v filtrovacich kondenzatorech, je jich tam plno - filtruji kdeco a maji dost velky potencial.
jistota je je a pouze pokud to proste vytahnete ze zasuvky a pockate.
zrychlit to jde jen jakoby zapnutim pc bez proudu. tim se vsecky kondiky vybiji a pak jeste par vterin pockat a jedeme...
take me to prekvapilo ale od dob ATX neni vlastne vypnuty zadny stroj. poznate to snadno, mnoho desek miva ledky a ty i pri vyplem pc neco signalizuji ( nejak sviti) co treba sitovky, i kdyz pc vypnete tak se sitovky hlasi (sice jako 10kova ale je ziva) - na routeru sviti Link. atd... -
Misula (neregistrovaný)Pokud vim, u PC se pouzivaji dynamicke RAMky, ktere musi radic pameti neustale cyklicky obnovovat (refresh), jinak v nich data vydrzi par milisekund. Jelikoz pri vyplem PC (i pri tom radoby vypnuti se sviticimi LEDkami) radic pameti nejede, rozhodne bych se nebal, ze v RAM neco zustane. Pri RESETu nevim, tam bych to tak kategoricky netvrdil.
-
Jooky (neregistrovaný)To je teoria. Prax su radovo sekundy az desiatky sekund (v pripade silneho podchladenia aj minuty). Toto presne testovali vedci v UK (neviem teraz kde som dal link). Skusali ako dlho trva nez data 'vyprchaju' z ram modulov bezne pouzivanych v pc a bookoch. Pri dostatocnom podchladeni mali dostatok casu prelozit ram z jedneho systemu do druheho bez straty obsahu (dost blbe ked mate OS v suspend to ram stave a kluce k disku v pamati).
-
Tap (neregistrovaný)Díky, ale já nemám problém s tím, jak to zprovoznit, to už jsem dávno nastudoval a provedl. Tenhle článek je zajímavý tím, že se v něm expert na šifrování vyjadřuje k určité implementaci šifrovacího systému (Truecrypt). Já používám dm-crypt a LUKS, a právě proto by mě zajímalo, jak vidí stejný expert toto řešení, z kryptografického hlediska.
-
Milan Knížek (neregistrovaný)Z tohoto důvodu používám na desktopu s linuxem encfs (pro domovský adresář). Je škoda, že encfs nemá kvalitní GUI frontend (kencfs nic moc...).
Má zřejmě pár nevýhod (menší výběr šifer, pomalejší), ale pár uživatelských výhod (na nešifrovaný disk se ukládají šifrované soubory jednotlivě, tj. menší riziko poškození všech šifrovaných dat; nejsou problémy s využitím místa - znáte to, rozdělíte disk na oddíly pro domovské adresáře a pro šifrovaná data a pak zjistíte, že na jednom oddíle je zbytečně moc místa a na druhém jste na nule).
Nicméně ve Windows používám TrueCrypt, je to skvělý software. -
Lukas Pravda (neregistrovaný)Tohle v TC mozne neni. Jedine co lze je vytvoreni "dynamickeho" disku (presny termin nevim, ale je mozno dohledat v dokumentaci), kde nastavite maximalni velikost a on pozdeji roste dle potreby. (hrube se nedporucuje z duvodu bezpecnosti, spolehlivosti a vykonu :) ) Zkousel jsem a je to opravdu katastrofa, nicmene je dobre mit tu moznost.
-
lummox (neregistrovaný)Do určité míry lze (alespoň na Windows) něčeho takového dosáhnout pokud je kryptovaný disk umístěn jako soubor v systému NTFS. Nový Truecrypt umí vytvořit kryptovaný disk jako tzv. sparse file, tj. soubor, kde se nulové bloky dat na fyzické médium nezapisují. Takový soubor (v tomto případě kryptovaný disk) se pak tváří, že má třeba 40 GB, ale jeho fyzická velikost začíná na pár megabajtech a postupně se zvětšuje s tím, jak do něj přibývají data.
Samozřejmě se tím nejspíš o něco sníží bezpečnost, protože lze pak na první pohled určit, které části kryptovaného disku obsahují data a které nikoliv. -
xxx (neregistrovaný)Njn, jsem to spatne precetl:) Ale zkusil bych rozsirit fyzickou partisnu na ktere to je a pak pri namountovanem disku rozsirit velikost partisny i tam. Pokud program dela jenom to, ze na jiste partisne prevadi data mezi OS a driverem, tak by to z principu melo fungovat, ale je to spis otazka na autory nebo to zkusit. Rozsirovani partisny by muselo nasledovat tak i tak. Jinak u souboru stejnym zpusobem jako u fyzicke partisny. Ve win32 je na to dokonce funkce.
-
Whirlpool je kryptograficky z mého pohledu nejkvalitnější. Ostatní dvě nabízené funkce (RIPEMD-160 a SHA-1) jsou klony třídy MD, která ztratila kredit kvůli snadnému nacházení kolizí. V Truecryptu se hashovaci funkce používají jako jednosměrné funkce pro tvorbu klíče z passwordu. Tady narušení jejich vlastnosti bezkoliznosti není zatím nijak použitelné, protože ta funkce je složitá. Takže je můžete používat, jen to nebude vypadat moc in.
Zcela mimo ještě uvádím perličku, autentizační protokol APOP (Authenticated Post Office Protocol). Člověk si myslí, že nalézání kolizí v následujícím protokolu nemůže nijak pomoci k útoku na password. Omyl, omyl, celý password lze odhalit pomocí kolizí...
Protokol:
Klient (pozaduje na serveru svoje e-maily)
Server mu posila vyzvu (vyzva ma urcita omezeni, ale nemnoho) C
Klient vraci hodnotu MD5(C || password)
Server zkontroluje hodnotu odpovedi, protoze zna klientuv password. Je-li ok, pošle mu maily.
-
Bilbo (neregistrovaný)Tak to by mne zajimalo jak to u toho APOP prohiha.
Nasadi-li se man-in-the-middle, tak pri prvnim (u tupejsich useru mozna az pri druhym nebo tretim) pozmenenym C nebo poslane response se to provali, nebot server odmitne autentizaci.
A pokud odposlechnu nejakou serii Cx, a MD(Cx || pass) tak v tom nevidim zpusob jak vyuzit ty kolize k prolomeni. Teda pokud tam neni nejaky flaw typu ze Cx muze byt jedna z 256 moznych nebo tak neco. -
Ten útok je opravdu MITM jak píšete, jen ho provádí jakoby server (útočník). Uživatel je ten, kdo se snaží server přesvědčit o tom, že je oprávněný, proto možná není nastaveno pravidlo třikrát a dost. Server se prostě ptá uživatele stále, pokud to uživatel típne, tak se k poště nedostane. Pokud to netípne, tak se server stále ptá na odpovědi na svoje výzvy. Po určité době se už neptá, odvodí si password. Není to všem server, ale útočník, který se jako server tváří.
Víte nějaké podrobnosti, jak je to na straně klienta s nastavením - kolik dotazů mu může server poslat, aby se na něj vykašlal? -
Bilbo (neregistrovaný)To priznam se nevim, ale tusil bych ze postovni program to zkusi asi jen jednou a pak zarve ze je spatne heslo (pri klasicke autentizaci taky nema smysl zkouset to same heslo dokola kdyz server napoprve rekl ze je spatne) ... a pak je to na uzivateli, aby si to nejak prebral
Otazkou pak je spis kolikrat uzivatel bude mackat nejake tlacitko na zpusob Reconnect/Retry nez mu dojde ze je tu asi neco spatne ...
Zase na druhou stranu, pokud server odpovi ze heslo je dobre a nabidne uzivateli ke stazeni prazdnou schranku (nebo treba par spamu at to vypada ze tam "neco je" :), tak si toho ze je neco spatne muze dotycny vsimnout pozdeji (pokud ceka na nejaky email a ten ne a ne dorazit, ale pri takovehle netrpelivosti pak muze kontrolovat schranku treba i kazdou minutu, cili vice poslanych challenges a vice prijatych responses)
Na druhou stranu, pokud stahovani mailu bude probihat nejak automaticky (napr. "zkontrolovat kazdych 5 minut novou postu") tak se muze program bez "vedomi" uzivatele pokouset treba kazdych 5 minut o pristup do schranky ...
Kolik challengi je takhle potreba postat a dostat zpet aby se heslo prolomilo? -
Na odhaleni jednoho znaku jakehokoliv passwordu je potreba v prumeru (za maximalne nepriznivych okolnosti) cca 255 vyzev. Obvykle to bude pouze cca 32. Pri utoku se pocita s periodickym automatickym prihlasovanim klienta. Utocnik uprostred dela hloupy server a stale klienta autentizuje. Voli si svoje vyzvy C a uci se z hodnot MD5(C || heslo).
-
PMoravec (neregistrovaný)Dobry den,
neni v pripade MitM utoku problem s prolomenim bezpredmetny? Mam za to, ze v pripade neuspechu APOP (-ERR Unknown command: APOP) E-mailovy klient automaticky zkouset nesifrovane USER/PASS; resp. APOP vubec nepouzije, pokud nenarazi v uvitani od serveru na timestamp, uvedeny mezi <>. Oboji muze falesny prostrednik sam zaridit. Jina situace by samozrejme nastala pri odposlechu periodicke kontroly E-mailu ve schrance.
Jinak by bylo treba pokazde nove spojeni, protoze se pro MD5 pouzije zmineny timestamp z uvitani POP3 serveru vcetne <> a shared secret.
RFC1939 uvadi jako priklad <1896.697170952@dbc.mtview.ca.us>tanstaaf s MD5 c4c9334bac560ecc979e58001b3e22fb.
Otazkou je, zda by podobny utok sel pouzit na CRAM-MD5 nebo novejsi variantu Digest-MD5. -
To uvitani od serveru <..cokoli..> je prave ona challenge C, o ktere se bavime (pro nezainteresovane ctenare - chapu, ze to tak nevypada, kdyz se to jmenuje timestamp). Pokud klient neodpovi MD5(C || password), tak by nemel od serveru postu dostat.
Kdyz se utocnik postavi do role serveru a nepouzije v uvitani vyzvu <....>, co se stane? Posle mu e-mailovy klient svuj password? Jestli ano, tak je tenhle utok opravdu bezpredmetny. -
PMoravec (neregistrovaný)Alespon v Thunderbirdu 2.0, ktery momentalne vyuzivam to tak vypada - kdyz neni vyzadovana uzivatelem zabezpecena autentizace, tak na serveru, ktery challenge (timestamp) poslal, zkousel rovnou APOP a kdyz ne, zkousel primo USER/PASS, coz by melo byt standardni chovani (vyplyva to z RFC, kde se primo pise "A POP3 server which implements the APOP command will include a timestamp in its banner greeting a The POP3 client makes note of this timestamp, and then issues the APOP command). Nevylucuji ale, ze v nekterych klientech je mozno APOP zvolit separatne. Nemam overenu tu variantu, kdy by v hlavicce od serveru challenge byla a APOP by selhal, muzu vyzkouset nasimulovat vhodnym programkem, tvaricim se jako POP3 server. Na druhou stranu utocnikovi staci pozmenit uvitani, aby challenge (timestamp) neobsahovalo. Oproti tomu pri zvolene zabezpecene autentizaci pri selhani AUTH *-MD5 a AUTH NTLM Thunderbird vyhlasi, ze se nemuze zabezpecene na server pripojit a nepokracuje.
-
PMoravec (neregistrovaný)No pri selhani APOP v bezpecne variante (kdyz jsem to ted zkousel ladit pres netcat) to alespon vyhlasi chybu, ze server nepodporuje bezpecnou autentizaci. Ale neobjevil jsem zadnou Ameriku, jiz je to popsano tady, jak jsem prave zjistil:
http://www.securityfocus.com/archive/1/464584/30/0/threaded
A number of POP3 servers support APOP, but most of them require some
special configuration. And it seems like Mozilla attempts to use APOP if
APOP banner is present in server reply and no secure protocol is
configured. So yes, it's used, but mostly as an alternative to
cleartext. Based on last 115000 sessions statistics for ISP's mail
server with CRAM-MD5, APOP and NTLM support, ~7000 mailboxes:
Cleartext: 96,3%
APOP: 2,1%
CRAM-MD5: 1%
NTLM: 0.6% -
xxx (neregistrovaný)Je tam benchmark, aspon ve win verzi. Pouzivam twofish a je to kolem 60MB/s na 3GHz P4, cteni o neco malo rychlejsi, ale v podstate stejne. V realu to nezatezuje prakticky vubec, leda pri kopirovani velkych mnozstvi dat a to pravda neni nejbeznejsi, navic i rychlost te x let stare P4 je za hranici rychlosti disku, takze v dnesnich C2D a podobnych je to uz uplne irelevantni:)
-
Proc se stale neprodava HW reseni - napriklad radic disku, nebo rovnou disk, ktery si sifruje data sam (ted nemyslim zamek ATA rozhrani, ktery lze obejit jinou elektronikou nebo ctenim disku primo)? K diskum by clovek dostal 2 tokeny, po power-on by ho musel pripojit, aby disk nabehl, bez tokenu by nefungoval, data by na plotnach byla sifrovana. Odpadly by problemy s OS apod.
-
xxx (neregistrovaný)Jen tak pro upresneni, ATA password na disku nejde obejit jinou elektrikou, v praxi to znamena, ze pokud si ho zamknes (nebo nejaka el. havet pokud nemas BIOS co to umi freeznout - vetsina BIOSU to neumi!), tak prijdes o data a pomuze ti jenom zaplatit xx tisic za recovery od nejake specializovane firmy
-
Nějaké takové disky se myslím dělají. Celkem nedávno jsem myslím něco četl na cdr.cz o discích Seagate. A šifrovací mezikus pro ATA disky už jsem taky (na obrázku ;-)) viděl.
Osobně mám ale raději softwarová řešení. Dají se tomu zkontrolovat zdrojáky, dají se tomu nainstalovat bezpečnostní záplaty a modernizovat používané technologie. A co když vám např. ten ATA mezikus shoří? Máte po datech. Musíte tedy stejně zálohovat a zálohy nějak šifrovat.
A speciálně se mi líbí software, který umožňuje vygenerování klíče jen z hesla. Je to sice o něco méně bezpečné než keyfile nebo hardwarové řešení (nikdo ale neříká, že se nemůže použít kombinace obojího), ale vím, že heslo, co mám v hlavě, a onen zašifrovaný soubor je všechno co potřebuju, když chci data zpátky. (Tedy pokud vím, jak přesně to bylo zašifrováno, tzn. ideálně mám původní program se zdrojáky. Při znalosti algoritmu ale není nezbytný.) Hardware se dá ztratit, může se rozbít apod. a navíc krom výrobce často nikdo neví, jak přesně data šifruje/dešifruje. -
corwin78 (neregistrovaný)Je nějaký způsob, jak pod Linuxem zašifrovat celý disk se systémem? Na workstejšně doma je mi to jedno, ale na notebooku bych to rozhodně přivítal. Pokud vím TrueCrypt toto neumí, jinak je to samozřejmě vynikající nástroj, který používám. Už se těším na GUI, i když i z komandlajny to funguje skvěle.
-
Reseni existuje - luks. Kdysi jsem si sam pro sebe napsal navod, jak toho dosahnout. Pokud te to zajima, tak se podivej na http://www.jetpac.org/wiki/index.php/VAIO#Encryption_setup
Mam tam sled kroku, vysvetleno tam neni nic. Jak to funguje muzes najit v odkazech na pouzitou literaturu na konci stranky.
Pokud by si v tom navodu nasel jakoukoliv chybu, dej mi prosim vedet, opravim to. Diky. -
Tap (neregistrovaný)
Je nějaký způsob, jak pod Linuxem zašifrovat celý disk se systémem?
Samozřejmě, viz dm-crypt a LUKS. Jediné, co zašifrovat nejde, je obraz jádra, zavaděč a initrd (čili /boot). Všechno ostatní zašifrovat jde.
-
Joe (neregistrovaný)Trochu mě zarazilo hodnocení keyfiles, že mohou prodloužit útok hrubou silou jen o zlomky vteřin. Platí to i v případě, že útočník obsah keyfile(s) nezná?
Měl jsem totiž za to, že obsah keyfile se "nějak" aplikuje na password, a tom případě by IMHO stačilo i prosté XORování, aby se ze slabého hesla stalo silné (tedy pokud má heslo rozumný počet znaků a keyfile je dostatečně randomizovaný).
(Že to není XORování jsem si našel na http://www.truecrypt.org/docs/?s=keyfiles-technical-details , ale je to na mě moc složité, nicméně jsem si to vyložil tak, že se jedná skoro o totéž)
Keyfile, aspoň jak mu rozumím, by tedy měl být jakýmsi "privátním klíčem", který ze své podstaty musí zůstat útočníkovi utajen. Podobně jako u ostatních šifer, kde prozrazení privátního klíče v podstatě znamená její prolomení. -
Když by útočník obsah keyfiles neznal, tak to pochopitelně je velmi silné - keyfiles se stávají (náhodným) klíčem místo passwordu: Na uvedeném linku je možné zjistit to, co jste zjistil vy. A tedy keyfiles se zpracují do 64 bajtů (to je onen zlomek vteřiny navíc), které znamenají náhodnou masku. Maska se pak naxoruje na password, eventuelně doplněný do 64 bajtů nulami. Jakýkoliv i slabý password se tak stane velmi silným (prakticky) náhodným klíčem o 512 bitech.
Účelem toho cvičení s keyfiles je tedy ze slabého passwordu udělat silný tím, že se k passwordu ještě xoruje ona Maska. Soubory keyfiles se proto musí utajit, jinak útočník Masku vypočte jen jednou a pak je to pro něj pouhá konstanta do luštícího programu, kterou nemusí počítat pro každý nově zkoušený password.
O něco lepší by bylo o tyto soubory (zpracovává se z nich jen 1 MByte) rozšířit sůl. Nebo vypočítat klíč z passwordu a soli tradičně bez keyfiles a poté skutečný_klíč = hash(klíč, keyfiles). V tomto případě musí útočník pro každý nový password načíst a zhašovat celý soubor keyfiles znovu. A to je podstatný rozdíl v náročnosti luštění.
Je to miniaturní připomínka. Účelem keyfiles je zřejmě pouze umožnit externí vstup passwordu (jakožto náhodného binárního souboru) z nějakého média (z USB, ze sítě,...) a zabránit keyloggerům odchytit password. Jediné, co bych TrueCryptu mohl vytknout je, že by měl nějak výrazněji a jednodušeji užiateli napovědět, k čemu jsou keyfiles dobré (nebo ho donutit číst manuál).
Pokud jsou keyfiles uloženy na hard disku, pak mají menší smysl (to je ale u domácích PC právě běžné). Většinou to bude adresář nebo jeden soubor. Útočník tak může zkoušet všechny do úvahy připadající praktické možnosti kombinací souborů. -
xxx (neregistrovaný)Shodou okolnosti jsem se k TrueCryptu(btw i k svinstvu zvanem ATA security) dostal minuly tyden a funguje velmi presvedcive. Predpokladam, ze jste uzivatelem windows, zajimal by me vas nazor na kryptovani v ramci NTFS, vim ze tam jde o jiny system pomoci certifikatu a podobne, ale zajimala by me bezpecnost pripadne by jste mohl napsat nejake shrnuti, jak je to s temi certifikaty a podobne:) Asi ne na rootu, ale nekde jinde, nicmene myslim, ze by to hodne lidi zajimalo, jelikoz spousta lidi nema o podobnych vecech ani poneti (jak prenaset certifikaty a podobne) a studovat tyhle veci do detailu na MSDN v anglictine je pro vetsinu neprijatelne. Urcite by to byl zajimavy clanek. Jinak dekuju za tento:) Skoda, ze neprisel o tyden driv, pouzil bych whirlpool:o)
-
První zásadní nedostatek je, že k tomu nemá zdrojáky nikdo kromě Microsoftu (tedy pochybuju, že by u tohoto udělali výjimku a zdrojáky dali k dispozici; pokud ano, tak se omlouvám a zbytek příspěvku ignorujte). Dělat tak o tomto systému jakékoli závěry je trošku problematické. I pokud jsou pravdivé všechny veřejné informace o použitých algoritmech apod., tak i bezpečný algoritmus jako AES se dá implementovat nebezpečně atd.
-
Pan Růžička Vám skvěle odpověděl. Výjimečnost Truecryptu je v tom, že zdrojáky jsou k dispozici a objemem jsou zanedbatelné vzhledem ke zdrojákům u Microsoftu. Lze to tedy mít ještě pod kontrolou. Je veřejnou informací, že jsem se podílel na náhradě Microsoft CryptoAPI za jine Krypto API pro NBÚ. Při této práci jsme v týmu objevili řadu pozoruhodných kryptografických vlastností. Například, když zadáte nějaký parametr šifry, systém vám ho potvrdí, ale uvnitř si nastaví něco jiného. Nejsem příliš paranoidní a nehledám v tom činnost tajných služeb, ale chyby při programování složitých systémů. Proto zcela souhlasím s panem Růžičkou. O takovém systému, který není prozkoumán širším týmem odborníků, nelze dělat jakékoliv závěry.
Je to škoda. Ano, je, protože šifrování ve Windows by mohlo zajišťovat soukromí a my bychom tomu mohli věřit. Než to ale nastane, narostou nám asi dost dlouhé fousy.
Článek ohledně certifikátů a šifrování NTFS zatím nechystám. Určitě je to věc, která by mě bavila, podobně jako CryptoAPI, ale zatím jsem se k tomu nedostal. -
tloudev (neregistrovaný)cus,
hele jak resite kryptovani suspend image? priklad: po hybernaci notebooku se jde jeho majitel zhybernovat do putyky, kde mu je jeho stroj ukradnut, disk pripojen k jinemu stroji a prectena cela pamet "ziveho" stroje.
takze: hibernovat radeji na swap nebo do fajlu? jak resumnout z fajlu na cryptofs? slepice nebo vejce?
dik za kopnuti, tl. -
V článku byla jediná výtka, která se týkala keyfiles. V odpovědi ve vláknu keyfiles jsem zhodnocení keyfiles už naznačil (Joe, dík za založení vlákna a správnou poznámku, a tím nakopnutí).
Oč jde, je to, že keyfiles by měly primárně sloužit jako (náhodný) password a být utajené (nebo útočníkovi nedostupné - na síti, na USB, prostě externí zdroj). Pokud nejsou utajené, jejich význam je malý - zde je pak na místě slovo "legrační" (a mohl by být jednoduše zvýšen opatřením, které jsem zmínil v odpovědi ve vláknu keyfiles). Dokumentace k TrueCrypt by měla utajování keyfiles pouze zdůraznit a takto jednoduše popsat jejich smysl. -
joe (neregistrovaný)Když moje poznámka došla takového uznání (děkuji), zkusím ještě trochu přispět na téma keyfiles. Jedná se o mé úvahy nad praktickým použitím vlasností popsaných zde: http://www.truecrypt.org/docs/?s=keyfiles
Osobně jsou mi keyfiles sympatické ze dvou důvodů: Jako keyfile se dá použít téměr jakýkoli soubor, takže se vlastně jedná o steganografii. Prosté scanování disku (i jen mallwarem) je schopno odhalit a ukrást různé certifikáty a privátní klíče, protože podle jejich vnitřní struktury se dá poznat, že jsou to privátní klíče. To u keyfiles nehrozí - nijak se neodlišují jiných běžných souborů.
Druhou sympatickou vlastností je možnost pomocí několika keyfiles obejít nutnost pamatovat si silné heslo, a to i v případě, kdy útočník zná všechny _potenciální_ keyfiles. Příklad: Na USB klíčence mám jednak nezakryptovaný oddíl a pak oddíl zakryptovaný TrueCryptem. V nezakryptovaném oddílu je, mimo jiné, cca 500 soukromých fotek. Mnemotechnicky vyberu 20 z nich (všechny z výletu na Kokořín, plus ty dvě, kde má Franta červené oči od blesku) a použiji je jako keyfiles. Možných kombinací je, tuším, 500! / (480!*20!) = 2,7e+35. Sice to není tak velké číslo jako 2^512, které odpovídá důkladnému 64 bytovému heslu, ale i tak mi to přijde velmi slušně zabezpečné proti útoku hrubou silou. Navíc to můžu ještě okořenit tím, že tam dám navíc jednu konkrétní fotku z flickr.com, která na USB disku nebude.
Sice to sám takhle důkladně nepoužívám, ale by člověk potřeboval např. odvézt větší množství dat (třeba dokumentární film) ze země, jako je Kuba nebo Čína, mohlo by se to hodit.
Podle mého názoru dokumentace TrueCryptu počítá s oběma možnými scénáři (utajené keyfiles vs relativně velký pool neutajených potenciálních keyfiles) a snaží to popsat jedním textem, což může být při prvním seznamování se s keyfiles matoucí.
Závěrem bych se chtěl připojit k ovacím za skvělý článek. Děkuji. -
Dobrý... Samozřejmě to lze, ale teď vážně. Tomu, kdo si nezapamatuje heslo, bych nedoporučil, aby svůj film zašifroval něčím, co může taky zapomenout. (Byly to hnědý Láďovy kalhoty ? nebo Frantova zelená čepice ? na výletu do Krkonoš ? nebo Evina modrá šála na výletě v Tatrách?)
Zkušený uživatel skutečně MůŽE takto nahradit kvalitní heslo.
Je to ale bizardní postup a do masově rozšířeného bezpečnostního programu bych to nedával kvůli blbuvzdornosti. Jako možnost vstupu utajeného klíče z externího vstupu bych to pochopitelně nechal (to je výhodné), ale s podtržením významnu v názvu třeba "extern secret keyfiles" a se striktním varováním před použitím otevřených dat (pod čarou možnost využití otevřených dat pro mimořádně zkušené uživatele, ale jen zcela výjimečně).
Shodneme se takto?
Jinak bych skoro založil nové vlákno na to, jak nějakému kameramanovi, co si prostě nic nepamatuje (kromě ovládání TrueCryptu ....) vtloukl do hlavy něco, co si bude pamatovat. Protože názory na to by mě zajímaly (přejdeme-li to, že v té větě je rozpor, a soustředíme-li se na podstatu). -
Tofu (neregistrovaný)V diskusii na http://www.redhatmagazine.com/2007/01/18/disk-encryption-in-fedora-past-present-and-future/ sa objavila zaujimava kritika Truecryptu. Aj ked autor uviedol len prve meno (Greg) oplatilo by sa jeho tvrdenia preskumat:
Problems with TrueCrypt that DM-Crypt, LUKS, loop-AES, etc. do NOT have:
TrueCrypt has a number of problems IMHO– problems that are not shared by its counterparts mentioned above.
1) Secretive, hidden developer community: The controlling project developers and the so-called “TrueCrypt Foundation” are hidden behind an anonymous screen of Internet tools. Their “foundation” doesn’t seem to be registered ANYWHERE or tied to any physical location or official entity. Their identities, names, backgrounds, countries-of-origin, etc. are unknown to anyone but their inner-circle and they refuse to address this issue (or even to explain themselves). This kind of black-hat persona certainly doesn’t lend itself to the trust of a corporate/business world, for good reason.
Furthermore, they rule their community with an iron fist and do so inconsistently. This makes it extremely difficult to maintain a normal support atmosphere there (would-be community members leave and abandon the project on a regular basis).
2) Cumbersome, antiquated licensing terms: TrueCrypt was born out of the OLD Encryption-For-The-Masses framework (e4m) and contains the work of several other authors/packages with inconsistent licensing conditions. This has caused them trouble in the past, for example when they tried to move their product to the GPL (unsuccessfully).
3) Information control issues: Forums will be suddenly taken offline, apparently deliberately, as certain critical discussions occur. This occurs frequently whenever a new version is released. At the very least, this makes it very hard to support the product properly as a member of their user community, let alone the trust issues this causes.
Furthermore, there are no published bug reports or vulnerabilities listed anywhere except for whatever makes it into their forums and isn’t deleted. Their bug submissions are only accepted through a private Web form on their site.
Finally, certain forums aren’t even visible for public viewing unless you first register. No explanation has been given for this.
For all these and many reasons, I now favor the work done in the “open” world by these other projects and I will no longer personally support TrueCrypt as an encryption platform. If you want the time/effort of folks like myself, you’ll stay away from the TrueCrypt-style tactics I’ve described. -
anonymní- "degraduje" je silné slovo, řekl bych, že primárně je určen k něčemu jinému, kdyby uměl šifrovat adresáře jak chcete vy, bylo by to samo ještě lepší, jeho výhoda je v tom, že to, co dělá, tedy šifruje volume, dělá profesionálně a zadarmo
- "zašifrovat Program Files, aby do toho nikdo nemohl zasahovat a aby
přitom wokna běžely? To samé se týká adresáře Dokumenty." - nezkoušel jsem, ale já jsem jen obyčejný uživatel. Podle mne lze adresář windows---dokumenty přesměrovat na jiný adresář(disk) někde nastavením ve windows (no a ten bych udělal truecryptem jako šifrovaný volume). Program files jsem nezkoušel a neporadím, ale tady vám určitě něldo poradí. Jenže tohle vlákno je dost staré, takže to zkusit někde na rootu jinde. -
Díky za info. Jak říkám, je to škoda, velmi bych tu možnost šifrování adresářů uvítal ... a myslím, že ne jenom já.
Na to přesměrování zmíněných adresářů jsem tedy nepřišel, tj. nenašel řešení .. :-(
Ano, vím že toto vlákno je už dost staré, ale na "čerstvější" zabývající se tímto tématem jsem nenarazil.
Díky g. -
anonymníPřesměrovat celou složku Dokumenty pro všechny programy Office jsem přímo nenašel, ale to je tím, že to možná nabízí jen při instalaci nebo úpravě jednotlivých programů/celého balíku Office (ovládací panel - přidat nebo odebrat prg - změnit nebo odebrat).
V každém případě to lze udělat jednotlivě ve wordu, excelu a určitě i dalších office programech.
V obou programech je to v menu nástroje-možnosti. Nezapomeňte tam přesměrovat také cestu pro automatickou obnovu, aut. ukládání,..., čili projít celé nástroje-možnosti.
U windows byla tahle možnost vždycky z důvodu přesměrování (uložení) Dokumentů lokálních uživatelů Office na síťový disk. Takže se to chce zeptat nějakého systémáka nebo vyhledat na MS netu. -
woknousák (neregistrovaný)Wokna umí na NTFS vytvořit linky mezi adresáři a "přesměrovat" tak adresář jinam, dokonce lze takto do adresáře připojit celý disk jako na UX systémech, akorát se to moc neví protože v systému na to chybí klikátko, utilitka co umí tyhle linky vytvářet se jmenuje Junction (http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx)
K šifrování adresářů "Documents and Settings" a "Program Files" s tím že wokna poběží - nepoběží, dal by se takhle šifrovat konkrétní profil, ale je to pakárna. Pokud je to jen trochu možné tak je ideální zašifrovat komplet systémový disk (TC od verze 5) -> wokna nic netuší a je ošetřené všechno včetně swapu. -
Moc to totiž nechápu. Když nejdou šifrovat kompletní adresáře, tak jsem si řekl, že tedy zkusím zašifrovat kompletní disk, aby se při bootování muselo provést vložení hesla. Jenže OUVEJ .... mám disk rozdělen na dva oddíly, na jednom XIN XP a na druhém Linux. A najednou po aplikování TrueCrypt se mi při bootu neotevře nabídka volby systému, ale ihned startujou wokna. Takže se teď k Linuxu vůbec nedostanu. K čemu to tedy je?
g.
ČLÁNKY DO MAILU