id: Гость   вход   регистрация
текущее время 03:52 15/07/2020
создать
просмотр
ссылки

Чем лучше сжимать диски TrueCrypt под Linux и Windows ?


Может я многого хочу. Но раньше были какие-то утилиты для сжатия информации "на лету", возможно ли сегодня повесить такое на смонтированный диск TC? В доках написано, что для ОС это обычный диск с которым можно делать все тоже самое, что и с обычным логическим диском.
Какими утилитами можно их сжимать наиболее безопасно с точки зрения вероятности потери данных в томе TC ?
Интересуют все операционные системы.


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии
— Гость (09/04/2015 06:01)   <#>

Да, есть некоторая мысль в том, что информационно-теоретическая стойкость — это overkill, если уже есть безусловная вычислительная.


Спасибо.


Он заранее заданный, но полученный рандомно. Обобщить на произвольный секрет мне предложили почти сразу, но это было бы слишком сложным на данном этапе. Для начала надо хотя бы с рандомным разобраться.


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


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

На второй странице драфта есть 4 требования, которым должен удовлетворять «примитив». Обратите внимание на третье требование — устойчивость к апостериорному раскрытию. Оно ключевое. Именно из-за него, как я понимаю, идеальные схемы невозможны, а замена экстрактора на AONT ничего концептуально не меняет. Никаких естественных «порогов» на число раскрываемых бит в задаче тоже нет, поэтому ожидать чего-то слишком эффективного именно от пороговых схем я бы тоже не стал. Они — просто как один из возможных вариантов.


Для определения безопасности хэш-функций (в т.ч., использующих ключ), они предложили использовать определение в модели UCE — универсального вычислительного экстрактора. Краткое неформальное определение UCE-безопасности звучит достаточно просто: запросы к функции должны давать на выходе ответ, неотличимый от случайного, с допуском на некоторую утечку, даже если противник знает ключ, до тех пор, пока эта утечка не позволяет вычислить вход. По мнению авторов, такой подход способен заменить эвристистически доказуемый подход на основе ROM на доказываемый (доказанный, доказательный) в рамках UCE.

Может быть, вы хотели сказать, что всё это можно обобщить ещё сильнее и формализовать в рамках UCE, но для меня это пока overkill как по поставленным задачам, так и по лимитам на собственные текущие знания. Впрочем, какой-то тип оракула всё равно придётся постулировать перед тем, как доказывать безопасность, так что, может быть, всё это ещё как-то сгодится.

В драфте в параграфе IV есть попытка формально описать протокол, там как раз что-то типа оракула и вводится. Над этим можно долго смеяться[создать], не спорю, но даже такое примитивное описание — прогресс по сравнению с тем, что было раньше, и даже оно заняло не один день размышлений и обсуждений с коллегами. То, что результат обсуждений оформлен хотя бы в виде такого пошагового описания в pdf'ке, а не где-то зарыт на обрывках салфеток среди тонн черновиков — уже что-то, от чего можно идти дальше.

Там же:

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

Одноразово выполняемые программы как раз здесь выше по треду обсуждались.
— Гость (09/04/2015 06:03)   <#>
P.S. Параллелизм с хардкором тоже напрашивается, но я его, хардкор, не понял.
— unknown (09/04/2015 10:10)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Про хардкор я вам там ответил, это само по себе простое понятие.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3