LINUX.ORG.RU

Вопросы по шифрованию разделов

 , , ,


1

1

Добрый день. Хочу зашифровать все данные на SSD-ноута с системой и доп. винчестере с бекапами и образами виртуальных машин. Скопился ряд вопросов, на которых хотелось бы получить ответы.

1. Система у меня стоит на SSD и имеет один раздел / (вместе с хомяком). Думаю имеет смысл перенести всё это на lvm, чтобы шифровать только /home. Или лучше всё сразу (тогда lvm не нужен)?

1.1 luks я так понимаю лучший выбор для этого?

2. Для внешних винтов думаю стоит юзать encfs с blowfish. Или лучше везде одни и те же инструменты использовать? encfs универсальнее, но мне в принципе по-барабану, т.к. винт этот стоит в ноуте и больше нигде кроме linux не используется.

2.1 какой по размеру блок данных ФС лучше использовать на x64?

2.2 заметно ли ухудшится скорость при работе с виртуальными машинами записанными на винт?

(пока что всё, но вопросы будут дополняться по мере возникновения)

Спасибо.

★★★★★

Ответ на: комментарий от emulek

Продолжаешь показывать свою некомпетентность. Знаешь про keyfiles? Молодец, а теперь подумай, что и они проходят через PBKDF2. Больше того, судя по этому документу в хедере даже не хранится информация о том, что это за ключ: пароль или кейфайл.

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

Продолжаешь показывать свою некомпетентность.

facepalm

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

какая разница между «паролем» и «кейфайлом»?

Знаешь про keyfiles? Молодец, а теперь подумай, что и они проходят через PBKDF2.

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

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

какая разница между «паролем» и «кейфайлом»?

Если нет разницы, зачем ты мне про enthropy ссылку давал?

что я должен «надумать»?

Подумать о своем комменте, по поводу того что чем медленнее алгоритм шифрования, тем он надежнее.

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

Тоесть самое менее ресурсоёмкое aes-xts-essiv, или даже aes-xts-plain?

aes - алгоритм шифрования, cbc и xts - блочные режимы шифрования, essiv, plain - алгоритмы генерации начального вектора.

0 417792 crypt aes-xts-plain64 e8cfa3dbfe373b536be43c5637387786c01be00ba5f730aacb039e86f3eb72f3 0 8:16 0
|    |     |    |   |     |                                 |                                   |  |   | 
start|     |    |  mode   IV                                |                                   |  |   offset
     size  |  cipher                                        |                                   |  device
         target                                        256bit-key                          IV offset


0 417792 crypt serpent-cbc-essiv:sha256 a7f67ad520bd83b9725df6ebd76c3eee 0 /dev/sdb 0
|    |     |      |     |     |     |                |                   |     |    | 
start|     |      |    mode   IV  IV-opts            |                   |     |   offset
     size  |    cipher                               |                   |  device
         target                                 128bit-key          IV offset

У меня выходило, что самый быстрый aes-xts-plain256 (128), но он же подвержен ряду атак, как за счёт ivs-plain, так и режима xts, но это если вдаваться в теорию.

Тесты из сети показывают примерно ту же картину.

Поясни плз что значит бекапить хидеры. Можно пример какой нибудь, или пруф?

cryptsetup luksHeaderBackup --header-backup-file /надёжное_место/head_sdX3 /dev/sdX3
cryptsetup luksHeaderRestore --header-backup-file /надёжное_место/head_sdX3 /dev/sdX3

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

Естественно, те пароли/ключи которые были в слотах хедера перед бэкапом и будут использоваться при его восстановлении.

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

Кстати, с ядрами проблем нет, т.к. у меня лайфсиди арча

А ну тогда да, загрузил, примонтировал, зачрутился, сделал.

А по скорости ж по идее пофиг lvm в luks, или luks в lvm?

Не располагаю :)

Ещё можешь поискать cryptsetup, ssd и прочее на pgpru.com, вот в тему.

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

не нужно шифровать. Нужно подписывать. А потом проверять подпись — если это твоя подпись, то очевидно бинарник цел. Можно даже обойтись md5, главное хранить их на зашифрованном разделе.

