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

[koziy_mf]

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

[jojo]

Лицензии от Микрософта дешевле обойдутся, чем такой самодельный "шифрователь"

Хороший повод перейти на пресловутый Линукс. Если он в плане коммерческого использования рулит, конечно.

[grumbler]

так сделано давно - работает и продается...
http://users.compnet.ru/elips/grimdisk.htm

[koziy_mf]

Радиоприемники тоже продаются, однако сколько народу сидело (а кто и сидит) за платой и дышет аромат канифоли *)))

[jojo]

кто говорил, что нельзя сделать? ..

и цена:
Плата ГРИМ-диск + контейнер + 2 таблетки Touch Memory + 1 год гарантии при нашей сборке 850 у.е.

[koziy_mf]

Да нахрен без той таблетки ну ее...надо использовать то, что есть..вот самое сердитое - SIM карты, ее фонарь программить и с внешним устройством коннектить...пусть она - ключ, закрытый, на запрос слусайного числа от контроллера генерит число, пусть это число и является ключом...короче как механизм аутентификации в GSM...ну или ввод пароля с той же клавы. Контроллер должен в зависимости от кода настроить матрицу на поточное дешифрование-шифрование...ну можно и на одном контроллере, но я только со слабыми работал (Tiny Atmel-e),....Жаль - что я на кафедре криптографии не учился...
А может в натуре голову не морочить и купить эту материку? Кстати - цена то на 20$ дороже будет от основной...без 800 баков *)))) Но когда сам делаешь - крутишь чего хочешь, а что кто-то сделал - иди копайся...

[AB27]

Как называется материнка? У ASUS вроде нет такой. Может быть ABit?

http://news.proext.com/hard/12010.html

[koziy_mf]

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

[AB27]

Все-таки это отдельная плата
http://www.abit-usa.com/products/multimedia/secureide
Стоит около $80. Материнка вместе с ней около $200.
Есть одно но: там ключ только 40 бит. Этого явно мало.

Чипы (ASIC) производит компания Enova
http://www.enovatech.net/products.htm
Есть чипы с длиной ключа до 192 бит.

[jeka]

Да, устройства интересные. Но немного смутило отсутствие радиатора и строчка:
- "Real-time" transparent automatic encryption with 1.6 Gigabit per second throughput.
Слабо мне верится в устойчивость от взлома данного метода кодирования хотя-бы потому что данные по всей видимости не сжимаются, а на диске некоторые сектора содержат стандартный код. Безусловно, для защиты от "дурака" сойдет на ура, но в серьезных системах такую штуку вряд-ли можно применять. Можно было б какую-никакую избыточность сделать, предварительно архивировать данные, а еще лучше кодировать их по случайному избыточному коду.

[AB27]

Надежность применяемых здесь алгоритмов DES/TDES зависит от длины ключа. Ключ 40-64 бит можно подобрать перебором всех возможных комбинаций. Для 128-192 бит это уже невозможно. То что данные не сжимаются, это как раз подходит для записи на диск, т.к. данные записываются в те же сектора, что и без шифрования.

[koziy_mf]

Верно то, что если знать - что записано, то легче найти ключ. Я в криптографии не сильно разбираюсь (не баран, конечно *))), но, например, известно на примере того же RAR: в Advanced RAR password recov. можно ввести, если известны, первые байты зашифрованого файла. Там если заведомо известно что это exe-файл, то 4D 5A (Win32) и т д. Это значительно должно ускорить поиск пароля по методу прямого перебора. Вот только я пытался так делать, набирал пароль на 7-8 символов. Нихрена - все тактже долго искало...
А ASIC...может с мобильника вытащить? Правда скорости для ATA уж точно не хватит *)))))))
Кстати - пытался таким же методом найти пароль к PGP. По заведомо известным данным...тоже нихрена не получается.
Восстановить функцию (ключ), подставляя аргументы, невероятно сложно, если функция, конечно, не 2*x :D ...а иначе бы и криптографии не было *)
А с избыточностью верно...вводя ее, было бы абсолютно невозможно получить ключ по известным данным на HDD.
Может когда-нибудь сделаю...скорей всего не в этой жизни *))

