режимы шифрования

Обратите внимание на режим счётчика (CTR). Он достаточно проанализирован (и стандартизирован NIST), не налагает жёстких требований на ГПСЧ (в сущности, даже в нём не нуждается) и гарантирует уникальность каждого шифртекста.

Если я правильно понимаю, для режима CTR необходима синхронизация счетчиков у отправителя и получателя. Т.е отправитель и получатель должны знать вектор инициализации, которым будут проинициализированы счетчики (ГПСЧ). Опять же, при неизменном векторе инициализации шифрование одинаковых сообщений даст одинаковые шифротексты.
В моем примере ГПСЧ инициализируется случайным вектором (Randomize), поэтому результаты всегда разные.
Обьясните, может я что-то не правильно понял?

Значение счётчика — не секрет, это просто последовательный номер зашифрованного блока. Соответственно, никакой синхронизации не требуется. Более того, можно осуществлять доступ к произвольной части шифртекста, чего Вы не достигнете при использовании CBC.

CTR — это потоковый режим шифрования. Для получения гаммы Вы заданным ключом зашифровываете случайные данные (вместо rand лучше используйте что-нибудь более простое и уникальное, скажем, дату и время зашифрования: ВИ не должен повторяться, а обычный rand этого не гарантирует), конкатенированные с показателем счётчика. А затем XOR'ом накладываете гамму на открытый текст.

Расшифрование выполняется полностью идентично, не нужно даже писать дополнительных функций. Просто на вход функции вместо открытого текста подаётся шифртекст. Значение случайных данных берётся из самого сообщения (оно должно передаваться открыто).

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

Это относится только к CBC с фиксированным вектором инициализации. Если IV использовать каждый раз случайный, то никакого повторения шифртекстов не получится.
Т.е. в т.н. режиме CBC$ генеририруется IV<-$, где "$" обозначает случайность.

Также нужно поступать и в режиме счётчика.

Иногда используется шифрование вектора инициализации, но по современным представлениям шифрование всегда должно использоваться совместно с аутентификацией, поэтому IV передаётся в открытом виде и в режиме счётчика и в режиме CBC.

В последнее время предпочтение отдаётся режиму счётчика, как наиболее простому и формально проанализированному.

Входная последовательность дополняется "мусором" до выравнивания по размеру блока (64бита).

Можно сделать проще: дойти до последнего полностью заполненного блока, кратного 64, зашифровать его ключём шифрования ещё один раз и использовать нужное количество этих бит для XOR с открытым текстом последнего неполного блока, ненужные биты отбросить. Вам не понадобятся ни мусор для заполнения, ни дополнительный байт для указания его размера.

Или использовать более стандартную схему заполнения последнего блока "ciphertext stealing":

Влияет ли как то на стойкость алгоритм его генерации, подойдет ли здесь стандартный Random?

Просто никогда не используйте стандартный random в криптографических приложениях (если это только не вызов юниксового устройства /dev/{u}random ). Причин может быть миллион. Лучше просто знать, что так делать не надо.

В результате при шифровании одних и тех же данных зашифрованные получаются всегда разные (точнее, количество вариантов определяется размером XOR-ключа и в данном случае составляет 4294967295).

4294967295=2^32, но в результате "парадокса дней рождения" у Вас возможна утечка информации уже после шифрования 2^(32/2)=2^16=65536, т.е. всего 64 килобайта данных или 65535 попыток ???

Я попытался формализовать Вашу схему, только не могу понять почему размер "XOR ключа" 32 бита вместо 64:

