id: Гость   вход   регистрация
текущее время 14:50 28/03/2024
создать
просмотр
ссылки

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


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


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Комментарии
— gyhsal (26/05/2013 02:22)   <#>
Если искуственно в качестве гаммы отбирать только те битовые строки, которые имеют строго одинаковое количество нулей и единиц, получим утечку информации.

Доказательство Шеннона абсолютной стойкости шифрования через «одноразовый блокнот» идет именно через тот факт, что гамма содержит равное количество нулей и единиц.
Только тогда в результате шифрования закон распределения окажется симметричным. Именно поэтому результат и не будет содержать вообще никакой информации из «открытого текста».
— Гость (26/05/2013 03:18)   <#>
«Гамма содержит равное количество нулей и единиц» ≠ «закон распределения симметричный», причём ни первое не следует из второго, ни второе из первого. Возьмите монетку, киньте её 50 раз и посчитайте количество решек и орлов. Очень маловероятно, что получите ровно 25 для каждой. Аналогичным образом можете проверить и вывод ГСЧ на ПК.
— gyhsal (26/05/2013 03:55)   <#>
А ну это то само собой, «равное» и «одинаковое» отнюдь не тоже самое, что «идентично» и «совпадать». Конечно отклонение может быть в несколько процентов. В современной истории задокументирован случай, когда человек играл в рулетку ставя на «красное» и «черное», удваивая ставку в случае проигрыша. Разорился из-за того, что «поймал» серию из семи или девяти совпадающих значений.
— Гость (26/05/2013 04:52)   <#>
В современной истории задокументирован случай

