Задержки чтения, вызванные воздушной турбуленцией в корпусе диска, являются одним из источников энтропии. (В данном контексте интересно, какова польза от твердотельных SSD-накопителей. Есть мнение, что для сбора энтропии они бесполезны.) И диск — едва ли не единственный источник, доступный в отсутствие живого оператора. Скажем, у встроенных систем типа маршрутизаторов OpenWrt и т.п. автономных устройств могут быть серьёзные трудности с качественной энтропией, если они не снабжены аппаратным ГСЧ.

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

Ну то есть я правильно понял ...

Да, правильно.

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

В программе Блокнот что-ли? Если только Винда не выгружала программу со всеми данными в своп. Если пароль вводился в любую подобную программу, советую исходить из того, что он уже где-то на жёстком диске, и, как минимум, сменить пароль с криптоконтейнеру.

Вроде блокнот не сохраняет в темп данные? Программа=то простенькая...а своп отключен...

Тут мне сказали, что шифровать целый винт – это заранее прощаться с инфой...((( что всё так плохо? ПИшут что любые ошибки софтовые и глюки питания и шлейфа – кранте инфе..

И диск — едва ли не единственный источник, доступный в отсутствие живого оператора

А как-же шумы звуковой карты? А зависимость частоты процессора от температуры (тротлинг)? А ограниченный ресурс чтения/записи флэш-памяти? А нестабильность в "разогнанной" системе видеокарты или отдельной планки оперативной памяти? (И даже у маршрутизаторов иногда бывает wifi в условиях нестабильной связи, которое можно создавать искусственно)

Вообще, в нерассчётных условиях поведение очень часто не поддаётся рассчётам :)

любые ошибки софтовые и глюки питания и шлейфа – кранте инфе..

Нужно особо позаботиться о критическом блоке данных – сделать несколько резервных копий. В остальном же как и обычно. Ну ещё и пароль не забывать надо :)

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

Я думаю, именно поэтому в алгоритмах типа WPA-PSK не используется Диффи Хеллман, в идеале он не подвержен брутфорсу, как имеем дело с WPA-PSK но на практике его применение в схемах отличных от WPA-Enterpise и привело бы еще к более быстрому брутфорсу (через подбор энтропии), чем существующие технологии.

любые ошибки софтовые и глюки питания и шлейфа – кранте инфе..

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

2 Мухтар (13/07/2009 13:41)

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

И из-за той же слабой мощности проца DH в небольших устройствах неприменим. Если только в эллиптических кривых.

Вроде блокнот не сохраняет в темп данные? Программа=то простенькая...а своп отключен...

Temp != swap. Что своп отключен — это хорошо.

А как-же шумы звуковой карты? А зависимость частоты процессора от температуры (тротлинг)? А ограниченный ресурс чтения/записи флэш-памяти? А нестабильность в "разогнанной" системе видеокарты или отдельной планки оперативной памяти? (И даже у маршрутизаторов иногда бывает wifi в условиях нестабильной связи, которое можно создавать искусственно)

Ещё раз повторю: в кастрированных встраиваемых системах. Из предложенного списка половина источников просто отсутствует, другая половина не годится, поскольку подвержена влиянию противника.

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

то есть бэкап заголовка залог безопасности?

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

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

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

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

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

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