Forum Debian Users Gang

lis6502 · 2014-06-12 18:59:10

ELoooo :>
Pacjent laptop+ soft Gentoo+ user lisu= aspiracje. Zastanawiam się czy na szyfrowaną partycję domową lepiej wybrać luks+lvm, sam luks, dm-crypt, czy morfikowe encfs+pam?
Zależy mi na nieczytelności danych dla pacjenta bez hasła (wiadome:P), jakimś sprzętowo (jeśli to możliwe- c2d t7250) wspomaganym crypto, oraz odhasłowaniu przy logowaniu się klienta (coś jak opisał to morfik w swoim tutku, dzięki ziąą :D), oraz, WAŻNE, jakimś failover, klucz możliwy do wyeksportowania na pendrive, domowego NASa. Kto pomoże?

Jacekalex · 2014-06-12 19:16:28

Trochę mały procek jak na szyfrowanie całego dyzia.

Nie masz tam czasem w zasięgu jakiegoś procka z AES-NI?
Te na AES mają szybkość około 1-2GB/s bez specjalnego wysiłku, podczas, gdy mój C2D wyciąga może z 65 - 70 MB/s przy full obciążeniu, co na lapku nie jest zbyt mile widzane.

uzytkownikubunt · 2014-06-12 19:38:44

836

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:53:35)

morfik · 2014-06-12 22:08:25

To encfs+pam to nie jest moje, ja z tego nie korzystam, bo ma szereg podatności. xD Poza tym, luks używa dm-crypta do szyfrowania, także tu nie ma różnicy żadnej, a lvm, to gdy chcesz się bawić w zarządzanie danych i mieć swobodę w montowaniu określonych partycji niezależnie, np. tmp, czy tam zmieniać ich rozmiary albo dodawać nowe, etc.

A co do backupu, to sobie zrób drugie hasło typu 123, zrób kopię nagłówka i schowaj. xD Potem to hasło wywal z nagłówka partycji i jak zapomnisz, to przywrócisz sobie kopie nagłówka ze zbackdorowanym hasłem i tyle. xD Tam chyba nie trzeba nawet operować bezpośrednio na nagłówkach partycji, można dodać takie hasło od razu do backupu i potem przywrócić taki nagłówek.

Tu masz kopie:

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Backup_and_restore

A tu jak operować na nagłówku:

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Key_management

A co do procka, to ja mam ten swój syfiasty pentium D z pseudo 2-core, zawsze jechałem na aes256 i nigdy mi to nie zawadzało, to nie ma wspomagania sprzętowego i filmy w 720p bez problemu odtwarza na poziomie 30% zużycia proca. Z 1080 jest trochę problem i czasem może nie dać rady.

lis6502 · 2014-06-12 22:19:03

Dzięki za odzew :). Hm, myślę że w temacie wyboru algorytmu pomoże mi jakiś benchmark- coś mi się obiło o oczy z pętklą while i poleceniem openssl; gdyby spiąć to z poleceniem time, możnaby pewnie wywnioskować jaki algorytm jest najlepszy dla mojej maszyny.
Aż tak mi nie zalezy by pakować się w jakieś 1024-bitowe szyfry, przepustowość chyba też nie ma większego znaczenia, bo to nie serwer gdzie dane mają być dostępne na wczoraj.
Wszelkie kompilacje dzieją się w ramie (/tmp montowany jako tmpfs), /var/db poza szyfrowaniem, więc i tu crypto nie spowolni.
Długość hasła i jego skomplikowanie zrzucę na głowę /dev/random, jako że chcę użyć pliku jako klucza (a tego po utrwaleniu na czymś fizycznym schowam pod panele podłogowe:P).

morfik · 2014-06-12 22:31:26

LUKS ma narzędzia do benchmarków:

Kod:

# cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       207392 iterations per second
PBKDF2-sha256     134847 iterations per second
PBKDF2-sha512      75851 iterations per second
PBKDF2-ripemd160  208713 iterations per second
PBKDF2-whirlpool   88562 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    55.0 MiB/s   128.5 MiB/s
 serpent-cbc   128b    48.2 MiB/s    75.7 MiB/s
 twofish-cbc   128b    80.5 MiB/s   106.3 MiB/s
     aes-cbc   256b    80.2 MiB/s    98.9 MiB/s
 serpent-cbc   256b    51.8 MiB/s    74.5 MiB/s
 twofish-cbc   256b    85.8 MiB/s   106.6 MiB/s
     aes-xts   256b   107.0 MiB/s   105.1 MiB/s
 serpent-xts   256b    72.7 MiB/s    73.6 MiB/s
 twofish-xts   256b   108.9 MiB/s   112.8 MiB/s
     aes-xts   512b    88.0 MiB/s    87.2 MiB/s
 serpent-xts   512b    73.3 MiB/s    73.7 MiB/s
 twofish-xts   512b   110.8 MiB/s   113.9 MiB/s

Jacekalex · 2014-06-12 22:33:34

Test szybkości OpenSSL?
http://www.intel.pl/content/dam/www/public/us/en/documents/white-papers/open-ssl-performance-paper.pdf
http://wiki.openwrt.org/inbox/benchmark.openssl

Ostatnio edytowany przez Jacekalex (2014-06-12 22:37:50)

