Cryptoapi windows что это

From Wikipedia, the free encyclopedia

The Microsoft Windows platform specific Cryptographic Application Programming Interface (also known variously as CryptoAPI, Microsoft Cryptography API, MS-CAPI or simply CAPI) is an application programming interface included with Microsoft Windows operating systems that provides services to enable developers to secure Windows-based applications using cryptography. It is a set of dynamically linked libraries that provides an abstraction layer which isolates programmers from the code used to encrypt the data. The Crypto API was first introduced in Windows NT 4.0^[1] and enhanced in subsequent versions.

CryptoAPI supports both public-key and symmetric key cryptography, though persistent symmetric keys are not supported. It includes functionality for encrypting and decrypting data and for authentication using digital certificates. It also includes a cryptographically secure pseudorandom number generator function CryptGenRandom.

CryptoAPI works with a number of CSPs (Cryptographic Service Providers) installed on the machine. CSPs are the modules that do the actual work of encoding and decoding data by performing the cryptographic functions. Vendors of HSMs may supply a CSP which works with their hardware.

Windows Vista features an update to the Crypto API known as Cryptography API: Next Generation (CNG). It has better API factoring to allow the same functions to work using a wide range of cryptographic algorithms, and includes a number of newer algorithms that are part of the National Security Agency (NSA) Suite B.^[2] It is also flexible, featuring support for plugging custom cryptographic APIs into the CNG runtime. However, CNG Key Storage Providers still do not support symmetric keys.^[3] CNG works in both user and kernel mode, and also supports all of the algorithms from the CryptoAPI. The Microsoft provider that implements CNG is housed in Bcrypt.dll.

CNG also supports elliptic curve cryptography which, because it uses shorter keys for the same expected level of security, is more efficient than RSA.^[4] The CNG API integrates with the smart card subsystem by including a Base Smart Card Cryptographic Service Provider (Base CSP) module which encapsulates the smart card API. Smart card manufacturers just have to make their devices compatible with this, rather than provide a from-scratch solution.

CNG also adds support for Dual_EC_DRBG,^[5] a pseudorandom number generator defined in NIST SP 800-90A that could expose the user to eavesdropping by the National Security Agency since it contains a kleptographic backdoor, unless the developer remembers to generate new base points with a different cryptographically secure pseudorandom number generator or a true random number generator and then publish the generated seed in order to remove the NSA backdoor. It is also very slow.^[6] It is only used when called for explicitly.

CNG also replaces the default PRNG with CTR_DRBG using AES as the block cipher, because the earlier RNG which is defined in the now superseded FIPS 186-2 is based on either DES or SHA-1, both which have been broken.^[7] CTR_DRBG is one of the two algorithms in NIST SP 800-90 endorsed by Schneier, the other being Hash_DRBG.^[6]

• CAPICOM
• DPAPI
• Encrypting File System
• Public-key cryptography
• Cryptographic Service Provider
• PKCS#11
• Crypto API (Linux)

• Cryptography Reference on MSDN
• Microsoft CAPI at CryptoDox

CryptoAPI (Cryptographic Application Programming Interface) is a legacy cryptographic framework provided by Microsoft for applications running on Windows operating systems. It serves as a set of functions and services that allow developers to incorporate cryptographic features, such as encryption, decryption, digital signatures, and certificate management, into their software applications.

In this article:

1. CryptoAPI in Windows
2. Transition-to-Cryptography-Next-Generation
3. Further Reading

CryptoAPI was widely used in earlier versions of Windows but has been largely replaced by the more modern Cryptography Next Generation (CNG) framework in recent Windows versions. It provided essential cryptographic functionality to secure data and communications within Windows applications, making it a crucial component for developers working on security-related tasks.

Картинка с сайта: networkencyclopedia.com

1. CryptoAPI in Windows

