Šifrování s TrueCrypt (diskuse)

[menphis]

Algoritmus šifrování [stačí ponechat AES, paranoici si zvolí nějakou kombinaci]

Mnohem vetsi vliv na bezpecnost ma volba modu sifrovani.

zašifrovaný oddíl vypadá jako /dev/urandom – můžete tvrdit, že jste si disk prostě přepsali náhodnými daty

Imho maximalne tak kamaradovi, manzelce.... jinak to poznat pujde.

Jinak jako nejvetsi slabina luksu se casto uvadi, ze ke generovani hlavniho klice se slouzi algoritmus SHA-1,( presne si to ted nepamatuji ).

[Lliure Darcia]

 

Imho maximalne tak kamaradovi, manzelce.... jinak to poznat pujde

Zajímalo by mě, jakým způsobem to půjde poznat?

 

[Villem]

Protože sám TrueCrypt musí mít někde uloženo, kde se ten "skrytý" oddíl nachází. Aby ho pak mohl připojit.

[Mrkva]

Doporucuji k precteni http://www.truecrypt.org/docs/encryption-scheme

[Jendа]

Program, o kterém ještě bude řeč příště, se snaží detekovat TC jednotky mimo jiné právě tím, že jsou dokonale náhodné .

[Bilbo]

Je vice "dokonale nahodnych" dat - jednak truecrypt, jednak opravdu nahodna data (/dev/random ...) jednak truecrypt neni asi jediny kryptosystem s touto vlastnosti (minimalne one time pad ma tuhle vlastnost a tusim i dalsi). Tusim ze taky nektere experimentalni PPMD kompresory, co produkovaly archivy bez jakkoliv hlavicky mely vystup co byl k dokonale nahodnym datum taky asi dost blizko.

[j]

jj, jak bylo receno, neco pocist, info si to nikam neuklada, veme proste raw data a pokusi se je rozsifrovat, pokud se povede, najde tam svoji hlavicku a disk pripoji, pokud ne, nepripoji nic.

BTW: co se tyce zjistovani zda na disku jsou nebo nejsou data, tak nikdo nikde nepise, ze to nejde "zjistit" ,ale ze to nejde !dokazat! a to je celkem rozdil. Kdyz budete nekomu tvrdit (apon za normalnich okolnosti v CR je lepsi netvrdit nic) ze tam zadny data nemate, tak si muze myslet co chce, ale nedokaze, ze nemluvite pravdu.

[Jendа]

Mnohem vetsi vliv na bezpecnost ma volba modu sifrovani.

TrueCrypt umí jenom XTS (který je IANACE (I Am Not A Cryptoghraphy Expert) dost bezpečný).

[Jendа]

Cryptoghraphy

Bez toho h, samozřejmě.

[Fluttershy, yay!]

Ighor?

[kralyk z abclinuxu]

[Jardík]

Dlouhé heslo? Pro AES-256 může být délka klíče 256bitů, takže to je maximální délka "reálného" hesla. Pokud z hesla vytvoří např. md5 a to pak nastaví jako klíč, to už je jiná.

Je moje heslo na jedno nejmenované fórum dlouhé 65gd::fbvc5b48?:_56fg69:fghf_vcbcv88vfdg@dfgd365dxcv45rf? Ani moc ne a přitom je stále zapamatovatelné. Pamatuje si ho za mě totiž nešifrovaný soubor ~/Notes/passwords.txt

[stativ]

amatuje si ho za mě totiž nešifrovaný soubor ~/Notes/passwords.txt

Doufám, že jsi nezapomněl na jeho zálohování na nástěnku.

[Jardík]

Jó, tam ho mám taky.

[stativ]

To je dobře. Záloha se vždycky může hodit

[b*d]

keepass(x)? a Perform auto-type. Bezpecna hesla a nemusim si nic pamatovat.

Taky moc nechapu, co maj s tim skovavanim hesel za hvezdicky a proc nektere sluzby zaroven chteji min a MAX delku v nerozumnem intervalu.

[corwin78]

Nedaří se mi přinutit TrueCrypt, aby připojoval disk (respektive soubor) bez hesla. Úpravu v sudoers jsem udělal jak je tu napsáno. Chodí to někomu? Mám Kubuntu 9.04.

[Jendа]

Chodí.

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

User_Alias  TCUSERS = jenda
Cmnd_Alias  TC = /usr/bin/truecrypt

TCUSERS     ALL= NOPASSWD : TC

