Názory k článku
Šifrujeme data programem TrueCrypt

vzdycky me zajimalo, jak dobre se podobne nastroje dokazi vyrovnat pri chybe media.
Kolik dat ztratim pokud dojde k pozkozeni dat (1B ci celeho bloku) na disku ci flashce.

najviac stratis 1 blok dat, avsak ak sa pokazi nieco v hlavicke, tak prides o vsetko.

Marně hledám pár měsíců polopatistický návod jak zašifrovat kompletně disk i se systemovym. Nejlepe již existující instalaci zkonvertovat na sifrovany. Staci, kdyz po vypnuti PC data nebudou dostupna, pri chodu mohou existovat nesifrovana data nekde v cachi.

Nevite o necem?

Pointsec. http://www.checkpoint.com/pointsec/

dd if=/dev/hda1 of=/dev/mapper/truecrypt0

Mohlo by to ísť, pre ľudí čo majú radi ruskú ruletu :-)

Spomínaný Pointsec dokáže zašifrovať už existujúci disk. Ale späť k truecryptu. Z článku mi vyšlo, že pod Linuxom nemôžem použiť šifrované NTFS, pretože neexistuje jaderný modul, ale len userspace.

Ntfs použít můžete, ale ne jako systémový. Možná by toi nějak šlo přes initramdisk, ale s tím jsem nikdy nechtěl experimentovat.

Kdybych chtěl zašifrovat celý disk, tak se podívám na http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS .

Btw. nápad s kopírováním stávajícího oddílu přes dd může fungovat například ve starém cryptsetupu (ne luks), ale některé šifrovací nástroje si na oddíl uloží hlavičku se svými daty a potom nelze oddíl 1:1 přenést, protože ten šifrovaný je právě o tu hlavičku menší.

Kdo by chtěl na Linuxu pouzivat jako / NTFS? Sklenar?

Proc by to dd neslo? Ta hlavicka je prece furt na stejnym oddilu, a jestli ne, tak se proste ty oddily zkopirujou dva (sifra + hlavicka a janevimcovschnojeste)

dd by nešlo proto, že nešifrovaný filesystém hlavičku nemá a šifrovaný ano. Program dd kopíruje celé bloky dat, nehledě na volné/plné místo. Pokud na oddíl o kapacitě 100GB chcete dát hlavičku a oněch stejných 100GB, nevyjde vám to.

Pokud jsem spravne pochopil system fungovani truecryptu ve spolupraci s dm, pak zarizeni /dev/mapper/truecrypt0 uz je rozsifrovany diskovy oddil. Cili by to melo jit (pokud tam bude dost mista).

Pokud je to stejný oddíl, tak to nepůjde, protože tam _nebude_ dost místa. Šifrovaný oddíl bude _vždycky_ menší (o hlavičku). Nehledě na to, že Truecrypt příslušný oddíl přepíše náhodnými daty ještě před vytvořením /dev/mapper/truecrypt*. Převést stávající nešifrovaný oddíl na šifrovaný tímto způsobem je "sebevražda", tj. o ta data spolehlivě přijdete. Klidně si to vyzkoušejte:

dd if=/dev/urandom of=/tmp/testfile bs=1M count=32
losetup /dev/loop0 /tmp/testfile
mkfs.ext2 /dev/loop0
mount /dev/loop0 /mnt/tmp
umount /mnt/tmp
truecrypt -c
mount /dev/loop0 /mnt/tmp

A konec: mount: wrong fs type... data byla přepsána ještě před tím, než jsme měli možnost je převést.

No samozrejme, ale jen blazen by prepisoval stejny disk:)

Vzhledem k tomu, že se hovořilo o převodu nešifrovaného oddílu na šifrovaný, předpokládal jsem, že se bavíme o stejném oddílu. Pokud by to byl jiný oddíl, tak není důvod používat dd, stačí všechno překopírovat (resp. přesunout).

Vzhledem k tomu, že předpokládám, že nejsme blázni, tak ten soubor se zašifrovaným oddílem bude zřejmě na jiném disku...