#Pseudocode: K_real <- $ &#123;64 bit&#125; ######################## algorithm Ek_real&#40;M&#41; Break M into n-bit blocks M[1]...M[m] GarbagePadding &#40;M&#40;m&#41;&#41; <-$ to 64 bit GPv <- Value &#40;GarbagePadding&#41; K_xor_init <- $ &#123;32 bit&#125; Break K_real to 32 bit &#40;into K_1/2_real&#41; k_xor <- &#40;K_xor_init&#41; XOR &#40; K_1/2_real&#41; for i <- 1 to m do C[i] <-Ek_xor&#40;C[i-1] XOR M [i]&#41; C<-C[1]...C[m] return <GPv, K_xor_init, C> ########################## algorithm Dk_real &#40;<GPv, K_xor, C>&#41; GPv <- Value &#40;GarbagePadding&#41; Break C into n-bit blocks C[1]...C[m] Break K_real to 32 bit &#40;into K_1/2_real&#41; k_xor <- &#40;K_xor_init&#41; XOR &#40; K_1/2_real&#41; for i <- 1 to m do M[i] <-E&#40;^-1&#41;k_xor&#40;C[i] XOR C[i-1]&#41; M<-M[1]...M[m] GarbagePaddingRemove &#40;M&#40;m&#41;&#41; <- GPv from 64 bit return <M> ##########################


У меня нет возможности провести конкретный анализ, но схема нестандартная и может содержать уязвимости.
Например при атаках с подобранным или известным открытым текстом мы в первом блоке всегда сможем получать на выходе зависимость одного и того же ( или подобранных) открытых текстов, соотвествующих им шифртекстов, но зашифрованных на разных ключах и ещё будем знать значение XOR разности этой зависимости. Т.е. будем контролировать вход шифра. Достаточно ли этого для проведения атаки?
Если шифр стойкий, то нет, но в стандартном CBC такой возможности не предоставляется.

Однако в последнее время опубликовано больше работ, где режим CBC прогоняется через модели "случайных оракулов", игровые модели и т.д. Если кто-то хорошо владеет этими техниками анализа возможно он скажет больше насчёт достоинств и недостатков Вашей схемы.

Могу лишь посоветовать придерживаться стандартных схем CBC$ со стойким генератором IV, равным размеру блока или схемы CTR.

CTR — это потоковый режим шифрования. Для получения гаммы Вы заданным ключом зашифровываете случайные данные (вместо rand лучше используйте что-нибудь более простое и уникальное, скажем, дату и время зашифрования: ВИ не должен повторяться, а обычный rand этого не гарантирует), конкатенированные с показателем счётчика. А затем XOR'ом накладываете гамму на открытый текст.

Расшифрование выполняется полностью идентично, не нужно даже писать дополнительных функций. Просто на вход функции вместо открытого текста подаётся шифртекст. Значение случайных данных берётся из самого сообщения (оно должно передаваться открыто).

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


Тогда какая должна быть разрядность у счетчика и ГПСЧ?
Может логичнее инициализировать счетчик сгенерированными случайными данными, которые потом добавляются к шифртексту?

Это относится только к CBC с фиксированным вектором инициализации. Если IV использовать каждый раз случайный, то никакого повторения шифртекстов не получится.
Т.е. в т.н. режиме CBC$ генеририруется IV<-$, где "$" обозначает случайность.

В этом случае вектор инициализации необходимо также в открытом виде добавлять к шифртексту.
Если в схеме CTR не использовать счетчик, или в схеме CFB не использовать связывание блоков, то получится т.н. "потоковый режим гаммирования", который обеспечивает разные шифртексты, но не обеспечивает различие зашифрованных одинаковых блоков в пределах одного сообщения (с одной сгенерированной гаммой). Т.е. это получается разновидность режима счетчика? Или разновидность CFB? Или я уже совсем запутался?

Можно сделать проще: дойти до последнего полностью заполненного блока, кратного 64, зашифровать его ключём шифрования ещё один раз и использовать нужное количество этих бит для XOR с открытым текстом последнего неполного блока, ненужные биты отбросить. Вам не понадобятся ни мусор для заполнения, ни дополнительный байт для указания его размера.

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

4294967295=2^32, но в результате "парадокса дней рождения" у Вас возможна утечка информации уже после шифрования 2^(32/2)=2^16=65536, т.е. всего 64 килобайта данных или 65535 попыток ???

Ну здесь не совсем утечка, в любом случае не хуже ECB. Ведь к исходному тексту доступа нет, а изменение шифртекста нужно для дополнительного внесения неопределенности. Откуда врагу знать, что в определенных местах совпали исходные сообщения и "XOR-ключ"?

Просто никогда не используйте стандартный random в криптографических приложениях (если это только не вызов юниксового устройства /dev/{u}random ). Причин может быть миллион. Лучше просто знать, что так делать не надо.

