Hi Dave, To add to what I said previously, It looks like EVP_DecryptUpdate() is dropping the last block here, (n==8) case.
cipherLen is 56 plainLen is 48 (After call to EVP_DecryptUpdate()) Regards, Rakesh -----Original Message----- From: Chenchu, Rakesh R Sent: Wednesday, June 01, 2011 1:18 PM To: [email protected] Cc: Mulchandani, Vasudev; Dussa, Suresh; Koripella, Srinivas; Subhash Sankuratripati Subject: RE: EVP_DecryptFinal Hi Dave, Thanks for the response. The OID I passed was: .1.3.6.1.4.1.789.1.25.1.1 or Something like this: snmpwalk -v3 -l authPriv -u snmpsha -a SHA -A otci1234 -x DES -X otci1234 10.72.43.201 .1.3.6.1.4.1.789.1.5.8.1.1 (It just displays the first entry of all rows). For USM user, it happens as follows: decryptMsg(pkt, usm_itr, msgPrivParams) calls -> decryptxDES The function decryptxDES() calls EVP_DecryptFinal as follows: snmpV3SecModel::decryptxDES(...) { ...... // Allocate a buffer the size of the cipher text message. *plain = NULL; *plainLen = 0; try { *plain = new u_char[cipherLen]; } catch (bad_alloc&) { return false; } EVP_CIPHER_CTX cipherCtx; EVP_CIPHER_CTX_init(&cipherCtx); // By default the OpenSSL EVP_DecryptFinal() function will strip // off the padding of the decrypted message. It assumes that the // padding bytes are set to the size of the padding. We do not // want to assume this, so we turn this functionality off. The // padding is left intact and ignored by message processing. EVP_CIPHER_CTX_set_padding(&cipherCtx, 0); if (!EVP_DecryptInit(&cipherCtx, evpCipher, (u_char *)usm_itr->get_privkey().data(), &iv[0])) { delete [] *plain; *plain = NULL; return false; } if (!EVP_DecryptUpdate(&cipherCtx, *plain, plainLen, cipher, cipherLen)) { delete [] *plain; *plain = NULL; *plainLen = 0; return false; } int finalBlkLen = 0; if (!EVP_DecryptFinal(&cipherCtx, *plain + *plainLen, &finalBlkLen)) { <---- fails here delete [] *plain; *plain = NULL; *plainLen = 0; return false; } } Below is the instrumentation details for failure case: snmpwalk -t 100 -v3 -l authpriv -u snmpsha -a SHA -A otci1234 -x DES -X otci1234 10.72.181.53 .1.3.6.1.4.1.789.1.25.1.1 cipherLen is 56 plainLen is 48 (After call to EVP_DecryptUpdate()) Regards, Rakesh -----Original Message----- From: Dave Thompson [mailto:[email protected]] Sent: Wednesday, June 01, 2011 2:03 AM To: [email protected] Subject: RE: EVP_DecryptFinal > From: [email protected] On Behalf Of Chenchu, Rakesh R > Sent: Thursday, 26 May, 2011 14:46 > Recently we identified a following issue when snmpwalk is being done on some tables: > The problem is in freebsd crypto function - EVP_DecryptFinal_ex(). > (n == 0) is a valid case for some OIDs. No it's not. When using PKCS5 padding, which is what this is checking (and is the default), 0 is illegal. > I have ... [output before DecryptFinal] <compressed> > Rakesh final:21 1 25 1 1 0 5 0 <---- last byte (n==0) > This is working tables : > Rakesh final:5 0 6 6 6 6 6 6 <---- (n==6) > Your thoughts? That 5,0 is apparently an ASN.1 NULL encoded after your OID (snipped). Thus the 0 is part of the plaintext, not padding. Either the encryptor is not padding correctly for the n=8 (= exact block for DES) case, or something along the path is dropping the last block of ciphertext (which here is all padding). ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