Серьёзна?

А помимо бинарей, все lib, сверять, для чего запилить самосборный initramfs который проверит себя, а потом на ранней стадии будет проверять подгружаемое и далее всё остальное. За пол дня взлетит, чо.

Но даже и не в этом-то дело.

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

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

Мораль: тебе не запишут ничего и не скажут, что это твоё.

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

А помимо бинарей, все lib, сверять, для чего запилить самосборный initramfs который проверит себя, а потом на ранней стадии будет проверять подгружаемое и далее всё остальное. За пол дня взлетит, чо.

а если ты это зашифруешь, будет быстрее? Почему?

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

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

Конечно можно использовать шифрование И подпись, но зачем тут шифрование?

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

мне не скажут, что /usr/bin/sudo моя? Няня, я у них поел.

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

Если нет разницы, зачем ты мне про enthropy ссылку давал?

что-бы ты знал, где и как брать ключи.

Подумать о своем комменте, по поводу того что чем медленнее алгоритм шифрования, тем он надежнее.

ну подумал. И в чём я не прав? Если ты намного компетентнее меня, тогда объясни. А не задавай глупых вопросов.

В конце концов, любая твоя безопасность завязана на некий пароль, из небольшого множества. Keyfile тут не причём, ибо я его не хуже тебя могу прочитать. А множество паролей ограничено, ибо пароль 01b0294eb0d8d83c56bf4fdd7fce6508845e777ab13f834d24c35d98b34a0bd689789c87967342b7b004680f5fd6fcc7e914999235272fdceb940433762650d3 ты не запомнишь.

Ну а простой пароль я просто тупо подберу, если конечно твоя криптосхема достаточно быстрая.

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

а если ты это зашифруешь, будет быстрее? Почему?

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

Впрочем, запили «пруф оф консепт», выложи обзор.

вообще-то ты путаешь «шифрование» и «подпись».

Нет, не путаю.

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

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

И ты берёшься, не имея ключа от него записать внутрь фотку котика?

Лол.

Конечно можно использовать шифрование И подпись, но зачем тут шифрование?

Шифрование затем, а вот зачем подпись? %)

мне не скажут, что /usr/bin/sudo моя? Няня, я у них поел.

Тебе скажут, что твоя переписка с Майклом Макфолом о выделении грандов на защиту поней на лоре найдена у тебя в

/usr/local/lib/python2.7/dist-packages/мокрыеписечки/цру/пони/

Дальше посмотрим чего ты поешь.

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

Просвети.

а что просвещать? Сам просвещайся: напиши программу, которая считает 100500 md5(или там sha, или блоков AES256 шифрует, не важно), и запусти. Посмотри, сколько она съест ватт-часов. Потом заряди батарею полностью, выполни cpufreq-set -r -g powersave, и снова запусти тест. Посмотри, сколько съело ватт-часов.

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

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

что-бы ты знал, где и как брать ключи.

Врешь, чтобы увести разговор в сторону.

И в чём я не прав?

intel опустила в унылое говно AES256, ибо теперь любой му*ак подберёт Over9000 паролей за секунду

У «м*дака» есть два варианта: перебирать сразу мастер-ключ или перебирать пароли. Про второе тебе уже все объяснено (скорость перебора упирается в вычисление хеш-функциия), в первом варианте не имеет значения, будет ли перебираться ключ 10^20 лет или 10^15. Это конечно, при условии, что мастер-ключ получен из нормального /dev/random.

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

нет. Ибо враг «тупо не введёт пароль». Откуда система узнает, что её не скомуниздили только-что?

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

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

напиши программу, которая

Которая работает линейно, ога.

У тебя работа устойчиво ассоциируется с dd if=/dev/zero of=/workfile ?

В основном идёт вялое рандомное чтение/запись, что по части криптопрослойки на проце вообще не сказывается.

Скорость, кстати, тоже практически не просядет, так как дешифруются сотни килобайт.