Náhodou, dříve, tuším ještě za dob loopaes, to takhle nějak provádět šlo. A pokud je to na jiném oddílu/disku, pak nechápu, proč se mučit s dd a kopírovat celý filesystém, když jdou zkopírovat jen příslušné soubory.

Převod disku na šifrovaný v cryptsetupu pomocí dd rozhodně funguje. Na svém domácím serveru jsem takto převáděl 3 disky 120,300 a 500 GB. Důležitá data jsem si samozřejmě zazálohoval, ale zálohu všech dat jsem neměl dost místa. Pravda, při převodu 500GB trvajícím téměř 12 hodin jsem byl trochu nervózní, ale klaplo to :)
Dokonce jsem u prvního disku prováděl převod pomocí dd z jedné šifry na druhou (silnější heslo) a taky to šlo.

Jaký cryptsetup? Byl to klasický nebo cryptsetup-luks? U běžného to fungovat má, u luks ne (viz dříve psaný http://www.root.cz/clanky/sifrujeme-data-programem-truecrypt/nazory/163606/)

O variantu cryptsetupu ani tak nejde (cryptsetup-luks zastane všechny funkce jako cryptsetup s tím, že navíc umožňuje vytvářet LUKS oddíly), jde o to, jestli dotyčný vytvořil LUKS oddíl nebo ne. Pokud ne, mohl oddíl tímto postupem zašifrovat/přešifrovat úspěšně. Pokud LUKS oddíl vytvořil, pak si s největší pravděpodobností uřízl konec filesystému, neboť šifrovaný LUKS oddíl je vždycky menší než nešifrovaný, o LUKS hlavičku.

Tak či onak, tento postup se nedoporučuje. Stačí výpadek proudu či SW chyba a můžete se s daty rozloučit.

neco malo je tady
https://help.ubuntu.com/community/EncryptedFilesystem

Díky všem za rady. Vypadá to, ale že tento link budu nejvhodnější pro mě :-) PointSec vypadá na placený, což pro mé domácí použití není to pravé ořechové...

Ak mas zvysne bubaky, mozes skusit Utimaco SafeGuard Easy :-) Funguje k spokojnosti, len to betari nemaju ako freeware :-)

Compusec

Docela náhoda, zrovna včera jsem si s Truecryptem hrál pod Open Suse 10.3. No a při pokusu o připojení existujícího kryptovaného souboru-disku (z Truecrypt z Windows)mi to po zadání hesla hodí "nedovolený přístup do paměti SIGněco". Z hlavy si ten SIG... nepamatuji, ale večer to sem když bude čas hodim.

Z vlastnich zkusenosti si myslim, ze tenhle ovladac je lepsi.
http://ext2fsd.sourceforge.net/

Bohuzial ext2 drajverj fs-driver je sice fajn, ale na ext2 pristupuje vylucne z windows-1250 charsetom (pri nasich windows) a neda sa pouzit ani ISO ani UTF. Vsetky diakritika je v haji, niektore subory su necitatelne.

Tak třeba moje učitelka zpěvu zásadně pojmenovává své nahrávky s diakritikou. A nepřesvědčím ji a nepřesvědčím.

Nejsme všichni geekové a občas někdo nezná ani rozdíl mezi významem slov "software" a "hardware". Takového člověka asi nepřeškolíte - a přitom od něj potřebujete data.

Proč někoho přeškolovat? Proč respektovat chyby v softwaru? Já si taky pojmenovávám soubory česky. Pokud to nefunguje, pak je to chyba a někdo by ji měl opravit, ale já se tím nenechám omezovat ;-)

+1

Tohle mám nainstalováno a s hrůzou jsem zjistil, že z windowsů vidím všechny adresáře na linuxovém oddílu, můžu si v nich libovolně mazat, můžu přistupovat do těch, které mají uživatelé chráněny proti prohlížení ostatními, atd. Tak jsem si to nepředstavoval.

Prave od toho je to tu sifrovani ;-)

Rovnako ako keď si bootneš iný unixový operačný systém, v ktorom si root (napr. live CD linuxu). To nie je bezpečnostná chyba, ale design decision :-)

