..

13.6.2005 09:50 | poslední úprava: 17.2.2015 19:46

..        

Komentáře

[Ritchie]

Návod, jak zprovoznit dm-crypt, je odkazován v jiné diskuzi.

[Jaris]

dakujem, prestudujem

[azurIt]

"cim vacsie a komplikovaniejsie heslo, tym lepsie"

toto nie je celkom pravda. vybranie spravneho hesla nie je az tak jednoduche :) praveze nesmie byt prilis dlhe ani prilis zlozite (tazko sa pameta - pouzivatel je nuteny si heslo niekam zapisat) a zase naopak nesmie byt ani prilis kratke ani prilis jednoduche. cize najlepsia je stredna cesta ;) (ako takmer vsade)

[Mikos]

Na zprovoznění dm-cryptu opravdu nic není, stačí si přečíst dokumentaci na webu a prostudovat nějaký ten příklad. Zvládl sem to tak v pohodě i já, tak by to snad opravdu problém být neměl Pokud to chcete vyzkoušet jen nad souborem (který připojíte přes loop), tak můžete postupovat třeba takto:

# pro zacatek hromada promennych secure_filesize=100 secure_file="~/secure/securedisk01.img" secure_key="~/secure/securedisk01.key.gpg"

secure_loop="/dev/loop0" secure_dm="securedisk01" secure_mountpoint="~/secure/securedisk01"

secure_keysize=256 secure_hash="sha256" secure_cipher="aes-cbc-essiv:sha256"

# vygenerovani klice a jeho zasifrovani pomoci GPG head -c 2880 /dev/urandom | uuencode -m - | head -n 65 | tail -n 64 | gpg -c --cipher-algo AES256 > ${secure_key}

# vytvoreni souboru, ktery budu mountovat dd if=/dev/urandom of=${secure_file} bs=1M count=${secure_filesize}

# nahozeni loop nad vytvorenym souborem losetup ${secure_loop} ${secure_file}

# nahozeni sifrovaneho zarizeni nad loopem gpg -q --cipher-algo AES256 --decrypt ${secure_key} | cryptsetup -v -h ${secure_hash} --key-size=${secure_keysize} --cipher=${secure_c ipher} create ${secure_dm} ${secure_loop}

# vytvoreni filesystemu na sifrovanem zarizeni mke2fs -j -m0 /dev/mapper/${secure_dm}

# primountovani sifrovaneho zarizeni mount -t ext3 -o noatime /dev/mapper/${secure_dm} ${secure_mountpoint}

[Mikos]

Jinak bych jeste doplnil, ze cryptoloop uz je (pokud vim) deprecated a ma co se bezpecnosti tyce sve problemy. dm-crypt je mnohem lepsi a nahrazuje jej. A spolu s sifrovanim aes-cbc-essiv:sha256 (ktere bylo pridano tusim v kernelu 2.6.10 a je imunni vuci watermark utoku) uz z meho pohledu neexistuje jediny duvod, proc pouzivat neco jineho (treba loop-aes nebo to co ste objevil vy).

[Mikos]

Ouuu, koukam ze tag <code> se nechova tak jak jsem cekal Tak jeste jednou ten postup vytvoreni kryptovaneho souboru a jeho primountovani, tentokrat s pouzitim tagu <pre>

# pro zacatek hromada promennych 
secure_filesize=100
secure_file="~/secure/securedisk01.img"
secure_key="~/secure/securedisk01.key.gpg"
secure_loop="/dev/loop0"
secure_dm="securedisk01"
secure_mountpoint="~/secure/securedisk01"
secure_keysize=256
secure_hash="sha256"
secure_cipher="aes-cbc-essiv:sha256"

# vygenerovani klice a jeho zasifrovani pomoci GPG
head -c 2880 /dev/urandom | uuencode -m - | head -n 65 | tail -n 64 | gpg -c --cipher-algo AES256 > ${secure_key}

# vytvoreni souboru, ktery budu mountovat
dd if=/dev/urandom of=${secure_file} bs=1M count=${secure_filesize}

# nahozeni loop nad vytvorenym souborem
losetup ${secure_loop} ${secure_file}

# nahozeni sifrovaneho zarizeni nad loopem
gpg -q --cipher-algo AES256 --decrypt ${secure_key} | cryptsetup -v -h ${secure_hash} --key-size=${secure_keysize} --cipher=${secure_cipher} create ${secure_dm} ${secure_loop}

