Comparison of The Open Group's GCS-API and Microsoft CryptoAPI Version 1.0
Who should read this document?
This document is directed to readers interested in the implementation and use of generic programming interfaces to cryptographic services.
Why should you read this document?
The GCS-API and CryptoAPI are two different specifications of interfaces to similar functionality. Companies are likely to want to implement one but not both of these interfaces. This document provides a structured comparison of the features and scope of the two specifications.
Code examples have not been included in this document. Examples are included in each of the specifications.
| GCS-API | CryptoAPI |
| The GCS-API has been produced by the The Open Group's Cryptographic Working Group comprising representatives of BULL, HP, IBM, Fujitsu/ICL, USA NIST, USA NSA, Olivetti, OpenVision, Siemens Nixdorf, TIS, together with input from Fischer international and RSA Data Security, Inc | The CryptoAPI has been published by Microsoft and is a component of their Internet Security Framework.. |
| The current GCS-API specification is a Preliminary Specification and a number of companies are undertaking trial implementations. | An implementation of Version 1.0 is incorporated into Microsoft Internet explorer 3.0 and Windows 95 refresh. |
| The GCS-API provides a generic interface to cryptographic operations that support the development of applications that are cryptographic algorithm independent. | The CryptoAPI provides a generic interface to cryptographic operations that support the development of applications that are cryptographic algorithm independent. |
| GCS-API is orientated around the concept of a single Cryptographic Support Facility (CSF) that is capable of supporting any number of algorithms, as determined by the implementation. | A single Cryptographic Service Provider (CSP) provides a limited set of algorithms and data exchange formats. If a caller requires to use a richer set of algorithms and formats then more than one CSP may be used at once. |
| The algorithms and their modes of operation are controlled by the definition of a set of template cryptographic contexts. The set of template cryptographic contexts may be predefined by an implementation or an implementation may support a set of functions by which an organisation may define its own set of template cryptographic contexts. | The algorithms and data formats by a single CSP are determined by the Provider Type of the CSP. A number of Provider Types have been defined by Microsoft. |
| A CSF supports the storage of any type of Cryptographic Context and keys. | A CSP supports named key containers each of which contains two public/private key pairs, one for signing and one for key export operations. |
| This comparison is based upon current preliminary Specification of the GCS-API. It is expected to progress to OpenGroup CAE status at the end of 1996. Separate work on certificate management services is being initiated within the OpenGroup in co-operation with other bodies as part of an overall Public Key Infrastructure. | This comparison is based upon CryptoAPI version 1.0. It is understood that Version 2.0 will add certificate functions to the API. |
| GCS-API | CryptoAPI |
| May be supported over either hardware or software cryptographic module implementations | May be supported over either hardware or software cryptographic module implementations |
| An objective of the GCS-API is support for hardware implementations with limited processing capability. | |
| The GCSAPI_PS assumes a stateless CSF. That is, a CSF is not assumed to maintain any internal state related to a sequence of calls for an individual client between calls. | The CryptoAPI assumes a statefull implementation |
| The GCS-API enables an implementation to pass intermediate state information back and forth across the interface in cryptographic contexts, intermediate_result, and session_context parameters. | No state information is passed back and forth across the API. A CSP is assumed to maintain the state associated with a particular CSP handle between successive calls (e.g., a Hash Object). |
| GCS-API | CryptoAPI |
| The GCS-API provides for the passing of authentication credentials to the CSF in gcs_initialise_session and also support for an authentication protocol requiring successive calls to gcs_initialise_session. | The CryptoAPI does not provide an ability to pass authentication credentials within the interface when acquiring a CSP context.. |
| The interface does not make provision for a CSF to conduct a dialogue with a user via the calling application. | The interface does not make provision for a CSP to conduct a dialogue with a user via the calling application. |
| A CSF implementation may also retrieve credential information from the caller's process environment or interact directly with a user independently of the calling application. | The CryptoAPI assumes that either there is sufficient credential information in the environment, for example an authenticated username, or that a CSP will interact with a user independently of the calling application to directly authenticate the user invoking the CSP services |
| The GCSAPI provides for the continuous authentication of a caller to the CSF through the inclusion of the session_context parameter with every call. The GCS-API therefore does not assume that a CSF implementation necessarily binds a security context to the communication channel with a caller but permits the security context to be verified on each call. | The CryptoAPI may be capable of supporting continuous authentication provided the security context is bound to the CSP handle. |
| GCS-API | CryptoAPI |
| The GCS-API defines an authorisation policy for the use of each function call on the basis of a set of defined GCS Authorities. | The CryptoAPI does not refer to an authorisation policy on a per function call basis nor specifically for controlling access to key containers. |
| The GCS-API also supports an implementation defined authorisation policy for access to stored keys. | The error codes for CryptAcquireContext imply that the names of key containers accessible by a user are stored in the Windows NT Registry and are determined at run time by entries under the HKEY_CURRENT_USER\software subtree. |
| The GCS-API supports a key usage control policy on a per key basis. | A key usage control policy is built into the concept of a CSP. Asymmetric algorithms cannot be used to encrypt data. Symmetric keys cannot be used to sign hashes. |
Cryptographic policy enforcement is considered from several aspects:
| GCS-API | CryptoAPI |
| Incorporates the concept of keys being protected by an implementation and referenced only by a handle above the API | Incorporates the concept of keys being protected by an implementation and referenced only by a handle above the API |
| Supports the concept of the export of keys above the API as protected opaque blobs | Supports the concept of the export of keys above the API as protected opaque blobs |
| Supports the concept of the provision of secure storage of any keys below the API. | Supports the concept of the provision of secure storage of private/public key pairs below the API. |
| The GCSAPI provides facilities for the persistent storage of any type of key and its associated context by a CSF under the control of a calling application. The calling application is able to name the stored key and, when multiple storage resources are available, to define the type of storage to be used (for example a smartcard device.) | The CryptoAPI only supports the persistent storage by a CSP of private/public key pairs generated by the CSP. No provision is made for the persistent storage of session keys, whether generated or imported, and imported public keys. When a CSP context is released then any session keys and imported public keys are lost. |
| Under the GCS-API a calling application does not need to have responsibility for handling keys that are required beyond a single session with a CSF except to assign a key an appropriate name and request the CSF to store it | The CryptoAPI places responsibility on a calling application to export and store any session keys or any public keys that it wishes to use beyond a single session with a CSP. |
| A calling application may retrieve and use any number of keys simultaneously. An access control policy determined by the implementation is enforced upon the retrieval of stored keys. It is therefore possible for callers to share access to stored keys under the conditions of that access control policy. | A CryptoAPI CSP supports a number of named key containers. By default, a container is named with a user's logon name and provides for the storage by a CSP of the private/public key pair's associated with the user. CryptoAPI supports the generation and storage of two private/public key pairs per container, one for key exchange and one for signature purposes. Only one key container may be open within a single CSP at once. An application may create and name its own key containers. |
| The GCS-API also provides functions for the secure archiving and retrieval of keys and their associated context. This provides support for the development of key recovery and notarisation services that may require the long term storage and control of keys. | The binding of a context with a key for long term storage is an application responsibility. |
| GCS-API | CryptoAPI |
| The fundamental concept of the GCS-API is the ability for the CSF to enforce policy on the use of the cryptographic functions and the use of cryptographic keys but the GCS-API does not proscribe any particular policy. | A fundamental concept of the CryptoAPI is that data is only enciphered and deciphered using symmetric algorithms. Asymmetric algorithms are restricted to use for signature and key export and import functions. |
| The operations of a GCS-API implementation are controlled by the definition of a set of template cryptographic contexts. These encapsulate an algorithm, a set of algorithm parameters and a set of key context parameters. Included within the cryptographic context is a key usage parameter that defines the specific cryptographic functions of the GCS-API with which that cryptographic context can be used. An implementation of the GCS-API may be supplied with a predefined set of template cryptographic contexts, in which case a policy similar to the CryptoAPI policy may be defined and enforced. Alternatively, or additionally, an implementation may provide the functions of the Advanced GCS-API that support the development of applications to manage the algorithm and key usage policies enforced by the CSF. | The CryptoAPI uses the concept of a CSP Type to refer to a set or family of algorithms and associated modes and data formats. The concept of a CSP Type defines:
It is possible for an application to connect to more than one CSP at a time and therefore gain access to a wider set of algorithms. |
| GCS-API | CryptoAPI |
| The GCS-API incorporates the concept of a key lifecycle and provides data structures and functions for its management if required. A cryptographic context includes structures for recording key lifetimes and usage and triggering internal key state changes that control the usage of the key, in particular enforcing its de-activation on expiry of its permitted active life. | The CryptoAPI does not acknowledge any concept of a key lifecycle, this is solely an application concept and responsibility. |
Microsoft support a secure loader within the Windows NT environment that verifies the Digital Signature of a software CSP module when it is loaded and periodically thereafter. This verifies the integrity of the software CSP module and that it has not been modified or subverted, for example to use longer key lengths. A CSP module has to be signed by Microsoft to be capable of being used within a Windows NT environment.
This secure loader has no impact on the CryptoAPI except for the presence of one error code indication a failure to verify the Digital Signature of a CSP module.
The protection of a CryptoAPI CSP implemented on any other operating system would be dependent on the provision of similar capabilities.
An implementation of the GCS-API could provided on an operating system that supports a secure loader. No impact on the API itself is required. A miscellaneous error code could be returned with an implementation specific minor status code to indicate a CSF integrity failure.
Cryptographic products are subject to the export, import, and usage controls of governments. In recognition of this fact both the CryptoAPI and the GCS-API support the enforcement of algorithm and key usage policies as described above. The ability to export, import or use implementations of the CryptoAPI or GCS-API are dependent upon the tamper proofing of the implementations and the protection of their integrity. Hence, the concept of secure loaders described above.
One of the objectives of both the CryptoAPI and the GCS-API is to enable the development of applications that use a common cryptographic interface and which can therefore be shipped without including any specific cryptographic implementation, simply linking to the cryptographic services available on the local platform. The legal status of an application written to one of these interfaces has still to be tested under all the relevant legislation on a case by case basis.
| GCS-API | CryptoAPI |
| The GCS-API includes a set of clear key management functions in support of the installation of initial CSF keys and also to support key exchange protocols that require the manipulation of clear keys when such protocols have not been directly implemented by a CSF implementation, for example Kerberos. | MS CryptoAPI does not include any CSP management services and in particular does not address service interfaces to manage clear keys (e.g., CSF Master keys.) This is presumably detailed in the Guide for CSP Developers. |
| gcs_initialise_session | CryptAcquireContext |
| gcs_terminate_session | CryptReleaseContext |
| GCS-API | CryptoAPI | |
| Incorporates the concept of a session between a caller of the cryptographic services and the cryptographic service facility. | Incorporates the concept of a session between a caller of the cryptographic services and the cryptographic service provider. | |
| Any algorithms supported by the CSF, and for which a CC is accessible may be used by the caller, subject to any authorisation policy enforced. | The CryptAcquireContext function requires the caller to specify the type of CSP to use, and optionally a provider name. This selects the set of algorithms and export data formats etc., that are to be used by the caller. | |
| Caller Authentication | ||
| The GCS-API provides for a caller to supply an opaque set of authentication data to gcs_initialise_session and returns a session_context to the caller for use in subsequent operations. | The CryptoAPI model is that the caller does not handle user authentication data but that the CSP interacts directly with the user for authentication purposes. This enables an application to be independent of the authentication model implemented by a CSP and prevents an application from being able to disclose authentication data. A handle to the invoked CSP is returned for use in subsequent operations. | |
| gcs_delete_cc | CryptDestroyKey |
| gcs_list_cc | CryptGetProvParam PP_ENUMCONTAINERS |
| gcs_retrieve_cc | CryptAcquireContext
CryptgetUserKey |
| GCS-API | CryptoAPI |
| The GCS-API supports the listing and retrieval of named Cryptographic Contexts that have been stored by a CSF. | The CryptoAPI supports the opening of a named key container within a CSP at the time a handle to the CSP is acquired. Only one key container within a CSP may be open at once. CryptGetUserKey may be used to get a handle to one of the key pairs held within the open key container. CryprGetProvParam may be used to enumerate the names of the key containers within a CSP. To switch to a different key may therefore require calls to CryptAcquireContext and CryptGetUserKey. |
| gcs_delete_cc deletes a callers local copy of a CC, that is deletes a callers copy of a key. If the CC has not been previously stored then the key is effectively destroyed. | CryptDestroyKey releases the handle to a key. once a key handle has been released, it becomes invalid and cannot be used again. Unless the key handle references one of the public/private key pairs stored in the CSP then the key itself is destroyed. |
| gcs_derive_key | CryptDeriveKey |
| gcs_generate_key | CryptGenKey |
Key Creation Functions
| GCS-API | CryptoAPI |
| The GCS-API supports the generation and derivation of both symmetric keys and asymmetric key pairs. All the information associated with the new key, such as algorithm type etc., is specified in the Template CC supplied to the call. | CryptoAPI Session Keys are generated using CryptGenKey or CryptDerivekey..
CryptoAPI Private/Public Key pairs are generated using CrypyGenKey specifying AT_KEYEXCHANGE or AT_SIGNATURE. Private/Public Key Pairs cannot be derived. |
| Keys of both types are not automatically stored by a CSF. A caller has to invoke the gcs_store_cc function to store a key (CC). | CSP automatically stores Private/Public Key Pairs in Key Container referenced by the current CSP Handle CSP cannot store session keys |
| A caller is not required to know which algorithm the key is to be used with. | Caller has to specify the algorithm to be used for any subsequent encryption/decryption operations when the key is generated |
| gcs_generate_checkvalue | CryptCreateHash
CryptHashData (+CryptHashSessionKey) CryptSignHash |
| gcs_verify_checkvalue | CryptCreateHash
CryptHashData (+ CryptHashSessionKey) CryptVerifySignature |
| gcs_generate_hash | CryptCreateHash
CryptHashData (+CryptHashSessionKey) CryptGetHashParam |
| gcs_generate_random_number | CryptGenRandom |
Hash and Signature Functions
The GCSAPI provides three related functions:
| gcs_generate_hash | gcs_generate_check_value | gcs_verify_check_value |
| minor_status (out) | minor_status (out) | minor_status (out) |
| session_context (in) | session_context (in) | session_context (in) |
| input_data (in) | input_data (in) | input_data (in) |
| cc (in,out) | IV (in, optional) | IV (in,optional) |
| intermediate_result (in,out) | chain_flag (in) | check_value (in) |
| chain_flag (in) | cc (in,out) | chain_flag (in) |
| output_data (out) (The hash value) | intermediate_result (in,out) | cc (in,out) |
| check_value (out) | intermediate_result (in,out) |
| GCS-API | CryptoAPI |
| The generated hash or checkvalue is handled directly by the calling application. | The hash is handled as an opaque object that comprises the information needed to generate the hash and the hash data. This hash object is referenced by a handle by the calling application. |
| The GCSAPI permits the creation of signatures using any algorithm, symmetric or asymmetric providing an appropriate Template CC or Populated CC is available. | The CryptoAPI only permits the use of asymmetric algorithms to create signatures and only those two algorithms supported by the current CSP for key-exchange or signature. |
| For data greater than the supported buffer size then multiple calls to these functions may be made using the "chain_flag" to indicate the first, a middle, or the last call to the function. | |
The hash value is generated by successive calls to CryptHashData
or CryptHashSessionKey. CryptHashSessionKey allows the session
key, or multiple such keys to be included in the data over which
the hash or signature is generated. The GCS-API does not support
the capability to include a key within the hashed data stream.
Once the all the input data has been processed by the hash object then only one of the following actions may be invoked:
(Not relevant here but CryptDeriveKey may also be called.)
Once one of the above have been called then CryptDestroyHash is called to destroy the hash object which can no longer be used.
Only the KeyExchange Key Pair or the Signature Key Pair of the current key container opened by the CSP may be used to sign the hash.
| gcs_encipher-data | CryptEncrypt |
| gcs_decipher_data | CryptDecrypt |
| gcs_protect_data | CryptEncrypt |
| gcs_decipher_verify | CryptDecrypt |
Data Encipherment Functions
ENCIPHER / DECIPHER
| gcs_encipher_data | gcs_protect_data | CryptEncrypt |
| minor_status (out) | minor_status (out) | - |
| session_context (in) | session_context (in) | - |
| input_data (in) | input_data (in) | pbData / pdwDatalen (in,out) |
| IV (in) | IV (in) | - |
| chain_flag (in) | chain_flag (in) | Final (in) |
| cc (in,out) | confidentiality_cc (in,out) | hKey (in) |
| - | integrity_cc (in,out) | hHash (in) |
| intermediate_result (in,out) | intermediate_result (in,out) | - |
| output_data (out) | output_data (out) | pbData / pdwDataLen (in,out) |
| - | check_value | - |
| - | - | dwFlags (in) |
| GCS-API | CryptoAPI |
| GCS-API provides two sets of interfaces: the gcs_encipher_data and gcs_decipher_data functions provide for the encryption and decryption of data, the gcs_protect_data and gcs_decipher_verify functions provide for simultaneous encryption and hash or signature functions on a set of data. | The CryptoAPI CryptEncrypt and CryptDecrypt functions includes a hash object handle hHash that provides for the simultaneous creation of a hash of the deciphered data. To complete the hash operation an additional call to one of CryptGetHashParam, CryptSignHash or CryptVerifySignature is needed. |
| GCSAPI uses separate input ciphertext and output cleartext buffers | CryptoAPI use a single buffer for both input ciphertext and output cleartext. |
| IV is included as a Key Parameter within a CC. GCSAPI also provides an IV as a specific input because it is required to change frequently. | IV is included as a Key Parameter but not as a parameter in function calls |
| GCSAPI uses chain_flag to indicate if this is the ONLY block to be processed, or the FIRST, MIDDLE, or LAST block of a sequence of blocks to be processed. | CryptoAPI uses the boolean Final for the same purpose. If TRUE this call is the last or only block to be processed. If false it is the first or a middle block to be processed. |
| GCSAPI uses a cc as a handle to the algorithm, the key and key parameters, | CryptoAPI uses hKey as a handle to the algorithm, the key and key parameters. |
| GCSAPI can use both symmetric and asymmetric algorithms for these functions | CryptoAPI only permits the use of a symmetric algorithm for these functions. |
| The CryptoAPI dwFlags parameter is currently unused and reserved for future extension. | |
| CryptEncrypt includes an additional buffer length parameter. |
| gcs_store_cc | CryptAcquireContext
CryptGenKey |
| gcs_remove_cc | CryptAcquireContext |
Cryptographic Context Storage Functions
| GCS-API | CryptoAPI |
| gcs_store_cc enables a CC to be named and stored in CSF storage. The CC may be a template CC or contain any type of key supported by the CSF implementation. | CryptAcquireContext enables a Key Container to be created within the current CSP. CryptGenKey with an AlgID of AT_KEYEXCHANGE or AT_SIGNATURE enables the key container to be populated with key exchange and signature key pairs appropriately. |
| gcs_remove_cc enables an individual named CC to be removed from CSF storage. | CryptAcquireContext enables a Key Container to be deleted, together with private/public key pairs contained within it. |
| gcs_export_key | CryptExportkey |
| gcs_import_key | CryptImportkey |
| gcs_key_agreement | - |
Key Exchange Functions
| GCS-API | CryptoAPI |
| Keys are exported as protected opaque blobs
Blob types are determined by supported export mechanisms. A single CSF may support multiple export mechanisms. | Keys are exported as protected opaque blobs
BlobTypes are determined by CSP type. SIMPLBLOB - Session key (Symmetric Key)
PUBLICKEYBLOB - public key. Private keys cannot be exported. |
| GCS-API support for integrated key agreement protocols. | Applications have to implement key agreement protocol. |
| gcs_export_key | CryptExportKey |
| minor_status (out) | - |
| session_context (in) | - |
| subject_cc (in.out) | {hKey (in) |
| {dwBlobType (in) | |
| kek_cc (in,out) | hExpKey (in) |
| export_data (out) | {pbData (out) |
| {pdwDataLen (out) | |
| dwFlags (in) |
For CryptoAPI BlobType is SIMPLEBLOB (Session key) or PUBLICKEYBLOB
(Public key)
For GCSAPI BlobType is defined by Protocol Type in subject_cc
| gcs_import_key | CryptImportkey |
| minor_status (out) | - |
| session_context (in) | - |
| kek_cc (in,out) | hImpKey (in |
| export_data (in) | {pbData (in) |
| - | {pdwDataLen (in) |
| subject_cc (in,out) | phKey (out) |
| hprov (in) |
If Public Key or session key is encrypted with callers's key exchange key pair then hImpKey is Zero. Otherwise this may contain public key of party creating Key Blob, if signed, or session key, if key encrypted with that session key.
The GCS-API also provides a key agreement function. This function supports the implementation of key agreement protocols within the CSF. Multiple calls between peers may be required with the exchange of partial Protocol Data Units.
| gcs_key_agreement | |
| minor_status (out) | |
| session_context (in) | |
| caller_cc (in/out) | |
| other_cc (in/out) | |
| pdu_in (in) | |
| pdu_out (out) | |
| kak_cc (in/out) |
| gcs_get_csf_param | CryptGetProvParam |
| gcs_release_buffer | - |
| gcs_release_bit_string | - |
Utility Functions
These functions enable a caller to retrieve the values of parameters specific to the implementation and to release memory allocated to buffers and bit strings.
| gcs-create_ac | - |
| gcs_delete-ac | - |
| gcs-set_ac | - |
| gcs-create_kc | - |
| gcs_delete_kc | - |
| gcs_set_kc | - |
| gcs_create_cc | - |
These GCS-API functions are used to create Template CCs. The
CRyptoAPI does not any equivalent functions for defining algorithm
and key usage policy.
| gcs_get_cc | CryptGetProvParams
CryptGetKeyParams |
| get_retrieve_cc | CryptAcquireContext
CryptGetUserKey |
| gcs-set-cc | CryptSetProvParams
CryptSetKeyParams |
| gcs_store_cc | - |
| GCS-API | CRyptoAPI |
| gcs_store_cc supports the storage by the CSF of any type of CC and key under a caller defined name. | The CryptGenKey function, when used to generate public/private key pairs automatically includes the storage of the generated key pair within a the current key container. |
| gcs_retrieve_cc supports the retrieval from a CSF of any CC previously stored by the CSF subject to an implementation defined access control policy. | CryptAcquireContext enables a caller to open a named key container within a CSP.
CryptGetUserKey enables a caller to obtain a handle to either the Signature or the KeyExchange private keys stored within the current key container.
|
| gcs_get_cc enables a caller to query the contents of a CC including details of algorithms and algorithm and key specific parameters included in the CC | CryptGetProvParam enables a caller to query information about the algorithms supported by a CSP.
CryptGetKeyParam enables a caller to query information about the parameters for a specific key. |
| gcs_set_cc enables a caller to modify the contents of a CC and is subject to an access control policy. | CryptSetprovParam does not currently perform any useful function as no settable CSP parameters have been defined.
CryptSetkeyparam enables key specific parameters to be modified. These include block length, key salt, permissions, IV, padding, mode, mode-bits. |
| A caller must possess a GCS_C_KEY_USAGE authority in order to successfully call gcs_set_cc. A finer grained control on access to specific parameters is not defined by this interface. | The permissions control operations on the key itself, not the operations for which the key may be used. |
| gcs_combine_key | - |
| gcs_load_public_key | - |
Additional Key Management Functions
These functions support the loading of keys in multiple parts.
There are no CRyptoAPI equivalent functions.
| gcs_advance_key_state | - |
| gcs-get_key_validity | - |
| gcs_reduce_key-usage | - |
| gcs_revoke_key | - |
| gcs_set_key_validity | - |
Key State Management Functions
These functions enable a caller to manipulate the state of a key
in the context of the key lifecycle model supported by the GCS-API.
CRyptoAPI does not provide support the concept of a key lifecycle
and there are no equivalent CRyptoAPI functions.
| gcs_archive_cc | - |
| gcs_restore_cc | - |
| gcs_generate_key_pattern | - |
| gcs_verify_key_pattern | - |
Supplementary CC Management Functions
The gcs_archive_cc and gcs_restore_cc functions are provided to
support the long term storage of a key and its associated context
including usage controls, current lifecycle state etc. The gcs_generate_key_pattern
and gcs_verify_key_pattern functions are provided to support the
testing of identical keys separately derived by different implementations.
There are no equivalent CRyptoAPI functions.
The principal data structure in the GCS-API is a Cryptographic Context (CC) which provides a handle to the algorithms, key and associated parameters that define the context of an operation. This table compares the contents of a GCS-API CC with data structures used the CryptoAPI. This is followed by a comparison of some of the other GCS-API function parameters with equivalents within the CryptoAPI functions.
| GCSAPI Data Structure | CryptoAPI Equivalents |
| Cryptographic Context | |
| CC Header | |
| Context_Version_Number | PP_Version |
| Context_Type (Keyed or Non-Keyed) | N/A |
| Context_Confidentiality_Flag | N/A |
| Context_ID (Not visible at API) | N/A |
| Context_Checkvalue (Not visible at API) | N/A |
| Algorithm Context | |
| Algorithm ID | Algid
Parameter to CryptGenKey |
| Mode of Operation | KP_MODE
Parameter to CryptSetKeyParam |
| Short Block Policy | KP_PADDING
Parameter to CryptSetKeyParam |
| Algorithm Specific Parameters | |
| - specific to algorithm and BER encoded according to standard defining the algorithm. examples are key length , feedback length, IV parameters, Modulus length, exponent lengths etc. | The size in bits of key for a supported algorithm may be retrieved by CryptGetprovParam. KP_MODE_BITS supplied to CryptSetKeyParam sets the feedback length for a key for some block modes of operation. |
| Key Context | |
| Key Usage | No equivalent |
| Permitted_Export_Mechanisms | KP_PERMISSIONS: Crypt_Export.
This is not controlled by MS RSA Base Provider but might be supported by a custom CSP. A CSP only supports a single export mechanism creating a Key-Blob of a fixed structure using the KEYEXCHANGE public key of the destination user.. |
| Key_State | No support for key lifecycle or key state |
| Time_of_Revocation | No support for key state" |
| Reason_for_Revocation | No suppport for key state |
| Key_Flag: | |
| IV_Needed | Not forced by CryptoAPI |
| Split | No support for split keys |
| Quasi_Compromised | No support for key state |
| Force_First_Usage | No support for flexible key usage control |
| Split_Protocol_Type | No provision for split keys |
| Key_Part_Number | No support for split keys |
| Number_of_key_parts | No support for split keys |
| Key_Validity: | No support for key lifecycle or key state |
| Activate Point | No support for key lifecycle or key state |
| Quiescent Point | No support for key lifecycle or key state |
| DeActivation Point | No support for key lifecycle or key state |
| Initialisation Vector (IV) | KP_IV - Parameter to CryptSetkeyParam |
| Key_Specific_Parameters | No key specific parameters are supported. (Parameters that can be set by CryptSetKeyParam are Algorithm Specific Parameters under GCS-API or are otherwise specifically identified within a GCS-API CC.) |
| CC_Reference | |
| Label | No equivalent |
| Storage_unit-class | No equivalent - (Storage type determined by CSP) |
| Storage_unit_instance | No equivalent |
| Cryptographic Context Name | |
| Domain_ID | Could be mapped to key Container Name within a CSP although GCS-API concept is wider than this. |
| CC_Name | Only two key names are supported by CryptoAPI within a single Key Container: AT_KEYEXCHANGE and AT_SIGNATURE. |
| Other GCS-API Function Parameters | |
| minor_status
Implementation specific return status | No equivalent in CryptoAPI |
| session_context
Implementation specific parameter that defines context between caller and CSF | Could be considered equivalent to the handle to a CSP returned by CryptAcquireContext in that both bind caller and context with CSP. |
| input_data / output_data
Separate buffers for input and output data to/from functions | pbData
Single buffer used for both input and output data to/from functions |
| IV
Optional IV parameter can be used instead of holding IV in CC with key. | IV is only handled as a Key Parameter via CryptSetKeyParam |
| chain_flag
GCS_FIRST, GCS_MIDDLE, GCS_LAST, GCS_ONLY | Final
Boolean used to indicate the last or only input block. |
| intermediate_result
intermediate_results from calculation are returned with successive calls. CSF does not preserve state between calls. | No intermediate_results are returned above API to caller. CSP maintains state between calls. |
| initialise_parameters
These are parameters supplied to the gcs_initialise_session call and may include authentication tokens or data and also information about the default context of the caller.. | CryptoAPI does not provide for a caller to supply authentication data to CryptAcquireContext but does support the specification of a CSP, and a key container. |
| pdu_in
Protocol Data Unit input to Key Agreement function | No equivalent in CryptoAPI |
| pdu_out
Protocol Data Unit output by Key Agreement function | No equivalent in CryptoAPI |
| key_part_type
GCS_FIRST, GCS_MIDDLE, GCS_LAST, GCS_ONLY | CryptoAPI does not support split keys |
| archive_string | CSPs do not provide functions for the archiving and retrieval of keys and their context |
This table compares CryptoAPI data with GCS-API equivalents.
| GCS-API Equivalents | CryptoAPI Data |
| This equates to a named pair of CCs perhaps with the same Domain_ID | Key Container Name:
PP_CONTAINER - Parameter to CryptGetProvParam. pszContainer - parameter to CryptAcquireContext |
| This information is included in each CC as Algorithm ID and Algorithm specific information. GCS-API does not currently support an API to directly retrieve a list of algorithms supported by an implementation except by retrieving Template CCs. | Algorithm Information
Alg ID Key Length in Bits Length of Name
Name PP_ENUMALGS - Parameter to CryptGetProvParam. |
| This might map to a naming convention for CCs,
e.g., Domain_Name | PP_ENUMCONTAINERS
Causes CryptAcquireContext to return name of next Key Container Maintained by CSP |
| GCS_IMPLEMENTATION_TYPE
Parameter to gcs_get_csf_params | Implementation Type
Hardware Software Both
Unknown (Not Revealed)PP_IMPTYPE PP_IMPTYPE - parameter to CryptGetProvParam |
| No direct GCSAPI equivalent. This might map to a naming convention for a set of CCs | CSP Name
PP_NAME - parameter to CryptGetProvParam pszProvider parameter to CryptAcquireContext |
| Context_Version_Number | Version Number of CSP
PP_VERSION - parameter to CryptGetProvParam |
| GCS-API does not directly support concept of algorithm class as a separate parameter. An implementation or end-user may implement this by using a naming convention for CCs | ALG_CLASS
Held for each AlgID, returned by GET_ALG_CLASS Macro Data Encrypt Hash Key Exchange Signature |
| Algorithm ID held in CC | Alg_ID stored with Key
KP_ALG_ID parameter to CryptGenKey or CryptDerivekey |
| No specific parameter defined in GCS-API. This could be included in Algorithm Specific Parameters | Block Length for Algorithm if Session Key
KP_BLOCKLEN - parameter to CryptSetKeyParam and CryptGetkeyParam |
| Not directly supported by GCS-API. This could be included as a key specific parameter settable by gcs_set_cc but caller would have to possess GCS_C_KEY_USAGE authority | Key Salt Value
KP_SALT - parameter to CryptSetKeyParam and CryptGetKeyParam |
| CRYPT_EXPORT permission maps to list of permitted export mechanisms in CC. GCS-API authorisation model controls which functions a caller may successfully call based on GCS authorities. Use for which a key may be used is controlled by key_usage data in CC. GCS-API does not include concept of permissions per key controlling operations that may be performed upon it (except for export.) An implementation may enforce an access control policy on access to keys but this is not configurable via the GCS-API. | Key permissions
These are ignored by MS RSA Base provider but may be used by custom CSP. KP_PERMISSIONS CRYPT_ENCRYPT - Allow Encryption CRYPT_DECRYPT - Allow Decryption CRYPT_EXPORT Allow key to be exported CRYPT_READ Allow parameters to be read CRYPT_WRITE Allow parameters to be set CRYPT_MAC Allow MACs to be used with key |
| IV in CC
Also separate per call parameter to encipher and hash groups of functions. | IV Value
KP_IV - parameter to CryptSetKeyParam |
| SHORT_BLOCK_POLICY in CC | Padding mode
KP_PADDING - parameter to CryptSetKeyParam |
| Mode of operation held CC as part of Algorithm Context | Cipher Mode
KP_MODE - parameter to CryptSetKeyParam EBC CBC OFB CFB |
| Short Block Policy held as part of algorithm context in CC | Number of mode bits
KP_MODE_BITS - parameter to CryptSetKeyParam |
| Hash Parameters | |
| Algorithm ID in CC | HP_ALGID
ALG_ID of algorithm specified when hash object created by CryptCreateHash |
| Size of hash is included as part of output_data gcs_buffer_structure and will be set by gcs_generate_hash function. | HP_HASHSIZE
Hash value size (No of bytes of hash value) (Normally 16 or 20) |
| Intermediate hash values and other state are returned to caller in a protected form in intermediate_data parameter to hash and signature functions. On final call output_data parameter to gcs_generate_hash holds hash value. | HP_HASHVAL
The Hash Value or Message Digest retrieved by a call to CryptGetHashParam.. CryptoAPI accumulates hash_value as internal data of hash object. Only accessible via CryptGetHashParam call. Once retrieved Hash Object is marked finished and cannot be reused but could be regenerated.. |
| Defined by export mechanism defined within CC | dwBlobType
SIMPLEBLOB for session keys PUBLICKEYBLOB for public keys |