gocryptfs

Dawno, dawno temu przestałem używać EncFS. Przestałem z kilku powodów. Po pierwsze, pojawiło się ostrzeżenie o tym, że nie jest to rozwiązanie do końca bezpieczne. Niby nic i w moich zastosowaniach nie przeszkadzało[1], ale jakaś tam zadra w pamięci i niechęć zostały. Po drugie, zwykłe dyski zacząłem szyfrować „normalnie” przy pomocy LUKS. A backupy itp. przy pomocy GPG. Dziś odkryłem godnego następcę: gocryptfs.

Mimo zmian w używanym szyfrowaniu, po EncFS została jedna dziura: dyski zdalne typu Dropbox czy Google drive. Miło by było móc z nich korzystać „normalnie”, ale tak, żeby dane na tych dyskach były zaszyfrowane. LUKS tu nie pomoże, bo działa dla dysków lokalnych. Szyfrowanie przez GPG dla pojedynczych plików jest niewygodne, a pakowanie w jakieś archiwa jest dobre do backupów, nie do normalnego korzystania. EncFS jako overlay dostępny poprzez FUSE ze swoim szyfrowaniem per katalog był idealny. Nie trzeba z góry określać rozmiaru szyfrowanych danych, dostęp online do pojedynczych plików, z zachowaniem ich struktury.

Okazuje się, że jest godny następca dla EncFS i nazywa się gocryptfs. Nie wiem czemu nie znalazłem go wcześniej. Może odrzuciłem, bo był świeży i w golang? Może przeważył brak realnej potrzeby?

W każdym razie: jest i wygląda bardzo dobrze. Przeczytałem opis projektu i zasadę działania. Posiada sensowne założenia, był audytowany, brak przypadłości EncFS. Do tego jest bardzo szybki. Instalacja w Debianie z pakietu – żadnych kompilacji. Do tego świetna dokumentacja, proste użycie i… dopracowanie. Oczywiście open source. Działa na Linuksie, macOS, istnieją nieoficjalne porty dla Windows i Androida.

Żeby przybliżyć o czym mowa. Weźmy takie utworzenie szyfrowanego katalogu. Jedno proste polecenie, podajemy hasło, powtarzamy je i… dostajemy master key, wraz z przeznaczeniem i jak się z nim obchodzić. Aż pokażę[2], bo na stronie tego nie ma:

$ gocryptfs -init cipher/
Choose a password for protecting your files.
Password:
Repeat:

Your master key is:

d28966ae-f39ff48a-695993f9-a5e354eb-
3d31e7a1-29c834c5-31b2cb3b-b38b6cec

If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs cipher MOUNTPOINT

Prawda, że piękne? Bardzo możliwe, że przyda się i wkrótce wrócę do tematu zdalnych dysków.

[1] Moje zastosowania: nie będą mi dyski sieciowe w stylu Dropbox grzebać po plikach, nawet jeśli nic tajnego tam nie ma.
[2] Jakby ktoś zaczynał panikować, że „ojej, master key podał” to spieszę donieść, że to z testowego katalogu utworzonego na potrzeby tego wpisu, żadnych danych tam nie ma i nie będzie.

Czy rozmiar ma znaczenie?

W tym przypadku prawo nagłówków Betteridge’a nie ma zastosowania, odpowiedź będzie twierdząca, a wszystko za sprawą Androida.

Logo Androida
Źródło: https://en.wikipedia.org/wiki/Android_(operating_system)

Od roku korzystam z Yanosika. Jakiś czas temu zauważyłem, że niemal skończyło mi się miejsce na karcie SD. Szybkie śledztwo ujawniło, że głównym winowajcą nie są – jak przypuszczałem – zdjęcia, tylko katalog yanosik-new, który zajmował ponad 700 MB z dostępnych 2 GB na karcie (wiem, mała, taka zaszłość). Ponarzekałem na FB, usłyszałem, że zawartość katalogu można bezpiecznie usunąć – odbuduje sobie co potrzebne. Znaczy się klasyczny cache. OK, rok używany, karta mała, nie robię afery. Usunąłem.

Ostatnimi dniami coś Yanosik zaczął zgłaszać błędy w stylu aplikacja nie odpowiada – czekaj/zgłoś/zamknij. Coś mnie tknęło, żeby znowu sprawdzić zajętość karty i… bingo. Znowu brak wolnego miejsca. Co prawda zrobiłem na urlopie parę zdjęć, ale zdecydowanie nie kilkaset MB. Oczywiście znowu yanosik-new ma rozmiar ponad 700 MB… Zacząłem szukać większej karty i rozglądać się za instrukcją zmiany karty w telefonie na większą. Przy okazji obmyślając, jakich ciepłych słów użyć pod adresem autorów Yanosika, bo zużycie 700 MB w rok to jeszcze jestem jakoś w stanie zrozumieć, ale w 3 tygodnie?

