Чем лучше сжимать диски TrueCrypt под Linux и Windows ?
Может я многого хочу. Но раньше были какие-то утилиты для сжатия информации "на лету", возможно ли сегодня повесить такое на смонтированный диск TC? В доках написано, что для ОС это обычный диск с которым можно делать все тоже самое, что и с обычным логическим диском.
Какими утилитами можно их сжимать наиболее безопасно с точки зрения вероятности потери данных в томе TC ?
Интересуют все операционные системы.
Доказательство Шеннона абсолютной стойкости шифрования через «одноразовый блокнот» идет именно через тот факт, что гамма содержит равное количество нулей и единиц.
Только тогда в результате шифрования закон распределения окажется симметричным. Именно поэтому результат и не будет содержать вообще никакой информации из «открытого текста».
Напомнило /comment32952 и /comment33208.
комментариев: 9796 документов: 488 редакций: 5664
Это исторически самое распространённое конструктивное решение, но само по себе не определяющее и не обязательное требование. Если посмотреть блочные шифры, основанные на смешении операций, такие как RC5 или IDEA, а также некоторую менее известную экзотику, то там нет раздельных слоёв подстановок-перестановок.
Это несколько упрощённо. Для описания уже давно (хотя и не в полной мере) разработаны теории PRF-PRP переходов и различителей с несколько другими ключевыми понятиями, терминологией, системой обозначений, привлекаемым матаппартом и методикой построения моделей и алгоритмов. Это не противоречит ранее использовавшемся методам, это небезуспешно пытается двинуть теорию и практику вперёд.
Потому «открытый текст» подвергается «рандомизации» перед тем как будет использован «генератором гаммы». Это происходит с «открытым текстом» либо до начала подачи в «блочный шифр», либо уже внутри него.
Оно может происходить и в неявном виде. Например, за счет того, что алгоритм корректирует полученные результаты в конце каждого раунда. Фактически как бы подстраиваясь под неравномерность частот в «открытом тексте».
Вскрываю переписку ради того, чтобы понять содержимое «открытого текста» и для этого далеко не всегда надо заниматься поиском ключей которыми оно шифровалось.
Сжатие «открытого текста» полезно ради уменьшения объёма шифротекста доступного противнику для анализа. Одно дело вскрывать переписку, где в тексте встречается:
«Высокоуважаемый Генералисимус Верховный Главнокомандующий и Президент Первой Демократической Банановой Республики».
И совсем другое, когда содержимое «открытого текста» неизвестно. В лучшем случае можно ожидать лишь наличие нескольких служебных символов идентифицирующих формат потока, а всё остальное в этом потоке напоминает выдачу генератора случайных чисел.
комментариев: 9796 документов: 488 редакций: 5664
Кажется созрело какое-то понимание разницы подходов.
Первый этап — можно рассмотреть методы преобразования открытого текста, повышающие стойкость системы. Второй этап — подумать, почему от них с некоторого момента стали отказываться.
Сжатие — самый простой, сравнительно практичный способ. Но не самый параноидальный. Как отмечено выше — это всё-таки не рэндомизация.
Истинная (полу)рэндомизация приводит к увеличению размера шифртекстов, поэтому непрактична. Например, заполнив каждую половину блока открытым текстом, а вторую — потоком истинно случайных данных, получим удвоенный по размеру шифртекст, против которого крайне сложно будет применить какие-либо методы криптоанализа (при расшифровании вторая половина просто отбрасывается). Схожий, ещё более параноидальный метод: послать два сообщения вместо одного. В одном зашифровать случайную гамму одним ключом и одним шифром. В другом — ксор этой гаммы с открытым текстом, но пошифрованный другим ключом и другим шифром. Нечто среднее между разделением секрета на одноразовых блокнотах и каскадным шифрованием.
Более практично — не полурэндомизация, а преобразования "всё или ничего" All or nothing transform. Открытый текст превращается в аналог шифртекста, который можно легко расшифровать обратно всем желающим без знания ключа (он вычисляется по шифртексту). Но если хотя бы часть такого псевдошифртекста неизвестна, то обратное расшифрование невозможно (на уровне криптостойкости). Понятно, что если это преобразование ещё раз пошифровать, уже с секретным ключом, то криптоанализ крайне затруднится.
Возможна псевдорэндомизация: наложение гаммы потокового шифра и лишь затем блочное шифрование.
Второй этап понимания: почему это перестали активно изучать и внедрять?
Исторически, принцип Керхгоффса отрицает "безопасность через неясность": если противник может взломать систему без знания ключа, то пытаясь держать её в секрете, вы уже потенциально проиграли.
Но дальше, негласно конвенционально, по мере накопления знаний, стали отрицать ещё два подхода к безопасности. Сейчас отрицают "безопасность через запутывание" — когда противник всё знает, но система сложна для понимания: и того, как её взломать, и того, как доказать её безопасность. Т.е., стараются избегать переусложнений, достигать результата простейшими способами (в рамках модели), чтобы каждый шаг был обоснован.
Второй отрицаемый подход — "безопасность через перестраховки". Строят максимально возможную полную модель и алгоритм или протокол проектируют только в её рамках, не добавляя ничего лишнего поверх, ничего не предпринимая на случай, если модель не сработает, если шифр окажется нестойким (значит у вас слабый шифр, потенциально вы уже проиграли).
Так, блочные шифры проектируют в ICM-модели (допуски и оговорки включены в модель). Базовый принцип модели: CPA/CCA-security. Если противник может заставить вас зашифровать/расшифровать менее, чем 2128 подобранных открытых/шифртекстов для ключа 2128 бит и по этой информации не то что вычислить ключ, а хотя бы найти различитель от идеальной перестанвки, по которому ещё ничего нельзя взломать — то вы уже проиграли. В режимах шифрования есть утечка до 2b/2 по размеру блока и прочие тривиальные различители, учитываемые в модели. Так что, если вы пытаетесь перестраховаться за пределами принятой модели — это считается маргинальным и необоснованным.
Другой пример: традиционное асимметричное шифрование не обеспечивает CPA/CCA-security. Поэтому его используют совместно с симметричным в рамках обоснованной модели (а не только потому, что так в тысячи раз быстрее шифруется).
Такой подход позволил внедрить режим блочного шифра счётчик (CTR), где на вход шифра не нужно подавать открытого текста в явном виде вообще — сжимать открытый текст в нём не имеет смысла. Также это позволило создать универсальный криптопримив Keccak. Если Keccak не стоек как хэш, то он нестоек и как потоковый шифр, и предварительное сжатие спасать не будет. Зато избавились от этих перестраховочных костылей и переключились на более ясные и сильные модели.
В дисковом шифровании также стремятся развивать всё более стойкие режимы, перекрывающие возможности утечки информации при разнообразных сценариях атак, а не надеяться на перестраховки.
Криптоанализ любительских шифров? Продолжайте «вскрывать». Одно дело — криптография времён ВОВ, когда шифровали короткий текст типа вами прииведённого и при этом часто меняли ключи. Другое дело — криптография XXI-го века, когда одним ключом шифруют террабайты и при этом требуют криптостойкость при знании всей информации об открытом тексте. На фоне последней криптографии первая — детская безделушка, но кто-то продолжает упорно жить в мире киношных шпионов ВОВ.
Интересная штука. Ровно то, что надо. С безусловной безопасностью можно это сделать? Что известно про максимальное количество информации, которое можно безопасно соообщить атакующему про «аналог шифртекста» и при этом не бояться взлома?
Грамматически и по смыслу звучит абсурдно. Как это «на вход шифра не подаётся открытый текст»? А куда ж он тогда подаётся-то? Можете пояснить эту фразу?
Да, Гость, лучше про пытки нам расскажите, это у вас лучше получается, и нам веселей послушать. А с криптографией у вас сразу не заладилось, оставьте её, не ваше это. Да и зачем вам TC со сжатием открытого текста? Всё равно ваши коллеги с паяльником, такие же как вы, выудят у вас всю информацию. Отказывайтесь от использования шифрования, пока ещё не поздно. Вы не понимаете, что кто-то использует вас втёмную, как пушечное мясо, чтобы потом вами прикрыться и подтереться. Он насоветовал вам спецсредств, трукрипты всякие, а реально они вас не защитят, только хуже сделают. Лучше работайте по-старинке: шифровки не длиннее телеграммы; шифр, проверенный десятилетиями; да про ампулу с цианидом, подшитую в воротник, не забудьте. И пребудет с вами счастье.
Именно это и является основной целью при расчете на долгосрочную перспективу. Какими бы хорошими ни были используемые алгоритмы «блочных шифров», а возможность лёгко и дёшево усложнить криптоанализ, отодвинув момент полной расшифровки — это вполне разумно.
Ведь никто же не пытается компенсировать недостатки системы генерации ключей или используемых алгоритмов.
Подход такой, что если увеличение степени энтропии «открытого текста» позволит выиграть лишний год-два, то игра стоит свеч. Потому как бывают ситуации, когда чем позднее будут дешифрованы перехваченные сообщения или утраченные носители информации, тем меньше людей пострадает. И тем меньше ресурсов потребуется привлекать для ликвидации последствий.
комментариев: 11558 документов: 1036 редакций: 4118
CTR генерирует гамму, шифруя простой счётчик; гамма ксорится с открытым текстом уже отдельно. Так что, да, шифровальный алгоритм с открытым текстом в этом режиме непосредственно не взаимодействует.
комментариев: 9796 документов: 488 редакций: 5664
Нет. В обычном сценарии только с вычислительной. Возможно как какую-то часть информационно-стойкого протокола можно прикрутить, но само по себе — точно нет.
При 128-битном ключе он не должен подобрать 128 неизвестных потерянных битов в тексте. Но проблема в том, что всё упирается в размер шифрующих (или преобразующих блоков). Как в губке Keccak: сначала безопасность растёт с ростом ключа, а затем остаётся константой (flat claim): за пределами 128-бит будут ломать поблочно, а не перебирать весь шифртекст. Другой вопрос, что есть много вариантов AONT, есть и более навороченные и экзотические, не все доступны моему пониманию, это малоизученное направление.
Совершенно верно. Практически, замена блочного шифра на потоковый. У Бернштейна с Беллейром (или Рогвеем, всё время их путаю :) был заочный спор: Бернштейн утверждал, что после изучения и обоснования стойкости всех режимов шифрования сообщений без аутентификации, никакой режим, кроме счётчика, не нужен якобы теперь вообще. За исключением протоколов, где нужно не просто шифрование, а именно зависящая от ключа перестановка.
Дисковое и аутентифицированное шифрование — отдельная тема. Также как non-mallebable encryption. С т.з. перестраховки на повышение стойкости есть ещё экстремальный вариант wide-block encryption: режим шифрования, при котором диффузия открытого текста происходит не в пределах блока, а по всему шифртексту (не путать с обычным CBC). Т.е. изменение одного бита в открытом тексте полностью меняет весь шифртекст и до, и после этого изменения в сообщении. Непрактично тем, что не годится для шифрования потоков — всё сообщение придётся держать в памяти или шифровать (как минимум, но не всё так просто) из начала в конец, а затем в обратном порядке. Но это для спец. протоколов, несвязанных с перестраховкой, скорее для того же non-malleable encryption, там где не впихнуть аутентификацию.
Опять же, при таком подходе, в единый блок открытого текста может быть вписан случайный IV, именно как часть открытого текста, которая будет отброшена при расшифровании, если это так надо.
Есть один предельный случай: половина текста — шифртекст (результат шифрования одноразовым блокнотом), а вторая половина — случайная гамма, которая использовалась при шифровании. Если знаете обе части текста, вы «расшифровываете» сообщение. Хотелось бы как-то перемешать гамму с шифртекстом, причём безусловно безопасно, так, чтобы было всё равно, какую часть битов мы раскрываем атакующему: первые n/2 из n штук или случайно выбранные n/2 из n штук, то есть, чтоб утечка информации о битах начиналась только при раскрытии n+1-го бита.
Насчёт «само по себе — точно нет» — где можно почитать доказательство невозможности?
комментариев: 9796 документов: 488 редакций: 5664
Шифрование в традиционном AONT-режиме идёт поблочно, например, обычным блочным шифром. Если у вас нет целого сообщения, у вас есть обычные блоки шифртекста, соответствующие определённым блокам открытого текста, к которым вы просто не знаете ключа.
Возможно Shamir's secret sharing? И вообще какой информационно-стойкий Secret sharing. Но как использовать это в режиме AONT, есть ли с соблюдением ваших требований какие-то подводные камни, я не знаю. На первый взгляд — нет, т.е. возможно это вам подходит. Смотря что вы ходите получить.