Thanks Steve.
I observe that in the case of decryptAES128 (AES decryption), they
additionally do EVP_DecryptUpdate(..) on padLen as follows. Is this
really required, now that EVP_DecryptInit_ex() is being used ?
837 // RFC 3826 - Section 3.1.4
838 // "The last ciphertext block (whose size r is less than or
839 // equal to 128) is exclusive-ORed with the segment of the r
840 // most significant bits of the last output block to recover
841 // the last plaintext block of r bits."
842 //
843 // The operations on the last block are identical to those
844 // performed on the previous blocks except for the fact that
845 // that the block can be less than the block size. We can
846 // just pad the last block and operate on it as usual and
then
847 // ignore the padding after decrypting.
848
849 u_int padLen = EVP_CIPHER_block_size(evpCipher) -
850 (cipherLen %
EVP_CIPHER_block_size(evpCipher));
851
852
853 // Allocate a buffer the size of the cipher text message
plus padding.
854
855 *plain = NULL;
856 *plainLen = 0;
857
858 try {
859 *plain = new u_char[cipherLen + padLen];
860 } catch (bad_alloc&) {
861 return false;
862 }
864 EVP_CIPHER_CTX cipherCtx;
865
866 EVP_CIPHER_CTX_init(&cipherCtx);
867
868 // By default the OpenSSL EVP_DecryptFinal() function will
strip
869 // off the padding of the decrypted message. It assumes
that the
870 // padding bytes are set to the size of the padding. We do
not
871 // want to assume this, so we turn this functionality off.
872
873 EVP_CIPHER_CTX_set_padding(&cipherCtx, 0);
874
875 if (!EVP_DecryptInit_ex(&cipherCtx,
876 evpCipher, NULL,
877 (u_char
*)usm_itr->get_privkey().data(),
878 privParams.data()))
879 {
880 delete [] *plain;
881 *plain = NULL;
882 return false;
883 }
884
885 if (!EVP_DecryptUpdate(&cipherCtx, *plain, plainLen, cipher,
cipherLen)) {
886 delete [] *plain;
887 *plain = NULL;
888 *plainLen = 0;
889 return false;
890 }
891
892 int blkLen = 0;
893
894 // Act on the padding block if necessary.
895
896 if (padLen) {
897
898 u_char pad[padLen];
899 bzero(pad,sizeof(pad));
900
901 if (!EVP_DecryptUpdate(&cipherCtx,
902 *plain + *plainLen,
903 &blkLen,
904 &pad[0],
905 padLen))
906 {
907 delete [] *plain;
908 *plain = NULL;
909 *plainLen = 0;
910 return false;
911 }
912
913 *plainLen += blkLen;
914 }
915
916 blkLen = 0;
917
918 if (!EVP_DecryptFinal_ex(&cipherCtx, *plain + *plainLen,
&blkLen)) {
919 delete [] *plain;
920 *plain = NULL;
921 *plainLen = 0;
922 return false;
923 }
Regards,
Rakesh
-----Original Message-----
From: Dr. Stephen Henson [mailto:[email protected]]
Sent: Wednesday, June 01, 2011 7:54 PM
To: [email protected]
Subject: Re: EVP_DecryptFinal
On Wed, Jun 01, 2011, Chenchu, Rakesh R wrote:
> Hi Steve,
>
> Also, EVP_DecryptInit_ex() expects a ENGINE *impl
>
> 271 int EVP_DecryptInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER
> *cipher, ENGINE *impl,
> 272 const unsigned char *key, const unsigned char *iv)
> 273 {
>
>
> Should this be set to NULL, irrespective of the engine ID created
during
> snmpuser creation?
>
Unless you want to target a specific ENGINE then NULL should be used
which
will use the default ENGINE.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
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]