id: Гость   вход   регистрация
текущее время 18:56 08/12/2019
Автор темы: Гость, тема открыта 15/07/2008 17:07 Печать
Категории: криптография, инфобезопасность, алгоритмы, симметричное шифрование
https://www.pgpru.com/Форум/Криптография/НужныТестовыеВекторыГОСТ28147-89
создать
просмотр
ссылки

Нужны тестовые векторы ГОСТ 28147-89

люди, пишу реализуцию, нужны векторы на правильность простой замены и имитовставки.



 
На страницу: 1, 2, 3 След.
Комментарии
— unknown (15/07/2008 17:50)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
А у кого вы брали S-блоки, они ведь в стандарте не опубликованы, а откуда тогда тестовые векторы официально взять?
— Имя (16/07/2008 13:24)   <#>
нет, мне необходимо проверить правильность реализации, официальные тестовые векторы не нужны.

таблицу замен можно использовать ту, что использует Центробанк РФ (ее описывает шнайер в Прикл. Крипт.).

можно просто зашифровать два 64-битовых блока по ГОСТ с имитовставкой по сертифицированной программе (ну можно и без сертификации) и выложить сюда.

естессно, приложите и откытый текст с ключом – а то какой-нибудь умник закинет только шифртекст :)
— SATtva (16/07/2008 13:32, исправлен 16/07/2008 13:33)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Вы уверены, что в "любой сертифицированной реализации" будут именно цэбэшные векторы из книги Шнайера?
— unknown (16/07/2008 15:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664








Случайный мусор вначале – это скорее всего IV – он всегда разный даже для одного ключа, равен размеру блока шифра (64 бит) и приписывается к началу шифртекста даже в режиме ECB.
А в конце – неполный блок, он всегда одинаковый для одного и тогоже ключа.

Программа несертифициорована.

ECB – это простая замена, а имитовставка – это я так понимаю CBC?



и ещё раз тот же ключ с другим IV:

— unknown (16/07/2008 15:14, исправлен 16/07/2008 15:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Кстати размер ключа у ГОСТ вообще-то 256-бит, а программа в режиме задания ключа hex съедает сколько угодно шестнадцатиричных знаков, но после 32 байт их не различает так что ключи скорее всего дполняются до:

0x00..01..00 и 0x00..02..00 (256 бит)
— Имя (16/07/2008 15:39)   <#>
имитовставка-это последовательность из L бит, где L – от 1 до 32.

в основном нужна была она, но все равно спасибо. сейчас буду разбираться что к чему.
— Имя (16/07/2008 15:45)   <#>
кстати, какая таблица замен? Без нее проблематично все сделать. или мне подбирать 512 бит? ))
не имеет значения какая ТЗ – главное, чтобы была указаны узлы замен.
— unknown (16/07/2008 16:11)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Посмотрите в исходниках. Скорее всего S-блоки (таблицы замен) из Большой Красной Книги Шнайера.
— Гость (08/05/2010 18:47)   <#>
В контексте комментариев /comment24232 и /comment24370 хотел бы задать вопрос про mcrypt vs openssl для симметричного шифрования. Вроде бы эти тулзы имеют пересекающийся функционал, и всё, что можно сделать mcrypt'ом, можно сделать и openssl'ем. В чём тогда преимущества/недостатки/ниша этих продуктов?

По поводу mcrypt: его опция -a rijndael-256 делает не то же самое, что и конвенциональный AES256. В 1ом варианте размер блока составляет 256, а во втором – 128 (причём это стандарт). Схема паддинга не полне соответствует PKCS-5. Размер ключа у обоих 256, как и должно быть. IV в mcrypt не выводят из пароля согласно PBKDF2, а генерят случайно и хранят в файле.

PS: openssl тоже может генерить шифрованные файлы без заголовка (наподобие mcrypt -b), что-то типа openssl enc -aes256 -nosalt.
— Гость (15/05/2010 01:18)   <#>
unknown, в вышеприведённом комментарии негласно подразумевалось, что Вы скажете что-нибудь по этому поводу :)
— unknown (16/05/2010 16:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
IV в mcrypt не выводят из пароля согласно PBKDF2, а генерят случайно и хранят в файле.


-salt use a salt in the key derivation routines. This option should ALWAYS be used unless compatibility with previous versions of OpenSSL or SSLeay is required. This option is only present on OpenSSL versions 0.9.5 or above.
-nosalt don’t use a salt in the key derivation routines. This is the default for compatibility with previous versions of OpenSSL and SSLeay.


Тогда при использовании nosalt обязательно нужно использовать:
-iv IV the actual IV to use: this must be represented as a string comprised only of hex digits. When only the key is specified using the -K option, the IV must explicitly be defined. When a password is being specified using one of the other options, the IV is generated from this password.


Иначе разные открытые тексты, зашифрованные тем же паролем будут иметь одинаковые векторы инициализации (если вообще будут иметь что-то отличное от нулевой строки).

В mcrypt опция bare по крайней мере что-то гарантирует хотя бы со слов документации. И всё равно, нужно разбираться, прежде чем например это куда-то встраивать, а в openssl такое использование штатно не предусмотрено.

openssl — это в первую очередь утилита-надстройка над соответствующей библиотекой реализации протокола ssl соответственно.
— Гость (17/05/2010 02:05)   <#>
В самом деле, у openssl с -nosalt IV генерится как однозначная ф-я ключа, но там не 0, но что-то типа PBKDF. Я, правда, не понимаю чем это страшно. У mcrypt IV генерится случайно и хранится в пакете. Понятно, что
  1. при IV=0 CBC становится ECB и это плохо,
  2. если у шифртекстов равны IV и пароли, и они имеют общие куски, то эти куски можно установить.
Можно ли еще что-то извлечь из этого?
— Гость (17/05/2010 02:16)   <#>
Вообще, если не нравится, можно использовать openssl с солью и отпиливать magic (первые 8 байт), а перед использованием запиливать обратно. Другое дело, что почему-то ни mcrypt, ни openssl не использует честную PBKDF2.
— unknown (17/05/2010 09:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Проектируемая схема всегда должна быть по-возможности идеальной. Использование даже не то что постоянного и неповторяемого, а хотя бы предсказуемого IV (например по счётчику) делает схему формально уязвимой к атакам с подобранным и адаптивно-подобранным шифртекстом.
— Гость (28/05/2010 23:51)   <#>
Вообще, если не нравится, можно использовать openssl с солью и отпиливать magic (первые 8 байт), а перед использованием запиливать обратно
Вот рабочий пример:

In Summery the "openssl" command is deficient:
  • You can't create a encrypted file that included an ic
  • You can't even specify the ic for the encryption (it just 1)
  • You can't pass Key and IV other than as command line arguments! (making them visible in process listings!)
  • You can't even use the "openssl" command to just do the basic conversions of pass-phrase + salt + count --TO-> key + IV perhaps with options for base64 or base16 (hexadecimal) output. For either PBKDF 1.5 using EVP_BytesToKey() or for PBKDF 2 using PKCS5_PBKDF2_HMAC_SHA1()
At the end of the day, OpenSSL is a library, not an end-user product, and enc(1) and friends are developer utilities and "demo" tools. When you need a product, you build something useful with the library. Yes, enc(1) should be better, but it is likely not a priority relative to improving the library.
© вот так оправдываются разработчики OpenSSL (из рассылки): вопрос, ответ. P.S.: Cамо pbkdf2 есть в OpenSSL, но на cli-тулзы они подзабили.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3