Многоликий ГОСТ Р 34.11-94



Готовил я как-то тесты для системы, один из модулей которой помимо всего остального вычислял значение хеш-функции для загружаемого файла. В ТЗ был прописан и необходимый алгоритм — ГОСТ Р 34.11-94. За эталон я взял значение хеша, посчитанного сторонней утилитой Rhash.

f86c9ecfb6e63726b35ebc79528d013d52b781e06e29d7eb0c9d1cb256efb7c1

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

964ba8755ca782ec3c5e0f98c93347f9b96d9f39cf5c7fdef43a23273fe8868a

Кто не прав — разработчик модуля или утилиты?

Оказалось, ни то, ни другое.

Дело в том, что ГОСТ Р 34.11-94 подразумевает использование параметров — так называемых узлов замены и стартового вектора хеширования. Но не регламентирует конкретные значения. Тем не менее в приложении к ГОСТ есть примеры данных значений и рекомендация:
использовать только в проверочных примерах для настоящего стандарта.

После изучения предметной области выяснилось, что существует два RFC. RFC 4357, в котором используются параметры, созданные «КриптоПро», и RFC 5831 с теми самыми значениями из ГОСТ. Rhash по умолчанию считает хеш по RFC 5831. Использование параметров «КриптоПро» необходимо явно указывать:

rhash --gost-cryptopro <Имя файла>

Казалось бы, проблема решена. Но, чтобы было еще интереснее, стандарт не определяет формат вывода хеша. А поэтому возникает вопрос с порядком байтов.



Для непосвященных — существует два основных способа представления данных. От старшего байта к младшему (Big-endian), и наоборот (Little-endian).

Рассмотрим пример. Для наглядности выделены байты.

Big-endian последовательность байт:

rhash --gost-cryptopro --gost-reverse <Имя файла>
8a86e83f27233af4de7f5ccf399f6db9f94733c9980f5e3cec82a75c75a84b96


Little-endian порядок:

rhash --gost-cryptopro <Имя файла>
964ba8755ca782ec3c5e0f98c93347f9b96d9f39cf5c7fdef43a23273fe8868a


Таким образом, противоречия нет — все вышеперечисленные значения, а также

rhash --gost --gost-reverse <Имя файла>
c1b7ef56b21c9d0cebd7296ee081b7523d018d5279bc5eb32637e6b6cf9e6cf8


соответствуют ГОСТ Р 34.11-94.

Ссылки:
Википедия
Подробное описание

Комментарии 10

    +13
    Тот факт, что хэш получается задом наперед не так страшен… А вот то, что нет единого устоявшегося стандарта и разные средства для одинаковых данных дают разные результаты — вот это беда...
      +1
      Это вы еще с подписью не работали. Возьмите библиотеку Bouncycastle и сравните с КриптоПро (спойлер — подпись делим пополам и каждую часть переворачиваем).
        0
        А ничего, что указанный ГОСТ «снят с производства»?
          0
          Аргументируйте, пожалуйста, свой комментарий.
            0
            Заменен на ГОСТ Р 34.11-2012, названный в честь Стрибога, славянского аналога Кукулькана.
              0
              ГОСТ Р 34.11-94 — устаревший российский криптографический стандарт вычисления хеш-функции. Дата отмены: 1 января 2013 года.
                0
                Во-первых, цитата из стандарта "«Криптографическая защита информации» (TK 26)"
                "Вместе с тем следует отметить, что отмена национального стандарта в области криптографической защиты информации не является основанием для приостановления или аннулирования действия сертификата СКЗИ, реализующего алгоритмы, определяемые данным стандартом (перечень таких оснований приведен в п. 10 «Положения о сертификации средств защиты информации», утвержденного постановлениемПравительства Российской Федерации от 26 июня 1995 г. № 608, с изменениями от 23 апреля 1996 г., 29 марта 1999 г., 17 декабря 2004 г., 21 апреля 2010 г., далее – Положение). Учитывая, что согласно п. 8 Положения срок действия сертификата СКЗИ не может превышать пяти лет, переход к использованию стандартов ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 в сертифицированных средствах защиты информации должен завершиться не позднее 31 декабря 2017 года."

                Во-вторых, криптопровайдер с поддержкой ГОСТ Р 34.11-2012 пока формально не сертифицирован.
                  +3
                  Ваш комментарий, как и приведенная цитата, ни коим образом не противоречит моему комментарию. Старые крипто-алгоритмы продолжат действовать до срока истечения действия сертификата на СКЗИ, НО… в перспективных разработках их применение запрещено (разрешено только для совместимости со «старым парком технических средств»). Просто я на своем опыте прочувствовал это — я принимал непосредственное участие в разработке УЦ и программно-аппаратного СКЗИ (ТЗ было подписано и согласовано с ФСБ еще до публикации новых алгоритмов) и на этапе сертификации (уже после публикации и ввода новых алгоритмов) ФСБ направила нам замечания с требованиями перейти на новые крипто-алгоритмы. И доработки уже приходилось делать «за свой счет»… УЦ так и пришлось «похоронить»…
                    0
                    Спасибо за пояснения. Но, как Вы сами заметили, обратную совместимость никто не отменял. УЦ, конечно, жаль(
                0
                Мой комментарий уже аргументировали коллеги, благодарю их за это. Еще хочется отметить, что заменены на новые так же: ГОСТ Р 34.10-2001 (заменен на ГОСТ Р 34.10-2012) и ГОСТ 28147-89 (заменен на ГОСТ Р 34.12-2015).

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

            Самое читаемое