ak je rozdiel medzi truecrypt a postupom.... Akosi som to z clanku nepochopil

Z hlediska bezpečnosti dost podstatný. Projděte si materiály na webu projektu. Třeba už tak "obyčejná" věc jako zacházení s klíčem, šifrovací mód, atd. Můžete si projít i tento článek.

raz som si zasifroval /home pomocou losetup -e aes a po upgrade balickov v ArchLinuxe (util-linux -> util-linux-ng) som nebol schopny nadalej desifrovat svoje data

V Arch Linuxu se mi už několikrát osvědčilo nemazat /var/cache/pacman/pkg a v případě potřeby provést downgrade.

mate to nekdo vyzkouseny nad /dev/mdX sestavenym ze dvou disku v mirroru?

Já používám dm-crypt/LUKS a to funguje nad mdX příkladně. Truecrypt by také mohl.

neni problem

Já bych uvítal článek představující nativní řešení pro Linux, tedy dm-crypt/LUKS.

Na Vámi odkazovaný článek je v dnešním článku několik linků, takže jejich provázanost není jen teoretická. Především se ale nejedná o „prakticky stejný článek“, protože ten starší se zabývá rozborem bezpečnostních mechanismů, kdežto dnešní probírá praktické použití TrueCryptu.

Jaka byla bandwidth a jaky byt typ pouziteho hdd? Zajima mne rychlost pred (MB/s) a po (MB/s). Podle meho nazoru je to nejdulezitejsi fakt, ktery vetsinou hovori proti encryption. Uvedte take pouzity algoritmus, velikost Vaseho nativniho oddilu a pouzity fs.

prakticke pouziti?
mno me prijde prakticke mit v klavesnici malicky usb flash s klicem a _cokoliv_(*) at mi pomoci tohoto klice automaticky pripoji pri startu pc cely home disk.

pokud by pak flash nebyl k dispozici, home se nedesifruje, nepripoji. to je prakticke poziti.

nejaky fat, windows, ci nejake disk.mpeg soubory me nezajimaji.
kompatibilita s widlema byt muze, ale nedava mi smysl. na jednu stranu sifruji a na druhou do toho lezu z widli?!? to jde proti sobe, ne?

*) nejlepci cokoliv je neco co je primo v debianu :-) treba dm-crypt/LUKS.

nejlepci cokoliv je neco co je primo v debianu :-) treba dm-crypt/LUKS

Souhlas. Docela se divím, jak moc je Truecrypt propagován mezi uživateli GNU/Linuxu, navzdory existenci nativního řešení. Pokud jde o dualbootery, pořád tu existuje řešení typu FreeOTFE, které umí otevřít LUKS kontejnery, takže přenositelnost by měla být OK i v případě dm-crypt/LUKS.

mno me prijde prakticke mit v klavesnici malicky usb flash s klicem a _cokoliv_(*) at mi pomoci tohoto klice automaticky pripoji pri startu pc cely home disk

Tohle řešení je sice na jednu stranu pohodlné, ale na druhou stranu mi nepřijde příliš bezpečné. Kdokoliv získá příslušný USB klíč, získá přístup k datům. Stačí ho zapomenout poblíž počítače.

Šifrovat jenom /home mi přijde také nepřijde jako úplně bezpečné. Minimálně by bylo dobré šifrovat ještě swap, třeba náhodně vygenerovaným heslem při každém startu. Bez šifrovaného kořenového oddílu je vhodné používat tmpfs nebo přesunout /tmp na šifrovaný oddíl. Nejlepší je ovšem šifrovat i kořenový oddíl. Zejména pak, pokud je chráněný stroj v prostředí, kde lze předpokládat možnost opakovaného přístupu útočníka k danému stroji. V tom případě bych ještě pro jistotu doporučoval vhodně vyřešit bezpečnost nešifrovaného oddílu se zavaděčem a obrazy jader.