Но, конечно, если ты пришёл на работу, подключил инет, и начал хэшить 800гб недокачаных торрентов, тут да.

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

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

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

если ты исключаешь атаку злой горничной, то какой смысл шифровать/подписывать системные файлы? Ну вот я сейчас с нетбука пишу, там как раз вся система не подписана и не зашифрована. Ну и что тебе даст кража моего нетбука? И да, /home/ смонтирована в память, и лежит на носителе в зашифрованном виде. Ключ лежит там же, но зашифрован пассфразой, которую я ввожу на каждой загрузке.

И ты берёшься, не имея ключа от него записать внутрь фотку котика?

AFAIK это твоя криптофс ещё и подписывает файлы. Просто ты об этом не в курсе наверное.

Шифрование затем, а вот зачем подпись?

для защиты от подмены нужна подпись. Для защиты от прочтения нужно шифрование.

Тебе скажут, что твоя переписка с Майклом Макфолом о выделении грандов на защиту поней на лоре найдена у тебя в

оригинально. А найти в моей квартире 3 килограмма героина разве не проще? Оно и для судьи будет понятнее. А то статьи про поней ещё нет в УК, а про героин — есть.

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

что-бы ты знал, где и как брать ключи.

Врешь, чтобы увести разговор в сторону.

ссылка, которую я дал, врёт? Или она не имеет отношения к генерации криптоключей? Тогда рассказывай, как их сейчас модно генерить.

У «м*дака» есть два варианта: перебирать сразу мастер-ключ или перебирать пароли. Про второе тебе уже все объяснено (скорость перебора упирается в вычисление хеш-функциия)

я не понял объяснения: как оно «упирается», если твоя функция самая быстрая? Очевидно, что чем быстрее хешфункция, тем хуже оно «упирается».

Перебирать ключи из 2048и бит я и не предлагал. Там совсем НЕ 10^20 лет, а НАМНОГО БОЛЬШЕ.

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

Очень просто: при загрузке ты вводишь пароль для расшифровки /home, в /home лежит ключ, который открывает доступ к винчестеру.

КУДА вводишь? Система-то зашифрована паролем, который лежит на $HOME. Как ты её загрузил с зашифрованного винчестера ПЕРЕД расшифровкой?

Я вчера проверял - всё работает.

что, дал свой ноут какому-то му*аку, и он не смог загрузится?

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

Очевидно, что чем быстрее хешфункция

Ты не понимаешь разницы между хеш-функцией и алгоритмом шифрования?

как оно «упирается», если твоя функция самая быстрая?

Про это тоже говорилось выше. См. параметр cryptsetup'а --iter-time

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

то какой смысл шифровать/подписывать системные файлы?

Это нужно тому, кому нужно, и не нужно тому, кому не нужно, это же очевидно.

твоя криптофс ещё и подписывает файлы. Просто ты об этом не в курсе наверное.

Ты, видимо, тоже.

для защиты от подмены нужна подпись. Для защиты от прочтения нужно шифрование.

Да ты шта?
Шифрование не обеспечивает целостности?
И не гарантирует защиты от подмены?

Шифротекст (блок) по сути и есть подпись исходного текста мастер-ключом. Но это не подпись в распространённом понимании. И никакой дополнительной подписи блоков нет.

А найти в моей квартире 3 килограмма героина разве не проще?

Мы тут о правовом поле, там как раз шифрование на страже приватности и аутентичности данных.

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

Которая работает линейно, ога.

а есть нелинейные программы шифрования? Очень интересно...

В основном идёт вялое рандомное чтение/запись, что по части криптопрослойки на проце вообще не сказывается.

угу. Потому-что дешёвый HDD тормозит намного сильнее, и сильнее жрёт батарейку. Принято. Но зачем ты powersave рекомендуешь? Какой в ней профит-то? Или ты просто гордишься своими знаниями, которые не связаны с темой обсуждения?

Скорость, кстати, тоже практически не просядет, так как дешифруются сотни килобайт.

