Регистрация"Вечное" выолпнение dd if=/dev/urandom of=/dev/sdX
Решил переформатировать HDD в криптованный диск для бэкапов.
Следуя советам, данным на форуме, для перезаписи данных на диске дал команду:
Сначала думал сделать что-то типа или , но что-то подумалось мне, что это делается на текущую mount point, и – не знаю, прав я или нет, но мне показалось, что дать команду на раздел безопаснее.
И вот уже полсуток продолжается работа dd и нет ей ни конца, ни краю... Причем, sfill по одному разу или по два раза, имхо, давно бы уже прошла вся (обычно на такой же объем уходило неск. часов, но не полсуток, если конечно не делать sfill без аргументов -l или -ll, когда оно будет 30 с гаком раз перезаписывать.
И только сейчас сообразил, что /dev/urandom генерит данные постоянно, это же не клонирование с диска на диск, если его не остановить, то он будет делать это вечно, или пока компьютер/диск не сломаются :)
Мне кажется, что полсуток достаточно для 300-гигового диска, что называется, с "головой".
Как правильно определить/задать время для данной работы?
И еще возник вопрос, почему здесь рекомендуется юзать /dev/urandom, а не /dev/random?
Я посмотрел, это разные устройства, а не ссылки одного на другого. Согласно манам, /dev/random генерит еще более "случайные" данные. Разве он не лучше?
Или для этой цели такой необходимости нет, а времени/ресурсов займет больше?
В смысле, если разбить систему на пять разделов, то фс будет в пять раз устойчивей? Не производит сильного впечатления. Для устранения сбоев фс ежедневное резервное копирование намного надёжней (которое в любом случае необходимо). Если есть несколько физических дисков, тогда действительно размещение разных каталогов (/home, /var и т.д.) на разных дисках может дать заметную прибавку к скорости и надёжности. Это обычно используют на серверах, а не домашнем ПК. Про гостевые системы на виртуальной машине может вы и правы, я в них не разбираюсь.
ABCDEF – это был пример, понятно что нужно использовать произвольное число. А в чём смысл стойкости ключа при шифровании нулей – то что их расшифруют и смогут отделить используемые блоки от неиспользуемых? Это можно применить только как косвенное доказательства наличия осмысленных (ненулевых) шифрованных данных.
На моём компьютере: urandom 4.9 MB/s, openssl 51 MB/s, dmcrypt 65 MB/s. Скорость ненамного ниже, а команд вводить намного меньше. С вашими аргументами в пользу dmcrypt согласен, сам пользуюсь только им.
А в дисковом нет? Мало ли в каком проекте как реализовано...
Почему? По ссылке рассмотрен OpenSSL, про другие программы молчок.
Слом одной файловой системы не повелечёт за собой (по крайней мере, автоматически) слом других файловых систем. При инсталляции всегда советовалось использовать для /var, /tmp, /home и т.д. разные разделы и разные файловые системы (тип файловых систем может быть один — например, ext3). К примеру, у меня однажды грохнулся диск, я его понёс в сервис и там восстановили, что могли. Итог: файловая система на /usr не монтировалась, но я на неё забил, а все остальные ФС смонтировались на ура. Была бы одна ФС на весь диск — потерял бы кучу данных. Про резервное копирование согласен, но тем не менее.
комментариев: 9796 документов: 488 редакций: 5664
Можно почти с полной уверенностью сказать, что нет. Потому что в дисковом шифровании есть жёсткое требование на необходимость равенства размеров открытого текста шифртексту. Лишние служебные заголовки внутрь самого шифртекста там уже не впихнуть.
И ещё так балансируют нагрузку у высокопроизводительных серверов, предусматривают возможность более удобного изменения разделов и др.
Если только затирать данные, которые лежали на носителе раньше, то конечно без разницы. А так, всё верно, чтобы не различали испольуемые и неиспользуемые блоки. Не только для доказательства факта шифрования, но и затруднения косвенного анализа содержимого (насколько заполнен контейнер?).
Служебные заголовки всё равно есть (хидеры того же LUKS, к примеру) вопрос лишь куда их писать. Наверно, про существование отличимости данных от случайных надо всё равно в каждом случае уточнять у авторов шифровальной программы или внимательно читать официальную полную спецификацию на неё. «Требование на необходимость равенства размеров открытого текста шифртексту» — не концептуальное, а скорее техническое. Потенциально можно как угодно реализовать, даже так, что равными не будут (встроить ту же коррекцию ошибок поверх шифротекста, например...).
Почему OpenSSL'евский ГПСЧ настолько быстрее?
Гость выше предложил вариант с mbuffers, он чем-то хуже? Там dd с обоих сторон, можно второму dd задать оффсет.
Что конкретно имелось в виду? Можно поподробнее? От cold boot attack это всё равно не спасёт, впрочем.
unknown, по вашей ссылке только список файлов на скачку, а цитаты этой нет.
В начале записи, всё ж таки(?), т.е.
Нужный скрипт можно поместить в любое свободное место на диске на том же носителе, извлекать его по dd в память и расшифровывать с помощью openssl (команду прийдётся выучить наизусть). Извлечение/подключение всего остального с диска можно запихнуть в этот скрипт и запоминать не надо.
Хоть здесь и критикуется шифрование загрузчика в grub, но там идеологически сделали как-то так, да. Пусть это не идеальная защита, но выносить загрузчик на внешний носитель после этого стало, полагаю, проще, особенно по сравнению с выносом туда ядра, корневой файловой системы, init-скриптов...
MDC можно считать частью заголовка файла? Или они принципиально по всему PGP-файлу разбросаны? Если кто-то недоизучил формат и обрезал половину заголовка, дело в обрезальщике, а не в подходе.
Как называются объекты IVk и Ck? Вектор инициализации и ещё что-то? Что означает индекс k?
Смешно признаться, но только сейчас понял, что вектор инициализации обозначают как IV, потому что Initialization Vector. Раньше я думал, что его почему-то решили обозначать римской четвёркой. Начинаю подозревать, что точки обмена интернет-трафиком (IX) — это тоже не девятки...
Действительно ли шифрование нулей с рандомно выбранным IV намного хуже того, как сейчас генерируется urandom? Если нет, то почему для генерации urandom используется не шифрование нулей, а что-то иное? Была бы скорость повыше...
комментариев: 9796 документов: 488 редакций: 5664
Потому что он не полноценный ГПСЧ, а в приведённом примере блочный шифр AES в режиме CBC, шифрующий нули. В отличие от /dev/urandom, который на хэшах и который полноценный ГПСЧ, с непредсказуемостью влево за счёт перетирания внутренних состояний и с непредсказуемостью вправо при условии подкачки энтропии — наперёд заданной секретностью. AES-CBC с фиксированным IV, ключом и шифртекстом не имеет непредсказуемости влево или вправо, стоит только один раз восстановить ключ и вся сгенерированная им гамма восстанавливается. Но для затирания носителя или контейнера такие свойства по стойкости не нужны, поскольку атаки с утечками внутреннего состояния исключаются моделью угрозы. В отличие от /dev/urandom, к выходу которого (и отчасти входу) одновременно может иметь доступ масса пользователей, в т.ч. и недоверяемых.
См. выше про непредсказуемость влево-вправо и атаки недоверяемых пользователей, пытающихся восстановить внутренние состояния. Плюс реализация /dev/urandom исторически сложилась задолго до появления AES. Плюс для такой непредсказуемости нужно большее внутреннее состояние, чем может обеспечить AES за один проход, если всё-таки попытаться переделывать на него. Вот внедрят SHA3/Keccak и всё ускорится и упростится. И доказуемость безопасности улучшится. Или везде (кроме виртуалок?) будет быстрый аппаратный ГСЧ, как в последних версиях процов. Но в нём извечный вопрос о доверяемости к железке, хотя для затирания места подойдёт.
Хороший вариант, что-то протупил и не додумался на счёт такого очевидного решения — использовать дважды dd вместо cat, а посредине неважно что, pv или mbuffers.
Это не от этого. Хотя эти эти утилиты, кажется, могут работать и с TPM. Вообще, это самое спорное решение, потенциально снижающее безопасность в обмен на удобство, когда нужно управлять очень большим количеством шифрованных разделов (например, на RAID-массивах, подключаемых носителях). Может произойти утечка пароля в своп (маловероятно, плюс он шифрованный) или лишний процесс с правами рута может подсмотреть пароль (это всё равно компрометация системы, dmsetup --showkeys table и так покажет все ключи).
Если любопытно, откуда взялись идеи по "продвинутому" использованию cryptsetup/dmcrypt, то в Debian (в других дистрах этого может не быть) с пакетом cryptsetup, в каталоге /lib/cryptsetup/scripts ставится набор скриптов decrypt_derived, decrypt_gnupg, decrypt_keyctl, decrypt_openct, decrypt_opensc, decrypt_ssl. Их можно запихать в /etc/crypttab и/или в initrd или позаимствовать оттуда кое-какие идеи. В доках описаны примеры использования.
Из описания пакета keyutils в системе.
Ключ.
Они самые, Internet EXchange Points.
Не понял зачем грузить скрипт в память. Его дело – получить из пароля ключ и передать его dmcrypt. Создаётся виртуальное шифрованное устройство и соответствующий ему ключ хранится в памяти. Скрипт может храниться где угодно, защита ключа обеспечивается стойкостью алгоритмов, а не сокрытием скрипта. Основной секрет – это пароль и он хранится в голове.
Подумалось: фишеры через n лет: «откройте терминал, сделайте
su -l rootsudo bash, введите dmsetup --showkeys table, скажите получившиеся цифры...»Мы о разных задачах с вами говорим. Я — про бессигнатурное шифрование. Цель скрипта — подмонтировать всё, что нужно (а там прийдётся область секторов на диске явно указывать и т.д.) с нужными режимами, заголовками, выводом ключей, возможностью интерактивного выбора, что подключать и т.д. Но сам скрипт надо откуда-то брать, вот его и можно записать на диск так, как я выше написал. Кроме того, один из секретов при выводе ключа — файл с солью (salt). Чтобы salt отрицаемо скрывать, лучше использовать бессигнатурное шифрование на том же (или другом) носителе, куда эта salt будет отрицаемо записана. Метод извлечения salt с диска тот же: dd в файл в память, расшифровать openssl'ем.
комментариев: 9796 документов: 488 редакций: 5664
А то, те, кто с этим не сталкивался или не задумывался, не понимают, о чём речь, зачем это нужно или понимают неправильно, или относятся предвзято.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
Подумалось ещё на счёт этого:
Чтобы не вспоминать тонкости режимов шифрования можно использовать только openssl enc -aes-256-cbc и задать неслучайный пароль. Вектор инициализации при этом будет случайный, а при использовании в аналогичных целях gnupg, ещё и случайный ключ, зашифрованный на пароль. После окончания можно просто затереть из /dev/urandom начало диска, куда попал заголовок.
Ещё надёжнее вообще не записывать заголовок на диск, отрезав его вторым dd:
комментариев: 9796 документов: 488 редакций: 5664