Názory k článku Zaostřeno na dm-crypt

Nechtel by nekdo napsat i takovy tutorial pro dm-snap? Diky.

No tak to sou strucne a jasne predlozeny fakta - takovy clanky mam rad!

Nějak se mi to nezdá - rekapitulace:
Mám data na hda2.
Vytvořím zařízení cryptl nad hda2.
Kopíruji data hda2 -> cryptl
Nemůže tím dojít k přepsání ZDROJOVÝCH dat na hda2?

Martin

No jasně. Přečtu sektor, zašifruji ho a vrátím zpátky na jeho místo. To není kopírování (zdroj->cíl), ale transformace dat. Určitě se vyplatí mít při prvních pokusech data někde zazálohovaná ;).

Jo tohle me taky zaujalo. Ono to asi fungovat bude (prectu, zasifruju, zapisu na puvodni misto), ale povazoval bych to za velice "krehkou" metodu :-)

co takhle recenzovat i http://loop-aes.sourceforge.net/ at je z ceho vybirat ;)

loop-AES se venuje dvoudilny clanek, na ktery v clanku dokonce dvakrat odkazuji;-) Mimo to je pod zminovanym clankem a v diskusi k nemu spoustu relevantnich odkazu, kde se o loop-AES doctete.

A co kdyz chci jen vytvorit sifrovany "kontejner"
a ten pak mountovat (jako pomoci loop) a pouzivat?

Da se to v uvedenem pripade take pouzit?

Mimochodem, jak je to vlastne se zpetnou kompatibilitou cryptoAPI, loop a pod.?
Mam totiz zasifrovana data z predchoziho systemu (RH7.3, jadro 2.4.20 nebo neco podobneho) a zkousel jsem na ne pristupovat ze Suse9.1 (jadro 2.6.8.1).

Algoritmus je twofish s 256 bitovym klicem a ted pri pokusu o pristup k datum pres loop dostanu hlasku ve smyslu:

IOCTL:LOOP_SET_STATUS: Nepripustny argument, request cipher or key length (256 bits) not supported by kernel.

Samozrejme, prislusny modul je zkompilovan a natazen.

Vi o tom nekdo neco?
Abychom kvuli vlastni paranoii nakonec (vubec) mohli pracovat s vlastnimi daty...


Petr

"Abychom kvuli vlastni paranoii nakonec (vubec) mohli pracovat s vlastnimi daty..."

Tim ale celou bezpecnost zkompromitujes! Spravny paranoik chape one-time pad jako skutecne one-time: pouzit pro zasifrovani a okamzite zahodit! :o)

Nevim jak je to v tomto pripade, ale obecne - i kdyz klic zadany uzivatelem (treba "heslo") i algoritmus je stale stejny (treba twofish) tak se muze znacne lisit expandovani toho hesla do vlastniho sifrovaciho klice, stejne tak pocitani inicializacnich vektoru a pod. Takze kompatibilita mezi ruznymi druhy sifrovanych disku (napr. cryptoloop vs. dm-crypt) nemusi byt zarucena.

Vzdyt to funguje _podobne_ jako loop zarizeni v tomhle smeru.
Kompatibilni to samozrejme neni.

!!!! Tak moment !!!!

Jestli se nemylim - ted jsem si to overil a rekl bych ze se skutecne nemylim - pouziva se interne linux cryptoAPI.

K cemu potom toto cryptoAPI je kdyz neda vzdy stejny vysledek pricemz vnitrnosti - cti algoritmus sifrovani - jsou stale stejne a meni se jen vnejsi rozhrani pro pristup k datum???!!!

V tomto pripade je naprosta zbytecnost a plytvani davat neco takoveho do jadra!


---------

