Fórum Root.cz
Hlavní témata => Software => Téma založeno: Jakub Váňa 07. 05. 2014, 22:52:37
-
Pekny den preju,
nevite nekdo prosim v cem by mohl byt zakopany pes - mam disk kryptovany
cryptsetup create Nazev /dev/device v CentOS 6.0 - zadat heslo - a vse funguje
pokud se pokusim stejnym zpusobem disk rozsifrovat v CentOS 6.5, tak mi rozsifruje nesmysly - dany filesystem vubec nerozpozna
Nejaky tip ?
-
Možná, že googlu pokládám špatný dotazy ale zatím jsem nenarazil na nic relevantního ....
Zakompilované konstanty se zdají být stejné, stejně jako verze cryptsetupu i dm-cryptu ...
-
Já používám Luks, čímž se vše dost zjednodušuje. A pokud člověk nechce nechávat luks hlavičku na disku, může si ji umístit třeba na flashku. Jinak s CentOSem jsem skončil právě kvůli cryptsetupu, který se rychle vyvíjí, a CentOS je sto let za opicema...
-
Jak uz radili, pouzij radeji misto create luksFormat
Jinak pouzivas starej format bez hlavicky a bez specifikace jakej mod, sifru a delku klice. Tim padem se pro create i open pouziji nejake defaultni hodnoty a ty se budou asi lisit. Takze bez luksu, kdyz bys ho nechtel z nejakyho duvodu pouzit, tak specifikuj vzdy presne sifru a bude. Treba:
cryptsetup create -s512 -c twofish-xts-plain64 /dev/xxx sifrovany
cryptsetup open -s512 -c twofish-xts-plain64 /dev/xxx sifrovany
Luks si vse ulozi v hlavicce, takze luksOpen nepotrebuje sifru ani nic dalsiho znat.
-
A jestli teda uz mas vytvoreny neco, co se v 6.0 jeste stale otevre a chces zjistit, jak to otevrit v 6.5, tak sifru v 6.0 pri otevrenym "sifrovany" zjistis takto:
cryptsetup status sifrovany
A to pak pouzijes v 6.5 pri otvirani
-
Děkuju pánové za reakci.
V Centosu 6 ce teda bohužel zřejmě kernel neexportuje informace o použitém kódování, ale nakonec jsem našel zmínku na nějakém fóru fedory, že se nedávno měnilo defaultní kódování z aes-cbc-plain na aes-cbc-essiv:256.
http://fossdev.blogspot.cz/2010/06/new-default-ciphering-algorithm-for.html
Jak jsem psal - cryptsetup --help na obou systémech píše jako default aes-cbc-essiv:256, což bohužel na 6 - ce není pravda a proto jsem se do věci zamotal.
cryptsetup create -s256 -c aes-cbc-plain:sha256 -h ripemd160 Sifrovany /dev/device
Toto je asi zbytecne upovidana verze, ale snad funkci všude ...
-
stejne bych se nespolehal na default, takze bych to radsi vzdy vypisoval uplne; da se to dat nekde do /etc/crypttab, zalezi na distribuci
treba kdyz budes potrebovat zachranit data z livecd, tam muze byt default uplne jinej
jen dve poznamky: proc nepouzijes luks? pamatuje si sifru, muze mit vic klicu bud s heslem nebo s tokenem a jeste "zlepsi" heslo pres pbkdf2, cimz zneprijemni brute-force
a druha, proc nepouzijes misto cbc xts? je novejsi a odolny treba proti watermark-attack
-
Tak důvod proč nepoužívám luks a xts je proto, že je neznám. Před nějakou dobou jsem se naučil používat nějaký způsob a doposud jsem s ním neměl problém - nehledal jsem tedy lepší řešení.
Ale po této zkušenosti si o tom něco zjistím. Nicnéně disk, který byl takto kryptován už nesl nějaká data a já to hlavně potřeboval rychle vyřešit.
Na disk jsem si přidal malou partitionu, která nese soubor mount.sh, kde jsem pro případ zapomenutí argumentů argumenty uvedl. Tak snad je to pro moje účely dostatečné.
Nemám důvod očekávat nějaký systematický útok - spíš jde o to, aby se k datům nedostal nějaký blb, který disk náhodou ukradne.
-
Vyhrabal jsem z poznamek svoje stare prikazy, je to jednoduche:
# dd if=/dev/urandom of=/tmp/data.img bs=1M count=1024
# losetup `losetup -f` /tmp/data.img
# losetup -a
# cryptsetup luksFormat -h sha512 -c aes-xts-benbi -s 512 --verbose --verify-passphrase /dev/loop0
# cryptsetup luksOpen /dev/loop0 sifrovano
# mkfs.ext3 /dev/mapper/sifrovano
# umount /dev/mapper/sifrovano
# cryptsetup luksClose sifrovano
# losetup -d /dev/loop0
# losetup `losetup -f` /tmp/data.img
# cryptsetup luksOpen /dev/loop0 sifrovano
# mount -t ext3 /dev/mapper/sifrovano /tmp/sifrovanoMNT
...
# umount /dev/mapper/sifrovano
# cryptsetup luksClose sifrovano
# losetup -d /dev/loop0
-
Pokud sifrujes víc než 2TB s xts tak hlavně HMAC plain64 a ne jen plain. Pokud si to dobře pamatuji.
-
jo, anebo benbi, jen ne plain
-
Co je na plain špatného ?
-
von se plain na velkym oddile (>2TB) zacne opakovat, kvuliva 32b int, takze 64b int je lepsi
-
JJ, takže teoreticky bezpečnostní díra, ale data to nezničí ? ....
-
Ono je to napsane i ve FAQ
https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_with_Specific_Versions_of_cryptsetup (https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_with_Specific_Versions_of_cryptsetup)
Totez pro IV plain/plain64 (odstavec 5.15, a ano, je to jen o tom, ze plain je z historickych duvodu 32bitovy a po 2TB se zacne opakovat).
BTW "-c aes-cbc-plain:sha256" nedava smysl, to :sha256 je tam zbytecne (kernel dm-crypt to vyignoruje).
Pro plain mod (cryptsetup create) se hash zadava pomoci -h.