# Uncomment to allow members of group sudo to not need a password
# (Note that later entries override this, so you might need to move
# it further down)
# %sudo ALL=NOPASSWD: ALL

Ohlásí to alespoň do /var/log/auth.log nějakou chybu?

[corwin78]

ve /var/log/auth.log je:

1 incorrect password attempt; TTY=unknown; PWD=/home/michal; USER=root; COMMAND=/usr/bin/truecrypt --core-services

[Jendа]

Já tam mám toto:

Aug  6 12:28:25 paranoid sudo:    jenda : TTY=unknown ; PWD=/home/jenda ; USER=root ; COMMAND=/usr/bin/truecrypt --core-service

Co máš v /etc/sudoers?

[corwin78]

Totéž co ty, jen na konci mám ještě:

%admin ALL=(ALL) ALL

[herne the hunter]

a nejseš náhodou v grupě admin? mám takovej pocit, že v sudoers záleží i na pořadí pravidel. tj. jestli patříš do skupiny admin (viz výpis id), tak přesuň řádek "TCUSERS…" úplně nakonec.

[corwin78]

Díky, to bylo ono. Už to fachčí.

[pepazdepa]

plz neco o integraci s initrd, aby mohl byt truecrypt pouzit pri sifrovani rootfs, diky

[#Tom]

Na rozdíl od Windows, pro která je na stránkách Truecryptu ke stažení nástroj, který to dovede, to bude docela složité, protože připravené binárky TrueCryptu závisejí na věcech, které při zavádění nejsou k dispozici, zejména pak GTK+, které na rozdíl od další použité knihovny (wxWindows) není linkováno staticky.

Protože ale Truecrypt staví na dm-cryptu, není problém si připravit řešení vlastní, kde se klíč bude získávat třeba z USB disku nebo zadáním hesla a jeho zpracováním nějakou hashovací funkcí. Např. pro jednoduchý případ s AES šifrou v obyčejném režimu je potřeba 32bitový klíč. Pokud je uložený v souboru, připojení proběhne např. takto:

KEY="/cesta/ke/klíči"
DEVICE="/dev/oddíl"
NAME="cryptoroot"

HEXKEY=$(dd $KEY bs=32 count=1 2> /dev/null | \
hexdump -v -e ' 1/1 "%02x"')

echo 0 $(blockdev --getsize $DEVICE) crypt aes-plain $HEXKEY 0 $DEVICE 0 | \
dmsetup create
# v souboru /etc/fstab by pak měl být řádek pro kořenový oddíl, který bude na /dev/mapper/cryptoroot

Toto všechno by mělo proběhnout před spuštěním INITu, tj. z nějakého initramdisku.

[Mrkva]

binárky TrueCryptu závisejí na věcech, které při zavádění nejsou k dispozici, zejména pak GTK+

Tohle není tak úplně pravda - dá se zkompilovat bez GUI :)