Tak v kavárně bych rozhodně nějaká mission-critical šifrovaná data nerozmotával, to je hodně veliký hazard. A co se práce týče, mám-li vlastní laptop, nemám problém. Pokud budu mít firemní stroj s kteroukoliv linuxovou distribucí, jsem v pohodě, protože dm-crypt/LUKS je nativní řešení pro GNU/Linux (na rozdíl od Truecryptu). Pokud budu mít Windows, máme tu FreeOTFE, které zajišťuje přenositelnost kontejnerů vytvořených pomocí dm-crypt/LUKS do prostředí Windows. Opět nemám problém.

Systémy pro diskové šifrování jako dm-crypt/LUKS nebo Truecrypt řeší především fyzickou bezpečnost dat na příslušném stroji. V tomto případě jde o přenositelnost maximálně těm, kteří používají dual boot. A i v tomto případě je možné použít dm-crypt/LUKS (viz výše). Data, která _přenáším_ z takto zabezpečeného systému někam jinam mohu šifrovat i jiným způsobem (což bývá leckde vhodnější), třeba pomocí SSH, GnuPG, apod.

A mimochodem, ani Truecrypt není příliš univerzální řešení, jak tvrdíte. Pokud bych měl v práci třeba MacOS nebo *BSD, mám smůlu.

Čili, já skutečně jako uživatel GNU/Linuxu nevidím příliš mnoho důvodů proč preferovat Truecrypt nad nativním dm-crypt/LUKS. Přenositelnost do Windows totiž díky FreeOTFE (a existenci jiných metod bezpečného přenosu) problém není.

MacOS a *BSD me netrapi, jejich rozsirenost je zanedbatelna a vzdycky je pobliz nejaky stroj, na kterem se da pracovat

Hovořil jste o _univerzálním_ řešení. To ale Truecrypt zjevně není a na to jsem se snažil poukázat. Hovořím-li o univerzálnosti, pak předpokládám širší přenositelnost a nikoliv pouze přenositelnost mezi těmi platformami, které zrovna já používám.

Vy stale predpokladate, ze pracujete pouze na pocitacich pod svou spravou, kam si muzete nainstalovat i linux, kdyz se vam to bude hodit.

Pokud zacházím s citlivými daty, která mám potřebu šifrovat, tak skutečně předpokládám, že pracuji na počítačích pod svou správou. To se na mne nezlobte.

Pořád se mi ale zdá, že nějak neakceptujete, že FreeOTFE je aplikace pro _Windows_. Mám-li šifrovaný kontejner vytvotřený pomocí dm-crypt/LUKS, mohu jej otevřít pomocí FreeOTFE ve Windows. Stejně jako v případě Truecryptu. Čili já nevidím rozdíl mezi přenositelností Truecryptu a dm-crypt/LUKS. Ale to jsem už vysvětloval a ne jednou. Četl jste vůbec moje příspěvky?

Já se nepodivuji nad tím, proč _někdo_ na Linuxu používá Truecrypt. Spíše se podivuji nad tím, jak moc se hovoří o Truecryptu a jak málo o dm-crypt/LUKS mezi uživateli Linuxu, kde bych předpokládal preferenci nativního řešení. Truecrypt bývá vyzdvihován kvůli přenositelnosti (Linux/Windows), avšak ta by měla být díky existenci FreeOTFE na stejné úrovni i pro dm-crypt/LUKS.

krom toho se vsak snazim rict, ze vas pattern pouzivani se proste lisi od toho, jak podobne aplikace pouzivaji jini a tim padem jsou i jejich potreby jine

To samozřejmě chápu. Nicméně vzhledem k tomu, že jste zatím argumentoval výhradně přenositelností, která by měla být u obou řešení na srovnatelné úrovni, nevidím tedy žádný očividný důvod proč preferovat Truecrypt nad dm-crypt/LUKS. Obě řešení se mi i z hlediska vašich potřeb zdají srovnatelná.

