Из ECMA-335:
Эта декларация используется для хранения младших 8 байтов хэша SHA-1 отправителя.
открытый ключ в ссылке на сборку, а не полный открытый ключ.
Ссылка на сборку может хранить либо полный открытый ключ, либо 8-байтовый «токен открытого ключа». Любой из них может использоваться для
проверить, что тот же закрытый ключ, который использовался для подписи сборки во время компиляции, также подписывал сборку, используемую в
во время выполнения. Ни то, ни другое не обязательно должно присутствовать, и хотя оба они могут быть сохранены, это бесполезно.
[Обоснование: открытый ключ или маркер открытого ключа, сохраненные в ссылке на сборку, используются для обеспечения того, чтобы
сборка, на которую ссылаются, и сборка, фактически используемая во время выполнения, была произведена сущностью во владении
одного и того же закрытого ключа, и поэтому можно предположить, что он предназначен для той же цели. В то время как
Полный открытый ключ криптографически безопаснее, он требует больше места для хранения в ссылке. Использование открытого ключа
Токен уменьшает пространство, необходимое для хранения ссылки, лишь слегка ослабляя процесс проверки.
окончание]
Что касается того, как вычисляется хеш (я предполагаю, что это может быть то, что вы спрашиваете, поскольку токен открытого ключа не "вычислен"), из той же спецификации:
Метаданные CLI позволяют производителю сборки вычислять криптографический хеш этой сборки (используя
хэш-функция SHA-1), а затем шифровать ее с помощью алгоритма RSA (см. раздел I) и публичного / частного
ключевая пара по выбору производителя. Результаты этого («цифровая подпись SHA-1 / RSA») могут быть сохранены
в метаданных (§25.3.3) вместе с открытой частью пары ключей, требуемой алгоритмом RSA.
Директива .publickey используется для указания открытого ключа, который использовался для вычисления подписи. Вычислять
хеш, подпись обнуляется, хеш вычисляется, а затем результат сохраняется в подписи.
Процесс подписания строгого имени (SN) использует стандартные алгоритмы хеширования и шифрования для подписи строгого имени.
SHA-1 хэш для большей части файла PE генерируется. Это хеш-значение подписано RSA с помощью закрытого ключа SN. За
В целях проверки открытый ключ хранится в PE-файле, а также подписанное хеш-значение.
За исключением следующего, все части PE-файла хэшируются:
• Подпись Authenticode: PE-файлы могут быть подписаны с помощью authenticode. Аутентикод
подпись содержится в 8-байтовой записи со смещением 128 в каталоге данных заголовка PE
(«Таблица сертификатов» в §25.2.3.3) и содержимое PE-файла в диапазоне, определенном этим
запись в каталоге. [Примечание: в соответствующем PE-файле эта запись должна быть нулевой. конечная нота]
• Blob Strong Name: 8-байтовая запись со смещением 32 заголовка CLI («StrongNameSignature»)
в §25.3.3) и содержимое хеш-данных, содержащихся в этом RVA в файле PE. Если 8-байт
запись 0, нет связанной строгой подписи.
• Контрольная сумма заголовка PE: 4-байтовая запись со смещением 64 заголовка PE для Windows NT-Specific
Поля («Контрольная сумма файла» в §25.2.3.2). [Примечание: в соответствующем PE-файле эта запись должна быть нулевой.
конечная нота]
Вы можете скачать спецификацию здесь бесплатно: http://www.ecma -international.org / публикации / стандарты / Ecma-335.htm