[#Tom]

Však proto píšu, že binárky závisejí.

[tyctor]

len pre zaujimavost nieco tu

[Pavel]

Máte zkušenosti se zprovozněním TrueCryptu pod Centosem, resp. RedHatem?

 

[xkucf03]

Super, díky za článek. Sám TC sice nepoužívám (LUKS), ale už vím, komu odkaz na tenhle návod pošlu

[Jiri]

Nevite o necem, co by podorovalo vice urovni skrytych oddilu? Truecrypt dnes uz kazdy zna a muze po vas chtit druhe heslo pro desifrovani skrytych dat. Kdyby tech hesel mohl byt libovolny pocet a inicializace oddilu by byla pomoci nahodnych dat, ktera by se dala tezko rozlisit od sifrovaneho obsahu, pak by to bylo horsi. Kdysi jsem mival patch pro ext2, ktery tohle delal. Nevite o nem nebo necem podobnem?

[#Tom]

Teoreticky to jde udělat tak, že se připojí skrytý oddíl a na jeho blokovém zařízení od dm se vytvoří další vrstva.

[Bilbo]

Muze, ale treba ja osobne tuhle feature nepouzivam a myslim si ze vetsina lidi taky ne, takze predpokladat z vsichni maji druhe heslo asi zas tak nejde ... (jo, chudaci lidi co hidden volume opravdu nemaji, jak dlouho je budou mucit nez jim uveri? :)

Existuje treba system Rubberhose, kde jeden kontejner muze obsahovat libovolne mnozstvi "podkontejneru" a nelze zjistit kolik jich je - viz. http://en.wikipedia.org/wiki/Rubberhose

Ale tusim ze je to software ted uz neudrzovany.

S TC to jde asi tak, ze na hidden volume je kontejner, na nem hidden volume a tak dokola .... ale tam je pak sifrovani ve vice vrstvach a bude to asi celkem pomale.

[Jiří J.]

Ten "duální" oddíl na dvě hesla uměl minimálně jeden další program, je na tom myslím postaven celý FS (něco zapadlého na wikipedii jsem kdysi četl - "pro země třetího světa a Velkou Británii" ).

Nicméně stejně půjde asi poznat, že je tam něco víc, ať už to přes debugger na truecrypt / strace / něco podobného. Nebo prostým zašifrováním těch dat a porovnáním velikostí, pokud TC nepřidává nějaký garbage ..
Druhou věcí taky je, zda se do toho "vyšetřovatelům" bude chtít.

[Jendа]

ať už to přes debugger na truecrypt / strace / něco podobného

Předpokládá se, že když tě oni chytí, tak máš ten disk odpojený

Nebo prostým zašifrováním těch dat a porovnáním velikostí, pokud TC nepřidává nějaký garbage ..

Nešlo, TC před zašifrováním celý oddíl přepíše náhodnými daty, takže není poznat, jestli je na nealokovaných blocích FS prázdno nebo něco zašifrovaného. Dál už bych se opakoval, počkej si na druhý díl, tam jsem to popsal podrobněji.

[Jiří J.]

Předpokládá se, že když tě oni chytí, tak máš ten disk odpojený

To nebyla má pointa - když po tobě budou chtít heslo, asi tě někde nechají ho zadat / napsat. Šifrovací program je pak možné při děšifrování sledovat, jaké funkce volá, jak postupuje, takže teoreticky je možné zjistit, zda nějaký blok dat přeskočí kvůli chybnému heslu ..

V prípadě, že by skrytá část byla na 2. místě, by možná šlo z dešifrovaných metadat / zbylé zašifrované oblasti (jak TC pozná, kam skočit, když první heslo nesedí?) potvrdit její existenci.

Ale nechám se překvapit pokračováním

[Cohen]

RTFM!

[...] Even when the outer volume is mounted, it is impossible to prove whether there is a hidden volume within it or not, because free space on any TrueCrypt volume is always filled with random data when the volume is created and no part of the (dismounted) hidden volume can be distinguished from random data. Note that TrueCrypt does not modify the file system (information about free space, etc.) within the outer volume in any way. [...]

[...] TrueCrypt first attempts to decrypt the standard volume header using the entered password. If it fails, it loads the area of the volume where a hidden volume header can be stored (i.e. the bytes 65536–131071, which contain solely random data when there is no hidden volume within the volume) to RAM and attempts to decrypt it using the entered password. Note that hidden volume headers cannot be identified, as they appear to consist entirely of random data. If the header is successfully decrypted (for information on how TrueCrypt determines that it was successfully decrypted, see the section Encryption Scheme), the information about the size of the hidden volume is retrieved from the decrypted header (which is still stored in RAM), and the hidden volume is mounted (its size also determines its offset). [...]

[Jendа]

Tak mě někdo předběhne a ještě k tomu to mám ve svém příkladu opačně. Nejdřív tedy zkusí rozšifrovat "normální" hlavičku... hmm...

[Jendа]

RTFM

To místo pro druhou hlavičku je buď vyplněno náhodnými daty (když tam skrytý oddíl není), nebo šifrovanou hlavičkou skrytého oddílu. Ale ta šifrovaná hlavička se také jeví jako náhodná data.

Když mu zadáš heslo, zkusí nejdřív rozšifrovat tu druhou hlavičku, což se mu nepovede, protože

1. tam žádná není
2. je to heslo jiné

...a skočí na první hlavičku, kterou se zase pokusí rozšifrovat, a to se mu povede, protože jsi vydal heslo ke vnějšímu oddílu.

zda nějaký blok dat přeskočí kvůli chybnému heslu ..

Lze zjistit (eh, on to sám píše do logu), že se mu blok, na kterém má být hlavička skrytého oddílu, nepodařilo rozšifrovat. Ale nelze zjistit, jestli se mu ho nepodařilo rozšifrovat, protože tam žádná hlavička není, nebo protože tam je, ale heslo je špatné.

jak TC pozná, kam skočit, když první heslo nesedí?

if ($header=rozšifruj_blok(2)){
  echo "Je to heslo ke skrytému oddílu";
  rozšifruj_data(get_info_from_header($header, block_addr_start), get_info_from_header($header, block_addr_end));
} else {
  if ($header=rozšifruj_blok(1)){
    echo "Je to heslo ke vnějšímu oddílu";
    rozšifruj_data(get_info_from_header($header, block_addr_start), get_info_from_header($header, block_addr_end));
  } else {
    echo "Wrong password or not a TrueCrypt volume";
  }
}
#Dostanu cenu za nejblbější pseudokód v historii?

Snad je to pochopitelné

[Jendа]

Mám tam bug, protože $header=rozšifruj_blok() vrátí 0 i když tím do $header nacpe nějaký balast Takže by to spíš mělo být něco jako

$header=rozšifruj_blok(2)
if (validuj_hlavičku($header)){
  echo "Je to heslo ke skrytému oddílu";
  rozšifruj_data(get_info_from_header($header, block_addr_start), get_info_from_header($header, block_addr_end));
} else {
  $header=rozšifruj_blok(1)
  if (validuj_hlavičku($header)){
    echo "Je to heslo ke vnějšímu oddílu";
    rozšifruj_data(get_info_from_header($header, block_addr_start), get_info_from_header($header, block_addr_end));
  } else {
    echo "Wrong password or not a TrueCrypt volume";
  }
}

[Jiří J.]

Díky, trochu mě to trklo, když jsem si článek přečetl ještě jednou (a pozorněji). Teď jsem si ještě prošel odkazovaný manuál a jo, je to tam docela pěkně vysvětleno, ale pořád mi uniká, JAK je vlastně skrytý oddíl uložen (tedy tuším, ale uvítal bych podrobnější informace). Předpokládám ohled na filesystém vnějšího oddílu (tzn. truecrypt má vlastní driver), jeho fragmentaci, zálohy superbloku a další věci.

Další věc už je hlavička skrytého oddílu - "(i.e. the bytes 65536–131071, which contain solely random data when there is no hidden volume within the volume)" - je tím myšleno, že truecrypt si svojí implementací ext3 vynutí nevyužité místo v tomto rozsahu i na oddílech bez skryté části? Rozsah je to docela velký a v případě, že by se tam na "normálním" oddíle nacházely soubory (a tím i metadata FS, inody), je prázdné místo tak blízko začátku FS (o velikosti třeba 50GB) docela podezřelé (pokud by to bylo přesně na byte - za předpokladu, že hlavička zabírá celý tento rozsah). Ovšem předpokládám, že tam to místo rezervuje i na normálním oddíle a pokud ne, tak alespoň hlavička je náhodně položena v rozsahu, aby fragmentace vnějšího oddílu byla pravděpodobnější příčinou.

Dále by mě zajímalo, jak TC řeší pokusy o zápis do oblastí vnějšího oddílu, když je zapnutá ochrana vnitřního. Zda při zaplnění volného místa (a disk full erroru) je v "df" vidět třeba 70% used, nebo zda truecrypt (jako abstrakční I/O vrstva) překládá a modifikuje metadata vnějšího FS při čtení (za běhu), aby to vypadalo, že je disk skutečně plný ("za běhu", protože to nebude samozřejmě dělat, pokud není zapnuta ochrana). Tedy zda při zapnutí ochrany se vnější svazek tváří menší a TC interně chrání oblast skrytého oddílu nebo zda jen vrací I/O error při pokusu zapsat do skryté oblasti.

Tak jsem se alespoň snažil o náměty na příští článek

[Andrej Herceg]

Tá hlavička má vždy rovnakú veľkosť, bez ohľadu na to, či tam je, alebo nie je skrytý oddiel (ak tam nie je, tak tá časť hlavičky obsahuje náhodné údaje).

Skrytý oddiel je uložení na konci vonkajšieho oddielu. Jeho maximálna veľkosť je taká, ako veľký je tam spojitý úsek voľných dát (a teda, ten úsek nesmie byť fragmentovaný).

Pri zapnutej ochrane toho skrytého oddielu sa údaje zapisujú len do sektorov, ktoré nepatria tomu skrytému oddielu. Ak je vypnutá tá ochrana, môže sa prepísať aj ten oddiel, keďže sa nedá nijako zistiť, že tam niečo je (údaje na tom súborovom systéme nie sú nijako upravované, práve preto, aby sa ten skrytý oddiel nedal zistiť).

[Jendа]

Skrytý oddiel je uložení na konci vonkajšieho oddielu.

Nebo může být i uprostřed, prostě tam, kde je nejvíc volného spojitého místa.

[Jendа]

Jo a ještě:

Pri zapnutej ochrane toho skrytého oddielu sa údaje zapisujú len do sektorov, ktoré nepatria tomu skrytému oddielu.

Ovladač FS o tom, že tam je nějaký chráněný oddíl neví (což je dobře, protože kdyby alokoval "kolem", tak by mohly tajné služby vypočíst, jak by alokoval "normálně", a pak by se divily, proč je tam spojité volné místo) a když se do toho místa pokusí zapsat, tak TC vyhodí I/O error a filesystém se nakřápne - takže do vnějšího oddílu zapisovat jenom minimálně...

[Jiří J.]

Dobrá poznámka ohledně toho znovuvypočtení postupu FS driveru, .. takže to potvrzuje druhou verzi mé domněnky. Škoda, up-to-date obsah na dummy oddíle by byl fajn

[Jendа]

IMHO když se FATka celá smaže a pak se tam začnou kopírovat soubory, tak se to zase plní od začátku, ne?

[Jiří J.]

Nešlo mi o dynamickou velikost hlavičky vnějšího oddílu, ale statickou velikost hlavičky vnitřního, zda ji TC hledá v tom rozsahu (což je AFAIK offset od začátku vnějšího oddílu), nebo zda má přesně tu velikost, jako rozsah.

Sice mi nejde do hlavy, proč by skrytý oddíl nemohl být fragmentován (a tím snad skryt ještě více; kdybych měl třeba disk rozdělen 50:50, absence záloh superbloků v druhé polovině disku by byla docela podezřelá ..), ale taky nemám důvod nevěřit.

Zbytek tak nějak ještě pobírám.

[Bilbo]

prvch 64 kb obyc hlavicka, druhych 64 kb hlavicka skryteho oddilu (nebo nahodna data pokud neni skryty oddil) a pak teprve zacina vlastni oddil. Jinak pro skryty oddli muzi byt pouzit "vhodny" filesystem pro vnejsi oddil, coz je snad jenom FAT32. Ext2 a NTFS cpou data "doprostred" i pri prakticky prazdnem disku (ext2 zalohy superblocku, NTFS nevim presne, ale taky neco ...), cimz misto na hidden volume dosti snizuji. FAT32 je netolik primitivni, ze pokud je disk prazdny, tak data cpe "tupe" na zacatek, cimz nechava misto na konci na hidden volume.

[Jendа]

zálohy superbloku a další věci.

Je to FAT

Rozsah je to docela velký a v případě, že by se tam na "normálním" oddíle nacházely soubory (a tím i metadata FS, inody), je prázdné místo tak blízko začátku FS (o velikosti třeba 50GB) docela podezřelé (pokud by to bylo přesně na byte - za předpokladu, že hlavička zabírá celý tento rozsah).

Jak místo začátku FS? Ta hlavička má 64 kilo a když tam prostě hidden volume není, tak je vyplněna náhodnými daty. FS vnějšího oddílu začíná až potom (na 131 072. bytu).

Dále by mě zajímalo, jak TC řeší pokusy o zápis do oblastí vnějšího oddílu, když je zapnutá ochrana vnitřního. Zda při zaplnění volného místa (a disk full erroru) je v "df" vidět třeba 70% used

Ano, je vidět třeba 70% a TC vyhodí I/O error, že se člověk pokusil zapsat do oblasti vnitřního oddílu, a blok zahodí.

Tak jsem se alespoň snažil o náměty na příští článek

On to původně byl jeden dlouhý, ale radši jsem navrhl rozdělení na dva . Už je to napsaný, v případě dalších nejasností můžu napsat třetí

[Jiří J.]

Díky za odpovědi,

Je to FAT

Já uvažoval o ext3, nedošlo mi, že pro dokonalejší zamaskování je potřeba použít OS drivery pro cílové filesystémy (i tak, neříkejte mi, že všechny verze ext3 modulu mají stejné strategie alokace (2.4.x - 2.6.31)).

Jak místo začátku FS? Ta hlavička má 64 kilo a když tam prostě hidden volume není, tak je vyplněna náhodnými daty. FS vnějšího oddílu začíná až potom (na 131 072. bytu).

Takže se to místo přeskakuje i při normal oddíle, ta druhá varianta (tedy skoro, já počítal s tím, že ten rozsah je už v mezích vnějšího filesystému):

... je tím myšleno, že truecrypt si svojí implementací ext3 vynutí nevyužité místo v tomto rozsahu i na oddílech bez skryté části? Rozsah je to docela velký a v případě, že by se tam na "normálním" oddíle nacházely soubory (a tím i metadata FS, inody), je prázdné místo tak blízko začátku FS (o velikosti třeba 50GB) docela podezřelé (pokud by to bylo přesně na byte - za předpokladu, že hlavička zabírá celý tento rozsah)...

Jinak myslím, že třetí článek nebude potřeba, tedy - podle diskuze u druhého a množsví zásobních nervů autora .

[kafi]

Vcelku by me zajimalo, jak se to chova v pripade napojeni daneho sifrovaneho HDD do jineho pc. Dejme tomu dojde k nejakemu problemu na stroji, vyjmeme HD z PC a vlozime do jineho PC. Jak se bude tento sifrovany disk (oddil) tvarit. Pujde pripojit standartne nebo se musi doinstalovat potrebne balicky pro TrueCrypt?

[Jendа]

Pochopitelně se musí na ten počítač nainstalovat TrueCrypt. Kdyby to šlo připojit "standartne", tak by celé šifrování jaksi pozbylo smyslu .

[xkucf03]

Bez instalace příslušného softwaru ho jaksi nemáš čím připojit Jinak ale máš všechno, co potřebuješ – pokud znáš heslo nebo máš příslušné klíče – ty je dobré neztratit .

Ale stejně funguje i ten LUKS – není problém mít zašifrovaný USB disk a připojovat ho v různých počítačích.

[kafi]

V pripade vyuziti sifrovani na USB kliecence se to chova jak? Pokud donesu k nejakemu pc svou klicenku tak ji neprectu bez nainstalovaneho softu. A to jak pod Windows tak Linux. Coz neni dobre. Znamenalo by to nosit u sebe jeste dalsi s instalackou jakehokoliv cryptovaciho programu ve kterem bude dana fleska kodovana. neni nejake lepsi reseni?

[corwin78]

A jak by jsi to chtěl jinak řešit? Mimochodem, co ti brání mít na té flashce malou partition s instalačkou Truecryptu pro Win a Linux a možná by se našla i portable verze, ale to nevím jistě, nikdy jsem po tom nepátral.

[j]

Portable existuje, ale je treba mit admina (aspon na widlich), pak staci pustit exe a primontovat. Potiz s flash je jiny, ze pokud na ni jsou dva (a vice) oddilu, tak to widle neudejchaj (teda jak kdy, ale tak v 50% pripadu se hrube branej). Takze kompatabilnejsi cesta je jeden velkej zasifrovanej soubor (coz ovsem vyzaduje mit naformatovano na ntfs, protoze to pro zmenu nerozdejcha FAT => mit v tucnakovi prislusnou podporu pro cteni a zapis).

[Cohen]

Nosit si s sebou svůj netbook/notebook? Už kvůli tomu, že zadávat heslo a zpřístupňovat chráněná data na cizím (potenciálně útočníkem ovládaném – a to ať už s vědomím jeho majitele nebo bez něj) počítači není vůbec dobrý nápad.

Zásadnější nevýhoda než samotná nutnost instalace šifrovacího software je, že jsou k tomu třeba administrátorská práva. A ta k tomu počítači rozhodně nemusíš mít ty, ani nikdo v jeho okolí.

[Bilbo]

Nebo mit na danem USB disku proste kontejner s TC daty, ktery zaplni nejakou cast disku Vyhodou je, ze kdyz disk strcim do ciziho pocitace, do normalni nesifrovane casti mi muzou lidi cpat soubory, ale do sifrovane casti se nedostanou (muzou sice poskodit nebo smazat kontejner (no co, mam zalohy :), ale nemuzou z nej nic precist. Na mem pocitaci je to sifrovany kontejner, na cizich je to proste "velky soubor, na nej nesahejte")

[Jendа]

1) Vy chcete zadávat heslo k šifrovaným datům na cizím počítači, ještě k tomu s Windows prolezlými červy a keyloggery?

2) Portable Mode, ale nezkoušel jsem a asi to půjde jenom na Windows.