[koziy_mf]

А стоимость такой платки какая (на сайте нет) с ключем на 128-192 бит для одного HDD? Мне понравились их разаработки. Такой чип enova можно на матрице сделать, алгоритмы DES описаны, IDE интерфейс - тоже...
Да - еще момент - кто в курсе - в USA кажется запрещено шифрование выше n-го числа бит...???

[Esquire]

в USA кажется запрещено шифрование выше n-го числа бит...???

Вряд ли (иначе как объяснить использование Blowfish с ключом 448 бит?), а вот экспорт продуктов, применяющих определенные алгоритмы (в т.ч. DES), запрещен в некоторые страны.
По крайней мере, этим объясняется ограничение длины ключа RC4 в старых версиях Office 40 битами.

[koziy_mf]

Да, боятся, что секретную инфу начнут таскать *)) Я нигде не нашел про USA (поэтому и спросил). Тут просто такая лажа творится с музыкой, фильмами и продуктами Microsoft...скоро начнется тоталитарный режим, обыски, глобальное стукачество...Уже параноя какая-то пошла - все, что режу на DVD-R, шифрую в PGP...вот есть идея на аппаратную шифровку, да чтобы подешевле. И думаю - а может и это незаконно...будь оно все.

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

[Oldring]

Да, устройства интересные. Но немного смутило отсутствие радиатора и строчка:
- "Real-time" transparent automatic encryption with 1.6 Gigabit per second throughput.
Слабо мне верится в устойчивость от взлома данного метода кодирования хотя-бы потому что данные по всей видимости не сжимаются, а на диске некоторые сектора содержат стандартный код. Безусловно, для защиты от "дурака" сойдет на ура, но в серьезных системах такую штуку вряд-ли можно применять. Можно было б какую-никакую избыточность сделать, предварительно архивировать данные, а еще лучше кодировать их по случайному избыточному коду.

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

[koziy_mf]

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

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

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

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

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

[ASN]

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

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

[Oldring]

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

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

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

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

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

[ASN]

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

[koziy_mf]

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

[ASN]

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