не, ну если твой HDD читает со скоростью X, а процессор со скоростью Y, причём X<Y, то скорость конечно не просядет. Вот только энергии тоже не сэкономится. Просто загрузка CPU будет больше. Вот в этом моём неттопе всего две частоты: 1600, и 800. Ну включу я 800, ну будет работать вдвое медленнее(расшифровка. Но скорость да, не пострадает, ибо HDD тупит всё равно сильнее), но считать-то столько же. А значит и энергии будет потрачено столько же (а IRL даже больше).

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

а есть нелинейные программы шифрования? Очень интересно...

Линейно - имеется ввиду большой объём данных запущенный на засекаемое время.

В данном контексте, не линейно, произвольный доступ к небольшим блокам данных размазанный во времени.

Скорости винта за скобками, суть в том, что при серфинге, кодинге у тебя идёт сохранение файла в 100кб раз в минуту и скажем чтение/запись кеша ещё на пару метров, при таких объёмах визуально нет разницы, что у тебя 100мб/с, что 40.

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

Перестань шланговать.

Открой gnome-power-statistics, история, скорость, погляди сколько ватт утекает при ondemand, сколько при powersave.

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

Ты не понимаешь разницы между хеш-функцией и алгоритмом шифрования?

я-то понимаю. А вот ты — не очень. Если оперируешь результатами теста, в котором вперемешку собраны хешфункции и функции шифрования.

На самом деле, важна скорость и того, и другого. И то и другое должно быть достаточно медленным. А атака будет направлена на то, что побыстрее.

Про это тоже говорилось выше. См. параметр cryptsetup'а --iter-time

этим ты затрудняешь атаку на угадывание ключа. Т.е. только одно время. На самом деле, это нужно только для всяких маздаев. В нормальной системе /dev/random тебе просто не даст нужное количество бит достаточно быстро. Будешь стоять, и ждать, сколько-бы там в --iter-time не вписал.

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

Это нужно тому, кому нужно, и не нужно тому, кому не нужно, это же очевидно.

т.е. засчитывать?

твоя криптофс ещё и подписывает файлы. Просто ты об этом не в курсе наверное.

Ты, видимо, тоже.

ext4 что-то подписывает? Да, не в курсе.

Шифрование не обеспечивает целостности? И не гарантирует защиты от подмены?

нет конечно. И не должно обеспечивать. Наверное ты «шифрование И подпись» называешь «шифрованием».

Шифротекст (блок) по сути и есть подпись исходного текста мастер-ключом. Но это не подпись в распространённом понимании. И никакой дополнительной подписи блоков нет.

а где я говорил про «дополнительные блоки с подписью»?

А найти в моей квартире 3 килограмма героина разве не проще?

Мы тут о правовом поле, там как раз шифрование на страже приватности и аутентичности данных.

что за бред? Какая разница? Героина у меня в квартире нет, также как и нет неведомой петиции в защиту поней. Не увлекаюсь подобным.

И если ты про «правовое поле», то тебе ещё надо доказать, что лоли на моём HDD принадлежат мне. Может это случайная комбинация байтов? А может это подделка из p2p? А может я просто качал «алису в стране чудес», а скачал CP. И это сложнее, чем с героином. Я не общаюсь с наркоманами, а вот с педофилами в Сети — я не знаю.

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

этим ты затрудняешь атаку на угадывание ключа.

На скорость перебора.

Т.е. только одно время.

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

На самом деле, это нужно только для всяких маздаев.

Расширь мысль.

В нормальной системе /dev/random тебе просто не даст нужное количество бит достаточно быстро. Будешь стоять, и ждать, сколько-бы там в --iter-time не вписал.

--iter-time не призван исправлять недостаток энтропии, а призван читай выше.

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

я-то понимаю. А вот ты — не очень.

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

Будешь стоять, и ждать, сколько-бы там в --iter-time не вписал.

Лол, при каждом монтировании шифрованного раздела?

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

Скорости винта за скобками, суть в том, что при серфинге, кодинге у тебя идёт сохранение файла в 100кб раз в минуту и скажем чтение/запись кеша ещё на пару метров, при таких объёмах визуально нет разницы, что у тебя 100мб/с, что 40.

