Fórum Root.cz
Hlavní témata => Software => Téma založeno: martin 24. 08. 2013, 13:50:12
-
Zdravim,
rad bych si LUKSem zasifroval disk a ze zvedavosti premyslim o nejbezpecnejsim nastaveni. Jde mi o sifru (aes, serpent, twofish,...), sifrovaci mod (ecb, cbc, lrw, xts,...), inicializacni vektor (plain, essiv:hash, benbi,...) a hash (ripemd160, sha1,...).
Cetl jsem, ze nejhorsi kombinace je ecb a plain - melo by jit o falesny pocit bezpeci.
Nikde jsem ale nenasel aktualne mozne maximalni zabezpeceni.
Jestli jsem spravne pochopil, tak nejlepsi sifrovaci mod je XTS (jadra >2.6.38, coz neni problem).
Jaka sifra? AES neni prolomena a je extremne siroce pouzivana, takze tady neni problem. Je lepsi AES-128, nebo AES-256? Na rootu jsem nasel, ze by melo byt bezpecnejsi (http://www.root.cz/zpravicky/google-zacal-automaticky-sifrovat-data-na-cloud-storage/vlakno/1/) AES-128 (Groveruv algortimus nechapu, ale to asi stejne neni moc aktualni). Kolika bitove AES LUKS umi?
Jaky inicializacni vektor? Je plain malo bezpecny (aes-xts-plain)? Nekde chvalili benbi (aes-xts-benbi), jaky je? A jake dalsi vektory se daji pouzit? Jaky hash je nejlepsi?
Co se vam zda nejbezpecnejsi?:
cryptsetup luksFormat -h sha512 -c aes-xts-plain -s 512 --verbose --verify-passphrase /dev/loop0
cryptsetup luksFormat -h sha512 -c aes-xts-plain64 -s 512 --verbose --verify-passphrase /dev/loop0
cryptsetup luksFormat -h sha512 -c aes-xts-benbi -s 512 --verbose --verify-passphrase /dev/loop0
Nebo neco uplne jineho?
Rychlost prosim nereste, pouze bezpecnost.
Diky za vase nazory :-)
-
http://xkcd.com/538/
-
aes-xts-benbi nebo aes-xts-plain64, plain ma potencialni problem na velkym disku, ze se zacne opakovat
IMHO xts nepouziva hash, takze -h bude ignorovano
Jeste misto aes muzes pouzit twofish nebo serpent
-
Jinak klic 512 v xts je nejdelsi mozny, prakticky ale sifruje polovicnim klicem, takze aes256. Jestli nejde o rychlost, tak serpent-xts-bebi -s 512
-
Chapu dobre, ze misto aes-xts-plain je lepsi aes-xts-plain64?
Kdyz XTS nepouziva hash, je horsi nez ostatni (cbc, lrw,...)?
Jestli nejde o rychlost, tak serpent-xts-bebi -s 512
V cem je serpent lepsi/bezpecnejsi ve srovnani s AES?
Co tedy doporucujete? aes-xts-benbi nebo serpent-xts-bebi?
-
Chapu dobre, ze misto aes-xts-plain je lepsi aes-xts-plain64?
ano, plain pouziva pouze 32b vektor, plain64 a benbi 64b
Kdyz XTS nepouziva hash, je horsi nez ostatni (cbc, lrw,...)?
ne, naopak lepsi
V cem je serpent lepsi/bezpecnejsi ve srovnani s AES?
Co tedy doporucujete? aes-xts-benbi nebo serpent-xts-bebi?
AES vyhral Rijndael (tedy ted aes), protoze byl rychlejsi nez druhej Serpent, ale Serpent bude bezpecnejsi, myslim i do budoucna, protoze se vsichni soustredi na AES. Prikladem je treba cold-boot attack, kde automaticky v pameti hledaji AES klice.
Z tohoto pohledu tedy neni spatny treti twofish, ten je rychlejsi nez serpent. Jestli tedy neni rychlost rozhodujici, tak serpent. Jestli je potreba rychlost tak twofish, jestli je potreba kompatabilitu (treba jadro, co nema serpent nebo twofish moduly), nebo aby se pouzily aes-ni instrukce u procesoru, co je podporuji, tak aes.
-
Prikladem je treba cold-boot attack, kde automaticky v pameti hledaji AES klice.
No tak pokud bude útočník alespoň trochu inteligentní, tak se před začátkem hledání podívá do hlavičky, zjistí, že tam není AES, ale Serpent, a bude hledat Serpent klíče ;). Jediný problém je, že na Serpent není dostupná ta hustá key-schedule optimalizace (viz aeskeyfind), takže je hledání šíleně pomalé, ale na lepším GPU by se to IMHO dalo dát přes noc (u AES to trvá minutu).
K původní otázce: na disk je bezpečné i CBC, na něj jsou útoky jenom když můžeš komunikaci real-time ovlivňovat, což u disku většinou nejde. Cokoli lepšího je plus… Šifra je spíš otázkou politického postoje (vybrala NSA AES proto, že je bezpečný a oni s ním chtějí chránit svá data, nebo proto, že je nebezpečný, chtějí poslouchat cizí data a doufají, že na to nikdo nepřijde?).
Neřešil bych to. Podle mě je mnohem pravděpodobnější, že ten počítač někdo hackne přes nějaký 0-day (díra ve FIrefoxu, je-li to desktop, díra v SSH, je-li to server, hacknutí admina, který se na ten server přes SSH přihlašuje…) nebo přes chybu uživatele/výrobce distribuce (podstrčení backdooru), pak možná i ten coldboot (dej si do case vypínač nebo zalep ramky epoxidem :) ) a pokud to někomu stojí za tvůj únos+mučení, tak prostým vymlácením hesla (tomu by mohlo pomoct mít klíč na nosiči, který se zničí).
-
...a pokud to někomu stojí za tvůj únos+mučení, tak prostým vymlácením hesla (tomu by mohlo pomoct mít klíč na nosiči, který se zničí).
Tak to je ale dost nesikovne, pokud behem muceni dojdes k zaveru, ze ti ta data za to nestoji.
-
...a pokud to někomu stojí za tvůj únos+mučení, tak prostým vymlácením hesla (tomu by mohlo pomoct mít klíč na nosiči, který se zničí).
Tak to je ale dost nesikovne, pokud behem muceni dojdes k zaveru, ze ti ta data za to nestoji.
That's a feature.
-
No tak pokud bude útočník alespoň trochu inteligentní, tak se před začátkem hledání podívá do hlavičky, zjistí, že tam není AES, ale Serpent, a bude hledat Serpent klíče ;)
Jiste, toto plati pro LUKS, bez nej jen s cryptsetup zadna hlavicka neni, coz je mi sympaticke. Na druhe strane LUKS dela slozitejsi overeni klice, coz protahuje dobu na jeho brute-force najdeni v kopii pameti.
-
Takže zjednodušme zadání: Jaké nastavení je bezpečné, aby šifru nerozlouskla Policie ČR, a to za předpokladu že se jim dokonce podaří sehnat borce který to umí s GPU a podobné skopičiny. Předpokládám že nejdůležitější bude dostatečně dlouhá passphrase, a jinak s tím nehnou. Použití exotičtější šifry by možná věc zkomplikovalo, ale proč, když dnešní CPU často mají podporu AES na hw úrovni...
-
Takže zjednodušme zadání: Jaké nastavení je bezpečné, aby šifru nerozlouskla Policie ČR, a to za předpokladu že se jim dokonce podaří sehnat borce který to umí s GPU a podobné skopičiny. Předpokládám že nejdůležitější bude dostatečně dlouhá passphrase, a jinak s tím nehnou. Použití exotičtější šifry by možná věc zkomplikovalo, ale proč, když dnešní CPU často mají podporu AES na hw úrovni...
Znova, passphrase je pro tyto účely naprostý nesmysl. http://xkcd.com/538/
-
Znova, passphrase je pro tyto účely naprostý nesmysl. http://xkcd.com/538/
PČR tě bude mlátit dokud nevydáš heslo? Nějaké zkušenosti? (neříkám tak ani tak, jen se ptám)
-
Jiste, toto plati pro LUKS, bez nej jen s cryptsetup zadna hlavicka neni, coz je mi sympaticke.
No ale furt tam ta data jsou, spoléháš jen na to, že útočník neumí použít GDB a ty jaderné struktury si vypsat :). V případě distribučního jádra/jádra se standardními parametry by to mohlo být i celkem snadné, protože si snadno sežene debug symboly.
Na druhe strane LUKS dela slozitejsi overeni klice, coz protahuje dobu na jeho brute-force najdeni v kopii pameti.
Na to bych zas tak nespoléhal, je složitější spočítat ten PBKDF nebo rozšifrovat kousek a zkontrolovat, jestli tam není nějaký FS?
Takže zjednodušme zadání: Jaké nastavení je bezpečné, aby šifru nerozlouskla Policie ČR, a to za předpokladu že se jim dokonce podaří sehnat borce který to umí s GPU a podobné skopičiny. Předpokládám že nejdůležitější bude dostatečně dlouhá passphrase, a jinak s tím nehnou. Použití exotičtější šifry by možná věc zkomplikovalo, ale proč, když dnešní CPU často mají podporu AES na hw úrovni...
Spíš než borce s GPU bych to omezil na „nesmí se jim povést cold-boot útok“. Pak je to, má-li to alespoň trochu rozumnou passfrázi (64bit+), naprosto v pohodě.
-
Tak předpokládám že onen "sprostý podezřelý" bude malá ryba typu přispěvatel na grower.cz a nebo warezák, nikoliv terorista, mafíán či politik. A u takových se "cold-boot útok" neprovádí, počítače se nahází do pytle a tím získání "důkazů" obvykle končí (a obvykle stačí). To už větší riziko hrozí při cestě do Velké Británie, tam můžete dostat pálku za neposkytnutí hesla, takže jediné rozumné řešení je TrueCrypt a "hidden partition" s dvojím heslem pro "plausible deniability".
-
No ale furt tam ta data jsou, spoléháš jen na to, že útočník neumí použít GDB a ty jaderné struktury si vypsat :). V případě distribučního jádra/jádra se standardními parametry by to mohlo být i celkem snadné, protože si snadno sežene debug symboly.
Data kde jsou? Na disku? Sifrovana data ano, ale sifra nikde ukozena neni. Muzu delat rucne cryptsetup create --cipher ... Potom rucne cryptsetup remove ... rmmod... A jak ted jen ze sifrovanyho disku zjistis, jaka sifra byla pouzita? Nezjistis...
Jeste findaeskey najde primo klic aes, ne passphrase, ta se nedrzi v pameti.
-
PČR tě bude mlátit dokud nevydáš heslo? Nějaké zkušenosti? (neříkám tak ani tak, jen se ptám)
Pokud to heslo znas, tak ho z tebe muzou vymlatit. Pokud heslo neni, no tak holt neni a maj smulu. Hod si klic na microSD a v pripade potreby ji holt rozkouses a sezeres, no... Vivat paranoia. ;D
-
To už větší riziko hrozí při cestě do Velké Británie, tam můžete dostat pálku za neposkytnutí hesla, takže jediné rozumné řešení je TrueCrypt a "hidden partition" s dvojím heslem pro "plausible deniability".
Už je hidden partition u TC použitelná? https://www.abclinuxu.cz/clanky/steganograficke-souborove-systemy-a-verohodna-popiratelnost#proc-verohodna-popiratelnost-v-truecryptu-neni-uplne-verohodna
Data kde jsou? Na disku?
Ne, v paměti, kterou jsem přes cold-boot vydumpoval, je klíč. Je jenom otázkou mojí šikovnosti, jestli ho najdu.
-
Ne, v paměti, kterou jsem přes cold-boot vydumpoval, je klíč. Je jenom otázkou mojí šikovnosti, jestli ho najdu.
no ty odpovidas na neco jinyho, slo o to, jak poznat sifru kdyz nepouzivas luks, jen cryptsetup bez luksu, kterej sifry nikam nepoznaci a ani nema zadnou hlavicku
ale kdyz dam cryptsetup remove, tak jak jsem byl naznacil, tak v pameti zadny klic nebude, tedy kdyz pockam dost dlouho dobu, tak jej neco prepise
-
PČR tě bude mlátit dokud nevydáš heslo? Nějaké zkušenosti? (neříkám tak ani tak, jen se ptám)
Pokud to heslo znas, tak ho z tebe muzou vymlatit. Pokud heslo neni, no tak holt neni a maj smulu. Hod si klic na microSD a v pripade potreby ji holt rozkouses a sezeres, no... Vivat paranoia. ;D
IMHO pokud jsi aspoň trochu psychicky odolný, tak tě PČR nezlomí. Ale když budeš mít klíč na kartě a heslo si nebudeš pamatovat, tak ji musíš použít při každém bootu → tzn. asi nebude někde úplně zašitá, budeš ji mít někde po ruce – a tam si myslím, že je dost velká šance, že ji najdou.
-
no ty odpovidas na neco jinyho, slo o to, jak poznat sifru kdyz nepouzivas luks, jen cryptsetup bez luksu, kterej sifry nikam nepoznaci a ani nema zadnou hlavicku
Odpovídám na „Prikladem je treba cold-boot attack, kde automaticky v pameti hledaji AES klice.“ Když vydumpuju paměť systému s přimountovaným svazkem, tak v paměti kromě klíčů najdu i algoritmus.
-
aha, no uz to chapu, takze utocnik zjisti, ze v dumpu pameti neni aes klic, zjisti, ze na disku neni luks hlavicka, tak bude hledat pres gdb v dumpu sifru, aby pak stejne kazdych 256 bytu pameti zkusil brute-force pouzit jako klic k teto sifre?
no asi by to slo, ale je to dost hard-core, muzu takovej dump z legrace udelat ;)
-
tak bude hledat pres gdb v dumpu sifru, aby pak stejne kazdych 256 bytu pameti zkusil brute-force pouzit jako klic k teto sifre?
No a nebo se mu přímo podaří zjistit, na které adrese v paměti je ten klíč.
Nedělej to, sám takové věci bohužel neumím.
-
tak nic, zase se nic nenaucim :-\ ;)
jinak aesfindeky prochazi celou pamet bez znalosti pozice, jen vi, jak ten klic ma vypadat