3) Pro Linux si můžete zkusit staticky slinkovat binárku, x86 pro normální lidi, amd64, pokud to plánujete připojovat u Jardíka.

[kafi]

No jde o to ze mam na flesce ulozen softwary, a dalsi veci, ktere pouzivam na diagnostiku PC u klientu. Dale dalsi sve prace a data. Uvazoval jsem o zasifrovani at v pripade straty se nikdo nedostane k temto datum. Proto ty debilni dotazy. V dane problematice sem se jeste nemel moznost poradne rozkoukat. Jelikoz pouzivam Linux ale ostatni windows potrebuju nejaky multiplatformni Crypt cimz TrueCryp zreme je. Takze dekuji za link prostuduju. Co se tyce rozdeleni flesky na vice partitions tak jsem o tom cetl ze Windows ma problem s rozpoznanim a precte jen prvni partisnu. Nemate s tim nejake zkusenosti?

[Jendа]

Ano, minimálně do XP včetně připojí jen tu 1. (vyzkoušeno). Ale TrueCrypt může klidně bydlet v souboru.

[xkucf03]

Jako multiplatformní by se dal použít ještě FreeOTFE – asopoň na prohlížení by neměl potřebovat instalaci ani práva admina.

[Jakub Lucký]

Já jsem zrovna včera večer převedl většinu svých profilů, které obsahují důležitá data pod encfs...