оно всё равно кешируется в памяти в открытом виде.

Перестань шланговать. Открой gnome-power-statistics, история, скорость, погляди сколько ватт утекает при ondemand, сколько при powersave.

ладно, с человеком, который не понимает, чем энергия отличается от мощности, мне говорить не о чем.

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

Шифрование не обеспечивает целостности? И не гарантирует защиты от подмены?

нет конечно.

GOTO файл-контейнер.

Героина у меня в квартире нет

Я в недоумении %)

тебе ещё надо доказать, что лоли на моём HDD принадлежат мне. Может это случайная комбинация байтов?

Ага, а сам ноутбук - вообще не ноутбук, а неопознанная флуктуация струн пространства породившая скопление атомов, которые выглядят как ноутбук, да?

Я тебе не про хиханьки, а про реальную правовую практику, по крайней мере из некоторых стран.

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

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

т.е. чем крепче ворота, тем лучше? А про забор можно забыть? Зачем дешифровать мастер ключ, если его просто можно подобрать один из небольшого множества? Да пусть твой ключ хоть час генерится, важно, что их у тебя мало. И что все твои возможные ключи можно быстро проверить.

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

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

тогда это будет другая функция.

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

да ты можешь хоть весь день крутить свой цикл. Это никак не отразится на множестве возможных ключей, и на скорость проверки каждого. А из чего ты начал свой цикл, я не узнаю, да. Ну а зачем это мне?

при каждом монтировании шифрованного раздела?

вот уж точно — лол. При чём тут монтирование? Ты же про создание мастер-ключа говорил только-что? Или про что?

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

GOTO файл-контейнер.

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

ну давай, дай. Рассказывай, как ты его сделал. Или алгоритмы ты в секрете держишь, да?

Я в недоумении

ну что поделать... Нет. Как и твоих поней.

Ага, а сам ноутбук - вообще не ноутбук, а неопознанная флуктуация струн пространства породившая скопление атомов, которые выглядят как ноутбук, да?

при чём тут сам ноутбук? Ноутбук — есть. И файл «алиса в стране чудес» там есть. Что дальше?

Я тебе не про хиханьки, а про реальную правовую практику, по крайней мере из некоторых стран.

что ты там про «практику» говорил? Кроме какого-то бреда. Давай факты сначала, а уж потом свои выводы и выводы какой-то тусовки. А то я здесь только выводы видел, с отсылкой хрен пойми куда.

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

Ты же про создание мастер-ключа говорил только-что?

Не мастер ключа, а кейслотов.

Это никак не отразится на множестве возможных ключей

Которых будет 2^128, а то и 2^256. Ты советуешь человеку брать самый медленный алгоритм, чтобы злоумышленник подобрал ключ за (например) 10^200 лет, а не за 10^100? С практической т.з. это одинаково неперебираемо.

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

не. Вся эта твоя «нелинейность» не имеет отношения к реальности. Шифрование вполне линейно, как и dd. Просто потому, что «нелинейное» чтение даже без всякого шифрования невозможно IRL, ибо долго.

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

Рассказывай, как ты его сделал. Или алгоритмы ты в секрете держишь, да?

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

Вариант приштукотурить кота открытым текстом снаружи отпадает.

Вариант поместить кота в другой контейнер схожего объёма и качеств не вариант ибо он не будет успешно дешифрован моим паролем от оригинального контейнера.

что ты там про «практику» говорил?

Искать пруфы, как обычно не буду.

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

Опять же если тебе надо это изучить - ты найдёшь _сам_. Хинты я тебе дал.

В крайнем случае погляди на то как формирует выдачу sleuthkit/autopsy.

с отсылкой хрен пойми куда

пгпру это найавторитетнейший ресурс в узких кругах :)

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

Которых будет 2^128, а то и 2^256.

вот в этом твоя ошибка: если у тебя 100500 паролей, то из них получится ровно 100500 ключей(однозначных, считаем, что коллизий нет. Если есть, то всё ещё печальнее). И нет никакой разницы, сколько там бит.

