Поточное шифрование ATA Опции

[koziy_mf]

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

[ASN]

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

[Oldring]

То, что слабо вериться устойчивость ко взлому 1,6 Гбит в секунду, IMHO, верно. Тут вот какое дело – ключ размазан по шифруемому тексту и объём зашифрованной информации является критичным. То есть теоретически, на достаточно большом промежутке зашифрованных данных начнёт проявляться статистическая  зависимость, и ключ станет уязвим к корреляционной атаке. Как это возможно сделать я лично себе не представляю, но умные дядьки (на подобие Б. Шнаера, В. Столлингса и прочих) уверены, что возможно.

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

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

[lvitaly]

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

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

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

[Oldring]

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

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

Вся информация здесь: http://csrc.nist.gov/CryptoToolkit/aes/

В двух словах, в AES 10 одинаковых раундов. Каждый раунд - слой одинаковых побайтных S-боксов (256 байт ROM каждый или различные извращенные декомпозиции с целью экономии места на кристалле), перемешивающий слой (перестановки и не слишком глубокий XOR), слой подмешивания частичного ключа. Частичный ключ очередного слоя вычисляется заранее для всех слоев, либо как некоторое довольно простое преобразование частичного ключа предыдущего слоя - в AES вычислять частичные ключи на лету дешево.

Для многих режимов применения шифра, кроме тех, где выход предыдущего блока нужно подмешивать ко входу следующего, алгоритм легко конвейеризовать - в нашем распоряжении 80 нс на слой - получаем 800 нс суммарной задержки на блок.

Что такое конвейер - объяснять не буду, сорри, этот термин должен быть общеизвестен для всех людей, интересовавшихся работой современных процессоров. Англоязычный аналог - pipeline.

Кстати, в 2000 году, когда выбирали AES, описали реализации алгоритмов, из которых выбирали, на VHDL и смоделировали синтезированные под тогдашние доступные технологии модель. Получили от максимально конвейеризованного варианта алгоритма, принятого в качестве окончательного, пропускную способность 5.3 Gbps при 7 миллионах транзисторов и не на много меньше при 4 миллионах. Так что, 1.6 Gbps - это мелочи.