[Jendа]

Jo, když nepotřebuješ skrytý oddíl, tak je to dobré - už jenom proto, že encfs pracuje přímo se soubory, takže zabírá přesně tolik, kolik je v něm dat.

[Jakub Lucký]

Hlavně jsem líný šifrovat celý /home, stačí mi

.gajim .mozilla .mucommander .ssh .gnupg .mozilla-backup .notifier.conf .aaa-my-scripts .kb .mozilla-thunderbird .scrshotrc

[Radek Hladik]

Na Windows by měl TC umět používat klíč přes PKCS11 na tokenu. Předpokládám, že buď umí nebo bude umět totéž i na Linuxu, pak je bezpečnost o několik řádů vyšší. A cena samozřejmě taky...

[Radek Hladik]

Ikdyž teď jsem na to koukal podrobněji, a TC používá token jen jako storage pro key file, takže bezpečnost není o tolik větší, než by mohla být...

[Matlas]

neni o tolik vetsi? proc? jak ten keyfile prectete z tokenu bez znalosti PIN? myslim, ze oproti normalni flash je bezpecnost celkem vysoka.

tedy za predpokladu, ze po preneseni keyfile na token tento soubor na puvodnim ulozisti bezpecne znicite. :)

 

ja truecrypt s keyfile na tokenu pouzivam. chodi to celkem pekne. pouzivam to s Aladdin eTokenPro, ktery na linuxu chodi celkem spolehlive. Problem je pouze s tim, ze nektere aplikace se ke kryptotokenum /fuj to je hnusne slovo/ chovaji doslova macessky. pri generovani klicu a certifikatu nekere aplikace token inicializuji misto toho aby pouze vytvorily klic (a pripadne stary smazaly). na to je treba dat pozor, jinak by se mohlo snadno stat, ze se clovek se spoustou svych dat proste rozlouci. :)

 