Ты советуешь человеку брать самый медленный алгоритм, чтобы злоумышленник подобрал ключ за (например) 10^200 лет, а не за 10^100? С практической т.з. это одинаково неперебираемо.

Понимаешь... Вот тебе хеш: 01b0294eb0d8d83c56bf4fdd7fce6508845e777ab13f834d24c35d98b34a0bd689789c87967342b7b004680f5fd6fcc7e914999235272fdceb940433762650d3 Ты точно уверен, что для обращения этой sha512 нужно перебрать все 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084096 комбинаций, ли хотя-бы значительную их часть?

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

Вариант поместить кота в другой контейнер схожего объёма и качеств не вариант ибо он не будет успешно дешифрован моим паролем от оригинального контейнера.

ты всё равно шифруешь не целиком, а блоками. Есть возможность подмены этих блоков другими(с твоего же диска).

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

ну и что из этого следует? Если у меня действительно такая ерунда есть, то её хеш — вполне себе доказательство моей вины. Как и подписи понятых под протоколом. А при чём тут шифрование?

Ты можешь внятно выразить свою мысль без «мокрыхписек», «цру» и «пони»?

Опять же если тебе надо это изучить - ты найдёшь _сам_. Хинты я тебе дал.

ЧТО изучать-то? Мне не нужны твои хинты, русским языком вырази свою точку зрения, без доказательств. А то ты тут что-то доказываешь, но я не пойму ЧТО именно?

В крайнем случае погляди на то как формирует выдачу sleuthkit/autopsy.

ещё раз: ЧТО доказывает этот вывод?

пгпру это найавторитетнейший ресурс в узких кругах

очень хорошо. Ну не все знакомы с К.О. оттуда. ЧТО тебе очевидно, как и остальным криптоаналитегам пгпру?

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

У тебя опять мысли поплыли куда-то в сторону от производительности алгоритмов.

Ты точно уверен, что для обращения этой sha512 нужно перебрать все

Этот твой хеш достаточно загуглить. В криптосистеме есть как минимум соль.

если у тебя 100500 паролей, то из них получится ровно 100500 ключей

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

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

1) весь раздел целиком (кроме /boot), или создать lvm в котором выбрать шифрование сугубо /home? Как считаете? Или по скорости я почти ничего не потеряю в первом случае?

Зачем тебе вообще LVM? Он полезен если ты хочешь ещё и swap шифровать и при этом иметь возможность s2disk, а так он тебе не нужен.

Шифровать лучше всю систему так как какая-нибудь потенциально компрометирующая информация может попасть в /root /tmp или /var

2)

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

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

Вообще у SSD и жестких дисков есть функция — пароль. Задаётся в BIOS. Шифрования может там и нет или есть но ненадёжное, но чтоб сбросить пароль, не уничтожив данные придётся повозиться.

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

Что вдвойне уныло если ноут, надо откручивать, вытаскивать

Зачем?! Просто LiveCD или LiveUSB любой берёшь и всё.

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

У тебя опять мысли поплыли куда-то в сторону от производительности алгоритмов.

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

Этот твой хеш достаточно загуглить

загугли. Раз «достаточно». В гугле забанили что-ли? Речь как раз и о том идёт, что такие хеши легко обратить.

В криптосистеме есть как минимум соль.

а на солнце есть пятна. Что дальше?

если у тебя 100500 паролей, то из них получится ровно 100500 ключей

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

это уже детали реализации. Важно то, что если для записи 3х битов использовать Over9000 битов, то это всё равно будет 3 бита. И способ преобразования значения не имеет, если оно однозначно(а если нет, то оно не годно для шифрования).

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

Зачем?! Просто LiveCD или LiveUSB любой берёшь и всё.

Это мой опыт :) лайвсд не вариант, всунут второй винт, лайвюсб не заготовил, пришлось выкрутить один винт и заменить на третий, который был запасным иногда подключаемым зеркалам рэйда.

Кстати, довольно удобно бэкапить массивы, подрубил третий винт,
mdadm --add / mdadm --grow --raid-devices=3 / mdadm --remove / mdadm --grow --raid-devices=2

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

