LINUX.ORG.RU

Garuda

Btrfs

Вот это выбрось и возьми простой Arch с Ext4, а вот это:

LUKS

  • оставь. И лучше шифровать весь диск, так влияние на производительность меньше (@WitcherGeralt подтвердит).
Korchevatel ★★★★★ ()
Ответ на: комментарий от Korchevatel

Почему же выбросить? Мне очень нравится этот дистрибутив, к тому же моментальные автоматические снимки системы и удобный gui для настройки почти всего мне как новичку очень кстати, та же Fedora уже из коробки btrfs, вопрос стоит лишь в том, стоит ли ставить при установке оси галочку на шифрование диска(которое там LUKS по дефолту), что это может мне дать и влияет ли на производительность)

fmx1k ()
Ответ на: комментарий от t184256

Тесты, использующие практически только память (без ввода-вывода на хранилище).

PBKDF2-sha1 1598439 итераций в секунду для 256-битного ключа PBKDF2-sha256 2032124 итераций в секунду для 256-битного ключа PBKDF2-sha512 1458381 итераций в секунду для 256-битного ключа PBKDF2-ripemd160 791975 итераций в секунду для 256-битного ключа PBKDF2-whirlpool 354728 итераций в секунду для 256-битного ключа argon2i 5 итераций, 1048576 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс) argon2id 4 итераций, 1048576 памяти, 4 параллельных нитей (ЦП) для 256-битного ключа (запрашивался 2000 мс)

Algorithm | Key | Encryption | Decryption

Алгоритм | Ключ | Шифрование | Расшифровка

aes-cbc 128b 608,5 MiB/s 1863,1 MiB/s serpent-cbc 128b 51,4 MiB/s 399,1 MiB/s twofish-cbc 128b 117,7 MiB/s 376,9 MiB/s aes-cbc 256b 821,0 MiB/s 2702,6 MiB/s serpent-cbc 256b 93,6 MiB/s 699,3 MiB/s twofish-cbc 256b 187,3 MiB/s 222,2 MiB/s aes-xts 256b 1763,8 MiB/s 1825,0 MiB/s serpent-xts 256b 338,4 MiB/s 358,0 MiB/s twofish-xts 256b 197,2 MiB/s 205,4 MiB/s aes-xts 512b 1398,7 MiB/s 1490,8 MiB/s serpent-xts 512b 345,9 MiB/s 357,4 MiB/s twofish-xts 512b 199,2 MiB/s 205,9 MiB/s

у меня ноут с ssd nvme, как посмотреть интерфейс?

fmx1k ()
Ответ на: комментарий от t184256

=== START OF INFORMATION SECTION === Model Number: WDC PC SN520 SDAPNUW-512G-1014 Serial Number: 19200E804083 Firmware Version: 20110000 PCI Vendor/Subsystem ID: 0x15b7 IEEE OUI Identifier: 0x001b44 Total NVM Capacity: 512 110 190 592 [512 GB] Unallocated NVM Capacity: 0 Controller ID: 1 NVMe Version: 1.3 Number of Namespaces: 1 Namespace 1 Size/Capacity: 512 110 190 592 [512 GB] Namespace 1 Formatted LBA Size: 512 Namespace 1 IEEE EUI-64: 001b44 8b44a3c488 Local Time is: Tue Jul 20 00:24:18 2021 MSK

надеюсь это то что нужно)

fmx1k ()
Ответ на: комментарий от fmx1k

https://www.harddrivebenchmark.net/hdd.php?hdd=WDC+PC+SN520+SDAPNUW-512G говорит, что в линейном чтении твой SSD выдает всего полтора гига в секунду. Так что смело шифруй. Получишь примерно за ту же производительность необходимость ввода пароля и зашифрованный диск. В паре с блокировкой экрана спасает от нервов при утере, не спасает от evil maid attack, не спасает от терморектального криптоанализа.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Спрашиваю чисто из соображнний, что можно поставить тогда галочку не запрашивать пароль при входе в систему если мое суждение верно

fmx1k ()
Ответ на: комментарий от fmx1k

Если будешь делать настоящий FDE, то можно сделать и так. Но это надо знать что делаешь (и желательно еще зачем, выгода с этого невелика). Если в инсталляторе галочку поставишь, то скорее всего он предложит вариант с незашифрованным /boot с ядром и initramfs, и тогда запрашивать будет уже на стадии initramfs (после загрузчика, до монтирования /).

t184256 ★★★★★ ()
Ответ на: комментарий от fmx1k

Нууу, с одной стороны да, логика в этом есть. С другой стороны, экран надо бы блокировать, а там все равно разблокировать по пять раз на дню. Или стратегически вовремя выключать.