CryptoAPI, also known as Cryptographic API, was introduced by Microsoft in the early versions of Windows. It served as a programming interface that allowed developers to integrate cryptographic functions and services into their applications. CryptoAPI provided a set of functions and Win32 libraries to perform various cryptographic operations, including encryption, decryption, digital signatures, and certificate management. This allowed developers to build secure applications that could protect sensitive data and communications.

CryptoAPI was present in several versions of Windows, including Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows 7, and Windows 8. It played a significant role in enabling cryptographic security features for a wide range of applications on these platforms.

2. Transition to Cryptography Next Generation (CNG)

Windows Vista features an update to the Crypto API known as Cryptography API: Next Generation (CNG). It has better API factoring to allow the same functions to work using a wide range of cryptographic algorithms and includes a number of newer algorithms that are part of the National Security Agency (NSA) Suite B. It is also flexible, featuring support for plugging custom cryptographic APIs into the CNG runtime. However, CNG Key Storage Providers still do not support symmetric keys. CNG works in both user and kernel mode, and also supports all of the algorithms from the CryptoAPI. The Microsoft provider that implements CNG is housed in Bcrypt.dll.

The transition to CNG marked a significant evolution in Windows cryptography. Here are key points to explain this transition:

1. Enhanced Security: CNG was designed to provide enhanced security features, support for modern cryptographic algorithms, and improved protection against emerging threats. It addressed the limitations of CryptoAPI, making it more suitable for today’s security requirements.
2. Flexibility and Extensibility: CNG offered a more flexible and extensible architecture, allowing developers to work with a broader range of cryptographic algorithms and services. This flexibility enabled better customization and adaptation to specific security needs.
3. Backward Compatibility: While CNG became the recommended cryptographic framework, Microsoft ensured backward compatibility. Existing applications using CryptoAPI could still function, but developers were encouraged to migrate to CNG for improved security and features.
4. Transition Period: During the transition, developers were provided with resources and documentation to help them adapt their applications to CNG. Microsoft also encouraged the use of best practices in cryptography to enhance security.
5. Ongoing Support: Microsoft continued to support CryptoAPI for a period to ensure a smooth transition for developers and users. However, new features and improvements were primarily focused on CNG.

In summary, CryptoAPI served as a foundational cryptographic framework in earlier versions of Windows but was gradually replaced by Cryptography Next Generation (CNG) in Windows Vista and later. The transition aimed to provide better security, flexibility, and modernization of cryptographic capabilities in Windows, ensuring that applications could adapt to evolving security challenges.

3. Further Reading

See also (Network Encyclopedia):

• Hashing Algorithm
• Cryptography
• Public-key Cryptography

External References:

• CryptoAPI System Architecture

На хабре довольно мало информации о Microsoft CryptoApi и нет упоминания о наших отечественных разработчиках, которые имеют лицензии в области шифрования информации, реализуют интерфейс CryptoApi и позволяют шифровать данные с использованием, например, ГОСТ 28147-89. Так что, если возникла необходимость зашифровать и передать данные, и сделать это с использованием отечественных стандартов, то вовсе необязательно изобретать велосипед, а можно воспользоваться криптопровайдером VipNet CSP.

Вкратце о Microsoft CryptoApi

Итак, CryptoAPI это — интерфейс программирования приложений, который обеспечивает разработчиков Windows-приложений стандартным набором функций для работы с криптопровайдером. Входит в состав операционных систем Microsoft. Большинство функций CryptoAPI поддерживается начиная с Windows 2000.
CryptoAPI поддерживает работу с асимметричными и симметричными ключами, то есть позволяет шифровать и расшифровывать данные, а также работать с электронными сертификатами. Набор поддерживаемых криптографических алгоритмов зависит от конкретного криптопровайдера.
Реализация всех алгоритмов (шифрования, цифровой подписи и т.п.) полностью выведена из состава самого Crypto API и реализуется в отдельных, независимых динамических библиотеках – «криптопровайдерах» (Cryptographic Service Provider – CSP). Сам же Crypto API просто предъявляет определенные требования к набору функций (интерфейсу) криптопровайдера и предоставляет конечному пользователю интерфейс работы с CSP. Для использования всех функций криптопровайдера достаточно знать его строковое имя и номер типа.

