Мы про парсинг данных, в сертификате.
А хешей можно всяких написать.

В общем да, вопрос этим и исчерпывается. Детали что ASN1 представления длины могут быть разные в зависимости DER BER или еще что несущественны, если делать через библиотечную функцию умеющую их все читать.
Согласен полностью.Ну так, как бы помягче сказать, этому разве место на Форуме КриптоПро? Это раз. Конечно все по-разному к КриптоПро относятся, но по факту это стандарт, который используют большинство отечественных организаций. Аналогично с параметрами гост - их можно задать разные, но фактически почти везде используют предложенные КриптоПро - так больше шанс, что подпись проверится другими криптопровайдерами.

Есть исходники на Си от Майкрософт с базовым кодом криптопровайдера, на их основе может любой Анонимус написать любой криптопровайдер как захочет и сформировать хэш для идентификатора ключа как захочет, это два. Поэтому наверно надо ограничить круг официальными (сертифицированными в случае отечественных) криптопровайдерами. Желательно бы пруф по этому поводу из нормативки ТК26, раз речь про гост.Да, это естественно. Или отбраковать все подписи не подходящие под некие параметры установленные в неком своем нормативном акте. Сейчас большинство ГИС так делают опубликуют критерии и все неподходящее бракуют.

Отредактировано пользователем 31 августа 2020 г. 13:46:52(UTC)  | Причина: Не указана

А встречали вариант от rawdata5?

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



Нормативки по софту имеют смысл только при использовании сертифицированного ПО для создания сертификатов - это раз.

Процесс создания запроса на сертификат и сертификата по запросу не имеет ничего общего с упомянутыми исходниками Microsoft.
минимальные обязанности CSP - экспорт низкоуровневых функкций криптографии. Отдельной функции на формирование хеша ключа там нет. Если не верите - можно взять отладчик и посмотреть, в каких случаях получает управление код КриптоПро и когда - Microsoft в CryptoAPI. Это два.

В имеющихся в наличии документах TK26 (и выросших из них рекомендаций по стандартизации) есть ссылки на RFC5280 в плане базовых структур X.509. Мне это достаточно. Если хотите доказать, что я не прав, то пруфы нужны уже от Вас. Это три :)

Отредактировано пользователем 31 августа 2020 г. 22:06:41(UTC)  | Причина: Не указана

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

Ну так а смысл пытаться обнять необъятное и учитывать все несертифицированное ПО, сделанное на коленке.
Нисколько не спорю, что в случае КриптоПро велосипед не изобретали и отдали проверку коду Майкрософт, который реализует функционал высокого уровня из базовых низкоуровневых функций. Это отнюдь не значит что высокоуровневые функции не могут быть переопределены криптопровайдером. В CryptoAPI очень много функций, которые можно перегрузить или, как с сожалением приходится признать, "пропатчить" (так как Майкрософт не дает возможность их поменять без патча и даже те самые исходники без патча не заводятся). Поэтому "левый" криптопровайдер может "заодно" пропатчить и код связанный с сертификатами. Что ему помешает?

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

Далее, примем с Ваших же слов, при работе с сертификатом выполняется код Microsoft и тогда вопрос - где в нем вариативность вычисления идентификатора ключа? Про то что теоретически возможно и допускается rfc я не спорю. Но, какая выгода, кроме желания Майкрософт продать очередную версию операционки под лозунгами безопасности? Именно лозунгами, потому что по факту безопасности от перехода с sha1 на sha256 прибавляется очень мало. Да, времени на вскрытие шифра потребуется меньше, но если задаться целью за 30 лет все равно можно расшифровать почти любую переписку. Если Вашу переписку зашифрованную записали, то все - прочитать вопрос времени. С другой стороны, даже самые слабые шифры продержаться пару часов и именно такая пара часов имеет критическое значение (на финансовых рынках, при расследованиях и т.д.). Толка от смены хеша в идентификаторе ключа вообще нет, но маркетинг такой маркетинг. Как рядовому пользователю поможет использование трех представлений одно и того же значения хэша на одном скриншоте Десятки, приведенном Вами?
В принципе, я тоже уверен в правоте, значит еще один случай когда не читая зарубежного формата, не делая попыток прояснить его относительно гост, отечественная нормативка ссылается на rfc.

Отредактировано пользователем 1 сентября 2020 г. 14:02:16(UTC)  | Причина: Не указана