Znalazłem jakąś kartę 4 GB, ale okazało się, że muszę sprawdzić, czy jest sprawna. Wymiana karty SD w urządzeniach z Androidem jest prosta – wystarczy zgrać całą zawartość na komputer, sformatować nową kartę, przegrać wszystkie dane na nową. I powinno działać. Wygląda prosto, ale stwierdziłem, że zrobię backup, poza tym i tak wygodniej wrzucić całość na chwilę na komputer, niż kopiować między czytnikami.

I tu niespodzianka. Po usunięciu miniaturek zdjęć (jakieś 200 czy 300 MB) i skopiowaniu wszystkich danych na dysku katalog zajął… 880 MB.  Czyli jakąś połowę tego, co na karcie. W tym momencie zapaliła mi się lampka ostrzegawcza. Czyżby rozmiar bloku? Katalog Yanosika ma dużo małych kilkusetbajtowych plików, więc może o to chodzi. Sprawdziłem jego rozmiar w komputerze. 130 MB, więc bez dramatu. Czyżby autorzy zrobili taki bezsensowny i niedostosowany do Androida cache?

Zacząłem drążyć temat i okazało się, że cfdisk pokazuje jako system plików FAT16. No ale jak to? I jaki jest rozmiar bloku dla FAT 16? I czy w ogóle pojemności rzędu 2 GB są obsługiwane przez taki zabytek? Szybka wyprawa do muzeum i okazało się, że owszem, FAT16 obsługuje pojemności dysku do 2 GB. A rozmiar bloku to wówczas… 32 kB. Zamiast wymieniać kartę, postanowiłem zrobić mały eksperyment: zmienić system plików na FAT32.

Zmieniłem typ partycji w cfdisk (raczej bez znaczenia) i sformatowałem kartę przy pomocy mkfs.vfat -F 32, czyli wymuszając FAT32. Skopiowałem dane z komputera, włączyłem telefon, odbudowałem cache zdjęć. Po tym zabiegu jest 930 GB wolnego, bez kasowania jakichkolwiek danych! Czyli rozmiar bloku ma w przypadku urządzeń z Androidem duże znaczenie.

Zastanawiam się tylko, jak to możliwe. Kto w XXI w. używa FAT16? Nie kojarzę gdzie była formatowana karta. Wiele wskazuje na to, że w samym telefonie. Czyżby Android był tak słabo zaprojektowany, że domyślnie formatuje karty o rozmiarze 2 GB i mniejsze na FAT16? Jeśli tak, to jak widać zupełnie bez sensu. Ciekawe też, jaki system plików jest w na wbudowanej pamięci flash. Bo o ile karty microSD są tanie (8 GB class 4 od 12 zł widzę, za mniej niż 20 zł można nawet 16 GB class 10 w sklepie kupić), więc rozważania o rozmiarze 2 GB są czysto teoretyczne, o tyle w przypadku wbudowanej pamięci nie ma możliwości zmiany jej rozmiaru – trzeba zmienić urządzenie. Gra w tym przypadku (Yanosik i jego cache plus jakieś inne dane typu zdjęcia, ale przypuszczam, że nie on jeden tak robi…) toczy się w praktyce o podwojenie miejsca…

Pewnego rodzaju obejściem problemu może być w tym przypadku opisane kiedyś przeniesienie aplikacji z pamięci wbudowanej na kartę. Oczywiście najlepiej sformatowaną na FAT32, ale to powinno już stać się automatycznie w przypadku pojemności większych niż 2 GB.

EncFS – kolejne narzędzie do szyfrowania upada

Dawno temu zachwycałem się EncFS[1]. Obsługiwało AES, pozwalało szyfrować pliki, nie partycje i pozwalało trzymać je na zwykłym systemie plików. Tak naprawdę szyfrowany był katalog. Jakiś czas temu upadł Truecrypt, który – zdaniem twórców – okazał się nie tak bezpieczny, jak postrzegali go ludzie. Teraz kolej na EncFS.

Wczoraj, podczas aktualizacji systemu[2], dostałem w twarz dialogboksem o następującej treści:

Encfs security informationAccording to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example,an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without this being noticed by a legitimate user, or might usetiming analysis to deduce information.Until these issues are resolved, encfs should not be considered a safe home for sensitive data in scenarios where such attacks are possible.

Pięknie, prawda? Szczególnie, że EncFS byłby świetnym rozwiązaniem do szyfrowania plików w chmurze – EncFS dla WebDAV czy Dropbox były proste w założeniu i wygodne w użytkowaniu[3]

Wygląda, że pomału można żegnać się z EncFS. A podobnych alternatyw jakoś nie widać na horyzoncie.

[1] Strona projektu zwraca 404. Przypadek? W każdym razie nie linkuję, łatwe do wyszukania…

[2] Debian unstable. Akurat tam nie używam encfs, ale instaluję wszędzie. Planowałem do chmury.

[3] Ładne ilustrowane howto dla EncFS w chmurze.