# vytvoreni filesystemu na sifrovanem zarizeni
mke2fs -j -m0 /dev/mapper/${secure_dm}

# primountovani sifrovaneho zarizeni
mount -t ext3 -o noatime /dev/mapper/${secure_dm} ${secure_mountpoint}

[Ritchie]

Jistě se nebudete zlobit, když váš postup podrobím kritice.

Způsob generování klíče je docela šílenost. Proč používáte pro získávání dat pseudonáhodné (urandom) namísto náhodného (random) zařízení?

Protože používáte na klíč 256b hash, mělo by teoreticky stačit 32 B zcela náhodných dat. Jako paranoik jich vezmu pro jistotu 64 B.

dd if=/dev/random bs=1 count=64 | gpg...

Není mně jasné, proč zadáváte key-size, když klíč negenerujete z nekonečného zařízení. Parametr key-size slouží, když se např. klíč čte z /dev/random pro šifrování swapu.

BTW Osobně používám na hashování hesla raději SHA512.

[Mikos]

Vaší kritiku beru, díky za ní. Já nejsem žádný odborník přes kryptologii a tenhle skript sem si vytvořil jen po přečtení webové dokumentace k dm-crypt a ještě nějakého příkladu. Toho že by mělo stačit teoreticky 32B když použiji hash sha256 jsem si vědom, nicméně použitím delšího přece člověk nic nezkazí Key-size sem zadával jen pro jistotu, abych na to nezapomínal v případě že bych někdy v budoucnu zvolil klíč jiné délky, který by byl třeba delší (zatím sem si s tím jenom hrál).

Co se týče /dev/random a /dev/urandom, tak tam jsem nikdy přesně netušil jak to s tím je. Věděl sem jen že /dev/random by mělo produkovat zcela náhodná data (narozdíl od pseudo-náhodných u /dev/urandom), ale jejich vygenerování mi přišlo že trvá moc dlouho (holt asi než se "nahromadí" dostatek entropie... ježiš fuj, to je ale hnusně a blbě formulovaný, ale teď mě nenapadá jak to formulovat lépe ) a jelikož jsem si s tím jen hrál, použil sem /dev/urandom.

[Mikos]

Btw. už si vzpomínám proč sem použil ten postup s vygenerováním mnohem dalšího klíče a aplikováním uuencode - chtěl jsem aby ten klíč neobsahoval žádné "paznaky".

[Ritchie]

64 B se přečte z /dev/random natotata a víc bytů skutečně není třeba. Hlavně jsem se pozastavoval nad tím složitým příkazem pro generování zašifrovaného klíče, když stačí dd a gpg.

Přeci nevadí, že jsou klíčem binární data. Pokud jej potřebujete uchovat v čitelné formě, tak jej můžete do ASCII jednoduše převést třeba pomocí uuencode či algoritmem base64 apod. Pokud přímo trváte na ASCII klíči, tak jednoduše vložte mezi dd a gpg příkaz pro překódování do ASCII.

Key-size má smysluplné použití skutečně jen tehdy, čte-li se klíč z nekonečného zařízení, aby se čtení někdy skončilo. Key-size omezuje velikost vstupu, který se bude hashovat. Vlastní šifrovací klíč pro algoritmus AES je pak výstup hashe, a je tudíž vždy tolikabitový, kolikabitová je použitá hash.

O entropii mi nehovořte, čeká na mě zkouška ze statistické termodynamiky.

[Mikos]

Jinak jeste jednou veci sem si nebyl jisty kdyz sem ten postup vymyslel - chtel sem za kazdou cenu pouzit GPG (symetrickou sifru), ale nevim zda je lepsi defaultni CAST5 nebo AES256 (kterou jsem nakonec zvolil). Zkousel sem ohledne porovnani techto dvou sifrovacich algoritmu najit nejake materialy, ale moc se nezadarilo... Nevite jak na tom ty sifry jsou? Pripadne srovnani jeste s nejakou jinou na podobne urovni, kterou GPG nabizi?

[Ritchie]

Ani já v kryptografii moc zběhlý nejsem. Do matematické podstaty hashí a šifer vážně nevidím, takže vám bohužel nemohu poradit.