On 11/ 5/09 02:42 PM, Dan Anderson wrote: >> On 11/ 5/09 01:59 PM, Dan Anderson wrote: >> ?| I meant root causing the test failures you saw earlier when >> ?| you did - >> ?| ?| ((pPart == pEncryptedPart) || >> ?| ?| ?| (inplace && (pEncryptedPart != NULL) && >> ?| ?| ?| (encrypt_update.eu_encrlen == encrypt_update.eu_datalen)) ? >> ?| ?| ?| ?| ?| ?| ?| ?| CRYPTO_INPLACE_OPERATION : 0; >> ?| The reason to care is that (plaintext_ptr == ciphertext_ptr) >> ?| is a valid PKCS #11 usage and the failures might be from >> ?| a latent bug. >> -Krishna >> > > Krishna, > I thought I'd already mentioned it, but looks like I didn't. The test > failures were legitimate--the tests failed because the length check was not > done (eu-encrlen == eu_datalen). When I added the length check back in the > STC2 tests passed.
I don't want to belabor this point. But, the issue here why the tests failed since it is valid to pass (plaintext_ptr == ciphertext_ptr) with different lengths? My claim is that this points to a problem down in the stack. In any case, this is not something that would impact encrypt(1) performance. Hence my suggestion of filing an RFE to deal with it later. -Krishna > Here's 2 examples of the failure below. > - Dan > > stdout| 1101. AES_ECB (in-line EncryptUpdate(6,10))/(in-line Decrypt(16)) : > stdout| C_EncryptInit took 2010 nsec > stdout| C_EncryptUpdate took 1857 nsecFailed > stdout| Error: Unexpected Output Length > stdout| Test 1101: Failed > stdout| > stdout| 1102. AES_ECB (in-line Encrypt(16))/(in-line DecryptUpdate(10,6)) : > stdout| C_EncryptInit took 1893 nsec > stdout| C_Encrypt took 1410 nsec > stdout| C_DecryptInit took 2202 nsec > stdout| C_DecryptUpdate took 1349 nsecFailed > stdout| Error: Unexpected Output Length > stdout| Test 1102: Failed > . . . > Test_Case_End| 16000 tests/functional/uef_pkcs11/pk11bulktest_test | FAIL | > 18:19:45 > 203755535064718 0 | > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/crypto-discuss/attachments/20091105/0a671404/attachment.html>