Напомнило /comment32952 и /comment33208.
— unknown (27/05/2013 10:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Работа «блочных шифров» строится не столько на наложении гаммы, но и на подстановках с перестановками. Однако, фактически их тоже можно свести к наложению гаммы.

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

Потому любой «блочный шифр» фактически сводится к генерации и наложению гаммы. Что возвращает к «одноразовому блокноту» и оценке стойкости исходя из свойств накладываемой гаммы.

Это несколько упрощённо. Для описания уже давно (хотя и не в полной мере) разработаны теории PRF-PRP переходов и различителей с несколько другими ключевыми понятиями, терминологией, системой обозначений, привлекаемым матаппартом и методикой построения моделей и алгоритмов. Это не противоречит ранее использовавшемся методам, это небезуспешно пытается двинуть теорию и практику вперёд.
— Гость (27/05/2013 19:06)   <#>
Если «блочный шифр» представить как генератор гаммы принимающий на вход ключ и «открытый текст», то чем больше будет энтропии в «открытом тексте», тем более качественная гамма получится на выходе.
Потому «открытый текст» подвергается «рандомизации» перед тем как будет использован «генератором гаммы». Это происходит с «открытым текстом» либо до начала подачи в «блочный шифр», либо уже внутри него.
Оно может происходить и в неявном виде. Например, за счет того, что алгоритм корректирует полученные результаты в конце каждого раунда. Фактически как бы подстраиваясь под неравномерность частот в «открытом тексте».

Вскрываю переписку ради того, чтобы понять содержимое «открытого текста» и для этого далеко не всегда надо заниматься поиском ключей которыми оно шифровалось.
Сжатие «открытого текста» полезно ради уменьшения объёма шифротекста доступного противнику для анализа. Одно дело вскрывать переписку, где в тексте встречается:
«Высокоуважаемый Генералисимус Верховный Главнокомандующий и Президент Первой Демократической Банановой Республики».
И совсем другое, когда содержимое «открытого текста» неизвестно. В лучшем случае можно ожидать лишь наличие нескольких служебных символов идентифицирующих формат потока, а всё остальное в этом потоке напоминает выдачу генератора случайных чисел.
— unknown (28/05/2013 12:03, исправлен 28/05/2013 12:06)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Кажется созрело какое-то понимание разницы подходов.


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


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


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


Более практично — не полурэндомизация, а преобразования "всё или ничего" All or nothing transform. Открытый текст превращается в аналог шифртекста, который можно легко расшифровать обратно всем желающим без знания ключа (он вычисляется по шифртексту). Но если хотя бы часть такого псевдошифртекста неизвестна, то обратное расшифрование невозможно (на уровне криптостойкости). Понятно, что если это преобразование ещё раз пошифровать, уже с секретным ключом, то криптоанализ крайне затруднится.


Возможна псевдорэндомизация: наложение гаммы потокового шифра и лишь затем блочное шифрование.


Второй этап понимания: почему это перестали активно изучать и внедрять?


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


Но дальше, негласно конвенционально, по мере накопления знаний, стали отрицать ещё два подхода к безопасности. Сейчас отрицают "безопасность через запутывание" — когда противник всё знает, но система сложна для понимания: и того, как её взломать, и того, как доказать её безопасность. Т.е., стараются избегать переусложнений, достигать результата простейшими способами (в рамках модели), чтобы каждый шаг был обоснован.


Второй отрицаемый подход — "безопасность через перестраховки". Строят максимально возможную полную модель и алгоритм или протокол проектируют только в её рамках, не добавляя ничего лишнего поверх, ничего не предпринимая на случай, если модель не сработает, если шифр окажется нестойким (значит у вас слабый шифр, потенциально вы уже проиграли).


Так, блочные шифры проектируют в ICM-модели (допуски и оговорки включены в модель). Базовый принцип модели: CPA/CCA-security. Если противник может заставить вас зашифровать/расшифровать менее, чем 2128 подобранных открытых/шифртекстов для ключа 2128 бит и по этой информации не то что вычислить ключ, а хотя бы найти различитель от идеальной перестанвки, по которому ещё ничего нельзя взломать — то вы уже проиграли. В режимах шифрования есть утечка до 2b/2 по размеру блока и прочие тривиальные различители, учитываемые в модели. Так что, если вы пытаетесь перестраховаться за пределами принятой модели — это считается маргинальным и необоснованным.


Другой пример: традиционное асимметричное шифрование не обеспечивает CPA/CCA-security. Поэтому его используют совместно с симметричным в рамках обоснованной модели (а не только потому, что так в тысячи раз быстрее шифруется).


Такой подход позволил внедрить режим блочного шифра счётчик (CTR), где на вход шифра не нужно подавать открытого текста в явном виде вообще — сжимать открытый текст в нём не имеет смысла. Также это позволило создать универсальный криптопримив Keccak. Если Keccak не стоек как хэш, то он нестоек и как потоковый шифр, и предварительное сжатие спасать не будет. Зато избавились от этих перестраховочных костылей и переключились на более ясные и сильные модели.


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

— Гость (30/05/2013 00:44)   <#>
Вскрываю переписку ради того, чтобы понять содержимое «открытого текста» и для этого далеко не всегда надо заниматься поиском ключей которыми оно шифровалось.

Криптоанализ любительских шифров? Продолжайте «вскрывать». Одно дело — криптография времён ВОВ, когда шифровали короткий текст типа вами прииведённого и при этом часто меняли ключи. Другое дело — криптография XXI-го века, когда одним ключом шифруют террабайты и при этом требуют криптостойкость при знании всей информации об открытом тексте. На фоне последней криптографии первая — детская безделушка, но кто-то продолжает упорно жить в мире киношных шпионов ВОВ.

All or nothing transform. Открытый текст превращается в аналог шифртекста, который можно легко расшифровать обратно всем желающим без знания ключа (он вычисляется по шифртексту). Но если хотя бы часть такого псевдошифртекста неизвестна, то обратное расшифрование невозможно (на уровне криптостойкости).

Интересная штука. Ровно то, что надо. С безусловной безопасностью можно это сделать? Что известно про максимальное количество информации, которое можно безопасно соообщить атакующему про «аналог шифртекста» и при этом не бояться взлома?

Такой подход позволил внедрить режим блочного шифра счётчик (CTR), где на вход шифра не нужно подавать открытого текста в явном виде вообще — сжимать открытый текст в нём не имеет смысла.

Грамматически и по смыслу звучит абсурдно. Как это «на вход шифра не подаётся открытый текст»? А куда ж он тогда подаётся-то? Можете пояснить эту фразу?
— Гость (30/05/2013 00:56)   <#>
Вскрываю переписку ради того, чтобы понять содержимое «открытого текста» и для этого далеко не всегда надо заниматься поиском ключей которыми оно шифровалось.
На фоне последней криптографии первая — детская безделушка, но кто-то продолжает упорно жить в мире киношных шпионов ВОВ

Да, Гость, лучше про пытки нам расскажите, это у вас лучше получается, и нам веселей послушать. А с криптографией у вас сразу не заладилось, оставьте её, не ваше это. Да и зачем вам TC со сжатием открытого текста? Всё равно ваши коллеги с паяльником, такие же как вы, выудят у вас всю информацию. Отказывайтесь от использования шифрования, пока ещё не поздно. Вы не понимаете, что кто-то использует вас втёмную, как пушечное мясо, чтобы потом вами прикрыться и подтереться. Он насоветовал вам спецсредств, трукрипты всякие, а реально они вас не защитят, только хуже сделают. Лучше работайте по-старинке: шифровки не длиннее телеграммы; шифр, проверенный десятилетиями; да про ампулу с цианидом, подшитую в воротник, не забудьте. И пребудет с вами счастье.
— Гость (30/05/2013 02:00)   <#>
Есть разница между поиском ключа при известном открытом тексте и прочтении шифрованной переписки без поисков ключа.
— gyhsal (30/05/2013 04:20)   <#>
Понятно, что если это преобразование ещё раз пошифровать, уже с секретным ключом, то криптоанализ крайне затруднится.

Именно это и является основной целью при расчете на долгосрочную перспективу. Какими бы хорошими ни были используемые алгоритмы «блочных шифров», а возможность лёгко и дёшево усложнить криптоанализ, отодвинув момент полной расшифровки — это вполне разумно.
Ведь никто же не пытается компенсировать недостатки системы генерации ключей или используемых алгоритмов.
Подход такой, что если увеличение степени энтропии «открытого текста» позволит выиграть лишний год-два, то игра стоит свеч. Потому как бывают ситуации, когда чем позднее будут дешифрованы перехваченные сообщения или утраченные носители информации, тем меньше людей пострадает. И тем меньше ресурсов потребуется привлекать для ликвидации последствий.
— SATtva (30/05/2013 08:24)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Такой подход позволил внедрить режим блочного шифра счётчик (CTR), где на вход шифра не нужно подавать открытого текста в явном виде вообще — сжимать открытый текст в нём не имеет смысла.

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

CTR генерирует гамму, шифруя простой счётчик; гамма ксорится с открытым текстом уже отдельно. Так что, да, шифровальный алгоритм с открытым текстом в этом режиме непосредственно не взаимодействует.
— unknown (30/05/2013 10:08, исправлен 30/05/2013 13:55)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Нет. В обычном сценарии только с вычислительной. Возможно как какую-то часть информационно-стойкого протокола можно прикрутить, но само по себе — точно нет.



При 128-битном ключе он не должен подобрать 128 неизвестных потерянных битов в тексте. Но проблема в том, что всё упирается в размер шифрующих (или преобразующих блоков). Как в губке Keccak: сначала безопасность растёт с ростом ключа, а затем остаётся константой (flat claim): за пределами 128-бит будут ломать поблочно, а не перебирать весь шифртекст. Другой вопрос, что есть много вариантов AONT, есть и более навороченные и экзотические, не все доступны моему пониманию, это малоизученное направление.



Совершенно верно. Практически, замена блочного шифра на потоковый. У Бернштейна с Беллейром (или Рогвеем, всё время их путаю :) был заочный спор: Бернштейн утверждал, что после изучения и обоснования стойкости всех режимов шифрования сообщений без аутентификации, никакой режим, кроме счётчика, не нужен якобы теперь вообще. За исключением протоколов, где нужно не просто шифрование, а именно зависящая от ключа перестановка.


Дисковое и аутентифицированное шифрование — отдельная тема. Также как non-mallebable encryption. С т.з. перестраховки на повышение стойкости есть ещё экстремальный вариант wide-block encryption: режим шифрования, при котором диффузия открытого текста происходит не в пределах блока, а по всему шифртексту (не путать с обычным CBC). Т.е. изменение одного бита в открытом тексте полностью меняет весь шифртекст и до, и после этого изменения в сообщении. Непрактично тем, что не годится для шифрования потоков — всё сообщение придётся держать в памяти или шифровать (как минимум, но не всё так просто) из начала в конец, а затем в обратном порядке. Но это для спец. протоколов, несвязанных с перестраховкой, скорее для того же non-malleable encryption, там где не впихнуть аутентификацию.


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

— Гость (30/05/2013 18:15)   <#>

Есть один предельный случай: половина текста — шифртекст (результат шифрования одноразовым блокнотом), а вторая половина — случайная гамма, которая использовалась при шифровании. Если знаете обе части текста, вы «расшифровываете» сообщение. Хотелось бы как-то перемешать гамму с шифртекстом, причём безусловно безопасно, так, чтобы было всё равно, какую часть битов мы раскрываем атакующему: первые n/2 из n штук или случайно выбранные n/2 из n штук, то есть, чтоб утечка информации о битах начиналась только при раскрытии n+1-го бита.

Насчёт «само по себе — точно нет» — где можно почитать доказательство невозможности?
— unknown (30/05/2013 21:39, исправлен 30/05/2013 21:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


Хотелось бы как-то перемешать гамму с шифртекстом, причём безусловно безопасно, так, чтобы было всё равно, какую часть битов мы раскрываем атакующему: первые n/2 из n штук или случайно выбранные n/2 из n штук

Возможно Shamir's secret sharing? И вообще какой информационно-стойкий Secret sharing. Но как использовать это в режиме AONT, есть ли с соблюдением ваших требований какие-то подводные камни, я не знаю. На первый взгляд — нет, т.е. возможно это вам подходит. Смотря что вы ходите получить.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3