[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.

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

[makc]

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

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

[lvitaly]

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

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

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

[ASN]

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

[makc]

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

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

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

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

[lvitaly]

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

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

[ASN]

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

Код

variable Math33: Math_32_Type;
variable CY: std_logic;
...
    PM   := PERMUTE_4x4(C.CM1);
    Math33:= ADDC_32(C.N4,N6,CY);
    CY    := Math33(KEY_VECTOR_LENGTH);
...

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

[lvitaly]

триггеры, тогда путь становиться минимально возможным. Поэтому и 35 тактов

35 тактов не поэтому, тут хватило бы 33 такта
Но, imho, тема себя исчерпала, уже начинаются частные беседы, поэтому лучше переместиться в мыло или PM (не будем засорять конференцию)

[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 - это мелочи.

[lvitaly]

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

Ну наконец-то, открыли мне глаза
Подтекст был таков - если какой-то режим работы шифра хорошо конвейеризируется, то этот режим является менее (возможно очень менее) стойким, чем тот, для которого конвейеризация невозможна.

Если по аналогии взять режим простой замены ГОСТ в качестве режима шифрования сектора диска, то шифруя каждый 64-битный блок независимым шифратором очень легко сделать поточный шифратор хоть для UDMA 133 (напихать шифраторов в крупную FPGA). Вот только его качество будет весьма сомнительным.

варианта алгоритма, принятого в качестве окончательного, пропускную способность 5.3 Gbps при 7 миллионах транзисторов и не на много меньше при 4 миллионах. Так что, 1.6 Gbps - это мелочи.

Так это понятно, но одно дело ASIC, а другое - FPGA. Я просто подумал, что тема посвящена больше не тому, что можно в принципе там, а тому, что можно сделать самому и здесь.

[ASN]

lvitaly
Утверждение, что конвейеризация снижает стойкость алгоритма, IMHO, достаточно спорное. Я хоть и не криптограф, что знаю, что все классические симметричный шифры используют сети Фaйстеля в качестве основы для своего функционирования. Все фaйстеливские шифры раудовые и имеют одно хранилище ключей, используемое в преобразовании данных. Конвейеризация в данном случае – это просто дублирование узлов и размножение хранилища ключей. То есть, если обеспечивается основное правило о секретности ключа для всех хранилищ, то конвейерная версия нисколько не отличается от её неконвейерной версии в плане стойкости. Использовать ГОСТ, IMHO, можно, если исключить возможность навязывания своих данных (то есть исключить возможность дифференциального криптоанализа). Это делается очень просто, если использовать режим гаммирования. Слабость ГОСТ доказана только к генерации аппаратных ошибок и всё (у DES плюс к этому – недостаточная длина ключа). При условии отсутствия доступа к аппарату зашифрования ГОСТ абсолютно стоек ко всем существующим (и перспективным) методам криптоанализа и взломать его можно только "влоб" -
он просто морально устарел (слишком медленный и затратный для реализации).
Стандарт AES требует меньше раундов, хорошо конвейеризируется и проще для понимания. И для шифрования диска я бы использовал либо AES либо SPECTR-128.

[lvitaly]

А кстати, где-то читал (попробую найти), что AES не основан на сетях Файстеля, и что именно поэтому при приличной конвейеризируемости не происходит снижения стойкости. Я и воспринял от обратного.

Насчет ГОСТ - вот только нигде не видел данных о зависимости его стойкости от содержимого узла замены. Кажется на РусКрипто в феврале будет доклад, посвященный этой тематике - от нас едет представитель, могу потом вкратце рассказать, если интересно.

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

А вообще, нам все равно придется делать AES на FPGA. Через месяцев пару смогу рассказать о результате, если интересно.

[Oldring]

Если по аналогии взять режим простой замены ГОСТ в качестве режима шифрования сектора диска, то шифруя каждый 64-битный блок независимым шифратором очень легко сделать поточный шифратор хоть для UDMA 133 (напихать шифраторов в крупную FPGA). Вот только его качество будет весьма сомнительным.

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

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

[Maksim]

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

Или паяльник в задницу . Тоже метод

[koziy_mf]

"Payal'nik v zadnicu...".. dlia chego? Dlia togo, chtobi vibit' kluch?????
Voobshe - reshenie electronshika *))) Tol'ko 60 Watniy, Sovetskiy. Kitayskie payal'niki dlia etoy celi ne godiatsa, kak i vse ih ostal'nie komponenti - rezistori, conderi itd *)

To: lvitaly
Interesno. Esli vremia budet - rasskajite. I interesuyet obshaya cena (bez zatrat na razrabotku i programmirovanie - ya imeyu v vidu - cenu komponentov + plata, i v obshem - na chem delali, mojete bez Nou-Hau, dlia russkogo cheloveka eto virajenie vseravno chto pokupat' gluchniy OrCAD za den'gi) )

[Oldring]

"Payal'nik v zadnicu...".. dlia chego? Dlia togo, chtobi vibit' kluch?????
Voobshe - reshenie electronshika *)))

Для тех, кто не знает - это классический метод криптоанализа, называемый в различных источниках как "проктотермальный" или "терморектальный".

[cupertino]

Для надежного шифрования диска сушествует новый криптографический стандарт на базе AES - IEEE P1619. Он абсолютно надежен и очень быстр - опубликованы ссылки на 70 Gbps реализации.

[Doka]

cupertino, спасибо. весьма интересный стандарт!!
и хоть он и пока в статусе draft, IP-корок уже достаточно в интернете.