protoze pro pristup k ke keysouboru je nutne zadavat PIN, pak bych rekl ( neoveroval jsem to) ze soubor je umisten v privatnim prostoru tokenu. pak myslim, ze bezpecnost je celkem obstojna. keyfile je (pokud je predpoklad spravny) ve stejne oblasti jako privatni klice. a tudiz na tokenu uz bezpecnejsi byt nemuze. :)

[Matlas]

jeste dodam, ze by jiste bylo lepsi, kdyby se keyfile na tokenu generoval jako klic primo. pak by to bylo tak rikajic epes rades:)

PKCS#11 na to funkce ma, je to tedy asi jen otazkou implementace. (ja ji delat nebudu, nejsem programator).

[Radek Hladik]

I obyčejný keyfile se používá v kombinaci s heslem. Takže nejlepší útok je právě na to heslo nebo PIN. A jakmile klíč opustí token, což po zadání PINU v případě TC udělá, tak už ho žádný PIN nechrání. Proto píšu, že bezpečnost je sice vyšší, než u flashky a spol, ale mohla by být větší, kdyby klíč token neopouštěl. Bohužel v případě symetrické kryptografie je implementace klíče na tokenu poměrně problematická. Buď musí klíč dělat nějakou podstatnou symetrickou operaci pro všechny bloky disku (například AES) nebo se klíč musí z tokenu v nějaké znovupoužitelné podobě dostat a pak je možné jej odchytit... Takže bohužel to není jen otázka implementace...

