On 10/30/09 05:58 PM, Dan Anderson wrote:
>
>
> On 28/10/2009 04:20 PM, Krishna Yenduri wrote:
>>
>> KY-1 -
>>
>> A PKCS #11 application is allowed to express in-place operation
>> by passing the same pointer for plaintext and ciphertext.
>> I recommend checking for this case and setting the
>> CRYPTO_INPLACE_OPERATION, if true. No other in-place checks
>> are needed in this case. For bonus points, modify encrypt(1)
>> to use this convention.
> The pre-existing code (all over kernelDecrypt.c and kernelEncrypt.c,
> and from where these functions are called) uses the current convention
> of using NULL for the output pointer for in-place operations. I don't
> see the reason/justification for changing the convention on existing code.
I am not suggesting to change the pkcs11_kernel (and /dev/crypto) to
KCF convention.
I guess this is easier to explain with code. I am suggesting the
following code -
encrypt_update.eu_flags =
((pPart == pEncryptedPart) ||
(INPLACE_MECHANISM(session_p->encrypt.mech.mechanism) &&
(pEncryptedPart != NULL) &&
(encrypt_update.eu_encrlen == encrypt_update.eu_datalen)) ?
CRYPTO_INPLACE_OPERATION : 0;
The same check can be done for the single part routines, C_Encrypt() and
C_Decrypt().
>>
>> KY-2 kernelDecrypt.c, line 375
>> kernelEncrypt.c, line 344
>>
>> The INPLACE_MECHANISM macro does the checks each time
>> the routine is called.
>> Recommend caching a bit flag in session_p->encrypt.flags field
>> and use it instead.
> The length fields could change on each call to C_EncryptUpdate() or
> C_DecryptUpdate(), so the flag can't really be cached.
Again, this is easier to explain with code. I am suggesting -
#define INPLACE_MECHANISM(sessionp) (session_p->encrypt.flags &
CRYPTO_MECHANISM_INPLACE_OK)
and set the CRYPTO_MECHANISM_INPLACE_OK flag
during C_EncryptInit() or if possible earlier. This saves on the
number of comparisons done in the current macro.
-Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/crypto-discuss/attachments/20091102/79b704cc/attachment.html>
