Чем лучше сжимать диски TrueCrypt под Linux и Windows ?
Может я многого хочу. Но раньше были какие-то утилиты для сжатия информации "на лету", возможно ли сегодня повесить такое на смонтированный диск TC? В доках написано, что для ОС это обычный диск с которым можно делать все тоже самое, что и с обычным логическим диском.
Какими утилитами можно их сжимать наиболее безопасно с точки зрения вероятности потери данных в томе TC ?
Интересуют все операционные системы.
Наверное, есть файловые системы (ФС), где сжатие встроено (TC'у всё равно, какая там ФС внутри будет, т.к. шифрование происходит на более низком уровне — уровне блочного устройства).
комментариев: 9796 документов: 488 редакций: 5664
Понятно, что сжимать можно или в прослойке между криптотомом и ФС, или внутри самой ФС (которая лежит на криптотоме), или поверх неё. Какие-то решения есть для всех случаев.
Гуглите Transparent compression, например BTRfs его поддерживает.
Никакого отношения к самому шифрованию это не имеет.
Алгоритмы, сжимающие и шифрующие одновременно, создавать пытались, но это маргинально-теоретическая область.
И не волнует, что у англичан не получилось вскрыть диск шифрованный TrueCrypt'ом. Просто они тупо пароль брутфорсили, не занимаясь криптоанализом шифрованных данных.
Да и Масленников не совсем прав, когда пишет, что теперь мол оригинальные тексты шифрованных телеграмм якобы можно спокойно показывать в телекамеры.
комментариев: 9796 документов: 488 редакций: 5664
Т.е. вы утверждаете, что если, например зашифровать 264 нулей алгоритмом (на данный момент) уровня AES, то существует атака, которая по получившемуся шифртексту восстановит ключ? Опубликуйте, будет сенсация.
а есть доказательство обратного? Что при ключах длинной много меньше «открытого текста» стойкость шифра никак не зависит от энтропии «открытого текста»?
«Радужные таблицы» успешно используются для взлома не только из-за слабой энтропии ключей. А так же и в случаях генерации ключей достойным аппаратным ГСЧ, но когда «открытый текст» не был пожат перед шифрованием «блочным шифром». Само собой, что «режим шифрования» сказывается, но и не служит особым камнем преткновения.
А вот хамские манеры лучше приберечь для ЛОРа и т.п. сборищ разномастных оболтусов.
комментариев: 9796 документов: 488 редакций: 5664
Что такое модель идеального шифра?.
Приведите список примеров, предпосылок, хотя бы убедительных домыслов, что существующие стойкие шифры настолько сильно отличаются от идеальной модели, с такими запроектными допусками, что это может привести к фатальному взлому, но этого почему то никто в упор не замечает.
Могу даже подтвердить, что теоретически такие предпосылки есть, но может вы назовёте их сами и приведёте оценку их применимости?
Открытого текста? Мы говорим вроде о блочном шифре. Для блочного шифра уместно говорить о соотношении размеров ключа и размера блока открытого текста. Вот иранские криптографы пишут (как обычно в Microsoft Word :), что в некоторых случаях сложность атаки равна O(max{2n, 2k-n}) для размера блока n и размера ключа k. Есть подозрение, что с дальнейшей возможностью увеличения ключа для блочно шифра больше оптимума n = k всё тоже не так гладко.
Вы пытаетесь попасть в зазор нестойкости в доли бита, который всем известен, но не имеет практической ценности? Т.е. надо или копать в глубокую теорию или ограничиваться мифами и фольклором.
Опишите модель атаки, которую можно остановить сжатием (биективным, между прочим, преобразованием).
Открытый текст становится закрытым после сжатия?
На основе того, что известно в современной криптографии — сжатие (как слабая перестраховка) может слегка усложнить атаки на шифр, который является нестойким. Стойким шифром можно шифровать всё: даже тексты, которые присылает противник; показывать ему результат расшифрования и пр. — иначе шифр нестойкий и его на помойку.
К вопросу о доверии к аппаратным ГСЧ.
У более софтовых генераторов с малоэффективным сбором энтропии, особенно в некоторых ОС, действительно были проблемы: раз, два, три.
Но есть: HAVEGE: альтернативный способ получения криптостойкой энтропии из процессоров.
Есть ли подходы к взлому такого генератора? Ссылки на реальные исследования были бы интересны.
Первая оценка возможности практического взлома AES: 1.5 триллиона US$ и менее года вычислений.
У вас есть что добавить к той новости и обсуждениям? Что-то более аргументированное и содержательное к вопросу о методике использования радужных таблиц и современных вычислительных мощностях?
Или оценки строятся на уровне рассказов про походы одних чиновников советской эпохи в кабинеты других чиновников?
А когда длинна «открытого текста» в разы превосходит длинну ключа и используется «режим шифрования» для работы с гигабайтами информации, то в игру вступает ещё и статистическая связанность. Так же, как и при отправки большого количества независимых сообщений шифрованных одним ключем. И для ухода от неё конечно же нужно сжатие и «рандомизация» перед каждый наложением гаммы.
комментариев: 9796 документов: 488 редакций: 5664
Ваши высказывания противоречат Key-dependent-PRP на уровне самого базового определения понятий.
Из определений (CPA-PRP, CCA-PRP)-security следует, что стойкость не должна зависеть от типа подаваемых со входа на выход (и обратно, с выхода на вход), данных. Про атаки со связанными, известными и подобранными ключами, уже вообще можно промолчать.
А иначе это не ICM.
Вообще-то там публикация в pdf.
Да и MS Word выигрывает в стабильности, производительности и качестве отрисовки у Writer'а входящего в тот же LibreOffice.
А формат документов word'а уже давно поддерживается опенсорсными поделками и компакнее pdf'ов.
комментариев: 9796 документов: 488 редакций: 5664
Экспортированная из MS Word. По кривости текста сразу видно.
Ни MS, ни какой другой Office-пакет обычно не используется для вменяемой подготовки пэдээфок для научных публикаций. У индусов, южнокорейцев, иранцев, ещё отчасти россиян и китайцев почему-то считается иначе.
Не удивлюсь, если такой костыль действительно где-то применяется для поддержки какого-то устаревшего шифра, режима шифрования, протокола ("чтобы не сильно проваливался"). Для соответствия каким-нибудь устаревшим внутриведомственным инструкциям, опять же.
В ряде стран научное сообщество представленно людьми далекими от "компьютерной грамотности". Привыкшими не заморачиваться по поводу пустяков и формальностей.
Вы внимательно читали вопрос? Речь шла не о сжатии контейнера а о сжатии информации ВНУТРИ контейнера.
Берем файл из "нулей" размером в 100 мб, архивируем, а лишь затем шифруем – так понятно?
Все что угодно смонтированное ТС в системе как логический диск