lis6502 · 2014-06-14 09:39:10

Dokadnie o coś takiego mi chodziło [b]morfik[/b]. Nie mogłem się uporać z narzekaniem cryptsetup o brak modułu algif_skcipher (nazwa modułu niewiele mi mówiła), ale wygrepałem w konfigu kernela :P
Coś takiego

Kod:

deimos linux # modprobe serpent
modprobe: ERROR: could not insert 'serpent_avx_x86_64': No such device
deimos linux # modprobe twofish
modprobe: ERROR: could not insert 'twofish_avx_x86_64': No such device

mam rozumieć jako brak sprzętowej- wewnątrzprocesorowej obsługi szyfrowania?
Jeśli powyższe założenia są prawdziwe- jest sens pakować się w szyfrowanie? Powiedzmy z tej listy

Kod:

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       315076 iterations per second
PBKDF2-sha256     164045 iterations per second
PBKDF2-sha512     109409 iterations per second
PBKDF2-ripemd160  239182 iterations per second
PBKDF2-whirlpool  110702 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   112.9 MiB/s   127.3 MiB/s
 serpent-cbc   128b    44.8 MiB/s   161.6 MiB/s
 twofish-cbc   128b   111.7 MiB/s   149.3 MiB/s
     aes-cbc   256b    90.3 MiB/s    99.1 MiB/s
 serpent-cbc   256b    45.8 MiB/s   161.9 MiB/s
 twofish-cbc   256b   112.7 MiB/s   147.8 MiB/s
     aes-xts   256b   132.0 MiB/s   128.3 MiB/s
 serpent-xts   256b   144.1 MiB/s   149.8 MiB/s
 twofish-xts   256b   136.5 MiB/s   137.4 MiB/s
     aes-xts   512b   100.9 MiB/s    98.5 MiB/s
 serpent-xts   512b   144.1 MiB/s   150.8 MiB/s
 twofish-xts   512b   136.5 MiB/s   138.2 MiB/s

wybrałbym najszybsze=najmniej obciążające algorytmy- jeżdżenie po dysku nie wessie mi baterii?

uzytkownikubunt · 2014-06-14 10:10:13

838

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:53:38)

lis6502 · 2014-06-14 18:31:57

Pewnie dlatego jest strasznie szybki, bo opcje konfiguracji kernela mówią

│ │ {M} Serpent cipher algorithm │ │
│ │ <M> Serpent cipher algorithm (x86_64/SSE2) │ │
│ │ < > Serpent cipher algorithm (x86_64/AVX)[/quote]
czyli na mój prosty rozumek- starsze(?) konstrukcje obsługujące instrukcje SSE2 skorzystają z wariantu z tymi opkodami procesora. No to okej, algorytm wybrany, a funkcja skrótu? Chodzi o hashowanie pliku-klucza? Tak jak w hasłach: hasło -> funkcja= hash_hasła, co trafia do bazy. Autoryzacja polega na hashowaniu proponowanego przez usera hasła i porównanie wyniku z zapisem w bazie. O to chodzi w funkcji? Wybaczcie laickość pytań, ale nie mogę doszukać się strawnego opracowania.

Time (s)	Query
0.00010	SET CHARSET latin2
0.00005	SET NAMES latin2
0.00158	SELECT u., g., o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.188.140.232' WHERE u.id=1
0.00065	REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.188.140.232', 1732552363)
0.00043	SELECT * FROM punbb_online WHERE logged<1732552063
0.00045	SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=25965 AND t.moved_to IS NULL
0.00010	SELECT search_for, replace_with FROM punbb_censoring
0.00148	SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=25965 ORDER BY p.id LIMIT 0,25
0.00082	UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25965
Total query time: 0.00566 s

Forum Debian Users Gang

Ogłoszenie

#1 2014-06-12 18:59:10

lis6502 - Łowca lamerów

dm-crypt czy encfs+pam?

#2 2014-06-12 19:16:28

Jacekalex - Podobno człowiek...;)

Re: dm-crypt czy encfs+pam?

#3 2014-06-12 19:38:44

uzytkownikubunt - Zbanowany

Re: dm-crypt czy encfs+pam?

#4 2014-06-12 22:08:25

morfik - Cenzor wirtualnego świata

Re: dm-crypt czy encfs+pam?

#5 2014-06-12 22:19:03

lis6502 - Łowca lamerów

Re: dm-crypt czy encfs+pam?

#6 2014-06-12 22:31:26

morfik - Cenzor wirtualnego świata

Re: dm-crypt czy encfs+pam?

Kod:

#7 2014-06-12 22:33:34

Jacekalex - Podobno człowiek...;)

Re: dm-crypt czy encfs+pam?

#8 2014-06-14 09:39:10

lis6502 - Łowca lamerów

Re: dm-crypt czy encfs+pam?

Kod:

Kod:

#9 2014-06-14 10:10:13

uzytkownikubunt - Zbanowany

Re: dm-crypt czy encfs+pam?

#10 2014-06-14 18:31:57

lis6502 - Łowca lamerów

Re: dm-crypt czy encfs+pam?

#11 2014-06-14 18:47:03

uzytkownikubunt - Zbanowany

Re: dm-crypt czy encfs+pam?

Stopka forum

Informacje debugowania