t184256 ★★★★★ ()
Ответ на: комментарий от fmx1k

Ставь, что б не ставить. «Вреда» с нее один ввод пароля на загрузку, может чуть усложненное вытаскивание данных, если диск полетит (но до этого все равно лучше не доводить). А просадку в скорости ты при обычном десктопном использовании не ощутишь.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Опять же, ставя галочку на автоматический вход без запроса пароля, и нажав в системе winlock, мне же потребуется ввести пасс чтобы залогиниться, разве нет?

fmx1k ()
Ответ на: комментарий от fmx1k

С точки зрения сухой логики, любой из них + возможность его применить скомпрометируют тебя по одни и те же помидоры.

С точки зрения цифровой гигиены, лучше никогда ни на что одинаковых паролей не ставь, а то увлечешься, поставишь его еще на твиттер, госуслуги и какую-нибудь третью дырявую помойку, а это черевато.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Ахах, ты мне очень помог, информация исчерпывающая все мои вопросы, пойду учиться юзать пакман, после убунты арч темный лес для меня

fmx1k ()
Ответ на: комментарий от fmx1k

Не за что. Извиняться не надо, просто задавай, до реально глупых вопросов по местным меркам твоим вопросам еще далеко. Даже в техразделах в среднем царят «какой язык учить», «что будет, если я поставлю дистрибутив X» и всякие «не получается вырезать гланды синим маркером», а уж за их пределами так вообще дикий запад.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Кстати, попробовав поставить галку, пароль запрашивает еще до загрузки граба

fmx1k ()
Ответ на: комментарий от t184256

Но про скомпрометировать по самые помидоры не совсем понял, если этот пасс не применяется в сети больше нигде, может ли он быть один для encrypt и для sudo команд? Или есть какие то риски?

fmx1k ()
Ответ на: комментарий от fmx1k

если этот пасс не применяется в сети больше нигде, может ли он быть один для encrypt и для sudo команд?

Может, кто ж тебя остановит.

Или есть какие то риски?

Теоретические есть, практически — минимальные. Векторы атаки разные совсем, компрометация и так и так полная. В итоге как на заднюю дверь сделать такой же ключ, что и на переднюю. Я бы не делал, но и существенных рисков кроме дальнейшего переиспользования в голову не приходит.

t184256 ★★★★★ ()

Если нужно тебе шифрование, то ставь, если не нужно, то не ставь, логично вроде. Я поставил, вдруг своруют ноутбук, у меня на нём информация, которую запрещено разглашать, меньше потенциальной головной боли. На производительность, естественно, влияет. Но в целом не особо заметно, если бенчмарки не гонять.

Мой бенчмарк, можешь сравнить со своим.

$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      1753471 iterations per second for 256-bit key
PBKDF2-sha256    2223915 iterations per second for 256-bit key
PBKDF2-sha512    1640964 iterations per second for 256-bit key
PBKDF2-ripemd160  923042 iterations per second for 256-bit key
PBKDF2-whirlpool  690761 iterations per second for 256-bit key
argon2i       4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1186.8 MiB/s      3650.2 MiB/s
    serpent-cbc        128b        96.4 MiB/s       755.8 MiB/s
    twofish-cbc        128b       225.7 MiB/s       407.7 MiB/s
        aes-cbc        256b       904.3 MiB/s      2925.3 MiB/s
    serpent-cbc        256b        99.3 MiB/s       755.4 MiB/s
    twofish-cbc        256b       231.2 MiB/s       397.2 MiB/s
        aes-xts        256b      3627.5 MiB/s      3625.7 MiB/s
    serpent-xts        256b       648.2 MiB/s       656.5 MiB/s
    twofish-xts        256b       363.6 MiB/s       361.2 MiB/s
        aes-xts        512b      2917.0 MiB/s      2909.2 MiB/s
    serpent-xts        512b       627.5 MiB/s       629.5 MiB/s
    twofish-xts        512b       358.2 MiB/s       358.2 MiB/s
Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Одно непонятно, почему у меня по дефолту у LUKS 0 и 1 слот заняты ключом, хотя ключ я делал только один, при попытке руками убрать ключ с 1 слота получилось что на загрузке grub ключ принимается, а ось не грузится, как так xD

fmx1k ()
Ответ на: комментарий от t184256

Одно непонятно, почему у меня по дефолту у LUKS 0 и 1 слот заняты ключом, хотя ключ я делал только один, при попытке руками убрать ключ с 1 слота получилось что на загрузке grub ключ принимается, а ось не грузится, как так xD

fmx1k ()
Ответ на: комментарий от t184256

Есть ещё вариант отказаться от шифрования / и от initramfs, тогда пароль запрашивать будет в процессе загрузки системы.