Речь как раз и о том идёт, что такие хеши легко обратить

Ну? Рассказывай, как ты будешь обращать sha512.

Важно то, что если для записи 3х битов использовать Over9000 битов, то это всё равно будет 3 бита.

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

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

ты всё равно шифруешь не целиком, а блоками. Есть возможность подмены этих блоков другими(с твоего же диска).

Но кота ты таким образом не сформируешь внутри контейнера.

Ты можешь внятно выразить свою мысль

Твои носители по тем или иным причинам изъяты для экспертизы, а к самому тебе сильная неприязнь, чтоб на тебя давить/закрыть, в суд надо предоставить reasonable evidence, которое форенсики формируют достаточно дотошно, у мистера Х на винте Y марки WD0000 в результате сканирования блоков файловой системы XZY в удалённом файле file92813 из блоков 123412, 1243454, 856343 была найдена фраза «сегодня в 21:20 у бульвара», далее следуют хэши, тайминги и прочая всячина.

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

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

Ну? Рассказывай, как ты будешь обращать sha512.

ну ясное дело, что не руками. Перебором и буду. Всего множества, мощность которого у нас 100500. Я думаю, одной секунды мне хватит(точнее моему CPU).

Важно то, что если для записи 3х битов использовать Over9000 битов, то это всё равно будет 3 бита.

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

для тех кто в танке: мощность множества паролей НЕ меняется, если эти пароли хешировать. Оно может только уменьшаться, если хешфункция кривая и с коллизиями. Т.е. если у тебя 100500 паролей, из них появится 100500 хешей. И нет никакой разницы, сколько бит в хеше.

Повторяю ещё раз: «чем медленнее криптофункция, тем она лучше. Вся криптография именно на этом и держится — тебе просто ресурсов не хватит проверить ВСЕ пароли. Если ты криптоаналитик, и если твой враг грамотно зашифровал свой файл, т.е. так, что тебе вправду ВСЕ пароли проверять надо»

Тут «ВСЕ» значит «все пароли», и «все хеши этих паролей», а вовсе НЕ «любые хеши». Т.ч. если у тебя sha512, то это само по себе ничего НЕ меняет.

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

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

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

для тех кто в танке: мощность множества паролей НЕ меняется, если эти пароли хешировать

Как ты будешь перебирать хеши паролей, не перебирая пароли и не хешируя их?

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

Но кота ты таким образом не сформируешь внутри контейнера.

у тебя есть кот на диске. Я его даже вижу.

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

можно. Но три килограмма героина найти будет намного проще.

Ты живёшь в каком-то придуманном мире, пообщайся с этими людьми из этих твоих органов, и они всё тебе разъяснят. Сам понимаешь: я тебе удостоверение предъявлять не стану.

Просто такого риска не существует. Если ты конечно действительно не являешься наркодиллером или владельцем студии CP. Если не являешься, то тебе куда как проще подбросить HDD с CP или 3 килограмма героина, чем заморачиваться с «результатом сканирования».

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

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

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

Это единственный случай, когда имеет значение скорость криптофункции.

единственной дыры в заборе достаточно, что-бы этот забор стал-бы полностью негодным.

Но в разумные сроки ты все равно не подберешь 256-битный ключ. Никто в здравом уме не будет перебирать все 2*256 ключей, будут перебирать пароли.

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

Как ты будешь перебирать хеши паролей, не перебирая пароли и не хешируя их?

это уже другой вопрос.

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

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

Казалось бы, зачем придумали «соль».

единственной дыры в заборе достаточно

Из скорости функции никак не следует наличие в ней уязвимостей.

это уже другой вопрос.

Нет, это не другой вопрос. И учти, что хеш функция там не sha512, а sha512(salt+sha512(salt+(... sha512(salt+x)...)))

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

я чёта не понял про аес256. ну выпустила интел проц с поддерждкой аес. ну это ж для криптовки, как это влияет на криптостойкость то? если я ничего не путаю, вообще никак не должно влиять.

AndreyKl ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.