Yup, that solves it. Another matter that's been troubling me is the output that I get when I run the s_server program with the debug option. At the end of the handshake, when the server sends the Finished Packet to the client, the following packet dump is obtained.
write to 099EB570 [099FADC0] (53 bytes => 53 (0x35)) 0000 - 16 03 01 00 30 b8 bd 82-61 05 3c 59 0e 0e cc 0b 0010 - 57 88 ad f2 93 1e 5a 1f -9f d1 82 3a 10 e2 4b d3 0020 - 00 f4 91 7d f1 10 a2 1d-d4 e6 ef 2a c6 be 1e b5 0030 - 16 fd f6 09 71 Byte 0x00 -> 0x16 is indicative of the Handshake protocol in progress. Byte 0x01 and 0x02 -> SSL v.3.1 Byte 0x03 and 0x04 -> Length of message that follows, 48 bytes + the 5 before it, totals to the 53 bytes shown at the very beginning. Byte 0x05 -> This is where the trouble begins. It shows 0xb8 which does not correspond to any standard message type. It should, in my opinion show, 0x14 which is the message type for the Finished packet. I ran the same program a few times I keep getting what appears to me as random bytes each time. When I run the s_server program with both the msg and debug options, the output from the msg tallies with my observation above. I was not sure if the actual packet contents that were being sent as both the msg and debug option seemed to contradict each other. I then wrote a sniffer to check the actual packet contents and they corresponded to those received from debug mode which now leads to me believe this -> That, in the "Finish" packet, the message type, message length and the handshake message are all encrypted. Am I right in thinking so? In which case, I wonder, if the client were to receive such a packet, which coincedentally were to have its Byte 0x05 as some standard message type, will it not proceed to treat that packet correspondingly instead of treating it as a Finished packet? Taking this even further, the whole idea of having 20 as a standard message type for a finished packet would be useless. I realise that the above is a pretty lengthy description of the problem that I am facing and will be more than happy to elaborate on any part of it that is ambigous. I am obviously wrong somewhere and it would be great if someone can point where exactly. Thanks a lot, Vijay K. On Tue, Jun 17, 2008 at 4:53 PM, lakshmi prasanna <[EMAIL PROTECTED]> wrote: > Hi, > > Actually, AES is by default implemented in CBC (Cipher Block Chaining > )mode in TLSv1. Refer RFC 3268. > Since the encryption is done in CBC mode, you will not get the same > encrypted text for identical plain text. > > --lakshmi prasanna > > On Tue, Jun 17, 2008 at 10:58 AM, jimmy bahuleyan > <[EMAIL PROTECTED]> wrote: > > > > Vijay Kotari wrote: > >> > >> @DS > >> Nicely put. > >> > >> So, if I was to try to decrypt/encrypt one of these messages, I would > need the key and the iv and something else? Because if just the key and iv > are sufficient to encrypt/decrypt the data, then how are the different > encrypted messages generated for the same cleartext? > >> > > > > http://en.wikipedia.org/wiki/Cipher_block_chaining > > > > -jb > > -- > > Real computer scientists don't comment their code. The identifiers are > > so long they can't afford the disk space. > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List openssl-users@openssl.org > > Automated List Manager [EMAIL PROTECTED] > > > > -- > thanks, > Lakshmi Prasanna > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
