Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Cześć. Chciałbym zaszyfrować sobie /home/ (jest na osobnej partycji) i zastanawiam się co zacząć czytać (odnośnie które rozwiązanie użyć)
Kiedyś ludzie używali truecrypt teraz rozumiem taki standard to dm-crypt tak?
ma ktoś z tym jakieś doświadczenia (jak mocno obniża się wydajność) ?
Offline
2038
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:20:00)
Offline
tak mam i7. właśnie dlatego truecrypt wolę uniknąć
Offline
Jeśli procek posiada support AES-NI, to wsio rawno, Truecrypt czy Cryptsetup, AES-NI to sprzętowy akcelerator AES zapewniający szybkość na poziomie 1,5-2 GB/s.
Radzę sprawdzić w TC i Cryptsetup, który lepiej korzysta z tego modułu.
Offline
Jeśli to ma być tylko /home/ , to możesz się pobawić http://ecryptfs.org/ . W debianie są narzędzia, które chyba za pomocą jednego klika przeszyfrują ci całą zawartość /home/$USER/ . Z LUKSem, to trzeba będzie dane przenieść na inną partycję, stworzyć kontener i wgrać dane ponownie. Ta partycja /home/ jest niegroźna i praktycznie nie ma żadnych problemów z jej montowaniem -- jak każdy inny zasób, byle przed załadowaniem się TTY, czy sesji graficznej. Tylko znów jest problem z /tmp/ , SWAP i kto wie z czym jeszcze.
Offline
2039
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:20:01)
Offline
Czy ja wiem, czy te 4% będzie zauważalne przy normalnej pracy? Choć w sumie nie wiem co na tym kompie ma być robione. Ja mam 2x 2ghz procek, co nie ma wsparcia dla AES, a szyfruje cały dysk AES256, zużycie procka mówi raczej samo za siebie:
analyzing CPU 0: cpufreq stats: 2.00 GHz:13.64%, 1.87 GHz:2.56%, 1.73 GHz:2.06%, 1.60 GHz:2.56%, 1.47 GHz:3.29%, 1.33 GHz:4.14%, 1.20 GHz:7.86%, 1.07 GHz:19.34%, 933 MHz:44.55% (16433) analyzing CPU 1: cpufreq stats: 2.00 GHz:12.78%, 1.87 GHz:2.21%, 1.73 GHz:1.89%, 1.60 GHz:2.39%, 1.47 GHz:3.39%, 1.33 GHz:4.18%, 1.20 GHz:8.45%, 1.07 GHz:19.88%, 933 MHz:44.83% (16750)
Tylko to powyższe jest na uptime 15 min, Jeśli by ten sprzęt pochodził parę godzin jeszcze, to by tam na 2GHz było może ze 2-4%. Także praktycznie nie jest zauważalne to szyfrowanie. Jasne, że sprawa ma się inaczej gdy się będzie mielić pełno danych nonstop ale z dłuższej perspektywy to nie wiem czy idzie to w ogóle odczuć, no może poza samym startem systemu ewentualnie firefoxa. xD
Zawsze może sobie też testy zrobić:
# cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 516031 iterations per second PBKDF2-sha256 356173 iterations per second PBKDF2-sha512 244537 iterations per second PBKDF2-ripemd160 332670 iterations per second PBKDF2-whirlpool 106389 iterations per second # Algorithm | Key | Encryption | Decryption aes-cbc 128b 103.7 MiB/s 123.3 MiB/s serpent-cbc 128b 35.0 MiB/s 162.0 MiB/s twofish-cbc 128b 88.7 MiB/s 131.5 MiB/s aes-cbc 256b 81.4 MiB/s 92.3 MiB/s serpent-cbc 256b 39.7 MiB/s 162.1 MiB/s twofish-cbc 256b 94.7 MiB/s 132.5 MiB/s aes-xts 256b 123.1 MiB/s 122.9 MiB/s serpent-xts 256b 143.4 MiB/s 150.9 MiB/s twofish-xts 256b 123.0 MiB/s 122.3 MiB/s aes-xts 512b 92.3 MiB/s 92.4 MiB/s serpent-xts 512b 142.6 MiB/s 150.8 MiB/s twofish-xts 512b 123.5 MiB/s 123.2 MiB/s
Ostatnio edytowany przez morfik (2015-07-05 12:47:43)
Offline
2040
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:20:02)
Offline
Dziękuję za wszystkie odpowiedzi. LVM on LUKS wydaje mi się najlepsze i chyba na to się zdecyduję.
https://wiki.archlinux.org/index.php/Dm-crypt/Encry … m#LVM_on_LUKS
Muszę jeszcze tylko poczytać nt. tych algorytmów i kluczów, bo nwm jakie opcje przy tworzeniu bd najlepsze typu:
cryptsetup --verbose --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sda2
- chyba, że ma ktoś jakieś propozycje? (core i7 64bit system)
Dodatkowo chce zaszyfrować istniejącą instalację arch linux, więc bd musiał: zrobić gdzeiś sobie obraz systemu -> stworzyć te zaszyfrowane volumeny -> na podmontowanych wypakować stary system z jakiegoś live cd -> ogarnąć /etc/fstab , mkinitcpio (tam dodać ten hook lvm2 itd..), bootloader itd.. - nwm czy o czymś nie zapomniałem??, no i tak pewnie wyjdzie w praniu ... ;\
póki co zasymuluje sobie to na razie w wirtualce, tylko kurde -żeby zrobić obraz (bez /home na razie) czy myślicie, że:
tar -clvpz --exclude=/mnt/* --exclude=/media/* --exclude=/proc/* --exclude=/home/* --exclude=/sys/* --exclude=/tmp/* --exclude=/dev/* --exclude=/run/* -f system.tgz /
będzie bezpieczne? czy może istnieje coś lepszego?
Offline
W nowych jajkach 4.1 pojawiło się szyfrowanie ext4 na poziomie systemu plików.
Zapowiada się to dosyć ciekawie, szczególnie bezpieczne przechowywanie klucza poza zasięgiem czegokolwiek z userspace, ma być używane w nowych wydaniach Androida od którejś tam wersji, pewnie 6.0.
https://lwn.net/Articles/639427/
https://docs.google.com/document/d/1ft26lUQyuSpiu6V … Tg/edit?pli=1
Moduły już są w standardowym jaju 4.1.4:
zgrep -i ext4 /proc/config.gz
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_ENCRYPTION=y
CONFIG_EXT4_FS_ENCRYPTION=y
Ostatnio edytowany przez Jacekalex (2015-08-08 20:40:07)
Offline
Jacekalex to teraz mi namieszałeś xd. Wiadomo coś kiedy to będzie nadawać się do użytku a może już się nadaje? Nigdzie nic nie znalazłem jak to w praktyce użyć/przetestować.
Offline
Niedługo powinno być gotowe, jajo już support ma zarówno w przedmiocie szyfrowania jak i przechowywania kluczy, trzeba chyba poczekać, aż e2fsprogs zacznie to obrabiać.
Tu masz conieco na ten temat w bardziej strawnej formie:
https://wiki.archlinux.org/index.php/Ext4#Using_ext … ry_encryption
Podejrzewam, że przy wydaniu jajka 4.2 już wsio będzie brykać, przecież Developerzy jakoś musieli już to testować. ;)
Offline
No fajne to w sumie i nawet myślałem by to użyć, ale jednak jak korzystam z hibernacji i chciałbym mieć wszystko zaszyfrowane (a nie tylko wybrane katalogi) to szyfrowanie na poziomie systemu plików zbytnio mnie nie urządza.
Offline
Dlaczego? szyfrowanie, jak szyfrowanie, powinno być nawet szybsze, bo to jajo się zajmuje szyfrowaniem, a nie jakiś program z userspace.
Opracowane z resztą też do Androida, więc raczej z hibernacją powinno się dogadać bez problemu.
Szyfrowanie na poziomie systemu plików ma tą zaletę, ze programy z userspace w ogóle nie muszą wiedzieć, ze trzymają dane na szyfrowanym systemie plików.
Przy okazji, szyfrowanie per/folder nie wyklucza zaszyfrowania partycji, pozwala za to na dużą elastyczność bez bezsensownej gimnastyki, np szyfrowanie /home, który siedzi na rootfs prosto z poziomu instalatora.
W Linuxie przecież folder może być zarówno miejscem na dysku, jak i punktem montowania partycji lub dysku.
W ten sposób znikają literalnie wszystkie ograniczenia w stosowaniu szyfrowania systemu plików.
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2015-08-09 00:05:27)
Offline
2125
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:21:53)
Offline
Tam się szyfruje inody na dysku, to trochę inna zabawa, niż te dowiązania, które wyglądają jak plik lub folder.
Całą sprawa tego szyfrowania jest z drugiej strony banalnie prosta, przechowywanie kluczy w kernelu jest od lat, system plików od zawsze, APi kryptograficzne od niemal zawsze, wiec co do czorta miałoby nie działać.
Nawet, jakby zdechło po aktualizacji kernela, to zawsze w systemie siedzi jeszcze ten starszy, na którym wszystko działa, a poza kernelem ? tylko trzeba załadować klucz do kernela, i to pewnie będzie załatwiane przez cmdline albo fstab.
Trzeba tylko poczekać na stabilne e2fsprogs-1.4.13.
Generalnie nie ma się za bardzo czego obawiać.
Kernel Linux to najstabilniejsza i najdoskonalsza część całego systemu, niewiele jest programów, które pod względem jakości kodu i supportu dorównują kernelowi. ;)
Cala sprawa powstała z resztą po to, żeby radykalnie uprościć szyfrowanie, i wyeliminować możliwe katastrofalne błędy, jak ostatnio w Androdzie 5.0, gdzie SELinux ubijał encryptfs.
Szyfrowanie systemu plików na poziomie kernela i systemu plików jest najbardziej odporne na potencjalne błędy programów z userspace.
I myślę, że właśnie dlatego Ekipa Google stworzyła te łatki do Ext4. ;)
Pozdro
Ostatnio edytowany przez Jacekalex (2015-08-09 00:21:39)
Offline
Jacekalex no, ale na partycji swap nie mam systemu plików ext4 (musiałbym zrobić swapfile) - a korzystam z zswap - ciekawe czy to nadal będzie działać, bo robi się dość skompilkowanie..
pozatym jak to wygląda dokładnie przy LVM on LUKS?
gdzie przechowywany jest klucz i jaki program z userspace zajmuje się szyfrowaniem? myślałem, że tym zajmuje się jądro (konkretniej moduł) i nawet ext4 włącznie nie wie, że jest na zaszyfrowanym dysku a co dopiero jakieś programy w userspace...
ciekawi mnie też czy przy tym szyfrowaniu ext4 szyfrowane są również metadane. (struktura drzewa katalogów, rozmiary plików itd...)
Offline
2128
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:21:56)
Offline
Strony: 1