Avinash Agarwal wrote:
Hello dragos,
I think you are referring to the problem with decrypting/encrypting the TLS app data...I faced the problem but i was finally successful in
decrypting/encrypting the TLS app data...
However my question pertained to generation of the MAC data to verify a message.
say i need to send this data "0x01 0x07 0x00 0x05 0x01" in the TLS app data. To send this I also need to create a MAC. Assuming I'm implementing a server..I use the server_auth_key and HMAC_MD5 as my MAC algo. To generate the MAC I do the following
Key for HMAC_MD5 = server_auth_key
Input msg to MAC algorithm { seq no = 0x00 (8bytes) Type = 0x23 (application data) version = 0x0301 Length = 0x05 Data = 0x01 0x07 0x00 0x05 0x01 }
The MAC generated from the above does not match ..what the client generates for verification. this is the same case when i try to generate a MAC on the server for any msg recieved from the client.
I'm stuck in the MAC generation part. Can someone help me out ?
Regards, Avinash
-----Original Message----- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 9/16/04 10:38 AM Subject: RE: TLS application data MAC
Hi Arvinash,
I think you have now exactly the same kind of problem I had when I implemented the client: the first TLS app data message the client was sending to the server (after FINISHED messages) couldn't be decoded correctly by the the server; this behaviour was caused by the fact that I was using the same iv (initialization vector) for all the records send by the client (I was using 3DES cipher for symmetric encryption).
Please check this thing on your code...I have a feeling that this might be your problem.
If this is indeed the problem, can be solved according to the RFC's 6.2.3.2 paragraph:
....................................... Note: With block ciphers in CBC mode (Cipher Block Chaining) the initialization vector (IV) for the first record is generated with the other keys and secrets when the security parameters are set. The IV for subsequent records is the last ciphertext block from the previous record. ......................................
So for each new app data record (after FINISHED message) you want to encrypt/decrypt, the IV will change (is the last ciphertext block from the previous record).
For stream ciphers (like RC4), the trick is different: this time there's no IV, but you have to keep cipher context between records.
Also keep in mind this is only for TLS 1.0; TLS 1.1 (still a draft) have a different way to compute IV.
Let me know if this solves your problem.
Dragos
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
