md5_hash[16];
sha_hash[20];
padding bytes[length of padding bytes]
length of padding bytes.
All of those padding bytes will be the same... and since its doubtful the client finished message will be EXACTLY 64 bytes and also since the final byte I've gotten has been pretty high, I can assume the decryption failed. I think today, I'll mess around and hack the s_client source so I can have it dump the actual keys and then I'll be able to determine exactly where my problem lies.
Do you know what the difference between the AES_set_encrypt_key and AES_set_decrypt key is? I mean conceptually, obviously they're used for different things, but do you know how they alter the AESKEY struct conceptually? Should I have 4 AESKEY structs for each key, scheduled each way? Can I use EVP to transparently handle all this or will that just lead to more confusion and more possible places for errors?
- Peter On Nov 29, 2004, at 1:45 AM, Richard Levitte - VMS Whacker wrote:
In message <[EMAIL PROTECTED]> on Sun, 28 Nov 2004 23:16:47 -0500, Peter <[EMAIL PROTECTED]> said:
peterius> I've managed to get calculate the proper peterius> "master_secret" or "master_key" for an (I think) SSLv3 peterius> connection and have double checked it with "openssl peterius> s_client". My problem is that I cannot seem to decrypt the peterius> AES encrypted client finished message. The last bytes are peterius> all different instead of all the same as they would be if peterius> they had properly been decrypted and were the padding bytes.
What's the length of the message? Do those last bytes correspond to the encrypted text in some way, or does it seem to be entirely random?
peterius> I'm sort of stumped, and I was wondering a little what peterius> the difference between AES_set_encrypt_key and peterius> AES_set_decrypt_key was, I've tried all combinations though. peterius> I'm using TLS_CK_RSA_WITH_AES_256_SHA incidentally.
AES_set_encrypt_key sets up a key schedule to be used for encryption. AES_set_decrypt_key sets up a key schedule to be used for decryption. Mixing them up never leads to any good results.
peterius> I'm assuming this is a non exportable algorithm
Pardon me? AES is Rijndael, which was invented in Europe (Belgium, IIRC). With that, are you still going to worry about "non exportable"? Either way, the non exportability of ciphers from the US was lifted in 2000 (IIRC).
peterius> and I copy initialization vectors bytes (size 16) right peterius> after I get the 32 byte keys right after I get the 16 byte peterius> MAC_secrets. If I could, I would alter the s_client code to peterius> print out the AES keys and IVs its using so I could double peterius> check that, but I'm using an openssl windows binary for the peterius> s_client and don't really have that setup. If anyone has peterius> any thoughts, that would be great.
Do you have a Unix box with a build environment to play with? In that case, nothing stops you from running your tests from it instead, and to fiddle with the source to boot.
Cheers, Richard
----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details.
-- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/
"When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
