Jon,
Does this info help:
The m value is calculated as follows:
boundary 0x00 The boundary value
identifier 0x02 The block type identifier
random n octets n octets of non zero PRNG data to make
len(m) = modulus of the
length of the
primary key p
boundary 0x00 The boundary value
algorithm id 1 octet The ID of the symmetrical algorithm used
with the session key
session key n bits This is the n bit session key to encrypt
the data
checksum 2 bytes Is the 16 bit checksum of the session key,
MOD 65536
At 03:15 PM 3/10/2000 -0700, you wrote:
Please let me know if this is adequate:
5.1:
The value "m" in the above formulas is derived from the session key
as follows. First the session key is prefixed with a one-octet
algorithm identifier that specifies the symmetric encryption
algorithm used to encrypt the following Symmetrically Encrypted Data
Packet. Then a two-octet checksum is appended which is equal to the
sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then encoded as described
in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m"
value used in the formulas above.
Note that when an implementation forms several PKESKs with one
session key, forming a message that can be decrypted by several
keys, the implementation MUST make new PKCS-1 encoding for each key.
and
5.2.2:
With RSA signatures, the hash value is encoded as described in
PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of
type DigestInfo, and then encoded using PKCS-1 encoding type
EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value
as an octet string into an ASN.1 structure. The object identifier
for the type of hash being used is included in the structure. The
hexadecimal representations for the currently defined hash
algorithms are: