pkcs11 — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
New Mechanisms subgroup Part 3 or 4, new AES
On 4/30/2013 8:46 PM, mark powers wrote:
On 04/30/13 03:59 PM, Michael StJohns wrote:
On 4/30/2013 5:19 PM, Robert Relyea wrote:
CKM_AES_XCBC_MAC_96
CKM_AES_XCBC_MAC_96 is a special case used with IPsec. 128-bit
result truncated to 96 bits.
Why wouldn't you just truncate the result after its returned from
PKCS11?
Because you might want to pass a pointer to a 96-bit field in a packet
to PKCS11 without
worrying that other fields will be clobbered. You could pass a 128-bit
buffer
and copy 96 bits into the packet, but that's not as elegant.
Or you could note that the signature can be truncated, and the
pulSignatureLen can be any size <= the size and it gets truncated. Or
on verify, you set the length you want to compare. I think this is a
reasonable general convention for MAC style signatures.
I think that adding a mode simply because you don't want to move bits
around is probably a bad idea.
Mike
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]