Re: Re: hello everyone

[abc_123_ok]

Dear Kyle Hamilton and All,

The client receive the data properly and The server receive the data properly.
I have added padding at the behind of the data. len of the data mode 8 equal 0.
code is as following:
static void packApplicationData(DBUF_T *msgptr)
{

  BYTE *ptr = dbuf_top(msgptr);
  DWORD len;            //  = msgptr->len + 16;
  //DWORD out_msglen;
  /*   int count; */

  len = msgptr->len + macLen;

  memmove(ptr + 5, ptr, msgptr->len);
  memmove(ptr,  header, 5);

  calcClientMAC(ptr + msgptr->len + 5, 0x17, ptr + 5, msgptr->len);

  //QZF add 3DES encrypted algorthim. 2008-6-24
  switch (sslContext[0].cipherSuite)
  {
  case SSL_RSA_WITH_RC4_128_SHA:
  case SSL_RSA_WITH_RC4_128_MD5:
    os_rc4_crypt(&sslContext[0].eARC4, ptr + 5, len);
    
    break;
  case SSL_RSA_WITH_3DES_EDE_CBC_SHA:
    {
   int  padlen,i;
   BYTE * msg;
   msg = ptr + 5;
  
   padlen = 8 - ( len + 1 ) % 8;
   if( padlen == 8 )
     padlen = 0;
   
   for( i = 0; i <= padlen; i++ )
     msg[len + i] = (unsigned char) padlen;
   
   len += padlen + 1;

   des3_crypt_cbc((des3_context *)sslContext[0].key_material->ctx_enc,
                   DES_ENCRYPT, 
                   len,
                   sslContext[0].key_material->iv_enc, 
                   ptr + 5, 
                   ptr + 5 );
    }
    
    break;
  case SSL_RSA_WITH_NULL_SHA:
    break;
  default:
    os_disp_puts("cipher suit error");
    break;
  }

  ptr[2] = 0x00; //(len >> 16) & 0x00FF;
  ptr[3] = (len >>  8) & 0x00FF;
  ptr[4] = (len      ) & 0x00FF;

  msgptr->len = len + 5;//len + 5;
}

Do you mention initialization vector is IV of 3DES algorithm for CBC?
My 3DES algorithm contain IV to CBC.

the handshake can build normally.

I don't know I have problem like this.

Thanks.
Best Regards.




abc_123_ok
2008-07-23



发件人： Kyle Hamilton
发送时间： 2008-07-23 10:06:44
收件人： openssl-users@openssl.org
抄送： 
主题： Re: hello everyone

Does the client receive the data properly?
Does the server receive the data properly?

You may have padding going on, you may have an initialization vector
being preset, you may have a whole bunch of things going on under the
hood.  As long as both the client and the server agree on what's going
on and what to interpret data as, there's no problems.

There have been some obfuscations made to help prevent CBC attacks, as
well (please see the TLS v1.0 and TLS v1.1 RFCs for references on what
the attacks are and why these obfuscations are necessary to defeat
them).

-Kyle H

2008/7/22 abc_123_ok  <[EMAIL PROTECTED] >:
> Dear All，
>
> I use openssl as a server to test SSL client of our comany.  the SSL client
> is a part of embedded system。
> I used command as blow in Cygwin.
>
>
> openssl s_server -accept 443 -cert testserver.pem -CAfile spectra_ca.pem
> -cipher DES-CBC3-SHA
>
> Loading 'screen' into random state - done
> Using default temp DH parameters
> Using default temp ECDH parameters
> ACCEPT
>
> bad gethostbyaddr
> -----BEGIN SSL SESSION PARAMETERS-----
> MHUCAQECAgMABAIACgQg7anPBHTC6jqWwBj/K5J8N4aJtFvBvvo/Cc/8IadX57gE
> MPFpEU9fWppV85v9f4oGy5Q7eVAXqb4QGfbQ3CaHlbw9/laI6yDDWncvGJxHAo9U
> oqEGAgRIhahuogQCAgEspAYEBAEAAAA=
> -----END SSL SESSION PARAMETERS-----
> Shared ciphers:RC4-MD5:RC4-SHA:DES-CBC3-SHA:NULL-SHA
> CIPHER is DES-CBC3-SHA
> 11111111
>
> I send "1111111111" to client from server.
> but I find a problem from capture software.
>
> I see two application data sent to the client.
> the first , it is 24 bytes. the second, it is 32 bytes. I decrypted these
> data , I find the , the first 8 bytes is wrong in 32 bytes.
>
> I don't understand why it have a 24 bytes application. the other, why the
> first 8 bytes
> is wrong in 32 bytes?
>
> who can help me?
>
> thanks a lot.
> best regards.
>
> ________________________________
> abc_123_ok
> 2008-07-22
:??I"???????ì(?鬲Z+?K?+??????x
???鬲[?z?(?鬲Z+?
??f?y??????f???h??)z{,??