ENCFS - lze doporucit? mozna uskali? (diskuse)

[Petr]

me by vadila nevyhoda ze pri zmene adresare s milionem souboru je nutne reenkryptovat vsechny soubory znova, takze performance pujde dolu, nebo nutnost mit milion souboru na disku misto jednoho disku celeho sifrovaneho. Spousta vyhod, ale z pohledu bezpecnosti je to asi ne uplne idealni.

[chochi]

Znal jsem lidi co to pouzivaly a celkem to i fungovalo.
Jedine na co si stezovaly byla performance - jakakoli prace s mnoha soubory (napr. vyvoj ve velkem gitovem repu) byla tragciky pomala (tudiz pak vsichni presly na LUKS / dm-crypt).
Tady samozrejme zavisi na co to pouzijes - pokud budes sifravat radove stovky souboru, tak to asi znat nebude.

[KS]

Spíše bych se držel dm-cryptu, připojit zašifrovaný blok není o mnoho složitější:

cryptsetup luksOpen encpart encpart_decrypted
mount /dev/mapper/encpart_decrypted /mnt/encpart/ 

Kompletní vytvoření šifrovaného souborového systému v souboru encpart:

fallocate -l 100M encpart
cryptsetup luksFormat encpart
cryptsetup luksOpen encpart encpart_decrypted
mkfs.ext4 /dev/mapper/encpart_decrypted
mkdir /mnt/encpart
mount /dev/mapper/encpart_decrypted /mnt/encpart/ 

Viz man cryptsetup, apt install cryptsetup-luks.

[Adolf Kernel]

A ked prestane 100M stacit ? Nanovo vytvarat novy subor a presuvat subory ?

[ehm]

LOL.

[Kkt1]

Muzes sifrovat cely disk.. pokud potrebujes sifrovat 100mb dat tak pouzij encfs. Pokud potrebujes sifrovat 500gb ve 20tis fotkach tak encfs bude mit problem s performance. Omezeni jednotlivych pristupu jsou dana a je na tobe zvolit si to co ti vyhovuje. Treba se 100mb zacnes s encfs a pak zjistis ze chces toho vice a prejdes k sifrovani disku. V dnesni dobr nevidim duvod proc bych nemel sifrovat disk.

[Jendа]

cryptsetup resize

[KS]

Dobrá otázka.

Budu se držet příkladu, ve kterém šifrujeme soubor vytvořený fallocate. Sice píšu z Raspberry Pi se 128 GB μSD kartou, můžu ale klidně na této kartě vytvořit 1 TB soubor:

$ fallocate -o 1T -l 1 encpart

Opravdu mám 1 TB soubor:

$ ls -lh encpart
-rw-r--r-- 1 root root 1.1T Feb 19 22:38 encpart

Ve skutečnosti ale zabírá jen 4 KB:

$ du -h encpart
4.0K    encpart

Zašifruji jej a vidím, že už zabírá 136 KB:

$ cryptsetup luksFormat encpart
$ du -h encpart
136K    encpart

Připojím šifrovaný blok s --allow-discards a vytvořím souborový systém:

$ cryptsetup luksOpen encpart encpart_decrypted --allow-discards 
$ mkfs.ext4 /dev/mapper/encpart_decrypted

Soubor teď má 1.1 GB:

$ du -h encpart
1.1G    encpart

Přimontuji s -o discard a zkopíruji dovnitř 1.8 GB soubor, takže sbour encpart bude mít 3 GB:

$ mount /dev/mapper/encpart_decrypted /mnt/encpart/
$ cp MVI_3100.MP4 /mnt/enc_part/
$ du -h encpart
3.0G    encpart

Odstraním soubor MVI_3073.MP4 a vidím, že encpart má zpět téměř původní velikost:

$ rm /mnt/enc_part/MVI_3073.MP4
$ du -h encpart
1.3G    encpart

[Josef Kufner]

To je hezké a velice praktické.

Zkoušel jsi, co filesystém na to, když se nepovede zapsat kvůli nedostatku místa na disku pod šifrovaným obrazem? V tvém případě při pokusu o zápis souborů o celkové velikosti lehce nad 126 GB.