[Bilbo]

Pote co clovek zada heslo nebo nejakym jiny zpusobem (token ..) primounti zasifrovany odil, tak uz nic nebrani cervum a jine haveti na sifrovany odil cokoliv zapisovat ...

[Matlas]

asi tak.  a co teprve jmelí! :)

[j]

Mam jiste tuseni, ze sifrovani neni ochrana dat pred cervy ( i kdyz, taky se jim tak da rikat ;) ).

[Matlas]

ano. to tuseni je spravne. pokud mate pripojeny sifrovany svazek,  pak musite ochranu pristupu na nej zajistit jinak.  cokoli muze na system, muze pravdepodobne i na tento svazek (pokud mu v tom nebrani treba SELinux, nastaveni prav, nebo jiny mechanismus).

[otula]

Sice nic nového, ale velmi hezky čtivě a vtipně napsáno

[Michal]

Pokud jde jen o pripad, aby se k datum nedostal nahodny zlodej kdyz ukradne notebook, pak typicky staci jen zadat heslo k celemu disku v biosu (vlastnost novejsich harddisku). Sice to nezabrani policajtum, aby se k datum dostali, ale na druhou stranu to nepotrebuje zadnou konfiguraci a nezere to zadny CPU ani nic.

[xkucf03]

Pak ale ta data nejsou šifrovaná, ne?