по сути - двойное применение AES с подмешиванием информации о адресе сектора для затруднения криптоатак. (XTS-AES).

вот они пишут: "The disk sector sizes frequently chosen for disk systems are 512, 520, 528 and 4096 bytes."
а где сектора по 520, 528 байт? на флеш чтоли?? но это же вроде на уровне контроллера флеш, а не на уровне контроллера дисков доступ к "избыточным" байтам сектора.

[cupertino]

и хоть он и пока в статусе draft

Это уже хорошо созревший draft. Несколько месяцев назад там произошла революция, и они поменяли LRW mode на XEX (который затем переименовали в XTS, так как поиск в интернете на термин ХЕХ в основном приводил на порно сайты). Процесс был весьма болезненым, тат как многие участники уже начали делать железо под LRW, и я не думаю, что группа P1619 пойдет на какие-нибудь радикальные замены еще раз.

вот они пишут: "The disk sector sizes frequently chosen for disk systems are 512, 520, 528 and 4096 bytes."
а где сектора по 520, 528 байт? на флеш чтоли?? но это же вроде на уровне контроллера флеш, а не на уровне контроллера дисков доступ к "избыточным" байтам сектора.

Сектора по 520 или 528 байт встречаются редко, но они упоминаются в стандарте из-за того, что для их обработки нужен специальный режим - так как AES работает только со 128 битными (16 байтов) блоками, а ни 520, ни 528 на 16 нацело не делятся, для работы с остатком придуман специальный режим - CTS (ciper text stealing)

[Doka]

вот они пишут: "The disk sector sizes frequently chosen for disk systems are 512, 520, 528 and 4096 bytes."
а где сектора по 520, 528 байт? на флеш чтоли?? но это же вроде на уровне контроллера флеш, а не на уровне контроллера дисков доступ к "избыточным" байтам сектора.

Сектора по 520 или 528 байт встречаются редко, но они упоминаются в стандарте из-за того, что для их обработки нужен специальный режим - так как AES работает только со 128 битными (16 байтов) блоками, а ни 520, ни 528 на 16 нацело не делятся, для работы с остатком придуман специальный режим - CTS (ciper text stealing)

ну да. читал про CTS . несколько заморочно сделано по сравнению с тем, как кодируются другие блоки.
просто непонятно вот что: в азиках всяких для SATA-II 3Gb/s также заявлено о ее поддержке (CTS). - но вроде ка кона для HDD не особо-то и нужна. отсюда и вопрос.


ктсати, вроде еще есть такая штука как Trusted Platform Module.
заявлена как аппратно-программная штука для (в том числе) защиты данных на дисках.
только что-то мутно оно как-то.. какой-то чип на мамке - так.. сбоку-припеку..
хотя занимаются им вроде серьезные дядьки (в TCPA/TCG - Trusted Computing Platform Alliance/Trusted Computing Group входят AMD, Hewlett-Packard, IBM, Intel, Microsoft, Seagate, Sony, Sun).

[cupertino]

ну да. читал про CTS . несколько заморочно сделано по сравнению с тем, как кодируются другие блоки.

CTS сделан так из-за того, что укороченный plain text надо дополнить чем-то случайным, непредсказуемым - блок, в котором большая часть информации известна, легко ломается. Я согласен, программировать CTS не самое приятное занятие (особенно в режиме расшифровки), но что делать...

ктсати, вроде еще есть такая штука как Trusted Platform Module.
заявлена как аппратно-программная штука для (в том числе) защиты данных на дисках.
только что-то мутно оно как-то.. какой-то чип на мамке - так.. сбоку-припеку..

Trusted Platform Module работает вместе с софтварным шифрованием, что, естественно, замедляет доступ к диску. XTS hardware accelerator при относительно небольших размерах может обеспечивать многие гигабиты в секунду, делая шифрование совершенно невидимым с точки зрения производительности системы.