[KS]

Dojde k chybě zápisu na úrovni zařízení pod tím filesystémem, protože pro filesystém to je úplné 1TB zařízení, a je na implementaci filesystému, jak se k tomu postaví. Může to být třeba kernel panic. Ext4 se ve výchozím nastavení remountne jako read only.

[Milan Uhrák]

Zdravím .. Chápu, že tato diskuze je již off, ale ten tvůj návod je super. Vyzkoušel jsem si ho a funguje pěkně.

Až na jednu maličkost.

Pod rootem jsem připojil (sshfs) oddíl na serveru. Vzdáleně ten soubor vytvořit nešel, tak jsem se na server lognul ssh a vytvořil jsem ho "lokálně".

Skrze sshfs jsem ho pak naformátoval, připojil, vytvořil FS (ext4), a ten taky připojil. Soubor měl nějakých 130MB

Zkopíroval jsem tam náhodně jednu složku asi 2,7GB. Chvilku jsem počkal, a po nakopírování jsem mrknul na soubor .. 3,6GB .. hm .. režie, říkal jsem si.

Smáznul jsem v obraze 800MB složku, což byl docela frmol - kouknu na soubor: 3,9GB. Ehm .. tak počkám, možná se soubor nesmrskne hned ...

Opakovaně pouštím "du zaloha.luks" a začínám nervóznět. 4,0GB ... 4,1GB .. šidítko na ploše ukazuje stálý tok 1MB/s směr server ...

Vyskakuju mc z mountnutého obrazu a dávám umount ... Tok dat utichá, "du" již růst neukazuje.

Co bylo špatně ? Proč mi ten luks-obraz pořád rostl ?

Díky za vysvětlení

[KS]

To je tím, že sshfs neumí pracovat se sparse soubory. Tam, kde jsou ve sparse souboru díry, se pošlou nuly.

Ani všechny "lokální" souborové systémy neumí sparse soubory. Nejjednodušším příkladem budiž FAT.

Ještě k těm parametrům cryptsetup luksOpen --allow-discards a mount -o discard, ty jsou dnes důležité u SSD disků, aby se zařízaní reportovaly bloky, které nejsou využívané.

[Roman]

There is a security audit report available on https://defuse.ca/audits/encfs.htm which identifies some security issues in encfs. Many of them affect the retrieval of encrypted data from unsafe storage which could have been manipulated by an attacker and have some impact on data retrieval or on future encryption operation, like adding zero bytes blocks inside of real data, or disabling MACs via configuration file (lowering the encryption complexity for subsequently added data). Some attacks affect the encryption mechanism (potential timing analysis of MACs, stream cipher is used to encrypt the last file block while generating block IV by XORing the block number).

[jmk]

Také používám ENCFS dlouhá léta a musím říci, že asi to není úplně neprůstřelnější kryptovací sowt, ale taky si nemyslím, že ho louskne, každý amatér ala profík. Zejména, když opravdu .xml soubor s hashem hesla mám jinde než u zakryptovaných dat a použiji trochu slušné heslo, anebo kryptování pomocí obrázku (místo hesla - což ENCFS také umožňuje).

Navíc pokud budu chtít používat i na desktopu tak to má docela pěkné/funkční grafické nadstavby pro BFU.

Za mně můžu určitě doporučit. Co se týče případného performance tak nemám zkušenosti se 100k souborů, ale přešel jsem právě z Truecryptu na ENCFS, protože si šifrované files rovnou syncuji na NAS, což je strašně pohodlné. Moje počty souborů se pohybují okolo 10k a mám tím třeba zašifrované úložiště TB - takže stále nějaký zápis/čtení a na desktopu s tímto nejsou naprosto žádné performance problémy.

[Sten]

Bezpečnostní problém s encfs není ani tak v samotném šifrování, to je silné dost, ale v side channelech, zkus se třeba podívat, kolik toho ze svého šifrovaného adresáře najdeš nešifrované ve /var/tmp jako různé náhledy a pracovní kopie.

