Здравствуйте всем! Я разрабатываю процедуру, которая будет шифровать файл по любому алгоритму, путем переданного адреса на элементарную функцию шифрования, к примеру на 32-З, если это ГОСТ28147-89. Так вот, в процедуру может быть переданна функция которая использует ини- циализирующий вектор(синхропосылка). У меня вопрос: Если взять размер элементарного блока и размер вектора, то будут ли они всег- да равны? ЗЫ: Вопрос следует понимать как: А есть ли алгоритмы шифрования использую- щие синхропосылку и в которых ее размер не равен размеру элементарного блока? Если вы говорите: "да, такой алгоритм есть!", то вы знаете этот алгоритм. Просьба привести его название, и режим шифрования! Для примера: В блочном алгоритме ГОСТ28147-89, если взять 32х разрядность, размер элемен- тарного блока равен 8 байтам, 32 разряда на L и 32 на R. А синхропосылка тоже имеет 8 байт! Меня очень интерисует есть ли какие нить алгоритмы шифрования, где это равенст- во не выполняется! ;--------------------------------- На последок: Мне необходимо зашифровать sizeof(инициализирующий вектор) байт, по алгоритму который использует только и только ключ шифрования, без таблиц-замен и который устойчив к криптоанализу! Это мне необходимо знать для того, чтобы ложить в конец выходного файла синх- ропосылку.
1. синхропосылка она на то и синхропосылка то шифровать её не надо. она передается в открытом виде. 2. синхропосылка может быть меньше блока не в каком-то алгоритма, а в каком-то режиме работы блочного шифра. мне ни один такой режим не известен. если посмотришь на режим cbc, то поймешь что т.к. IV ксорится в блоком, то замена алгоритма на другой вряд ли что-то изменит....
Блин, то ись можно передать синхропосылку в открытом? я все верно понял? А про "на последок"? Ни каких мыслей? Я все таки попробую реализовать с закрытием синхропосылки!
"Я все таки пришью собаке пятую ногу" без обид А если серьезно, то шифрование синхропосылки ничем не отличается от приклеивания к началу файла фиксированного количества байт случайного содержимого с выкидыванием их на приемной стороне после дешифрования.
OLS Конечно без обид, хоть сколько прикалывайся, только учи поболее. Вобщем так, я разработатал такой формат файла: /* Данный формат файлов будут иметь названия CFA-файлы, CFA - Crypto File Alberty. В честь Альберти пример: protected.cfa */ Термины: Гоша - блок который по размеру менее чем размер элементарного блока IV_first - иницилизирующий вектор для РГПЧ применяемый при шифровании part_first, о партиях ниже IV_second - ин. вектор для РГПЧ применяемый при шифровывании part_second IV_feedback - вектор применяемый при расшифровывании part_second part_first - часть данных без Гоши part_second - часть содержащая Гошу и др. нужные вещи шифрование 1. Зашифровать part_first используя IV_first Место где заканчивается part_first является "Федей" на си, федя это: Федя = &ГОША, но не всегда ибо ГОШИ может и не быть! Но это не значит то что part_2 может не быть, part_2 есть всегда 2. Вычислить следующее значение количества случайных байтов - СОНЬКА СОНЬКА - кол-во хреновых байт: temp_1 = (кол-во байт в ГОШЕ) + (кол-во байт в имени файла, включая завершающий ноль) + 8 байт(4 на кол-во байт в гоше и 4 на Федю) Округлить значение temp_1 до кратности размеру элементарному блоку в большую сторону будет temp_2 СОНЬКА = temp_2 - temp_1 3. Выделить память в sizeof(temp_2 + (размер IV_second)) байт 4. Закидываем в буфер: 4.1 Закидываем ГОШУ 4.2 Закидываем Имя оригинала, включая завершающий ноль 4.3 Закинуть СОНЬКА хреновых байт(псевдо случайных) 4.4 закинуть кол-во байт в Гоше 4.5 закинуть Федю 5. Зашифровать в буфере temp_2 используя IV_second, конечное значение IV_second есть IV_feedback 6. Зашифрвать IV_feedback используя алгоритм "securecy", после исполь- зуя простую замену СЛАБОЕ МЕСТО: В зашифрованном файле содержится имя оригинала а это значит, что это ASC_II символы, как правило. могут конечно и юникоды, так вот это значит, что: - при строчных латинских: 6 и 5 биты это "1" и "1" - при заглавных латинских: 6 и 5 биты это "1" и "0" - если учесть и заглавные и сторчные то только 6 бит является статичным "1" Вопрос: Насколько этот факт будет влиять на криптостойкость зашифрованной информации в файле?
Если алгоритм стойкий - то ни на сколько. Только вот зачем в зашифрованом файле хранить имя оригинала? А где у тебя проверка правильности расшифрования?
>А где у тебя проверка правильности расшифрования? А на фига она? Чтобы дать криптоаналитику, что он не правильно расшифровал? Я тут наткнулся на рекламные вещи одной книге по криптографии, так вот там. человек зная что файл ".doc" и в названии "накладная" предположил что на некотором месте должна стоять сумма, пользуясь стандартом на накладную. и видо изменил ее! Я не хочу довать лишней информации для криптоанализа, пусть думаю, что в файле: музака(mp3,wav), текстовик, или все таки фильм? Они будут гадать по более.
Чисто для общего развития : что такое "... рекламные вещи ..." ? Конечно он мог такое сделать, если шел какой-нибудь из режимов без обратной связи по шифротексту : OFB, CTR или еще что-либо подобное. Только для защиты от этого не шифровать надо, а ЭЦП добавлять, имитовставку или на худой конец IGE-цепочку создавать.
>"... рекламные вещи ..." я не знаю автора, а в сети долго искать тем более с такой скоростью какая в данный момент, но помню там Тарелка для приема со спутника избражена. Так вот под такими вещами, я имел ввиду то, что на сайте этой книги выложили некоторые части этой книги для ознакомления(мол глядите-ка какая рулезная инфа), чем не реклама? Да там действительно шел OFB, точнее "гаммирование". >IGE-цепочку чето дядя янд не дал хорошего определение на данный термин. Ну ничего вечером даст, когда связь будет получше. И еще: мистер flankerx говорил, что синхропосылку можно не шифровать и можно прицепить к шифрованной информации в файле в открытом виде, начем основано такое утеврждение?
Видимо на том, что она не является ключем и на стойкость алгоритма не влияет, без неё ты не расшифруешь правильно первый блок (и остальные соответственно) Хотя про остальные, кажется это справедливо только в режиме зашифрования
http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ProposedModesPa ge.html читать напротив IGE ну кстати и другие тоже очень интересно почитать
ХОрошо ключом оно есно дело не является, но ведь при шифровании учавствовало!!! причем самый первый гаммируется юзая гамму, которая только один раз через базовый цикл(в госте "простая замена") прошла!!!
Есть две разные цели: - конфиденциальность содержания - конфиденциальность формы Первое обеспечивается ключом, второе - синхропосылкой. Если хочешь повысить первое - увеличивай длину ключа, если хочешь повысить второе - увеличивай длину синхропосылки (естественно не выше размера блока - дальше бессмысленно). Шифровать синхропосылку ни для повышения первого, ни для повышения второго не нужно. Если принципиально хочешь сделать рандомизирующие данные секретными - делай как я написал выше - приклеивай к шифруемому файлу слева случайные байты размером в один блок. Только я принципиальной выгоды от их секретности не вижу. Если кто меня поправит - с радостью приму.
ну вот ты подумай... есть у тебя n блоков, зашифроаванных в CBC. Что накладывается на первый блок перед расшифрованием? А на второй? А на сорок пятый? Возможен ли произвольный доступ к данным, зашифрованным по CBC?
flankerx У меня такая мысль витала, но я как то еще не уверен в себе, поэтому пока не оформятся мысли в нормальную схему, мне кажется придется вас всех беспокоить, но вы не думайте что совсем ничего не делаю, нет, просто у меня плохой запас математ.багажа знаний. сорри, если где туплю
Тебе не помешало бы почитать Шнайера "Прикладную Криптографию". В части про CBC весьма понятно написано что такое IV, зачем он нужен и почему его не нужно хранить в секрете. RTFM.
