On Wed, Jan 12, 2011 at 2:38 PM, Robert Relyea <[email protected]> wrote:
> On 01/12/2011 01:26 PM, Bernhard Thalmayr wrote:
>> 331569088[1bd1610]: C_UnwrapKey
>> 331569088[1bd1610]: hSession = 0x6
>> 331569088[1bd1610]: pMechanism = 0x7fffcd592ea0
>> 331569088[1bd1610]: hUnwrappingKey = 0x8
>> 331569088[1bd1610]: pWrappedKey = 0x36ac9bc
>> 331569088[1bd1610]: ulWrappedKeyLen = 48
>> 331569088[1bd1610]: pTemplate = 0x7fffcd592cf0
>> 331569088[1bd1610]: ulAttributeCount = 6
>> 331569088[1bd1610]: phKey = 0x36bfd58
>> 331569088[1bd1610]: CKA_SIGN = CK_TRUE [1]
>> 331569088[1bd1610]: CKA_VERIFY = CK_TRUE [1]
>> 331569088[1bd1610]: CKA_CLASS = CKO_SECRET_KEY [8]
>> 331569088[1bd1610]: CKA_KEY_TYPE = 0x10 [8]
>> 331569088[1bd1610]: CKA_DERIVE = CK_TRUE [1]
>> 331569088[1bd1610]: CKA_VALUE_LEN = 3000000000000000 [8]
>> 331569088[1bd1610]: mechanism = CKM_DES3_ECB
>> 331569088[1bd1610]: *phKey = 0x54
> The extra data here is dumping out interesting values inside the
> parameters passed to C_UnwrapKey. The list of CKA_XXXX = XXXXX are
> dumping out the template sent in pTemplate. CKA_VALUE_LEN looks wrong to
> me, I don't know if tehre is some byteswap issue here.
I looked into the CKA_VALUE_LEN issue. I found that our PKCS #11
logger prints CKA_VALUE_LEN as a hex dump. So
3000000000000000 [8]
means a sequence of 8 bytes:
0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
On a little-endian system (such as x86/x64), this is 48 decimal, which
is the length of the SSL/TLS master secret.
I filed an NSS bug https://bugzilla.mozilla.org/show_bug.cgi?id=625491
to improve the logging of CKA_VALUE_LEN, with a patch.
Wan-Teh
--
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