V clanku mi chybi srovnani s jinym podobnym systemem - LUKS. Prijde mi ze LUKS je pro mnoho veci vyhodnejsi nez TC. Zejmena je lepe integrovatelny s grafickymi aplikacemi pri soucasnem hot-plug (Flash disky a tak podobne). Myslim ze TC se snazi aby na diskove oblasti vubec nijak nebylo videt ze jde o TC (coz nekdy taky muzete chtit), zatimco LUKS ma poznatelnou partition, takze na ni muze desktopove prostredi reagovat napriklad vyzvou k zadani hesla. Navic TC tusim neumi vic nez jeden autentizacni klic, zatimco v LUKS jich muzete mit nekolik (napriklad kazdy admin muze mit sve heslo, pripadne muzete mit nejake zalozni heslo v obalce v trezoru).

-Yenya, http://www.fi.muni.cz/~kas/blog/

Souhlas.. navic je LUKS integrovany do distribuci a svobodny.

Zdravim.
Neda se nejak velikost uz vytvoreneho (a naplneneho) disku zvetsit a nasledne (treba pomoci kparted) natahnout i filesystem?
Vhodne napr. pro pripady, kdy nemam dost mista na vytvoreni dalsiho (vetsiho) disku pro prekopirovani.

nějaké trauma z dětství ?

Asi mu nakej tucnak_natrchfrdel... ;P

I tihle lidé mají volební právo? ;)

... lidé ...

A není to jen nějaký špatně naprogramovaný bot?

Vzkaz pro všechny debily? Tak tohle je dokonalá ukázka rekurze.

;DD chjo, tak to si vystihl...
Osobně používám deba a je mi jedno, že to znamená, že sem retardovaný kryplýk ;DD

Řekl bych, že nikoliv, ale rád se nechám přesvědčit o opaku.

Dá, tedy pokud nemyslíte disk, ale oddíl. fdisk (změna velikostí) a fsck (viz manuál pro používaný systém, hledejte grow). Umí to ext2, ext3, ext4, ReinerFS, Reiser4 i XFS. Několikrát jsem takhle souborový systém zvětšoval i zmenšoval (bylo to na LVM, ne na oddílech) a bylo to bez problémů.

Vy píšete, že se nedá poznat co je tenhle soubor zač... Když ho ale TC otevře a dekryptuje mnou poskytnutým heslem, tak má nějakou hlavičku, jak ale ví, jestli je korektní... Nemůže se stát, že disk omylem připojím s chybným heslem a pak při prvním zápisu přijdu o nějaká data??

Těžko. Mrkněte se do specifikace. Správnost klíče by měla být ověřena pomocí kontrolního součtu. Ale ani kdyby tomu tak nebylo, dešifrování nesprávným heslem by vyprodukovalo náhodná data. V takovém případě by systém na daném oddíle (kontejneru) neobjevil žádný souborový systém. Přirozeně, v takové situaci by nikdo na příslušný oddíl (kontejner) nic nezapisoval, takže by k poškození dat nedošlo. Prostě byste oddíl (kontejner) odpojil a zinicializoval pomocí správného hesla. Ale to není třeba, jelikož se správnost hesla ověřuje pomocí kontrolního součtu.

...jste mi pripomel XOR "sifrovani" v T602 :-)

XOR sifry sou sranda, par mych implementaci naleznete napr. zde: http://www.soom.cz/index.php?name=download/kategorie&sid=12
Tak nejak sem se k tomuto dotazu take dostal... Napr. jeden soubor s dvemi ruznymi klici muze byt uplne jiny film ;D (otazkou je, co je pak ten klic ;)

Hlavní problém co se týče bezpečnosti je IMHO "prosakování" šifrovaných dat (nebo informací o nich) mimo šifrovanou oblast. Lze předpokládat, že s (de)šifrovanými daty nějak pracujete. I když třeba EncFS zajistí nemožnost extrahování názvu souboru, obyčejná aplikace, která si pamatuje několik naposledy otevíraných souborů, může tuto informaci "vynést". Pokud se zrovna updatuje databáze pro "locate", máte ještě větší smůlu. Ale ani tady problém nekončí. Pokud používáte jenom EncFS a nešifrujete swap, může se klidně stát, že se kus (de)šifrovaných dat objeví v něm. Pokud šifrujete swap, ale nepoužíváte tmpfs, mohou se (de)šifrovaná data klidně objevit v /tmp.