А какой тогда использовать? Если генерировать на основе времени / каких-то других внешних факторов, то резко замедляется быстродействие.
Нашел вот такой вариант:
Также встретил следующую аццкую рекомендацию:

Источник последовательности элементов для выработки гаммы является настолько важным компонентом шифра, что разработчики российского стандарта шифрования сочли необходимым определить его явным образом. Стандартный источник состоит из двух независимых рекуррентных генераторов 32-битовых элементов с периодами 2^32 и 2^32-1, в результате чего период повторения всей последовательности равен 2^32(2^32-1) ~ 2^64. Кроме того, соседние элементы последовательности отличаются по крайней мере на один бит в каждом байте.

Что Вы думаете насчет этого?

забыл подписаться..

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

Именно в открытом виде эти данные и надо добавить к шифртексту.

Возьмите информацию хотя бы здесь:
http://en.wikipedia.org/wiki/B.....r_modes_of_operation,

http://en.wikipedia.org/wiki/Residual_block_termination

Short message

For messages shorter than one block, residual block termination can use an encrypted IV instead of the previously encrypted block.

только проверьте по ссылкам, что её никто не испортил.

Ведь к исходному тексту доступа нет,

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

Если она выстоит против этого, тога можно думать, что она чего-то стоит и на практике.

Linear Feedback Shift Register (LFSR)

Это классика криптографии (60-е годы прошлого века, возможно более ранне изобретение, сейчас их редко используют по причине нестойкости).

Вообще всё уже изобретено, если нужна теория – читайте работы Bellar & Rogaway и их предшественников, если практика, то есть готовые стандарты. Для начала общепринятые, затем можете сравнить их с отечественными.

Фактически общепринятыми считаются американские стандарты (или официальные рекоммендации),:
http://csrc.nist.gov/publicati.....00-38a/sp800-38a.pdf,
хотя некоторая путаница может быть и в них и в российских стандартах.

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

А как насчет LRW, что за зверь, стоит по умолчанию в TrueCrypt, какие мнения есть?
"Volumes created by this version of TrueCrypt can be encrypted only in LRW mode. CBC mode has been deprecated (however, volumes encrypted in CBC mode can still be mounted by the current version of TrueCrypt). LRW mode is more secure than CBC mode and is suitable for disk encryption. LRW mode is to become an IEEE standard for sector-based storage encryption (P1619)"
http://www.truecrypt.org/docs/? S=modes-of-operation

Не совсем по LRW, но похожее обсуждение у нас было http://www.pgpru.com/%D4%EE%F0....._comments=1#comments

На основе http://clemens.endorphin.org/LinuxHDEncSettings и др. источников.

Дополнительные режимы нужны:

1) Для шифрования дисков, контейнеров со встроенной файловой системой, а не отдельных файлов и связанных с этим особенностями возможных атак.

2) Для объединения в одном режиме и шифрования и аутентификации.

Собственно, LRW и нужен для шифрования дисков http://en.wikipedia.org/wiki/Disk_encryption

Сделал режим счетчика. Использовал ГПСЧ
// The "Mother-of-all Pseudo Random Number Generators"
// Invented by Dr. George Marsaglia, Florida St. Univ., Dept. of Statistics
// Assembly implementation by Agner Fog
// Delphi BASM conversion, v1.0, ©1999, EFD Systems
// Excellent statistical properties and extremely long
// cycle length (approx. 3*10^47)
В принципе, он используется в качестве счетчика, поэтому я не думаю, что его стойкость имеет значение. Вот для генерации его начального значения используется Windows API coCreateGuid. Теоретически, она должна генерировать неповторяющиеся значения.

http://sector18.narod.ru/rc5.rar

Почему-то это напоминает потоковый шифр, где в качестве ГПСЧ, инициализируемого ключем, используется шифр RC5.
Хочу еще сделать режим CBC со случайным вектором инициализации.
Буду рад услышать полезные замечания и конструктивную критику :)

Мышки плакали, кололись, но продолжали жрать кактус...

Кстати, celeron, Вы ведь кажется были зарегистрированы в старом форуме. Зачем регистрировались снова?