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



Członek DUG




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




Zbanowany





2038
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:20:00)
Offline



Członek DUG




tak mam i7. właśnie dlatego truecrypt wolę uniknąć

Offline







Podobno człowiek...;)








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





Cenzor wirtualnego świata
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




Zbanowany





2039
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:20:01)
Offline





Cenzor wirtualnego świata
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/sOstatnio edytowany przez morfik (2015-07-05 12:47:43)
Offline




Zbanowany





2040
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:20:02)
Offline



Członek DUG




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







Podobno człowiek...;)








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



Członek DUG




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







Podobno człowiek...;)








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



Członek DUG




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







Podobno człowiek...;)








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




Zbanowany





2125
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:21:53)
Offline







Podobno człowiek...;)








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



Członek DUG




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




Zbanowany





2128
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:21:56)
Offline
Strony: 1