Tyto problémy se samozřejmě týkají i používání systémů pro diskové šifrování (jako Truecrypt), pokud třeba šifrujete pouze /home, zatímco swap a kořenový filesystém necháváte nešifrované. O těchto možnostech "prosakování" (de)šifrovaných dat je tedy dobré vědět a zařídit se podle toho.

A co takhle FreeCompusec?Ja s jeho pouzivanim mam jen ty nejlepsi zkusenosti. Uznavam,ze je to trochu jine reseni, cryptovany je totiz cely disk a pouziva se PreBoot authentication, ale funguje to fakt skvele

Šifrovací řešení na bázi černé skříňky (bez zdrojáků) mne moc nelákají. Nelze ohodnotit ani kvalitu, ale ani bezpečnost daného řešení. A nejde jenom o možnou existenci zadních vrátek, jde také o bezpečnost dané implementace. OK, nejsou zdrojáky, tak by se člověk podíval alespoň na dokumentaci. Jenomže tu jsem jaksi nikde nenašel. Ano, Free Compusec používá šifru AES. Super. Ale jaký je šifrovací mód? Jak se zachází s klíči? Kde je uložena hlavička? Jaký má formát? Atd.

Bezpečnost takového řešení tedy nemohu ohodnotit, ani ze zdrojáků, ani z dokumentace. Může to být bezpečné, ale také nemusí. Jak mám věřit něčemu, co si nemohu ověřit? A co když se něco poláme? Pokud znám detaily implementace, mohu se (a) na problémy připravit a (b) problémy nějak řešit. V tomhle případě mi není jasné ani to, jak bych k šifrovaným oddílům přistupoval z live cd, abych mohl provádět ty nejprimitivnější záchranné operace.

Je sice fajn, že je to "zdarma", ale to je tak všechno. Je mi líto, ale minimálně já bych se tomuto řešení obloukem vyhnul. Už z principu nesvěřím svá data něčemu, co nevím, jak funguje.

A mate nekdo zkusenosti s tim losetup-em?
Asi to nebude tak rychly a bezpecny, ale da se tim sifrovat prakticky vsechno ne?
viz. man losetup...

Osobně bych se tomtuto způsobu šifrování vyhnul. Truecrypt, nebo dm-crypt/LUKS jsou IMHO _podstatně_ bezpečnější a šifrovat se s nimi dá také ledacos. Obojí se navíc dá využít i ve spolupráci s losetupem.

Respektive, abych toto řešení úplně nezatracoval, na něco menšího se to jistě použít dá, i když v tom případě se dá použít i GnuPG, EncFS či něco jiného. Jako diskové šifrování (tj. na úrovni diskových oddílů nebo celých disků) bych to rozhodně nepoužil.

Mám zásadní problém s Truecryptem. Tento vynikající software mi slouží velmi dobře jak ve Windows, tak v linuxu, kde ho ovládám přes příkazovou řádku. Problém se však objevil v okamžiku, kdy jsem zkopíroval vypálený archiv vytvořený ve Windows na linuxový oddíl ext2, připojil ho příkazem truecrypt /home/mujprofil/Desktop/soubor /home/mujprofil/Desktop/mountdir/ -M users,gid=users,umask=0000,rw S archivem lze normálně pracovat, soubory i adresáře přidávat a mazat, ale ... ty které jsem vytvořil ve Windows mají zkaženou diakritiku. Jaký mountovací příkaz je prosím třeba doplnit, aby byly soubory a adresáře vytvořené ve Windows XP správně zobrazené? Jinak program oceňuji, jediná věc, která mi u něj chybí je podpora šifrování celého systémového disku i s bootovacím oddílem (viz placený Drivecrypt pro Windows, který to umí).

Nemůžu přijít na to, jak zašifrovat adresář se soubory. Vždy to chce vytvořit virtuální disk a do něj můžu ty data překopírovat/přesunout. To já ale nechci, chci jen ten adresář zašifrovat tam, kde je. Jde to vůbec? Prosím info na mail.
Díky.