Byla vydána nová verze 1.24 programovacího jazyka Go (Wikipedie). Přehled novinek v poznámkách k vydání.
Jiří Eischmann upozorňuje, že GNOME nemá české překladatele: "Posledních minimálně 15 let byly překlady GNOME do češtiny ve výborném stavu. U každého vydání jsem jen hlásil, že je vše přeložené, poslední roky to platilo i pro drtivou většinu dokumentace. Poslední rok se to ale začalo zadrhávat. Přispěvatelé, kteří to dlouhé roky táhli, odešli a není nikdo, kdo by to po nich převzal. Proto jsme se rozhodli jít s pravdou ven: GNOME momentálně nemá české překladatele a pokud se toho neujme někdo nový, překlady začnou postupně upadat."
Otevřený zvukový bezztrátový kodek FLAC (Free Lossless Audio Codec, Wikipedie) byl vydán v nové verzi 1.5.0. Hlavní novinkou je podpora vícevláknového kódování. V prosinci loňského roku byl FLAC formálně specifikován v RFC 9639.
Evropská unie hodlá iniciovat investice do rozvoje umělé inteligence v hodnotě 200 miliard eur, v přepočtu zhruba pět bilionů korun. V projevu na summitu o umělé inteligenci v Paříži to v úterý řekla předsedkyně Evropské komise Ursula von der Leyenová. Umělá inteligence podle ní může přispět mimo jiné ke zvýšení konkurenceschopnosti.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.3 (Mastodon). Přehled novinek i s videi a se snímky obrazovky v oficiálním oznámení. Podrobný přehled v seznamu změn.
Lennart Poettering se na Mastodonu rozepsal o novince v systemd, na které pracuje: systemd bude umět nabootovat z obrazu disku staženého pomocí HTTP v rámci initrd.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2025.2. Nově lze zálohovat také na Google Drive a Microsoft OneDrive.
V kinech aktuálně běží animovaný film Kočičí odysea, v originálu Flow, (Wikipedie) vytvořený v Blenderu. Film získal řadu ocenění a má dvě nominace na Oscary 2025. Na ČSFD má 80 %. Režisérem je Gints Zilbalodis. Rozhovor s režisérem na stránkách Blenderu.
Oficiálně byla vydána (Mastodon, 𝕏) třetí RC verze GIMPu 3.0. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu. GIMP je nově k dispozici také ve formátu AppImage.
Nejnovějším projektem Blender Studia je herní projekt DogWalk. Cílem projektu je prozkoumat možnosti a vylepšit spolupráci Blenderu s herním enginem Godot a vytvořit jednoduchou hru. Jde o jejich druhý herní projekt. Prvním byla hra Yo Frankie! (projekt Apricot) postavená na již nevyvíjeném Blender Game Enginu.
Aplikace TrueCrypt je již neudržovaná (od roku 2014). Jeho nástupcem je VeraCrypt.
Pokud na Linuxu disk již šifrujete, pravděpodobně k tomu používáte dm-crypt. Ten je v mnoha distribucích přítomen již při instalaci, takže obvykle pouze stačí zaškrtnout nějaké políčko a instalátor se již o vše postará. dm-crypt má výhody a pochopitelně i nevýhody:
+ přímo v jádře (od 2.6.4) a většině distribucí
- hlavička; nemůžete tedy tvrdit, že na disku ve skutečnosti žádná šifrovaná data nemáte. Například příkaz file
si o LUKSovém oddílu myslí toto:
/dev/hda1: LUKS encrypted file, ver 1 [aes, xts-plain, sha1] UUID: ee980a84-25ae-43e1-94a3-2f60068
- absence skrytých oddílů
Podobný výčet v případě TrueCryptu:
+ zašifrovaný oddíl vypadá jako /dev/urandom
– můžete tvrdit, že jste si disk prostě přepsali náhodnými daty
+ skrytý oddíl (bude vysvětleno dále)
- od verze 5 vyžaduje FUSE
Ze stránek TrueCrypt.org si stáhneme balíček. Ve skutečnosti se stáhne soubor .tar.gz. Ten obsahuje právě jeden spustitelný soubor (takže proč jeden soubor tarují?), který po spuštění extrahuje kýžený balíček. Takovýto proces rozbalování je minimálně pozoruhodný.
Po instalaci balíčku (závisí na fuse-utils, dmsetup, libsm6 a libgtk2) by mělo stačit spustit příkaz truecrypt
, čímž se dostaneme do grafického rozhraní.
TrueCrypt potřebuje pro připojování oddílů práva roota. Vlastně si pod rootem spustí démonka (na Linuxu /usr/bin/truecrypt --core-service
), který se mu o to stará. Protože jistě chceme používat TrueCrypt i pod běžným uživatelem, doporučuji instalaci sudo a následné přidání několika řádků do /etc/sudoers
(připomínám, že soubor upravujeme programem visudo
):
User_Alias TCUSERS = jenda, pepa, lojza Cmnd_Alias TC = /usr/bin/truecrypt TCUSERS ALL= PASSWD : TC
Pokud nahradíme PASSWD
za NOPASSWD
, nebude TrueCrypt vyžadovat při připojování oddílů heslo. Nechávám na zvážení každému paranoikovi, zda to tak opravdu chce.
V grafickém rozhraní programu jde všechno celkem jednoduše naklikat, takže jen ve stručnosti.
Uživatelé holdující terminálu nechť si všimnou, že TrueCrypt se v textovém módu spouští truecrypt -t [přepínače] akce [mountpoint]
. Seznam akcí se zobrazí po spuštění TrueCryptu s přepínači -t
a -h
. Nás asi budou zajímat především akce --create
a --mount
; z jejichž názvu je zřejmé, co udělají. Po spuštění se i v textovém módu objeví průvodce, který se bude postupně ptát.
Hotový svazek připojíme tak, že v hlavním okně vybereme šifrovaný soubor a klikneme na Mount. V textovém režimu truecrypt -t --mount
, nedoporučuji zadávat jméno souboru přímo na příkazové řádce, protože se zaznamená do historie shellu. Připojovací okno v grafickém rozhraní si zaslouží trochu pozornosti.
Heslo. Přiznávám, že na obrázku je jeho délka přehnaná.
Zobrazí heslo při psaní. Hodí se, pokud máte heslo tak dlouhé, že ho nenapíšete bez překlepů. Jo a dejte si pozor na toho člověka, co vám vždycky kouká přes rameno!
Při vytváření oddílu jste si mohli vybrat, zda ho chcete chránit heslem, nebo nějakým souborem. Klíčem k odšifrování dat tak může být buď vaše hlava, nebo USB flash disk. Tajné služby jsou ve čtení dat z flash disku trochu dále než ve čtení myšlenek, ale zase v případě flash disku lze klíč průkazně, nezvratně a rychle zničit.
Připojí oddíl pouze pro čtení. Ať už ho máte na CDčku, nebo jste byli právě propuštěni z vyšetřovací vazby a nechcete dát vyšetřovatelům důkaz o existenci skrytého oddílu, použijte to.
Pokud máte skrytý oddíl a chcete zapisovat do vnějšího oddílu, rozhodně zaškrtněte a zadejte heslo ke skrytému oddílu. TrueCrypt zabrání přepisu skrytého oddílu.
V oddíle může být libovolný souborový systém. Pokud si chcete hrát na úrovni FS, zaškrtněte. V /dev/mapper/
se vytvoří normální blokové zařízení, které můžete podle libosti formátovat či fsckovat, pochopitelně se všechna data šifrují.
Kam chcete oddíl připojit. Standardně se připojuje do /media/truecrypt1
až truecrypt32
.
Jak už jsem řekl, výsledkem šifrování je náhodný balast a nikdo nemůže prokázat, jestli jsou ta data náhodná, nebo je to něco strašně tajného zašifrovaného. Některé méně civilizované národy ovšem provozují takzvané internační tábory, kde vás ubytují a budou se tázat, jestli nejste divní, když máte na disku 20 GB náhodných dat a šifrovací program. V dokumentaci TrueCryptu je to napsáno, pravda, trochu méně eufemisticky.
There are many situations where you cannot refuse to reveal the password (for example, due to extortion).
Je mnoho situací, kdy prostě nemůžete vydání hesla odmítnout (například kvůli násilnému vymáhání).
Řešení se jmenuje skrytý svazek (hidden volume). Vytvoříte si oddíl, kde budou vaše běžná data (ten se nazývá outer, vnější), a potom se ve volném místě tohoto oddílu vytvoří ještě jeden oddíl, kde bude ta vaše turistická mapka Pentagonu (ten se nazývá inner nebo hidden, vnitřní nebo skrytý). Při připojování oddílu zkusí TrueCrypt nejdřív rozšifrovat skrytý oddíl a když se mu to nepovede (buď tam prostě není, nebo je to heslo špatné), pokusí se tím heslem rozšifrovat vnější [outer] oddíl. Svým hostitelům dáte heslo k oddílu vnějšímu, oni se spokojeně proberou vašimi běžnými daty a pak vás pustí (možná). V klidu domova zadáváte heslo k oddílu skrytému.
Opět nám pomůže klikací průvodce. V kroku druhém si vybereme, že budeme vytvářet oddíl skrytý. Nejdřív se vytvoří oddíl vnější, pak nás průvodce vyzve, abychom si do něj nakopírovali nějaká méně tajná data, a potom se vytvoří oddíl skrytý.
V dokončení povídání o Truecrypt podrobněji rozebereme fungování skrytých oddílů a podíváme se na nástroj, který je údajně umí odhalit. Kromě toho ještě zmíním, jaký dopad má používání Truecrypt na výkon.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Imho maximalne tak kamaradovi, manzelce.... jinak to poznat pujde
Zajímalo by mě, jakým způsobem to půjde poznat?
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ý).
CryptoghraphyBez toho h, samozřejmě.
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 amatuje si ho za mě totiž nešifrovaný soubor ~/Notes/passwords.txtDoufám, že jsi nezapomněl na jeho zálohování na nástěnku.
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.
# /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: ALLOhlásí to alespoň do
/var/log/auth.log
nějakou chybu?
ve /var/log/auth.log je:
1 incorrect password attempt; TTY=unknown; PWD=/home/michal; USER=root; COMMAND=/usr/bin/truecrypt --core-services
Aug 6 12:28:25 paranoid sudo: jenda : TTY=unknown ; PWD=/home/jenda ; USER=root ; COMMAND=/usr/bin/truecrypt --core-serviceCo máš v /etc/sudoers?
Totéž co ty, jen na konci mám ještě:
%admin ALL=(ALL) ALL
plz neco o integraci s initrd, aby mohl byt truecrypt pouzit pri sifrovani rootfs, diky
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/cryptorootToto všechno by mělo proběhnout před spuštěním INITu, tj. z nějakého initramdisku.
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 :)
len pre zaujimavost nieco tu
Máte zkušenosti se zprovozněním TrueCryptu pod Centosem, resp. RedHatem?
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
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?
dm
se vytvoří další vrstva.
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.
ať už to přes debugger na truecrypt / strace / něco podobnéhoPř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.
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
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). [...]
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é
$header=rozšifruj_blok()
vrátí 0 i když tím do $header nacpe nějaký balast $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"; } }
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
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.
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
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
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.
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% usedAno, 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ánekOn to původně byl jeden dlouhý, ale radši jsem navrhl rozdělení na dva
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 .
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.
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.
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í.
Jako multiplatformní by se dal použít ještě FreeOTFE – asopoň na prohlížení by neměl potřebovat instalaci ani práva admina.
.gajim .mozilla .mucommander .ssh .gnupg .mozilla-backup .notifier.conf
.aaa-my-scripts .kb .mozilla-thunderbird .scrshotrc
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...
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...
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. :)
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).
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...
asi tak. a co teprve jmelí! :)
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).
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.
Pak ale ta data nejsou šifrovaná, ne?
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
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?
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ý.