[Mono-list] TripleDES encryption problem

[Carlos Guzman Alvarez]

Hello:

> Well this isn't the structure described in rfc2246. You may not be
> encrypting the right structure!
> But I'm unsure why you are encrypting this. What are you using as the TLS
> specification ?

The RFC, see this:

        block-ciphered struct {
            opaque content[TLSCompressed.length];
            opaque MAC[CipherSpec.hash_size];
            uint8 padding[GenericBlockCipher.padding_length];
            uint8 padding_length;
        } GenericBlockCipher;


As i don't use compression, as i tell before i'm encrypting fragment +
mac + padding length:

content 	-> fragment
MAC		-> MAC
padding		-> padding
padding_length 	-> padding length

How the padding length has the same value as each byte on the padding i
think this is correct on decryption you have (i'm not using PKCS7 for this):

	fragment + mac + padding + padding length

> Yeah this is all true, PKCS#7 pads using the number of unused bytes as the
> padding value. You can see this in your previous sample when you had 7 times
> 0x07 decoded by OpenSSL - so Mono got the PKCS#7 padding right.

I think that mono is not making the correct padding, in windows using
ms.net openssl decodes the padding as 03 03 03.

Here is an example of the output of OpenSSL on Windows using MS.NET (for 
the Client Finished message too):

tls1_enc(0)
EVP_Cipher(ds=00A11E50,rec->data=00A032F5,rec->input=00A032F5,l=40) ==>
	EVP_CIPHER_CTX: 0 buf_len, 24 key_len [8 128], 8 iv_len
		IV: 78E0DF8C36464C10
	rec->input= be 81 66 bc 99 0c 15 aa f8 1d 22 59 ae f7 9e b8 c1 1d 53 da 
c4 94 6e b4 c9 d8 a2 2a 50 4f 7e a1 0a 25 81 a4 52 7e 6a d7
des_ede_cbc_cipher(ctx=a11e50, buflen=0)
	 iv= 78E0DF8C36464C10
	rec->data= 14 00 00 0c e9 7a 9f 6c 69 af 83 00 90 d6 92 9e c2 08 6c e4 
4f 20 2f 2b 14 ab 4f 3e 02 1b 51 97 e6 db 70 18 03 03 03 03
dec 36
14 00 00 0C E9 7A 9F 6C 69 AF 83 00 90 D6 92 9E
C2 08 6C E4 4F 20 2F 2B 14 AB 4F 3E 02 1B 51 97
E6 DB 70 18

> But this ISN'T the behaviour described in rfc2246 in section 6.2.3.2. If you
> check the included example (page 20) you'll see that the last 8 bytes are xx
> 06 06 06 06 06 06 06 (7 times 0x06) which ISN'T a standard PKCS#7 padding
> but consistent with the pseudo-code GenericBlockCipher structure.

I think the last 7 bytes byte of the example are (in the RFC the example 
shows an 8 byte as xx that is the last byte of the MAC if understand well):

Padding		: 06 06 06 06 06 06
Padding length	: 06

I think that as i making the encryption, PKCS7 padding matches perfectly
to what i need :) , for this example i need that mono or ms.net
adds only 6 bytes for padding because the last byte is added by me ;).



-- 
Best regards

Carlos Guzmán Álvarez
Vigo-Spain