Poznamka k memu prvnimu prispevku:
Data byla v obou pripadech (RH7.3 i Suse9.1) sifrovana pres crypto loop. Jen v nove instalaci mi system tvrdi ze uvedenou sifru (pocet bitu klice) modul nezna, takze kdysi zasifrovana data ted nemuzu precist.
Pravdepodobne bude problem mezi zidli a klavesnici ale skutecne jsem hledal na netu a nenasel odpoved. Takze muj (zduraznuji) soukromy a prozatimni zaver je ze tento zpusob sifrovani je mozna trochu diskutabilni...


Budu moc rad kdyz se budu mylit - taky po mne totiz jdou :-)


Petr

No ale vzdyt o to "vnejsi rozhrani pro pristup k datum" prece jde!

Nejen o to "vnejsi rozhrani" (cryptoloop jako takovy), ale i o losetup, jak je v clanku zmineno. Existuje nekolik navzajem nekompatibilnich patchu na util-linux. Lisi se jednak verzi cryptoapi (ted nebudu zcela presny, ale "stare" cryproapi se pozna podle /proc/crypto - ma jinou strukturu v /proc nez "nove" cryptoapi (t.j. to co je ted v kernelu)). Pak jde u losetupu i o zpusob prace s tim heslem - nektere patche berou to heslo primo jako klic, jine zase maji bug v tom, ze zada-li se binarni heslo, bere se jen do 0x00, jine patche z hesla udelaji nejprve hash a ten je pouzit jako klic. Pricemz nektere patche umi pracovat jen se "starym" cryptoapi, jine s "novym" a jine s obojim. Aby to bylo jeste komplikovanejsi, tak jsou i problemy s delkou klice - nektere patche pouziji jen 128 bitu pro klic, nektere zase vubec neumi delku klice specifikovat a syntaxe pro oznaceni algoritmu je take casto jina. Nekdy je to treba "-e blowfish-256", jindy je to "-e blowfish -k 256" apod. Samotne cryptoapi za ten zmatek nemuze, to spis ty patche na util-linux. Cteni na tato temata jsou treba http://www.dcoce.ox.ac.uk/docs/CryptoFS2Dec03.pdf nebo http://clemens.endorphin.org/Cryptoloop_Migration_Guide.html . Sam pouzivam patch na util-linux 2.12, ktery vychazi z patche co je v Debianu. Uz se tesim, az (zda) tento sileny stav nekdy skonci.

> K cemu potom toto cryptoAPI je kdyz neda vzdy
> stejny vysledek pricemz vnitrnosti - cti
> algoritmus sifrovani - jsou stale stejne a meni
> se jen vnejsi rozhrani pro pristup k datum???!!!

Problem je v nepochopeni co dela CryptoAPI. V zasade ma rozhrani typu: "zasifruj mi tenhle blok pomoci algoritmu aes-128-cbc timhle klicem a onimhle inicializacnim vektorem". Takze je to vlastne takova obdoba casti OpenSSL knihovny primo v kernelu.

No a tuhle knihovnu vyuziva nekolik ruznych kernelovych subsystemu: dm-crypt, cryptoloop, ipsec, ipv6, ...

Ze dm-crypt a cryptoloop ji pouzivaji kazdy jinak (ruzne pocitaji IV, ruzne tvori hesla z uzivatelova vstupu, ...) za to CryptoAPI *opravdu* nemuze.

Da se to pouzit s EVMS2?

Ano, EVMS2 ma toto implementovano.

Existuje v linuxu reseni, jak zasifrovat pouze jeden vybrany adresar z daneho odilu? Nechci sifrovat celou partition.

Chapu ze to vyzaduje podporu na urovni FS.

Do toho zarizeni device mapper muzete nakopirovat cokoliv, ovsem pak to z toho puvodniho mista musite bezpecne smazat. To bezpecne je tam velmi dulezite, protoze pouhym smazanim (rm, F8 v MC,...) se data z disku neodstrani a neni problem je dale pouzivat, pokud je neprepisete jinymi daty.
Ale toto reseni jste asi nemyslel:-) Muzete zkusit trebas take GnuPG ... to byl vtip;-))

