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]