[Fero]

Úskalia: [1] [2]

[otasomil]

Zdravim
Ten skript vyzaduje wordlist. Bez pravdepodobneho hesla ve wordlistu si neporadi? Asi by mohlo stacit presunout soubor .encfs6.xml nachazejici se v adresari se zasifrovanyma datama ktery obsahuje hash hesta. Potom by to melo byt neprustrelne.

[Fero]

Dnes su dostupne niekolko gigabajtove sk/cs/en pouzitelne slovniky... nevidim problem :)

[Petr]

Treba u me bys s tim nepochodil...

[otasomil]

Cili opravdu skript umi pouze zkouset hesla ze slovniku.
No pri hesle viz treba FQ47-4Mhf_E452 nepredpokladam uspesnou akci.

[janci]

používam na zašifrovanie textových súborov v ktorých mám heslá. funguje to tak ako má ...

[Jendа]

Jak bys poznal, kdyby to nefungovalo, jak má?

[Petr]

Urcite by to poznal, ma preci zdrojaky, ktere si precetl, zkompiloval to samozrejme z tech zdrojaku a pocitac ma zasadne v uzamcenem trezoru, v uzamcene a hlidane mistnosti 5ti policajty, samozrejme se s nim nikam nepripoji...

[Bystroushaak]

Lehce mimo téma, ale přijde mi to jako zajímavý počin: “Finite Field Arithmetic.” Chapter 1: Genesis.

Autor se v podstatě rozhodl, že moderní sw pro šifrování je shit a tak začal psát jednoduše pochopitelný seriál na téma "programujeme vlastní šifrovací knihovnu" v subsetu ADA-y, kde by měli čtenáři stíhat sledovat co a proč a ověřovat si korektnost. Nevypadá to naivně a autor podle všeho ví co dělá na kryptografické úrovni.

Cíle:

• Written in a heavily-restricted subset of the Ada programming language — the only currently-existing nonproprietary statically-compiled language which permits fully bounds-checked, pointerolade-free code and practically-auditable binaries. We will be using GNAT, which relies on the GCC backend.
• No external dependencies or libraries are made use of; suitable for embedded systems with limited memory. Language features which bloat the generated binary (e.g. OOP) are avoided.
• No use of heap allocators. (In fact, wholly allocator-agnostic.) Memory requirement for all operations is readily calculable in advance from the width of the inputs.
• The total set of components needed for RSA occupies around 3000 lines, incl. comments, of clear and unidiomatic (i.e. containing no “perlisms”) code.
• Contains no inline assembler and is married to no particular machine (i.e. can be built for microcontrollers, MS-DOS boxes, CPUs of virtually any “bitness”)
• Does not branch-on-secret-bits
• Does not address memory by secret values, i.e. is cachebleed-proof
• Fully unrollable, deterministic (and ergo auditable) control flow. I.e. all RSA modular-exponentiation operations will take exactly the same amount of time, via exactly the same flow of instructions; all algorithmic-complexity attack vectors are ruled out.

[Semo]

Nema niekto tipa na nieco podobne s podobnym urcenim - sifrovanu synchronizovanu kopiu lokalneho adresara umiestneneho v cloude/remote ulozisku, ale za podmienky, ze ten cloud je dost tupy a zvlada len delete/upload suboru. Nezvlada prepis casti suboru. Rozsekat sifrovany kontainer na 1000 malych suborov by to asi riesilo.

Nema niekto tip na nieco uz hotove? Nechce sa mi to pisat si to cele sam.

[Semo]

Nemam ziadne prakticke skusenosti s LVM (na vsetky podobne potreby som si vzdy vystacil s mdadm nad fyzickymi partitionami). Ale nebolo by riesenim postavit pomocou LVM nejake JBOD nad 1000 malymi subormi a nad tym encfs?

Zapis dat by cez medzivrstvy sposobil zmenu maleho poctu podkladovych suborov a tie by sa synchronizovali s remote uloziskom. Predpokladam pripojenie z jedineho miesta, takze nejake problemy s roznymi verziami sietovej kopie riesit nemusim.