The CRANDOM macro covers the following functions
mixing additional seed material into the token’s random number generator
generating random data
All functions are performed asynchronously if asynchronous function execution was specified for the task with C_Initialize.
A detailed description of the functions of the CRANDOM macro can be found in PKCS#11 V2.20: Cryptographic Token Interface Standard in section 11.15 “Random number generation functions”.
Macro | Operands |
CRANDOM | MF=C / D / L / M / E ,VERSION=001 / 002 ,ACTION=*SEEDRANDOM / *GENERATERANDOM / <var: enum-of _action_set: 1> / default: _action_set.undefined ,SESSION=<var: int:4> / <integer 0..2147483647> / 0 ,DATA=<var: pointer> / NULL ,DATALEN=<var: int:4> / <integer 0..2147483647> / 0 ,BOID=<<var: int:4> / 0 ,RPOSTAD=var: pointer> / NULL ,RPOSTL=<integer 1..2> / <var: int:4> / 0 |
VERSION
specifies which version of the parameter area is to be generated. It is always advisable to use the latest version.
=001
This generates the format that was supported by CRYPT V1.0. This format supports the parameters already known in CRYPT V1.0.
VERSION=001 is the default.
=002
This generates the format supported as of CRYPT V1.1.
ACTION
Type of action.
The corresponding PKCS#11 function is specified for each action code.
=*SEEDRANDOM
corresponds to the PKCS#11 function C_SeedRandom;
mixes additional seed material in the token’s random number generator
=*GENERATERANDOM
corresponds to the PKCS#11 function C_GenerateRandom;
generates random data.
SESSION
Session identifier
DATA
points to the following data:
with *SEEDRANDOM: DATA points to the start parameter material.
with *GENERATERANDOM: DATA points to the memory location that receives the random data.
DATALEN
Length of the data in bytes
BOID
Event identification
in the case of synchronous execution: BOID is not used.
in the case of asynchronous execution: Event identification to which the end of function processing is signalled.
RPOSTAD
Postcode address
in the case of synchronous execution: RPOSTAD is not used.
in the case of asynchronous execution: specifies a field containing postcode information which is to be transferred to the corresponding program that issues the SOLSIG call (see also “Executive Macros” user guide [3]).
Length of postcode: 4 or 8 bytes
RPOSTL
Length of postcode
in the case of synchronous execution: RPOSTL is not used.
in the case of asynchronous execution: specifies the length of the postcode information in words (1 or 2).