Garuda

Btrfs

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

LUKS

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

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

Вывод cryptsetup benchmark и интерфейс подключения твоего SSD в студию.

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

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, как посмотреть интерфейс?

=== 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

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

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

вопрос может глуповат, но все же задам, а пароль он в какой момент запрашивает? при старте grub’a?

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

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

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

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

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

А с точки зрения безопасности, для удобства я могу поставить такоц же пароль на LUKS, как и на учетку с админку?

Это последний глупый вопрос) спасибо большое за ответы

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

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

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

Потребуется, если у тебя других методов залогина нету (токен, отпечаток пальца, велосипед какой).

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

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

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

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

Или все же лучше чтобы они отличались?

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

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

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

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

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

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

$ 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

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

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

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

Btrfs

выбрось

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

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

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

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

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

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

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

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

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

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

Влияет. Насколько? - Зависит от того поддерживает ли процессор аппаратное шифрование (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 
➜ 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

короткий

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

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

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

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

Для примера скорость запись на 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.

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

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

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

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

Где ты там и что шифровать собрался? Давай на пальцах, для тупых.

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

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

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

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

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

➜ 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 как снапшоты не буднет использовать, то она ему не нужна.

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

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

Так LUKSовый еще медленнее подбирать.