mas pravdu, toto reseni jsem fakt nemyslel.
a GnuPG je to co pouzivam ted, ale neprijde mi to moc prakticky, nefunguje to transparentne

No co třeba namapovat si přes loop fajl jako šifrované blokové zařízení, udělat na něm filesystém a namountovat ho do toho adresáře? Podporu filesystému to nevyžaduje ;-)

jasne, jenze ten fajl se mi nebude dynamicky rozsirovat, podle toho kolik tam dam dat.

DD,
mám šifrovaný celý root pomocí cryptoloop a i s modulem AES optimalizovaným pro i586 je na mém Athlonu 1,4GHz výkon na hranici únosnosti (tak 5MB/sec, maximálně 10, teď přesně nevím). Zajímalo by mě, jak je to s výkonem dm-crypt. Pokud by došlo k nějakému (aspoň 20%) nárůstu, asi by stálo za to věnovat tomu čas a přejít na dm-crypt.

To by mohl být zajímavý námět na článek, pokud už něco takového neexistuje, co říkáš roote? Srovnat cryptoloop a dm-crypt co se výkonu týká (případně na různých jádrech, s různými algoritmy, apod.)

To jestli prejit na dm-crypt je obecne bez pochyb, ale vykonnost/rychlost zrejme nebude tim hlavnim a padnym duvodem.

Mno, dm-crypt, v gentoo s 2.6.8 jadrom som teraz pouzil pri kopirovani cca. 6G na prazdny disk, dosiahol som rychlosti stabilne okolo 7-10MB/s, hw je centrino 1.4, 5400 rpm disk s 2M cache, pri 600 MHz sa vytazenie procesoru pohybovalo medzi 20-50% ... takze podla mna v pohode

aaaaa sifra je 256bit AES

Vím, že AES doporučuje americká vláda. A to mi právě trošku vadí (jsem fakt paranoik). Nemůže v tom být nějaká bota? Nemají způsob, jak ji dešifrovat? Rozumějte, vše, co doporučuje americká vláda veřejnosti v ohledu bezpečného šifrování dat, je mi podezřelé - vzhledem k vývoji v této zemi. Sám používám twofish, ale nevím, zda jsem se nedostal touto volbou z deště pod okap. Není tady nějaký kryptolog, který by mi jasně a stručně napsal, tahle šifra ANO a tahle NE?

Bota v tom muze byt vzdycky - zvlaste pokud jde o US vladu;-) Nybrz AES nedoporucuje pouze US vlada (resp. prislusne instituce), ale i uznavani kryptoanalytici, takze to ocividne vypada jako nejlepsi volba. Ale mozna zijeme s falesnim pocitem bezpeci jako v pripade MD5:-)
Je nutno rici, ze zadna sifra neni nerozlustitelna - tzn. ze kazdou sifru lze _nekdy_ rozlustit. Ovsem pokud je realna doba rozlusteni rovna _trojnasobku doby uplynule od vzniku vesmiru_ ;-), tak ji muzeme povazovat za bezpecnou.

Abych umožnil mount na tuto jednotku ze svého userid (a nemusel se přihlášovat jako root) udělal jsem setuid na cryptsetup a do fstab umístil odkaz

/dev/mapper/lock6 /mnt/mrd ext3 noauto,user 0 0

To funguje bezproblémově. Ale při každém startu systému dostanu chybovou hlášku při zpracování fstab že jednotka /dev/mapper/lock6 neexistuje. Což je myslím logické. Divné na tom je to, že mám v fstab několik těchto řádků, první je výše uvedený /dev/mapper/lock6, pak mám /dev/mapper/lock7 etc. Chybová hláška se objeví jen u prvního řádku. Další už projdou bez chyb. Ta chyba sice není kritická, ale ta hláška mne rozčiluje. Nevíte někdo, jak se jí zbavit? Díky.

Jo, používám Fedora 2 s jádrem 2.6.7.

A co jeste pred prikaz cryptsetup dat neco jako tohle:

if [ -b /dev/mapper/lock6 ] ; then
/usr/local/sbin/cryptsetup.sh remove lock6
fi

Ta chyba se neobjevuje před cryptsetup, ale při startu systému v okamžiku, kdy se zpracovává fstab.

napada me jestli si pri te chybe neudela modprobe na spravny modul a u dalsich uz mu to projde...

Omlouvam se za neodbytnost a "jednodussi" nahled na svet ale v teto oblasti jsem skutecny zelenac.

Podle vyseuvedenych prispevku je tedy vysledek sifrovani silne zavisly na util-linux a podobnych vecech.

Mate mne ale to, ze cryptoAPI je primo soucasti jadra, takze kdyz mu poslu __z jakehokoliv__ rozhrani stejna data a heslo, (a samozrejme volam stejny sifrovaci modul) mel bych dostat stejny vysledek.

V pripade sifrovani oddilu jsou data na disku jen posloupnost bytu s nejakou hlavickou pro OS, aby bylo jasne ze se nejedna o nahodny shluk dat.
Ja tyto byty ctu (pravdepodobne pomoci funkci jadra pro pristup k hardware), posilam jadru k (de)sifrovani a zase pres jadro k uzivateli nebo zpet na disk.

Vzhledem k tomu ze pri pouziti ruznych rozhrani dostanu jiny vysledek, se muj hurvinkoidni pohled na vec hrouti. Co sakra jeste dela toto rozhrani nez ze slouzi jenom jako "vyhybka" pro spravne nasmerovani dat k jadru a kontrole (jadrem) vracenych hodnot volanych funkci (hash hesla atd.)?

Zasahuje primo do sifrovani???

<sci-fi>
Nestalo by zato tyto veci trosicku zjednotit, treba si sednout s Linusem k pivu, prastit do stolu a rict "je v tom zmatek, trochu to standardizujeme"?
</sci-fi>

<realita>
Jak co nejvic omezit vyskyt situaci ze se i pri pouziti stejnych rozhrani (jako napr. v mem pripade loop + cryptoAPI) po upgrade systemu / jadra nedostanu k sifrovanym datum?
</realita>

fungujici analogie:
sifrovani uzivatelskych hesel v systemu, kdy se po upgrade muzu dale beze zmen prihlasovat (meznik stinovych hesel je davno pryc)!!!

Uf, to jsem se rozepsal....

Petr

Pokud vim, cryptoapi nefixluje a je-li stejny klic, stejny algo a stejny IV, dostaneme stejny vysledek. Problemem je ten losetup, ktery z hesla (treba i v binarni forme) vyrobi klic a tento klic preda cryptoapi. Kazdy losetup totiz ten klic z hesla dela jinak - proto budes-li upgradovat, nekam si schovat losetup, nejlepe staticky slinkovany, jeste lepe samozrejme zdrojaky. Co se tyka sifrovani root partisny, nepouzivam initrd, ale "maly system" na nezasifrovane partisne, kde mam zakladni veci (/bin /sbin /dev /etc apod.), pripojim nekam budouci opravdovy root svazek, pivot_root, chroot a exec /sbin/init, takze je to vlastne podobne jako u initrd. Co se tyka prechodu na dm-crypt, tak o tom nevim vubec nic ani po precteni tohoto clanku :-). Treba mi neni jasne, jak zasifruji partisnu, kde uz mam data a nemam jinde volne misto. V cryptoloopu to jde snadno - nalosetupuju (fuj) si loop a neco jako dd if=/dev/hda1 of=/dev/loop1 bs=4096 a mam zasifrovano. Da se neco obdobneho udelat s dm-cryptem ?

Bud jsem slepej a nebo v jadre 2.6.8.1 neni target crypt pro device-mapper :(

solved :) jaxi jsem prehledl ze jsem vypnul CONFIG_EXPERIMENTAL a pak to nevidel :)

btw. proc se tu neda odpoveded na vlastni prispevek? :)