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...
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.
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 :-)
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.
ČLÁNKY DO MAILU