eternal_sorrow ★★★★★ ()
Ответ на: комментарий от Korchevatel

Btrfs

выбрось

А вот и вредные советы подъехали.

anonymous ()

Заклюют конечно, но имхо: Garuda неплохая сборочка для начальной установки арча. Во-первых, там нет своих репо поверх или вместо реп арча, т.е. по сути это просто готовая конфигурация (все свои пакеты они размещают в aur). Во-вторых, там очень неплохой конфиг для старта (не считая пёстрого внешнего вида для некоторых сред рабочего стола). И да, btrfs + timeshift снапшоты + LUKS там из коробки.

vyazovoi ★★★ ()
Ответ на: комментарий от fmx1k

Лучше так не делать. Скомпрометировать пароль, который ты вводишь по сто раз на дню, куда проще (попав на камеру, например) чем тот, который ты вводишь единожды. К тому же вводить длиннющий пароль, чтобы разблокировать экран или выполнить судо — то ещё удовольствие, так что лучше иметь два разных.

WitcherGeralt ★★ ()
Последнее исправление: WitcherGeralt (всего исправлений: 1)

имеет ли смысл ставить при установке ОС с btrfs шифрование LUKS?

Имеет, стоит сделать FDE - шифрование системного раздела с /home

И влияет ли это на производительность?

Да, снижает. В моём случае - примерно на 10%, у каждого может быть по-своему. Команда cryptsetup benchmark показывает сравнение работы нескольких алгоритмов в памяти, но не реальное влияние на работу hdd/sdd.

mxfm ★★ ()
Ответ на: комментарий от WitcherGeralt

Смысл тогда иметь длиннющщий пароль на LUKS, а при открывания крышки потерянного ноута запрашивать короткий и легко компрометируемый? Дизбаланс какой-то в твоей картине мира.

t184256 ★★★★★ ()
Ответ на: комментарий от mxfm

FDE - шифрование системного раздела с /home

А давайте FDE будем называть шифрование хотя бы всех разделов, а не половины?

t184256 ★★★★★ ()

Влияет. Насколько? - Зависит от того поддерживает ли процессор аппаратное шифрование (AES-NI). Btrfs с ZSTD где-то 400-500 Mib/sec при дефолтных настройках LUKS выдает:

~ on ☁️ tz4678@gmail.com took 10s 
➜ sudo compsize /home
Processed 12001213 files, 504378 regular extents (6032523 refs), 7501056 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       79%       37G          47G         544G       
none       100%       32G          32G         384G       
zlib        38%      819M         2.0G         2.0G       
lzo         52%      644M         1.2G          20G       
zstd        35%      4.2G          12G         137G       
prealloc   100%       52M          52M         208M       

~ on ☁️ tz4678@gmail.com took 2m8s 
➜ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync oflag=direct
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.33132 s, 461 MB/s

~ on ☁️ tz4678@gmail.com took 2s 
➜ rm test                                   

~ on ☁️ tz4678@gmail.com 
➜ 

tz4678 ★★ ()
Ответ на: комментарий от tz4678

Надо учитывать, что сжатие в Btrfs особенное, потому как мелкие файлы хранятся в дереве как есть, т.е. без сжатия. У меня, например, большинство файлов несжатые. Выполнять дефрагментацию, которая должна пережать файлы смысла нету

tz4678 ★★ ()
Ответ на: комментарий от mxfm

FDE применяется ко всему диску. У него есть недостатки: нельзя использовать suspend, проблемы с Dualboot, boot entry с Arch Linux будет пропадать на некоторых материнках, точнее на некоторых версиях UEFI (после разблокировки устройства у тебя будет грузиться Windows, пока не переименуешь каталог с EFI Windows)

tz4678 ★★ ()
Ответ на: комментарий от tz4678

Btrfs с ZSTD где-то 400-500 Mib/sec при дефолтных настройках LUKS выдает

у тебя что-то с процом, ящитаю.

t184256 ★★★★★ ()
Ответ на: комментарий от tz4678

нельзя использовать suspend

?может хотя бы hibernate?

проблемы с Dualboot… Windows

логично, Windows с LUKS не грузится

boot entry с Arch Linux будет пропадать на некоторых материнках

жесть, но при чем тут FDE?

Короче, твоя когерентность 0/3, говори понятно.

t184256 ★★★★★ ()
Ответ на: комментарий от t184256

Ты написал жуткий бред.

Windows с LUKS не грузится

Windows с LUKS не грузится

Windows с LUKS не грузится

Если это такой троллинг, то он настолько тонкий, что я его не понял.

tz4678 ★★ ()
Ответ на: комментарий от t184256

короткий