ViPNet CSP

VipNet CSP – это программный комплекс, который реализует интерфейс Microsoft CryptoApi.

ViPNet CSP обеспечивает выполнение следующих функций:

• Генерация закрытых и открытых ключей ЭЦП и шифрования в соответствии с алгоритмом ГОСТ Р 34.10 – 2001.
• Вычисление хеш-функции в соответствии с алгоритмом ГОСТ Р 34.11-94.
• Вычисление и проверка ЭЦП в соответствии с алгоритмом ГОСТ Р 34.10-2001.
• Выработка случайных и псевдослучайных чисел, сессионных ключей шифрования.
• Шифрование и имитозащита данных в соответствии с алгоритмом ГОСТ 28147-89.
• Аутентификация и шифрование при передаче данных по протоколам SSL/TLS.
• Операции с сертификатами открытых ключей, соответствующих стандарту X.509 v3.

Совместимость

ViPNet CSP функционирует под управлением ОС Windows 2000 (32 бит)/XP (32 бит)/Server 2003 (32 бит)/Vista (32 бит) /Windows 7 (32/64 бит).

К сожалению VipNet CSP – это платный продукт, но на сайте есть бета-версии, которые отлично функционируют.

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

Пример использования

Итак, мы инсталлировали криптопровайдер, можем написать программу, шифрующую данные с использованием ГОСТ 28147-89. В скачиваемом пакете (архиве) есть папка «ViPNet CSP SDK (для разработчиков)», найдем там заголовочный файл importitccsp.h, в нем объявлены необходимые нам константы. Смотрим пример:

HCRYPTPROV hProv;
HCRYPTKEY hSessionKey;

// Получение контекста криптопровайдера
// VPN_DEF_PROV и VPN_PROV_TYPE - указывают на то, что мы используем ViPNet CSP
if (!CryptAcquireContext(&hProv, NULL, VPN_DEF_PROV, VPN_PROV_TYPE, CRYPT_VERIFYCONTEXT))
{
printf("Error CryptAcquireContext");
return;
}

printf("provider initialized");

// Генерация сессионного ключа
// CPCSP_ENCRYPT_ID - используется ГОСТ 28147-89
if (!CryptGenKey(hProv, CPCSP_ENCRYPT_ID, CRYPT_ENCRYPT | CRYPT_DECRYPT, &hSessionKey))
{
printf("Error CryptGenKey");
return;
}

printf("key generated");

// Данные для шифрования
char data[]="habrahabr";
DWORD count=strlen(data);

// Шифрование данных
if (!CryptEncrypt(hSessionKey, 0, true, 0, (BYTE*)data,
&count, strlen(data)))
{
printf("Error CryptEncrypt");
return;
}

printf("encrypt done");

// Тестовый вывод на экран
printf("Encrypted string: %s", data);

// Расшифровывание данных
if(!CryptDecrypt(hSessionKey, 0, true, 0, (BYTE*)data, &count))
{
printf("Error CryptDecrypt");
return;
}

printf("decrypt done");

// Тестовый вывод на экран
printf("Decrypted string: %s", data);

// Освобождение контекста локальных переменных
CryptDestroyKey(hSessionKey);
CryptReleaseContext(hProv, 0);

Шифрование данных и расшифрование их на другом компьютере — тема отдельной статьи.
Спасибо за внимание.

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

Интерфейс CryptoAPI

В сфере защиты компьютерной информации криптография применяется в основном для: шифрования и дешифровки данных; а также создания и проверки цифровых подписей. (Прим. автора: в русскоязычной литературе применяется термин «ЭЦП» — электронно-цифровая подпись. В этой статье для краткости используется термин «цифровая подпись».)