[m]

ne, a imo to je mozne obejit tim, ze se na disku vymeni jeden cip a tim se zase vse odemkne ke cteni... takze data se nesifruji, jen "zamkne" cteni/zapis

[j]

Pokud vam nekdo slohne NTB kvuli datu a ne kvuli zelezu, tak mu toto nedela absolutne zadny problem. Pokud ho slohne kvuli HW, tak stejne v 99% vsechno honem smazne, aby se nezjistilo komu patril.

[Non_E]

Výkonově je na tom skoro stejně jako cryptsetup (aes šifra, stejný fs, vyprázdněná cache). Práci obstarává jeden cryptd proces

[JeanVEGA]

Asi tak pred rokom a pol som nim zaoberal. Kamos ho mal na servri a pouzival hidden partisny (tusim v 4.3). Pol roka to krasne slapalo a potom z neznameho dovodu sa partie nedali pripojit (jeden GURU to skusal analyzovat a povedal nieco v zmysle, ze sa tam TrueCrypt snazil zapisat s nespravnym klucom a tym data znicil).
Tento pripad sa stal dokonca 2x :)
Okrem toho je takmer nemoznost najst k nemu starsie verzie (jedine torrent) a vsetko, co pouziva FUSE nemusi byt idealne, ze? Gentoo asi vie preco je v masked :)

[xkucf03]

njn, s chybou softwaru nebo hardwaru (disk, řadič) je potřeba počítat vždycky – proto se zálohuje

BTW: je na to nějaký bug? Dá se tahle chyba reprodukovat?

[JeanVEGA]

No prave ten GURU to oznacil ako bug v TrueCrypte (proste cumel na nejaky balast v assebleri a prehlasil to) ... migrovalo sa vsetko na loop-aes a odvtedy to ide bez najmensieho problemu :)

[Heron]

Já teda TrueCrypt považuji za čistě desktopový nástroj určený spíše pro ochranu dat na USB diskách či HDD u noteboků (ochrana dat při krádeži). Dávat ho na server by mě ani ve snu nenapadlo, co vás k tomu vedlo a jak jste řešili zálohu dat?

[Cohen]

Starší verze TrueCryptu (po třech kliknutích z titulní stránky).

Co se týče nemožnosti přimountování, tak to se stát může. Ani software ani hardware není dokonalý. I souborový systém se může rozsypat, i kdy se všichni snaží, aby se to nestalo. Proto je nutné vždy zálohovat (a proto je dle mého vhodnější používat šifrované kontejnery místo přímého šifrovaní diskového oddílu – šifrovaný kontejner je běžný soubor, který se dá zálohovat stejně snadno jako každý jiný.

[Bilbo]

Ty starsi verze truecryptu ale obsahuji jenom binarky a jenom verzi 6.1a a 5.1a. Aneb prakticky bezcenne. Zdrojaky nikde (takze si tim nejspis porusuji vlastni licenci :)

Ale neni treba se hned hrnout na torrenty. Staci zamirit na http://cyberside.dontexist.org/truecrypt/ kde je (asi neoficialni) archiv starsich verzi truecryptu (vcetne signatur), takze staci si postahovat verze co chci a pak jen overit ze signature sedi.

[otula]

Hm, jestli se ti ale podaří 4.3a sestavit. Mně se to s jádrem 2.6.30 již nezadařilo (možné je, že na vině bylo něco jiného, co se mezitím upgradovalo), takže jsem proti své vůli přešel na aktuální verzi.