Смысл в том, что с очень большой долей вероятности, даже при наличии очень короткого пароля при открытии крышки, никто его подбирать не будет трое суток тыча палочкой в произвольные кнопки, а просто перезагрузят в надежде «а вдруг» и упрутся в LUKS. Это если ноутбук случайно потерялся.

легко компрометируемый

К случайной потере не имеет отношения отношения. Ты же не пишешь свой очень короткий длинный пароль прям на крышке, как раз для случая случайной потери, надеюсь.

А если он потерялся не случайно, то ты сам уже упомянул терморектальность бытия.

Brillenschlange ()

Для примера скорость запись на ext4 без LUKS (такая же скорость будет и при аппаратном шифровании, т.е. SED/FED, так как оно всегда работает):

➜ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync oflag=direct
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.852531 s, 1.3 GB/s

У btrfs где-то гиг бы был (но скорость будет падать в геометрической прогрессии вместе с ростом количества, записываемых данных). В этих тестах большей скорости можно добиться, играясь с параметром bs.

tz4678 ★★ ()
Последнее исправление: tz4678 (всего исправлений: 1)
Ответ на: комментарий от t184256

Нет никакого дисбаланса. Когда ноут остаётся без присмотра, например на ночь в офисе, он выключается. Да и в случае кражи прямо из под носа, на клавиатуре перебрать пароль проблематично, даже с использованием устройства, генерирующего ввод, никто этой фигнёй заниматься не будет, сразу достанут винт, а там уже капитально обломаются.

короткий и легко компрометируемый?

Это сколько символов по-твоему? В моём понимании это 8-10.

WitcherGeralt ★★ ()
Ответ на: комментарий от WitcherGeralt

никто тебе же не запрещает зашифровать пароль с помощью миллиона итераций, тогда пароль и из 6 символов брутить очень долго придется

tz4678 ★★ ()
Ответ на: комментарий от tz4678

зашифровать пароль с помощью миллиона итераций

Это же бесполезно?

тогда пароль и из 6 символов брутить очень долго придется

Нет. Только если если есть задержка.

Im_not_a_robot ★★★★★ ()
Ответ на: комментарий от WitcherGeralt

не так выразилсяю зашифровать ключ паролем с миллионом итераций

tz4678 ★★ ()
Ответ на: комментарий от Legioner
➜ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1      2826350 iterations per second for 256-bit key
PBKDF2-sha256    5454231 iterations per second for 256-bit key
PBKDF2-sha512    2092966 iterations per second for 256-bit key
PBKDF2-ripemd160  994853 iterations per second for 256-bit key
PBKDF2-whirlpool  738433 iterations per second for 256-bit key
argon2i       6 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      6 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1125.1 MiB/s      4245.7 MiB/s
    serpent-cbc        128b       115.7 MiB/s       797.9 MiB/s
    twofish-cbc        128b       231.2 MiB/s       428.9 MiB/s
        aes-cbc        256b       872.2 MiB/s      3422.4 MiB/s
    serpent-cbc        256b       122.7 MiB/s       814.3 MiB/s
    twofish-cbc        256b       242.2 MiB/s       440.8 MiB/s
        aes-xts        256b      3577.7 MiB/s      3407.3 MiB/s
    serpent-xts        256b       736.1 MiB/s       742.8 MiB/s
    twofish-xts        256b       401.6 MiB/s       396.3 MiB/s
        aes-xts        512b      2736.8 MiB/s      2949.3 MiB/s
    serpent-xts        512b       727.1 MiB/s       707.6 MiB/s
    twofish-xts        512b       406.5 MiB/s       414.6 MiB/s

Тут на производительность влияет BTRFS очень-очень существенно. Я ее использую чтобы данные важные не потерять. Самый нубский случай, набираешь sudo rm -rf / и далее автоподстановка тебе предлагает варианты, выбираешь нужный, нажимаешь Enter и сносится корень… Я не помню когда так последний раз делал, но тем не менее, очень вероятное развитие событий. Лучше перебздеть чем недобздеть. Однако, у BTRFS есть недостаток такой, что, если затрешь данные частично на разделе, то восстановить их нельзя будет. Если топикстартер такие фичи BTRFS как снапшоты не буднет использовать, то она ему не нужна.

tz4678 ★★ ()
Ответ на: комментарий от tz4678

я вспомнил когда в последний раз снапшоты эти мне пригодились. я снес (отменил все изменения в git, удалив untracked files) .env файл с паролем от базы и из снапшотов через snapper его восстанавливал

tz4678 ★★ ()
Ответ на: комментарий от tz4678

Тонкий. Я выбрал интерпретировать твой коммент как «шифрование LUKSом всего диска, включая Windows, вызовет проблемы с dualboot», потому что вообще не особо вижу смысл твоего коммента.

t184256 ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.