Востановить соль, используемая для расшифровки каталогов в ext4

Welcome to zfs :)

Одно время пользовался nilfs2, считал эту систему просто гениальной. Но однажды (нет я не про оффициальный сайт, который сменили разработчики, после чего его купили шутники и разместили там ссылки на порно) что-то в системе сбойнуло и она не смогла себя восстановить.

Теперь с подозрением отношусь ко всем не «топовым» базовым файловым системам.

Хотя ZFS выглядит на голову выше nilfs2. Википедия пишет, что с 30 версии поддерживается шифрование, остаётся узнать сколько раз они дублируют соль :-D

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

Ответ:

точно зная пароль дала бы возможность её забрутфорсить

Нафига было делать 16 байт совершенно не ясно.

брутфорс на суперPC.

Нафига было делать соль размером 16 байт.

Позволил себе поиграть в эту новую, интересную игру. Ничего полезного не наиграл, зато появились вопросы:

Я правильно понимаю, что эта соль, хранящаяся внутри ext4, необязательна? Получается, что если e4crypt add_key -S s:salt (т.е. с явно указанной солью), то это нигде не записывается и никакой UUID не генерируется.

Т.е. в общем достаточно следующий раз повторить и ту же соль вручную (строкой или из файла), и ту же passphrase, чтобы получился ключ, для расшифровки каталога?

Тогда ведь соль может быть хоть в 1 байт же, вроде.

Получается, что поле Encryption PW Salt это один из способов хранить «пароль на бумажке», ладно половину пароля. Так ведь?

ТС хочет странного — самому себе небезопасного шифрования, чтобы все вскрывалось. Понятно, что такое желание от отчаяния.

Но то, что затирание первых байт превращает всё в кашу — это отличная фича безопасности. Ибо попробуйте-ка затереть обычные разделы на HDD, поседеете.

Опять дискредитация ext4, задрали уже

Я правильно понимаю, что эта соль, хранящаяся внутри ext4, необязательна? Получается, что если e4crypt add_key -S s:salt (т.е. с явно указанной солью), то это нигде не записывается и никакой UUID не генерируется.

Именно так. Но рассмотрим поведение обычного потребителя, котрый хочет зашифровать каталог. Что он делает. Берёт каталог, архивирует каким-нибудь rar-ом указывая пароль. Он интуитивно догадывается, что те кто знает этот пароль, смогут извлечь содержимое каталога, кто не знает, те не смогут (если пароль достаточно длинный и его не смогут подобрать).

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

Конечно-же после первого выстрела в ногу, пользователь начнёт задавать значение соли явно, но утерянные данные это уже не спасёт.

Получается, что поле Encryption PW Salt это один из способов хранить «пароль на бумажке»

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

Спасибо за тему, конечно. Вдруг надумаю на чем-то боевом это применять - а теперь уже опыт будет. Ваш опыт. )

Данная информация хранится всегда в одном и том-же месте в открытом виде на файловой системе.

Я попробовал - просто e4crypt add_key -S s:@ и ввел passphrase «1».

Т.е. мне надо просто помнить в голове - собака + единичка. Вполне себе работает. Без хранения в одном и том-же месте. И без Encryption PW Salt, конечно.

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

А, да, забыл - UUID которые генерируется, если не указывать -S - нигде на разделе не нашел, кроме одного места. Т.е. - если тупо грепать эту последовательность байт на сыром /dev/sd??, которую он нагенерил - то она только один раз там попадается.

Боюсь, сие означает, что оно не восстановимо.

Боюсь, сие означает, что оно не восстановимо.

Уважаемый Harliff заметил, что raid6 при порче одного диска может выдавать информацию как ему вздумается Востановить соль, используемая для расшифровки каталогов в ext4 (комментарий) А значит есть шанс вынуть правильное значение соли. Но в моём случае это скорее всего не сработает, так как fsck.ext4 мне уже восстановила суперблок, что привело к невозможности посмотреть то, что было.

Я на основании Востановить соль, используемая для расшифровки каталогов в ext4 (комментарий) сделал вывод, что факты записи в суберблок записываются в жунрал. Я сохранил все журналы что были и при появлении свободного времени планирую изучить их содержимое.

Ананимус в свою очередь в топике Востановить соль, используемая для расшифровки каталогов в ext4 (комментарий) обрал внимание, что GUID это не полный рандом а содержит информацию. И может даже быть сгенерированно от времени, но к сожалению, окзаалось что в этом случае сгенерировано достаточно случайно чтобы востановить его в рамках моей компетенции.

Вдруг будут ещё какие идеи, о которых я и вы подумали?

Если продолжать тему по «а теперь уже опыт будет. Ваш опыт», замечу фразу аннонимуса Востановить соль, используемая для расшифровки каталогов в ext4 (комментарий).

Но то, что затирание первых байт превращает всё в кашу

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

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

Раньше я был просто уверен, что шифрование блоков происходит независимо, но вставляется извесная затравка, например номер блока, но сейчас уже в этом не уверен, нужно проверять.

Вдруг будут ещё какие идеи

Кажется до меня дошел ваш «план Б», если UUID так и не найдётся.

У нас есть passphrase, и у нас есть derived_key (полагаю, мы же можем его e4crypt get_policy?), который получается из passphrase + salt через pbkdf2_sha512.

Если со стороны salt перебирать и пропускать через sha512, до тех пор пока не получится искомый derived_key не выходит, значит может быть есть способ наоборот, через какой-то «reverse sha512» пропускать passphrase и derived_key, чтобы получить любой подходящий salt )

Посмотрел что там делается с паролем и солью в кишках e4crypt.c, страшное дело. 65 тыщ раз взболтать и перемешать их - сильно впечатлило. )

Всё, наигрался, извините если помешал.

если UUID так и не найдётся.

То план Б это освободить место на диске от белого шума :-). Но перед удалением нужно убедится что соль нигде не осела и никаких способов её востановить нет.

«reverse sha512>

Об этом речи, конечно, не идёт.

В чём принято держать базу содержимого съёмных накопителей? (комментарий)

В чём принято держать базу содержимого съёмных накопителей? (комментарий)

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

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