Подскажите, пожалуйста, на мои вопросы.
1)Есть винчестер 1Tb, хочу его полностью зашифровать TrueCrypt. Безопасно ли это с точки зрения стойкости ко всяким повреждениям и другой хрени, не дай бог, приведущей к неоткрытию его? Или лучше сделать несколько отдельных контейнеров поменьше, намного это будет лучше? Хотя целым было бы более удобно..
2)В какой файловой системе лучше форматировтаь его? Фат32 или НТФС?
3)Перед шифрованием есть необходимость форматировать винт (если да, то в какую систему)? А то винт новый, неформатированный ещё.. Как лучше будет?
1)Есть винчестер 1Tb, хочу его полностью зашифровать TrueCrypt. Безопасно ли это с точки зрения стойкости ко всяким повреждениям и другой хрени, не дай бог, приведущей к неоткрытию его? Или лучше сделать несколько отдельных контейнеров поменьше, намного это будет лучше? Хотя целым было бы более удобно..
2)В какой файловой системе лучше форматировтаь его? Фат32 или НТФС?
3)Перед шифрованием есть необходимость форматировать винт (если да, то в какую систему)? А то винт новый, неформатированный ещё.. Как лучше будет?
Ссылки
[link1] http://i-novice.net/pravilno-xranim-paroli-v-bd/
Лучше зашифровать целиком и сделать резервную копию заголовка (соответствующая опция есть в меню программы).
NTFS.
Это не требуется.
А версия Трукрипта имеет значение? Слышал от вас, что после 3,4 лучше не использовать? Или ситуация изменилась?
Точней 4.3а
Новые версии значительно более сложные и, как следствие, потенциально менее безопасные. Критерий чисто инженерный.
но не стоит забывать, что в новых версиях исправляют старые ошибки и оптимизируют работу программы, увеличивая скорость выполнения алгоритмов и т.п.
Разумеется. А ещё добавляют более эффективные и безопасные режимы вроде XTS.
Ну и где же тогда истина...чтоб выполнялись два условия – Надёжность хранения и стойкость к взлому.
The truth is out there. © X-Files
а что такое соль для создаваемого контейнера? И сильно ли влияет на стойкость время хаотичного перемещения мышью перед созданием контейнера?
Соль – вектор инициализации (IV) – открытое случайное число.
Ключ – f(IV, passwd). Так одинаковые пароли дают разные ключи.
И сильно ли влияет на стойкость время хаотичного перемещения мышью перед созданием контейнера?
И ещё вопрос...говорится, что берётся информация из системы для формирования соли и ключа. Эта величина случайная или может быть так. что в сгенерированном коде будет часть кода находящегося в буфере или написанном какой-нить программе пароля или подобные утечки?
http://en.wikipedia.org/wiki/Salt_(cryptography)
В русской wikipedia'ии статьи пока нет. Что-то на русском можно прочитать, например, здесь[link1].
Никто не знает?(((
В некоторой степени. Если противник сможет с точностью определить все движения мыши (дельты перемещений и временных задержек), а также все прочие данные, собираемые в пул ГСЧ, то вероятно сможет восстановить мастер-ключ. Сценарий реалистичный только если в Вашей системе живёт троян, но уж если Вы так облажались, то и нет особого смысла заниматься криптоанализом: просто читай себе файлы с диска.
Это случайное значение, но, поскольку компьютер — это детерминированная система, формируется оно из множества неслучайных показателей (включая и движения мыши). Проблема для противника в том, что эти показатели криптографически смешиваются, и для успешной атаки на выход ГСЧ ему необходимо с точностью предугадать их все. Это будет практически невозможно, если Ваша система не была скомпрометирована изначально.
Это только в теории. На практике, например, время чтения с жёского диска зависит от качества намагниченности (блоки могут прочитаться не с первого раза), которое ухудшается непредсказуемым образом, возможно даже теоретически непредсказуемым, поскольку может зависеть от квантовых эффектов.
Задержки чтения, вызванные воздушной турбуленцией в корпусе диска, являются одним из источников энтропии. (В данном контексте интересно, какова польза от твердотельных SSD-накопителей. Есть мнение, что для сбора энтропии они бесполезны.) И диск — едва ли не единственный источник, доступный в отсутствие живого оператора. Скажем, у встроенных систем типа маршрутизаторов OpenWrt и т.п. автономных устройств могут быть серьёзные трудности с качественной энтропией, если они не снабжены аппаратным ГСЧ.
Ну то есть я правильно понял, что по анализу шифродиска невозможно будет из его кода извлечь пароль к этому же диску (который находился в открытом блокноте) или восстановить кусок копромитируещего тебя видеофайла или фотографии, просмотренной при создании контейнера и сбора информации ею?
Да, правильно.
В программе Блокнот что-ли? Если только Винда не выгружала программу со всеми данными в своп. Если пароль вводился в любую подобную программу, советую исходить из того, что он уже где-то на жёстком диске, и, как минимум, сменить пароль с криптоконтейнеру.
Вроде блокнот не сохраняет в темп данные? Программа=то простенькая...а своп отключен...
Тут мне сказали, что шифровать целый винт – это заранее прощаться с инфой...((( что всё так плохо? ПИшут что любые ошибки софтовые и глюки питания и шлейфа – кранте инфе..
А как-же шумы звуковой карты? А зависимость частоты процессора от температуры (тротлинг)? А ограниченный ресурс чтения/записи флэш-памяти? А нестабильность в "разогнанной" системе видеокарты или отдельной планки оперативной памяти? (И даже у маршрутизаторов иногда бывает wifi в условиях нестабильной связи, которое можно создавать искусственно)
Вообще, в нерассчётных условиях поведение очень часто не поддаётся рассчётам :)
Нужно особо позаботиться о критическом блоке данных – сделать несколько резервных копий. В остальном же как и обычно. Ну ещё и пароль не забывать надо :)
Я думаю, именно поэтому в алгоритмах типа WPA-PSK не используется Диффи Хеллман, в идеале он не подвержен брутфорсу, как имеем дело с WPA-PSK но на практике его применение в схемах отличных от WPA-Enterpise и привело бы еще к более быстрому брутфорсу (через подбор энтропии), чем существующие технологии.
Нет это не так. Сцепление блоков не может быть большой длины так что просто потеряете больше одного сектора, если разработчики не совсем идиоты, что маловероятно. В остальном просто попробуйте затереть пару секторов и проверить, как восстанавливается.
2 Мухтар (13/07/2009 13:41)
Верно. Всякие брелки автосигнализаций, проездные карточки и пр. взламывались за счёт дефектного ГСЧ, который туда технологически не разместить. Пытаются делать его полностью на чипе – ловить сигналы нестабильного осциллятора, но это пока не до конца проработанная технология. В этих устройствах ещё ограничения по объёму памяти и мощности процессора, а вот в обычном компе можно фоном обрабатывать большие объёмы данных на предмет дистилляции энтропии.
И из-за той же слабой мощности проца DH в небольших устройствах неприменим. Если только в эллиптических кривых.
Temp != swap. Что своп отключен — это хорошо.
Ещё раз повторю: в кастрированных встраиваемых системах. Из предложенного списка половина источников просто отсутствует, другая половина не годится, поскольку подвержена влиянию противника.
то есть бэкап заголовка залог безопасности? А его нужно прятать под пароль? Облегчит ли он взлом для противника?
Остаётся риск, что повреждение шифртекста приведёт к повреждению (возможно, фатальному) файловой системы, но этот риск не выше, чем для нешифрованного диска.
Не обязательно, мастер-ключ в нём и так зашифрован текущим паролем. (Этот факт, кстати, можно использовать как средство аварийного восстановления зашифрованного диска на случай, если забудете пароль: установите простейший и очевидный пароль типа "123", сделайте резервную копию заголовка, а затем верните прежний надёжный пароль. Резервный заголовок будет зашифрован паролем "123", и если его восстановить, то диск также будет доступен по этому паролю. Разумеется, такую резервную копию нужно надёжно хранить.)
SATtva, зачем так усложнять? Тем более, что мастер-ключ можно прочитать из физической памяти, вслучае затрояненой машины.
Такой хитрый финт особенно полезен в корпоративной среде: админ создаёт пользователям криптоконтейнеры, бэкапит заголовки, а юзеры могут поставить удобные им пароли. И овцы сыты, и волки целы.
А в случае затрояненной машины можно вообще всё. Наверное, лучше до этого не доводить, не так ли?
Я использую полное дисковое шифрование AES чтобы предотвратить доступ посторонних к хвостам информации оставляемым программами в операционной системе. Саму секретную информацию храню в файловом контейнере зашифрованном Twofish. Какой шифр получается в итоге при записи данных в контейнер – каскадный AES-Twofish или иная смесь? Если иная смесь то замедление шифрования в контейнере сопоставимо с каскадным шифром или нет?
Кратко: другая смесь, не каскадный шифр.
С точки зрения теории всё выглядит так:
Блочный шифр — это зависящая от ключа псевдослучайная перестановка всех возможных открытых текстов во все возможные шифртексты в пределах размера блока.
Каскад из двух шифров — это шифрование с помощью шифра E' открытого текста P ключом k1 и повторное шифрование результата с помощью шифра E'' ключом k2 с получением на выходе шифртекста C:
C = E''k2 ( E' k1 (P))
Получается последовательное склеивание двух перестановок в каскад — одну перестановку в виде гетерогенного шифра с двумя ключами и разными структурами раундов, что и обеспечивает трудность криптоанализа.
При размещении криптоконтейнера в виде файла он лежит на файловой системе с некоторыми заголовками, отформатированными блоками и прочей служебной информацией. Это даёт некоторые предположение о попадаемом между шифрами открытом тексте. И даже если он неизвестен, то принцип непосредственного соединения двух перестановок в одну нарушается. Это может способствовать нахождению различителей. Результат не является перестановкой из-за попадания между шифрованиями посторонних данных.
Максимум, что вы получаете — это раздельное использование разных ключей для разных секретов.
С точки зрения практики — это однако всё равно даёт некоторое повышение безопасности и даже устойчивости к криптоанализу, но не каскад.