Как тиражировать пример хэша sha256 из документации CyberSource REST API?

Question

Я исследую API-интерфейс CyberSource REST и хочу проверить метод аутентификации веб-токена JSON, как описано здесь: https://developer.cybersource.com/api/developer-guides/dita-gettingstarted/authentication/GenerateHeader/jwtTokenAuthentication.html

Я не могу скопировать хэш sha256 полезной нагрузки JSON, описанной в разделе «Полезная нагрузка JWT / набор заявок».

{
  "clientReferenceInformation" : {
    "code" : "TC50171_3"
  },
  "orderInformation" : {
    "amountDetails" : {
      "totalAmount" : "102.21",
      "currency" : "USD"
    }
  }
}

Я пытался использовать команду sha256sum в двоичном и текстовом формате для файла, содержащего пример полезной нагрузки. Я также пытался выполнить эту команду для различных перестановок полезных данных, например, без пробелов или новых строк.

Я ожидаю получить пример хэша

2b4fee10da8c5e1feaad32b014021e079fe4afcf06af223004af944011a7cb65c

но вместо этого получите

f710ef58876f83e36b80a83c8ec7da75c8c1640d77d598c470a3dd85ae1458d3 и другие разнородные хеши.

Что я делаю не так?

Answer 1

Поскольку предполагаемый «примерный» хеш содержит 33 шестнадцатеричных символа, можно увидеть, что это не является допустимым допустимым выводом SHA256. Поэтому вы ничего не можете сделать, чтобы ваш пример соответствовал их примеру.

В этом обсуждении также есть пример base64, но он также недопустим для base64. Добавив дополнительный символ дополнения '=' к base64, его можно сделать допустимым, и расшифровка показывает, что он в основном соответствует предполагаемому хешу SHA256.

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

Answer 2

Возможно, вы не делаете ничего плохого. Хэш-функции имеют лавинный эффект , в котором любой другой бит на входе сильно меняет выходной хэш. Если исходный пример сайта использовал другую кодировку или имел другой порядок для элементов JSON, или даже имел больше или меньше вкладок, пробелов, разрывов строк или любых других «мусорных» символов, вам будет трудно найти подходящее сообщение для хеша, показанного на сайте.

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

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

Кроме того, я заметил, что спецификация JWT не определяет поле «Дайджест» для полезной нагрузки JWT. Таким образом, вам может даже не понадобиться использовать это поле. Если только CyberSource REST API не сделает его обязательным.