Появились платы с шифрованием Asus - прямо между IDE контроллером и винтом...Такое можно самому попробовать сделать? На Xilinx, например. Пусть даже для ATA 33, выше сложновато будет - скорость...У кого какие мысли есть?
Можно было бы в Инет-кафе ставить на компы....вот приходят сотрудники миллиции....конфискуют комп - а на нем то без шифра на винте один мусор - и никак не ломануть...или ну очень долго перебирать...лет 100 *))))))) И не доказать преступления против Мелкософта....*)

Для нормальных алгоритмов шифрования это совершенно некритично.

То есть Вы хотите сказать, что для нормального алгоритма шифрования даже если мне и известна часть расшифрованных данных, то это мне ни в коей мере не может помочь найти ключ для расшифровки остальной части? Верно?

Если, например, Blowfish при шифровании создает в зависимости от выбранного ключа 10 основных и 2 дополнительные матрицы, затем разбивает входные данные блоками по 64 байта (кажется) и затем шифрует эти данные (перестановкой) используя значения элементов в этих матрицах, то я НИКАК по куску известных мне данных не могу "восстановить" сами матрицы и, соответственно, ключ (хотя найдя матрицы - и ключ не нужен, ведь это и есть ключ, если известен, конечно, метод шифрования).

Если это не так, тогда однозначно нужно после разбивки данных на фрагменты сжимать каждый фрагмент (пусть по LZH), и сколько "свободного" места остается в каждом фрагменте - заполнять случайным мусором, а потом шифровать.
Хотя, сдругой стороны злоумышленник (люблю это слово) имея кусок данных, зная места разбиения фрагментов (это из алгоритма шифрования) может точно также сжать кусок по LZH, и, если мусор был добавлен не произвольно, а в конце, например, использовать такой фрагмент без окончания для дальнейших действий.
Можно, правда, и мусор раскидывать, используя определенные значения матриц шифрования, и сами значения мусоров (*))) тоже генерить исходя из ключа. Так, чтобы цикл получился. Тогда, даже и имея известную часть данных, использование их будет безсмысленно.

Я понимаю - что, в общем то - пустословлю по отношению к конкретике - то есть все не на формулах а на догадках. И тем не менее это помагает потом определиться с выбором и засесть за конуретную литературу.

Поправте, в чем не прав. Критика поддерживается!

Не совсем. Есть такие понятие как линейный и дифференциальный криптоанализ. Для гарантированного вскрытия ключа для нормальных алгоритмов необходимо определённое количество пар зашифрованного и открытого текста. Если количество пар текстов очень велико, то набрать их просто невозможно. Таким образом, решение простым перебором "в лоб" наиболее простое.

Про понятия я в курсе.

Говоря простыми словами, в настоящее время нормальным считается только тот шифр, для которого для произвольного ключа из любого заданного подкласса ключей, защитого внутри черного ящика, реализовывающего шифрование и расшифровку этим ключем, не существует известного алгоритма определения зашитого ключа, более эффективного, чем полный перебор возможных ключей. Криптоаналитик при этом может произвольным образом и в произвольном порядке генерировать входы черного ящика и смотреть, что появляется на выходе. Если такое свойство выполняется - тогда, очевидно, знание только некоторых пар вход-выход (как в рассматриваемом случае) ему не слишком может помочь. Сжатие позволяет дополнительно застраховаться на случай, если, вдруг, такой алгоритм будет когда-либо открыт.

BTW AES, например, доказуемо устойчив к линейному и дифференциальному криптоанализу.

