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

А у кого вы брали S-блоки, они ведь в стандарте не опубликованы, а откуда тогда тестовые векторы официально взять?

нет, мне необходимо проверить правильность реализации, официальные тестовые векторы не нужны.

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

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

естессно, приложите и откытый текст с ключом – а то какой-нибудь умник закинет только шифртекст :)

Вы уверены, что в "любой сертифицированной реализации" будут именно цэбэшные векторы из книги Шнайера?

dd if=/dev/zero bs=1c count=64 | mcrypt --keymode hex --key \ 00000000000000000000000000000001 --algorithm gost --mode ecb --bare \ --force --flush | xxd

0000000: bc80 ded9 c9f8 f0d9 4110 92de 7dda 3780 ........A...}.7. 0000010: 4110 92de 7dda 3780 4110 92de 7dda 3780 A...}.7.A...}.7. 0000020: 4110 92de 7dda 3780 4110 92de 7dda 3780 A...}.7.A...}.7. 0000030: 4110 92de 7dda 3780 4110 92de 7dda 3780 A...}.7.A...}.7. 0000040: 4110 92de 7dda 3780 dc67 5fae bb2d 4abd A...}.7..g_..-J.

dd if=/dev/zero bs=1c count=64 | mcrypt --keymode hex --key \ 00000000000000000000000000000002 --algorithm gost --mode ecb --bare \ --force --flush | xxd

0000000: 2335 ff30 2df3 62f7 a1b4 81db 2863 4283 #5.0-.b.....(cB. 0000010: a1b4 81db 2863 4283 a1b4 81db 2863 4283 ....(cB.....(cB. 0000020: a1b4 81db 2863 4283 a1b4 81db 2863 4283 ....(cB.....(cB. 0000030: a1b4 81db 2863 4283 a1b4 81db 2863 4283 ....(cB.....(cB. 0000040: a1b4 81db 2863 4283 82de 605d 4df5 15af ....(cB...`]M..

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

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

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

dd if=/dev/zero bs=1c count=64 | mcrypt --keymode hex --key \ 00000000000000000000000000000001 --algorithm gost --mode cbc --bare\ --force --flush | xxd 0000000: 020c 4896 44bf ece4 036f 5871 430e c2ad ..H.D....oXqC... 0000010: d1d7 d6f1 0068 3599 89f7 55eb 54ce ee01 .....h5...U.T... 0000020: 1827 caac 640b 77ee d116 0138 9101 5cb9 .'..d.w....8..\. 0000030: 9d70 345b e94b 1fba a706 11dc 4c12 b9c3 .p4[.K......L... 0000040: daf9 3f67 26c8 7941 b87d d4a6 63ae 0b9e ..?g&.yA.}..c...

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

0000000: 1d78 0c9b 7704 5edd 6d5e fa9e 3d7c 83c2 .x..w.^.m^..=|.. 0000010: 75fa 6bbb 048c 04a1 786a ec81 bfdd 484b u.k.....xj....HK 0000020: 8d58 9c78 b279 1c35 4211 8a12 eac7 3165 .X.x.y.5B.....1e 0000030: bb7f df9b 3d93 efe4 6b6d 8a7f dcf6 b128 ....=...km.....( 0000040: 3774 cc66 560c 4c6c a74d 78b3 19af 449f 7t.fV.Ll.Mx...D.

Кстати размер ключа у ГОСТ вообще-то 256-бит, а программа в режиме задания ключа hex съедает сколько угодно шестнадцатиричных знаков, но после 32 байт их не различает так что ключи скорее всего дполняются до:

0x00..01..00 и 0x00..02..00 (256 бит)

имитовставка-это последовательность из L бит, где L – от 1 до 32.

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

кстати, какая таблица замен? Без нее проблематично все сделать. или мне подбирать 512 бит? ))
не имеет значения какая ТЗ – главное, чтобы была указаны узлы замен.

Посмотрите в исходниках. Скорее всего S-блоки (таблицы замен) из Большой Красной Книги Шнайера.

В контексте комментариев /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.

unknown, в вышеприведённом комментарии негласно подразумевалось, что Вы скажете что-нибудь по этому поводу :)

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 соответственно.

В самом деле, у openssl с -nosalt IV генерится как однозначная ф-я ключа, но там не 0, но что-то типа PBKDF. Я, правда, не понимаю чем это страшно. У mcrypt IV генерится случайно и хранится в пакете. Понятно, что

1. при IV=0 CBC становится ECB и это плохо,
2. если у шифртекстов равны IV и пароли, и они имеют общие куски, то эти куски можно установить.

Можно ли еще что-то извлечь из этого?

Вообще, если не нравится, можно использовать openssl с солью и отпиливать magic (первые 8 байт), а перед использованием запиливать обратно. Другое дело, что почему-то ни mcrypt, ни openssl не использует честную PBKDF2.

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

Вообще, если не нравится, можно использовать openssl с солью и отпиливать magic (первые 8 байт), а перед использованием запиливать обратно

Вот рабочий пример:$ cat tfile йожыки $ (dd if=/dev/random bs=8 count=1 && openssl enc -aes-256-cbc -salt -in tfile | tail -c +9) > tfile.out 1+0 записей считано 1+0 записей написано скопировано 8 байт (8 B), 2e-05 c, 400 kB/c enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: $ hexdump -Cv tfile.out 00000000 9a 5b f9 76 fa 8d 0d 74 38 df 04 56 7f 09 e4 dc | [ЫvЗ~M.t8ъ.V..Дэ| 00000010 0c 22 21 e1 80 c7 c8 bd 5c d9 ac 72 76 b1 8c 68 |."!А~@гх╫\ы╛rv╠~Lh| 00000020 $ (echo -n 'Salted__' && tail -c +9 tfile.out ) | openssl enc -d -aes-256-cbc -salt -out tfile.dec enter aes-256-cbc decryption password: $ cat tfile.dec йожыки

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-тулзы они подзабили.