Шифрование данных позволяет ограничить доступ к конфиденциальной информации, сделать ее нечитаемой и непонятной для посторонних. Применение цифровых подписей оставляет данные открытыми, но дает возможность верифицировать отправителя и проверять целостность полученных данных.

Для защиты информации специалистами Microsoft был разработан интерфейс CryptoAPI, который позволяет создавать приложения, использующие криптографические методы.

Структура CryptoAPI

В Crypto API существует понятие «криптопровайдер» (Cryptography Service Provider, CSP). Криптопровайдер — это независимый модуль, содержащий библиотеку криптографических функций со стандартизованным интерфейсом. Криптопровайдер отвечает за реализацию функций интерфейса, а также играет роль хранилища для ключей всех типов. Подобная архитектура позволяет переходить от одного провайдера к другому с минимальными изменениями исходного кода, так как интерфейс (т. е. сами функции) не меняется.

В операционную систему Windows включен криптопровайдер Microsoft RSA Base Provider.

Криптографические ключи

В CryptoAPI существуют ключи двух типов:

• сессионные ключи (session keys
• пары открытый/закрытый ключ (public/private key pairs).

Сессионные ключи. Это симметричные ключи, так как один и тот же ключ применяется и для шифрования, и для расшифровки. Сессионные ключи меняются. Алгоритмы, использующие сессионные ключи (так называемые симметричные алгоритмы), — RC2, RC4, DES. Microsoft RSA Base Provider работает с 40-разрядными сессионными ключами.

Пары ключей используются в так называемых асимметричных алгоритмах шифрования. Если шифрование выполнялось одним ключом из пары, то дешифровка производится другим. Открытые (public) ключи могут передаваться другим лицам для проверки цифровых подписей и шифрования пересылаемых данных. Длина открытого ключа в Microsoft RSA Base Provider составляет 512 разрядов.

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

Хранение ключей

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

В CryptoAPI ключи для шифрования/дешифровки и создания/проверки подписей разделены. Называются они соответственно «пара для обмена ключами» и «пара для подписи».

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

По умолчанию для каждого пользователя создается контейнер с именем этого пользователя. Можно создавать дополнительные контейнеры и назначать им произвольные имена, которые обязательно должны быть уникальными (см. Рисунок 1).

Картинка с сайта: www.osp.ru

Рисунок 1. База данных криптографических ключей.

Работа с CryptoAPI

Ниже приводятся примеры работы с некоторыми функциями CryptoAPI. Все примеры написаны на языке С++ в среде MS Visual C++ 6.0. Приведены прототипы наиболее интересных функций с пояснениями. Чтобы не перегружать читателя деталями, обработка ошибок в листинги не включена.

Названия функций CryptoAPI имеют префикс Crypt. Как правило, все они возвращают результат типа BOOL — TRUE при успешном завершении и FALSE, если произошла ошибка. В последнем случае для получения сведений об ошибке необходимо вызвать GetLastError().

Прототипы функций описаны в файле wincrypt.h. Для использования этих функций в свойствах проекта нужно определить константу _WIN32_WINNT и задать ей значение 0x0400 (или больше). Данная константа применяется в файле wincrypt.h для проверки версии Windows.

Для некоторых функций CryptAPI также требуются библиотеки crypt32.lib и advapi32.lib.

Криптопровайдер

Прежде чем использовать какие-либо функции Crypto API, необходимо запустить криптопровайдер. Делается это с помощью функции CryptAc-quireContext:

BOOL CRYPTFUNC CryptAcquireContext(
HCRYPTPROV*	hCryptProvider,//дескриптор
 провайдера, out-параметр
LPCTSTR	pszContainer, 		// имя
 контейнера ключей
LPCTSTR	pszProvider,		// имя
 провайдера
DWORD	dwProvType,		// тип
 провайдера
DWORD	dwFlags		// флаги
)

Кроме инициализации криптопровайдера данную функцию можно использовать для создания и удаления контейнеров ключей. Для этого параметру dwFlags присваивается значение, соответственно, CRYPT_NEW-KEYSET и CRYPT_DELETEKEYSET.

Функция CryptAcquireContext работает в два этапа: сначала она ищет криптопровайдер по имени и типу, указанному в аргументах, а затем контейнер ключей с заданным именем.

По окончании работы с криптопровайдером необходимо вызвать функцию CryptReleaseContext (см. Листинг 1).

Работа с ключами

Генерация ключей. В CryptoAPI имеются функции для генерации ключей любого типа. Функция CryptGenKey генерирует сессионные ключи и пары для обмена и подписи на основе случайного числа.

BOOL CRYPTFUNC CryptGenKey(
HCRYPTPROV	hProv
ALG_IG		Algid
DWORD		dwFlags
HCRYPTKEY*	phKey
)

Сессионные ключи можно сгенерировать также на основе некоторого заданного значения (пароля) при помощи функции CryptDeriveKey. Это стоит делать, например, в том случае, когда нужно избежать пересылки сессионного ключа вместе с зашифрованными данными (см. Рисунок 2). Получатель данных, зная пароль и алгоритм, может сам сгенерировать сессионный ключ и с его помощью расшифровать данные (см. Листинг 2).

Картинка с сайта: www.osp.ru

Рисунок 2. Шифрование.

Получение дескриптора ключа. Дескриптор открытого ключа можно получить, вызвав функцию CryptGet-UserKey.

Экспорт ключей. Операция экспорта выполняется при сохранении сессионных ключей и при передаче ключей третьим лицам.

Двоичные данные ключа могут быть получены при помощи функции CryptExportKey:

BOOL CRYPTFUNC CryptExportKey (
HCRYPTKEY	hKeyToExport
HCRYPTKEY	hCryptKey
DWORD		dwBlobType
DWORD		dwFlags
BYTE*		pbData, // указатель на буфер
DWORD* pdwDataLen )  // длина буфера

Поясним значения аргументов. Первый аргумент — дескриптор экспортируемого ключа. Второй аргумент — дескриптор ключа, которым шифруется экспортируемый ключ.

Открытые ключи экспортируются в незашифрованном виде. В этом случае hCryptKey = 0.

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

При вызове с аргументом pbData = NULL функция вернет необходимую длину буфера по адресу, на который указывает аргумент pdwDataLen (см. Листинг 3).

После успешного завершения переменная dwSessionKeyLen будет содержать действительную длину BLOB-структуры ключа. Это значение необходимо сохранить для обратной операции — импорта ключа в криптопровайдер.

Импорт ключей. Ключи импортируются функцией CryptImportKey:

CryptImportKey (   HCRYPTPROV hProv
BYTE*		pbData
DWORD		dwDataLen
HCRYPTKEY	hCryptKey
DWORD		dwFlags
HCRYPTKEY*	phImportedKey  )

hCryptKey = 0 в том случае, если импортируемый ключ был зашифрован асимметричным ключом или не был зашифрован вообще.

Если импортируемый ключ шифровали сессионным ключом, то hCryptKey должен содержать дескриптор этого ключа.

По окончании работы с ключом необходимо для его дескриптора вызвать функцию CryptDestroyKey(HCRYPTKEY hKey).

Шифрование и дешифровка данных

В CryptoAPI для шифрования и дешифровки используются и симметричный, и асимметричный алгоритмы.

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

Картинка с сайта: www.osp.ru

Рисунок 3. Дешифровка.

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

Для шифрования и дешифровки применяется функция (см. Листинг 4).

BOOL CRYPTFUNC CryptEncrypt (
HCRYPTKEY	hKey, // дескриптор ключа
	для шифрования
HCRYPTHASH	hHash
BOOL			bFinal
BYTE*		pbData, // параметр [in, out
DWORD* pdwDataLen, // параметр [in, out
DWORD		dwBufferLen )

Последний и предпоследний параметры являются одновременно входными и выходными. Это означает, что зашифрованные данные записываются поверх исходных в буфер pbData, а длина данных, соответственно, в dwBufferLen.

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

pbData   = NULL;
pdwDataLen = длина исходных данных.

Длину буфера функция вернет по адресу: pdwDataLen.

Дешифровка данных производится аналогично функцией CryptDecrypt.

Цифровые подписи

Цифровая подпись — это двоичные данные небольшого объема, обычно не более 256 байт. Цифровая подпись есть не что иное, как результат работы хеш-алгоритма над исходными данными, зашифрованный закрытым ключем отправителя. Проще говоря, берем исходные данные, получаем из них хеш и шифруем хеш своим закрытым ключом (с помощью асимметричного алгоритма).

Полученные в результате шифрования хеша двоичные данные и есть наша цифровая подпись (см. Рисунок 4).

Картинка с сайта: www.osp.ru

Рисунок 4. Создание цифровой подписи.

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

• получает хеш от данных (данные остались открытыми);
• расшифровывает нашу цифровую подпись при помощи нашего открытого ключа;
• сравнивает свой хеш и результат дешифровки. Если они эквивалентны, значит, данные были подписаны именно нами (ну, по крайней мере, нашим закрытым ключом, см. Рисунок 5).

Картинка с сайта: www.osp.ru

Рисунок 5. Проверка цифровой подписи.

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

Для работы с цифровыми подписями используются функции CryptCreate-Hash, CryptHashData, CryptSignHash, CryptVerifySignature, CryptDestroy-Hash.

Создание цифровой подписи. Процесс создания подписи состоит из следующих этапов:

• создание хеш-объекта функцией CryptCreateHash;
• наполнение хеш-объекта данными (CryptHashData);
• подписание хеша (CryptSignHash);
• разрушение хеш-объекта (Crypt-DestroyHash).

Аналогично функциям CryptEncrypt, проверка длины буфера для подписи производится вызовом функции CryptSignHash с нулем вместо указателя на данные. Как и у функции CryptEncrypt, указатели на данные и их длину являются параметрами типа [in, out] (см. Листинг 5).

Проверка цифровой подписи. Проверка подписи (см. Листинг 6) выполняется так:

• создается хеш-объект функцией CryptCreateHash;
• хеш-объект наполняется данными (CryptHashData);
• подпись расшифровывается и результат сравнивается со «своим» хешем (CryptVerifySignature);
• хеш-объект разрушается (CryptDes-troyHash).

ВИТАЛИЙ ЛИ — разработчик ПО в компании «Киберплат.Ком». С ним можно связаться по адресу: vitaly1000@mail.ru.

The Cryptography API is implemented as an application-level system that Win32
applications may call for cryptographic services. The applications are thereby
insulated from the business of providing their own algorithms for such things
as encryption and hashing. Against that, the applications are limited to whatever
cryptographic services happen to be available in the current configuration of
the CryptoAPI system.

The CryptoAPI system is built in parts. An interface layer is exposed to the
client applications. Underneath are drivers that do the actual work of providing
the cryptographic services. Each such driver is called a Cryptographic Service
Provider (CSP). Microsoft itself supplies some CSPs with the CryptoAPI system.

The first retail package to include the CryptoAPI seems to have been Windows
95 OEM Service Release 2 (OSR2), with NT 4.0 following soon after. The Crypto
API has been a standard feature of both the Windows and NT packages ever since.
(For an aside with arguably non-trivial implications, see
The CryptoAPI and the Original Windows 95 Release.)

Technical Notes

Implementation details, some of which do not seem to be documented explicitly
by Microsoft, may reasonably be matters for public interest, whether for increasing
the CryptoAPI system’s perceived usability or for assessing the quality of a given
CryptoAPI implementation.

• CSP Signatures (15th September 1999)