Oldring
Уважаемый, про понятия я, конечно же, не Вам отписал. Извиняюсь, что не указал адресат.
IMHO, просто сжимать исходные данные - это, по существу, выполнить дополнительное зашифрование. То есть достаточно зашифровать одним алгоритмом, и зашифровать этот же текст ещё раз другим (наподобие TripleDES). Если при этом, использовать различные ключи (или один ключ длиной 128 бит), то сложность даже для атаки «встреча посередине» становиться слишком большой, а дешифрование данных невозможным. Сжатие данных – это способ снизить расход ключа, но ценой значительного увеличения вычислительных мощностей. Тем более, что это эффективно только если исходные данные принципиально сжимаемы. IMHO, для современных форматов хранения аудио- и видео- записей (а также для исполняемых файлов) это свойство исходных данных отсутствует. Так что, ничего проще и надёжней, чем генератор гаммы, IMHO, предложить нереально. Тут ведь речь идёт о скорость в единицы мегабит в секунду.
jeka
То, что слабо вериться устойчивость ко взлому 1,6 Гбит в секунду, IMHO, верно. Тут вот какое дело – ключ размазан по шифруемому тексту и объём зашифрованной информации является критичным. То есть теоретически, на достаточно большом промежутке зашифрованных данных начнёт проявляться статистическая зависимость, и ключ станет уязвим к корреляционной атаке. Как это возможно сделать я лично себе не представляю, но умные дядьки (на подобие Б. Шнаера, В. Столлингса и прочих) уверены, что возможно.
koziy_mf
Разрабатывать, (в смысле, «исследовать» для собственного образования) различные алгоритмы преобразования информации (например, с целью повышения «достоверности хранения» или «устойчивости к передачи») Вам никто запретить не может. Это Ваше право. В том числе и в USA. Вы даже можете публиковать Ваши наработки в открытой печати, но не в электронном виде. Вы не имеет право также продавать или сдавать в аренду Ваши устройства.
Если уж встала задача аппаратного зашифрования, то, IMHO, проще скачать с opencores.org пару корок, купить Evolution board и всю критичную инфу гонять бы через сей девайс. Хотя, ежели кому-то очень надо «хакнуть» Вашу инфу, то они это сделают очень просто: либо просто считают всё информацию прямо с экрана монитора, либо выкрадут ключ – ведь 128 бит абсолютно случайной информации не в голове же хранить. . Так что, IMHO, Вы всё правильно делаете – простецкий программный маскиратор и «случайная» длинная фраза, захешированная в пароль – самое то.

Nu spasibo - teper' mojno spat' spokoyno *) I posledniy vopros - A chto takoe "атакa «встреча посередине»" ? V dvuh slovah, dlia barana v kriptografii.

koziy_mf
Если очень вкратце, то криптоаналитик подбирает тексты таким образом, чтобы высчилять значения сразу обоих ключей, то есть количество текстов равно не 2**(n*n), а 2**(n+1). Лучше, конечно, почитать Ваше нынешнего "соотечественника" Б. Шнаера. Там всё подробно описано... Это очень интересная область - я, например, прочитал дважды просто для собственного развития .

Возьмем, например, AES-128. 1.6 ГБит в секунду - это 80 ns на блок. Что же в этом невероятного? Особенно, с учетом хорошей конвейеризуемости алгоритма? Или я что-то пропустил, и AES уже скомпрометирован?

IMHO шеноновские теоретические границы, связанные с equivocation, не имеют никакого отношения к _практической_ возможности взлома современных шифров. Допустим, нам известен результат шифрования AES-128 с некоторым неизвестным ключем блока из 128 нулевых бит. Очевидно, этих 128 бит достаточно для определения ключа. Полным перебором. Но какая от этого практическая польза?

Я бы не сказал, что 80 нс на блок - это так уж тривиально. Обработка блока в AES - 43 раунда, кажется. Если взять наш ГОСТ - 32 раунда. 2 нс на такой раунд вряд ли представляются тривиальной задачей. Особенно если делать на FPGA, а не на ASIC.

Кроме того, очень хотелось бы услышать - что имеется в виду в данном случае под конвееризацией алгоритма шифрования?

А кто-нибудь пробовал реализовать наш ГОСТ на ПЛИС?

Если пробовал, то очень интересно, какая получалась рабочая частота проекта при учете того, что шифрование блока выполняется за 32 такта. Т.е. раунд за такт.

Я думаю, что пробовали многие. Лично у меня выходило 132 МГц такт, 35 тактов на блок. Использовал Xilinx Virtex-2. Задачи добиться более высокой частоты не было.

Oldring
Уважаемый, я же указал, что "...Как это возможно сделать я лично себе не представляю, но умные дядьки (на подобие Б. Шнаера, В. Столлингса и прочих) уверены, что возможно.(с) ASN" . Я же интересующийся любитель, а не профессионал .
lvitaly
Yes! ГОСТ

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

Да, это самый длинный путь. Но есть нормальный способ решения именно этой проблемы. Большего, увы, я Вам не скажу, поскольку начинаются конкретные know how. Я занимаюсь ГОСТом (и сопутствующими ГОСТами) уже несколько лет, так что если нужно что-то сделать в этой области - милости просим в мыло.

makc
Просто, без изысков

Что такое PERMUTE_4x4 по предыдущей ссылке. На выходе KeyData - триггеры, тогда путь становиться минимально возможным. Поэтому и 35 тактов (данные, то в CM1 := ADD_32(KD,N1) будут только на следующем такте) .