Hello,
> 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
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 len
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 enc
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()
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
if you use the unsimplefied version of the cryptoapi you have to reverse the
bytes auf your results before using them.
>
>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 funct
