Re: bad decrypt in EVP_CipherFinal_ex
Jorge Fernandez-3 wrote: Make sure you use the same iv that you used when encrypting. You should make a copy of the iv vector, since the encrypting process overwrites the buffer of the iv that you pass. Hi! I wonder why my buffer of iv is overwritten. What can I use it for? If the overwritten iv is useless, why doesn't the library make a clone of it for its own purposes? I am not sure about overwriting the iv by encrypting process (EVP_EncryptInit() accepts pointer to const), but EVP_BytesToKey() does it. Thanks in advance. -- View this message in context: http://www.nabble.com/bad-decrypt-in-EVP_CipherFinal_ex-tf4718597.html#a13583302 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: DES3: Windows CryptoAPI and OpenSSL
As you said, CryptDeriveKey() has some specific indeed :) If it obtains a
key (from the hash object) with a smaller length than required, then it
applies some extra steps to derive the key.
http://msdn2.microsoft.com/en-us/library/aa379916.aspx wrote:
Let n be the required derived key length, in bytes. The derived key is the
first n bytes of the hash value after the hash computation has been
completed by CryptDeriveKey. If the required key length is longer than the
hash value, the key is derived as follows:
1. Form a 64-byte buffer by repeating the constant 0x36 64 times. Let k
be the length of the hash value that is represented by the input parameter
hBaseData. Set the first k bytes of the buffer to the result of an XOR
operation of the first k bytes of the buffer with the hash value that is
represented by the input parameter hBaseData.
2. Form a 64-byte buffer by repeating the constant 0x5C 64 times. Set
the first k bytes of the buffer to the result of an XOR operation of the
first k bytes of the buffer with the hash value that is represented by the
input parameter hBaseData.
3. Hash the result of step 1 by using the same hash algorithm as that
used to compute the hash value that is represented by the hBaseData
parameter.
4. Hash the result of step 2 by using the same hash algorithm as that
used to compute the hash value that is represented by the hBaseData
parameter.
5. Concatenate the result of step 3 with the result of step 4.
6. Use the first n bytes of the result of step 5 as the derived key.
Actually, the first 16 bytes of the key, produced by EVP_BytesToKey() are
equal to hash value of CryptoAPI hash object after CryptDeriveKey() returns.
So, the following simple function must produce the same derived key as
CryptDeriveKey() does.
Here keyOpenSSL raw is identical to hash object value and its length in my
case is 16 bytes.
int Win32DeriveKey(const unsigned char* keyOpenSSL, unsigned long
lenOpenSSL/*=16*/,
unsigned char* keyWin32, unsigned long lenWin32)
{
unsigned char buf1[64];
unsigned char buf2[64];
std::fill_n(buf1, _countof(buf1), 0x36);
std::fill_n(buf2, _countof(buf2), 0x5C);
for (unsigned long i = 0; i lenOpenSSL; ++i) {
buf1[i] ^= keyOpenSSL[i];
buf2[i] ^= keyOpenSSL[i];
}
unsigned char bufmd5[2 * MD5_DIGEST_LENGTH];
MD5(buf1, _countof(buf1), bufmd5);
MD5(buf2, _countof(buf2), bufmd5 + MD5_DIGEST_LENGTH);
memcpy(keyWin32, bufmd5, std::min(_countof(bufmd5), lenWin32));
return 1;
}
The results are amazing to me.
CryptoAPI derived key
ca ee 31 f5 5e d5 65 00 e9 60 c2 eb 79 58 68 b8 b6 fd d5 26 8d 3c 21 f7
cb ef 31 f4 5e d5 64 01 e9 61 c2 ea 79 58 68 b9 b6 fd d5 26 8c 3d 20 f7
keyWin32 value
As you can see, these keys are a little bit equal. :)
But... the 3DES-ciphers are equal!
What does it mean? Why do 3DES algorithm of CryptoAPI and 3DES algorithm of
OpenSSL produce the same cipher by different keys? :confused:
Dr. Stephen Henson wrote:
On Thu, Oct 25, 2007, MaxAndr wrote:
Kiefer, Sascha wrote:
if you use the unsimplefied version of the cryptoapi you have to
reverse
the bytes auf your results before using them.
I'm not sure that the translation is correct at all. Since the derived
keys
and the encrypted data are completely different.
If EVP_BytesToKey() gives not appropriable key then may be I should try
some
other functions. I have read about
http://www.openssl.org/docs/crypto/EVP_BytesToKey.html EVP_BytesToKey()
that
Newer applications should use more standard algorithms such as PKCS#5
v2.0
for key derivation.
Which of them should I use?
None of them. CryptDeriveKey() doesn't have a direct equivalent in OpenSSL
for
3DES keys.
I can't remember the details but CryptDeriveKey() does something different
when the message digest doesn't provide enough keying material. Do a
search on
the web somewhere.
EVP_BytesToKey() does non standard things too in such circumstances which
is
why things like PKCS#5 v2.0 are recommended for new applications.
However that wont help with your case.
You have several options.
One is to use the exponent of one hack in CryptoAPI to use a raw key (see
MS
knowledge base).
Alternatively you can write an implementation of CryptDeriveKey() based on
OpenSSL functions (digests).
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
View this message
DES3: Windows CryptoAPI and OpenSSL
Hi!
I am trying to convert my code of 3DES encoding from Windows CryptoAPI to
OpenSSL. Could you verify the code attached and may be point me to
appropriate OpenSSL functions?
/
// Windows CryptoAPI// OpenSSL
//
HCRYPTPROV hProv; //
CryptAcquireContext(hProv, NULL, //
MS_ENHANCED_PROV, PROV_RSA_FULL,//
CRYPT_VERIFYCONTEXT)); //
//
HCRYPTHASH hHash; //
CryptCreateHash(hProv, CALG_MD5, 0, 0, hHash);//
//
unsigned char *user_key, ukeyl; //
CryptHashData(hHash, user_key, ukeyl, 0); //
//
//
// 192-bit or 24-byte key length // unsigned
char *user_key, user_key_len;
const unsigned int derived_key_len = 0xC0 0x10; // unsigned char
*derived_key, derived_key_len;
//
unsigned char *iv = NULL;
HCRYPTKEY hKey;//
CryptDeriveKey(hProv, CALG_3DES, // derived_key_len
= EVP_BytesToKey(
hHash, derived_key_len, hKey);//
EVP_des_ede3_cbc(), EVP_md5(), NULL,
//
user_key, user_key_len, 1,
//
derived_key, iv);
//
//
EVP_CIPHER_CTX ctx = {};
//
EVP_EncryptInit(ctx,
//
EVP_des_ede3_cbc(), derived_key, iv);
//
const unsigned char* text;// const
unsigned char* text;
int encoded_len; //
unsigned char* encoded;
bool FinalBlock = false; // int
text_len, encoded_len;
//
CryptEncrypt(hKey, 0, FinalBlock, 0,//
EVP_EncryptUpdate(ctx,
text, encoded_len, 1024); // encoded,
encoded_len, text, text_len);
//
FinalBlock = true; //
CryptEncrypt(hKey, 0, FinalBlock, 0,//
EVP_EncryptFinal_ex(ctx,
text, encoded_len, 1024);//encoded
+
encoded_len, NULL);
--
View this message in context:
http://www.nabble.com/DES3%3A-Windows-CryptoAPI-and-OpenSSL-tf4689809.html#a13403663
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: DES3: Windows CryptoAPI and OpenSSL
The text is completely unreadable in some email readers. Please, read the message on the web http://www.nabble.com/DES3%3A-Windows-CryptoAPI-and-OpenSSL-tf4689809.html http://www.nabble.com/DES3%3A-Windows-CryptoAPI-and-OpenSSL-tf4689809.html or find the file attached http://www.nabble.com/file/p13403962/CryptoAPI2OpenSSL.cpp CryptoAPI2OpenSSL.cpp -- View this message in context: http://www.nabble.com/DES3%3A-Windows-CryptoAPI-and-OpenSSL-tf4689809.html#a13403962 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: DES3: Windows CryptoAPI and OpenSSL
Kiefer, Sascha wrote:
if you use the unsimplefied version of the cryptoapi you have to reverse
the bytes auf your results before using them.
I'm not sure that the translation is correct at all. Since the derived keys
and the encrypted data are completely different.
If EVP_BytesToKey() gives not appropriable key then may be I should try some
other functions. I have read about
http://www.openssl.org/docs/crypto/EVP_BytesToKey.html EVP_BytesToKey()
that
Newer applications should use more standard algorithms such as PKCS#5 v2.0
for key derivation.
Which of them should I use?
Would it be helpful if I show my runnable sources of 3DES encoding with
CryptoAPI and OpenSSL?
Kiefer, Sascha wrote:
Hi!
I am trying to convert my code of 3DES encoding from Windows CryptoAPI to
OpenSSL. Could you verify the code attached and may be point me to
appropriate OpenSSL functions?
/
// Windows CryptoAPI// OpenSSL
//
HCRYPTPROV hProv; //
CryptAcquireContext(hProv, NULL, //
MS_ENHANCED_PROV, PROV_RSA_FULL,//
CRYPT_VERIFYCONTEXT)); //
//
HCRYPTHASH hHash; //
CryptCreateHash(hProv, CALG_MD5, 0, 0, hHash);//
//
unsigned char *user_key, ukeyl; //
CryptHashData(hHash, user_key, ukeyl, 0); //
//
//
// 192-bit or 24-byte key length // unsigned
char *user_key, user_key_len;
const unsigned int derived_key_len = 0xC0 0x10; // unsigned char
*derived_key, derived_key_len;
//
unsigned char *iv = NULL;
HCRYPTKEY hKey;//
CryptDeriveKey(hProv, CALG_3DES, //
derived_key_len
= EVP_BytesToKey(
hHash, derived_key_len, hKey);//
EVP_des_ede3_cbc(), EVP_md5(), NULL,
//
user_key, user_key_len, 1,
//
derived_key, iv);
//
//
EVP_CIPHER_CTX ctx = {};
//
EVP_EncryptInit(ctx,
//
EVP_des_ede3_cbc(), derived_key, iv);
//
const unsigned char* text;// const
unsigned char* text;
int encoded_len; //
unsigned char* encoded;
bool FinalBlock = false; // int
text_len, encoded_len;
//
CryptEncrypt(hKey, 0, FinalBlock, 0,//
EVP_EncryptUpdate(ctx,
text, encoded_len, 1024); // encoded,
encoded_len, text, text_len);
//
FinalBlock = true; //
CryptEncrypt(hKey, 0, FinalBlock, 0,//
EVP_EncryptFinal_ex(ctx,
text, encoded_len, 1024);//encoded
+
encoded_len, NULL);
--
View this message in context:
http://www.nabble.com/DES3%3A-Windows-CryptoAPI-and-OpenSSL-tf4689809.html#a134
03663
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/DES3%3A-Windows-CryptoAPI-and-OpenSSL-tf4689809.html#a13409345
Sent from the OpenSSL - User mailing list
Re: OpenSSL 0.9.8f Win32 Compile Error
Alex Pokotilo wrote: I used following instruction to build the release(I used MSVC 2005 but I think it will work with 2003 too). 1) Create build.bat with following content: @echo off rem the following path point to your MSVC 2005 or 2003 call E:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat IF %1% == build ( if not exist ..\ssl_compile md ..\ssl_compile perl Configure VC-WIN32 --prefix=..\ssl_compile call ms\do_ms copy /y ntdll.mak ms\ntdll.mak nmake -f ms\ntdll.mak exit /B 0 ) IF %1% == test ( nmake -f ms\ntdll.mak test exit /B 0 ) IF %1% == install ( nmake -f ms\ntdll.mak install exit /B 0 ) echo wrong parameter exit 2) change path to Visual studio installation. In my example it is E:\Program Files\Microsoft Visual Studio 8\VC\bin\vcvars32.bat 3) copy build.bat to the release root directory 4) start build.bat build. 5) when build failed go to ms directory and copy ntdll.mak to the release root directory 6) open ntdll.mak(in the root directory) go to 19th line and delete /Wx option. 7) start build.bat build again. After successfully build you can run either build test or build install Best Regards Alex Pokotilo As well as Chris Clark, I'm trying to compile version 0.9.8f for Windows, but I'm using VS2005 SP1. I've done all the steps you've recommended, but I still have some errors like this cl /Fotmp32dll\uplink.obj -Iinc32 -Itmp32dll /I D:\Program Files\Microsoft Visual Studio 8\VC\include /I D:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\Include /MD /Ox /O2 /Ob2 /W3 /Gs0 /GF /Gy /nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_USE_APPLINK -I. /Fdout32dll -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_TLSEXT -DOPENSSL_NO_KRB5 -DOPENSSL_NO_DYNAMIC_ENGINE -D_WINDLL -c ms\uplink.c uplink.c D:\Program Files\Microsoft Visual Studio 8\VC\include\crtdefs.h(556) : error C2485: 'deprecated' : unrecognized extended attribute D:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(69) : warning C4003: not enough actual parameters for macro '__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_EX' D:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(69) : error C2169: '_strset' : intrinsic function, cannot be defined D:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(69) : error C2143: syntax error : missing ')' before '*' D:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(69) : error C2082: redefinition of formal parameter '_strset_s' D:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(69) : error C2143: syntax error : missing ';' before '*' D:\Program Files\Microsoft Visual Studio 8\VC\include\string.h(69) : error C2059: syntax error : ')' ms\uplink.c(44) : error C2063: 'strcpy' : not a function The total number of errors/warnings is 78. Could you or somebody else tell me what I should do to fix the flaw? I hope that my problem is rather simple since I'm beginner at OpenSSL. -- View this message in context: http://www.nabble.com/OpenSSL-0.9.8f-Win32-Compile-Error-tf4616108.html#a13382152 Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
