8-10 раз надо повторять только если ожидается разбор диска на блины и изучение каждого под электронным микроскопом, чем будут заниматься только очень специфические люди в очень специфических случаях. А в большинстве ситуаций хватит shred/srm или одного прохода dd.
Не секурненько, расшифруют что было записано и узнают что там было до. Это на HDD, на SSD файл может быть просто сохранён в некоторой любой области, потом у контроллера спросят этот файл вернуть и он отдаст. Хотя с таким подходом и на HDD получится, но на SSD можно и случайно.
И это, рекомендую 16 терабайтные диски, технология пока не позволяет их прочитать, но прогресс не стоит на месте и лучше шифровать чтобы файл был максимум в памяти (атаки на память самые простые кстати). Не забудь зарандомить память потом.
Не имею возможности проверить, но таится во мне подозрение, что 1 прохода будет мало и при восстановлении файлов, что-нибудь да может восстановится. Метод Гутмана и всё такое.
Быть может проще заранее использовать шифрование. Избавится от ключа проще, чем диск перезаписывать.
Опять же требует разбирать диск в лаборатории. Что долго, дорого и будет сделано только если у атакующего много много денег и он точно уверен что не выкинет их зря.
не лучше нагреть? чай не из вольфрама блины там, комнатная электропечка справится. немного долго конечно, зато основательно. только надо смотреть чтобы электросеть не подвела.
Не факт. Нет никакой гарантии что там фирмварь на самом деле не прячет твои файлы где-то. Так-то и в HDD фирмварь может детектить попытки затереть файлы утилитами типа shred и специально их припрятать в неиспользуемом месте для ФБР.
Deleted ()
Последнее исправление: pyroman
(всего
исправлений: 1)
Всё это ерунда и не спасёт при термо-ректальном криптоанализе.
Если что-то нужно удалить, то для начала нужно создать шифрованный том и потом на него писать файлы, и при удалении не нужно будет нервничать и затирать весь диск по десять раз. Главное ключи правильно заныкать, а это куда проще.
Фирмарь знает. Если информация и затрется, может оставить по крайней мере лог с именами файлов.
Что она знает? А если в данном конкретном случае не лог с именами фалов нужен, а что-то другое? Как угадать среди миллионов проданных устройств, в каком случае какой тип данных важен?
Нет, это например, десять раз записать в определённый участок из /dev/urandom.
А сколько просто перезаписывается разной информации? Как понять, какую именно надо оставить и спрятать?
Очень просто. Когда файл просто штатно удаляется, значит он просто удаляется. Когда сектора пытаются ещё и поверх несколько раз перезаписать, как поступают утилиты типа shred (идёт в coreutils) и тому подобные, значит там что-то такое интересное было.
Deleted ()
Последнее исправление: pyroman
(всего
исправлений: 3)
Когда сектора пытаются ещё и поверх несколько раз перезаписать,
Когда пытаются перезаписать все сектора (запись в новый файл), как ты поймёшь, какие именно сектора были интересны? А если то же самое делают через сутки?
Когда пытаются перезаписать все сектора (запись в новый файл), как ты поймёшь, какие именно сектора были интересны?
Те самые и были. В чём проблема-то?
А если то же самое делают через сутки?
Что именно? Десятикратную перезапись растягивать на десять суток? Можно, но так на практике никто не делает, удалить ведь надо срочно, а то вдруг что-то внезапное произойдёт.
Сколько сможет сохранить, столько и сохранит. Программе-то всё равно, она не для себя это делает, а спецы потом разберутся со специальным софтом, у которого ключик к контроллеру есть. Если шредится весь диск, можно сделать вид что шредится. Ты всё равно об этом не узнаешь, если не будешь низкоуровнево в обход контроллера прямо поверхность диска читать. Контроллер может просто пометить сектор что он «зашреденый» будто-бы, а при чтении сектора выдавать рандом не с диска, а из своего встроенного /dev/urandom. Алсо когда ты шредишь весь диск, он может предварительно данные перемещать туда-сюда и спасти их от шрединга. Короче, контроллер там может мутить что угодно внутри, ты этого просто так не увидишь.
А ещё у тебя диск может на 1ТБ, а на самом деле нам на блине 2ТБ, и этот лишний ТБ тебе не показывают, его контроллер использует для этих самых дел.
Deleted ()
Последнее исправление: pyroman
(всего
исправлений: 1)
Он же не мгновенно всю поверхность затирает. Скопировал первый сектор в другое место, затёр, вернул обратно, занялся следующим. Или вообще ничего не затирал, а сделал вид. Вытворять там контроллер может что угодно, мы этого не видим.
Deleted ()
Последнее исправление: pyroman
(всего
исправлений: 1)
Скопировал первый сектор в другое место, затёр, вернул обратно, занялся следующим.
На сколько у нас там i/o просело? :-) Это если ещё не учитывать, что мы файл пишем, а фирмварь не знает, это мы затираем, или пишем, как раз то самое, интересное. Вернёшь - запорешь данные. В общем, ты какой-то фантастики начитался, либо киношек про шпионов насмотрелся.
где сохранит? Диск на X байт, а шредю X байт. Где он сохранит эти X байт? На запасном маленьком квантовом хранителе в углу микросхемы?
Программе-то всё равно, она не для себя это делает, а спецы потом разберутся со специальным софтом, у которого ключик к контроллеру есть. Если шредится весь диск, можно сделать вид что шредится. Ты всё равно об этом не узнаешь, если не будешь низкоуровнево в обход контроллера прямо поверхность диска читать.
конечно узнаю. Просто прочту весь диск заново и сравню контрольную сумму.
Контроллер может просто пометить сектор что он «зашреденый» будто-бы, а при чтении сектора выдавать рандом не с диска, а из своего встроенного /dev/urandom. Алсо когда ты шредишь весь диск, он может предварительно данные перемещать туда-сюда и спасти их от шрединга. Короче, контроллер там может мутить что угодно внутри, ты этого просто так не увидишь.
если я буду считать контрольную сумму потока из /dev/urandom, и потом после шреда читать диск и сравнивать сумму, то никак контроллер не сможет ничего сделать.
А ещё у тебя диск может на 1ТБ, а на самом деле нам на блине 2ТБ, и этот лишний ТБ тебе не показывают, его контроллер использует для этих самых дел.
Ну а ещё эти затиралки особенно бесполезны на SSD, т.к. нет никакой гарантии что контроллер затрёт именно те физические сектора, т.к. для равномерного распределения износа ячеек контроллер там творит всякое.
Ну а ещё эти затиралки особенно бесполезны на SSD, т.к. нет никакой гарантии что контроллер затрёт именно те физические сектора, т.к. для равномерного распределения износа ячеек контроллер там творит всякое.
Шансы возрастают, да. Но мы об уничтожении отдельных файлов говорили вроде. А так, я и не утверждал что сохранят все 100% данных. Контроллер может предпринимать что-то, если есть такая возможность. Когда шредишь весь диск, шансов у него может и нет. А может в таком случае какую-то инфу всё равно возьмёт да и сохранит, хотя бы метаданные какие нибудь в каких нибудь служебных местах, там много не надо. И журнал операций.
где сохранит? Диск на X байт, а шредю X байт. Где он сохранит эти X байт?
У SSD (да и у HDD тоже) есть резервные блоки. Поэтому не «диск на X байт, а шредю X байт», а «есть возможность пошредить X байт, а всего накопитель внутри содержит αX байт, где α>1».
Но это в теории. На практике нужно ещё мозг сломать, чтобы понять, как контроллер распределяет данные. Сомневаюсь, что детали работы контроллеров публично доступны.
Даже после тупого rm восстановить файл будет стоить столько денег, что никто за это браться не будет! И ТС может успокоить свои маниакальные наклонности.
P.S. Терморектальный криптоанализ — значительно более дешевое и действенное средство против таких параноиков! Ну удалишь ты файл, и чо? Никому нафиг не надо его восстанавливать, достаточно засунуть в задницу паяльник, и жертва с радостью все, что нужно, доложит, лишь бы ускорить свою смерть!