Dear Ger Hobbelt and All,
I should introduce a situation to you.
I use openssl server and client to test with DES-CBC3-SHA.
server show as following:
$ openssl s_server -accept 443 -cert server_cert.pem -CAfile server_ca.pem -cip
her DES-CBC3-SHA
Enter pass phrase for server_cert.pem:
Loading 'screen' into random state - done
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
-----BEGIN SSL SESSION PARAMETERS-----
MHUCAQECAgMBBAIACgQgzaEJiBUiqFiWXT+W7XIP5ARv+G4UuwfKED2Gu4TMKLEE
MDWXUKokAf0it42BTyfP8X08fGfQYnL5SutZKBYQCOJW2rN6H0dLOYZR7oEQXaQB
daEGAgRIjpfBogQCAgEspAYEBAEAAAA=
-----END SSL SESSION PARAMETERS-----
Shared ciphers:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3
-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES
128-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-
EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-
RC4-MD5
CIPHER is DES-CBC3-SHA
ddddd
sssss
client show as following:
[EMAIL PROTECTED] ~]$ openssl s_client -connect 192.10.10.104:443 -cert
client_cert.pem -CAfile client_ca.pem
Enter pass phrase for client_cert.pem:
CONNECTED(00000003)
depth=1 /C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL
PROTECTED]
verify return:1
depth=0 /C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED]
verify return:1
---
Certificate chain
0 s:/C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED]
i:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED]
1 s:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED]
i:/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED]
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDpDCCAw2gAwIBAgIBATANBgkqhkiG9w0BAQQFADCBjjELMAkGA1UEBhMCQ04x
EjAQBgNVBAgTCWd1YW5nZG9uZzERMA8GA1UEBxMIc2hlbnpoZW4xFDASBgNVBAoT
C3NwZWN0cmF0ZWNoMQswCQYDVQQLEwJSRDENMAsGA1UEAxMEcXV6ZjEmMCQGCSqG
SIb3DQEJARYXc3pfcXV6ZkBzcGVjdHJhdGVjaC5jb20wHhcNMDgwNzI0MDMwNTU1
WhcNMDkwNzI0MDMwNTU1WjB7MQswCQYDVQQGEwJDTjESMBAGA1UECBMJZ3Vhbmdk
b25nMRQwEgYDVQQKEwtzcGVjdHJhdGVjaDELMAkGA1UECxMCUkQxDTALBgNVBAMT
BHF1emYxJjAkBgkqhkiG9w0BCQEWF3N6X3F1emZAc3BlY3RyYXRlY2guY29tMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxZxJlk6W+mkBzzMW7E1uz5+du1oV8
dufTuNE4YGM52uWE/6PJOai84VGPx7SWQgFslEpQ5Zso1sAstvN4c+T2Xnw9VgR8
6H1Zy2YM3WT5ca35/K33Qm0wR4o5bdHcePrqbyWoZ7XTm6eW/1IMTBNrxHtywfMX
KaDTVdeMNlPDHwIDAQABo4IBIjCCAR4wCQYDVR0TBAIwADAsBglghkgBhvhCAQ0E
HxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFGGAhawP
CJpMWw5QCvXcmFk6CTXqMIHDBgNVHSMEgbswgbiAFNlmSaexZ1HyCe4KZG1ymGPO
ICx2oYGUpIGRMIGOMQswCQYDVQQGEwJDTjESMBAGA1UECBMJZ3Vhbmdkb25nMREw
DwYDVQQHEwhzaGVuemhlbjEUMBIGA1UEChMLc3BlY3RyYXRlY2gxCzAJBgNVBAsT
AlJEMQ0wCwYDVQQDEwRxdXpmMSYwJAYJKoZIhvcNAQkBFhdzel9xdXpmQHNwZWN0
cmF0ZWNoLmNvbYIJAMpTAf5ipB/0MA0GCSqGSIb3DQEBBAUAA4GBAEnxl5ax3rzW
/oyE086XKuC+NGmzNlstsry8fFPhrA2qjVo4G+6c1nWt/0Cu98stq30u527AjdQK
zcKm+wTK1df2zlCJiXdc8FsvRZ0MQ+1xMkbf8II4hJfUo0AH+w7ub3ebtkbb3q59
/6RfJEOiQ8lKwvqNiKDmH/xY0v30+mBw
-----END CERTIFICATE-----
subject=/C=CN/ST=guangdong/O=spectratech/OU=RD/CN=quzf/[EMAIL PROTECTED]
issuer=/C=CN/ST=guangdong/L=shenzhen/O=spectratech/OU=RD/CN=quzf/[EMAIL
PROTECTED]
---
No client certificate CA names sent
---
SSL handshake has read 2012 bytes and written 332 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DES-CBC3-SHA
Session-ID: CDA109881522A858965D3F96ED720FE4046FF86E14BB07CA103D86BB84CC28B1
Session-ID-ctx:
Master-Key:
359750AA2401FD22B78D814F27CFF17D3C7C67D06272F94AEB5928161008E256DAB37A1F474B398651EE81105DA40175
Key-Arg : None
Krb5 Principal: None
Start Time: 1217303619
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
ddddd
sssss
I use capture software catch the package as following:
Secure Socket Layer
TLSv1 Record Layer: Application Data Protocol: http
Content Type: Application Data (23)
Version: TLS 1.0 (0x0301)
Length: 24
Encrypted Application Data: 83A774CFF8152C3975B7B846076398EC1439672ECE2E1D64
TLSv1 Record Layer: Application Data Protocol: http
Content Type: Application Data (23)
Version: TLS 1.0 (0x0301)
Length: 32
Encrypted Application Data:
7C43BC0F546596DCFEA5C85022615ACEA579A6708BEA7948...
the package include two application data, the first is length=24, I don't know
what the 24 bytes?
My english is not very good. so I can't express my idea very well.
thanks
abc_123_ok
2008-07-29
发件人： Ger Hobbelt
发送时间： 2008-07-28 18:09:11
收件人： openssl-users@openssl.org
抄送：
主题： Re: Re: Re: hello everyone
Couple of things to test/check next:
up to now you've fed it sequences of 8 bytes which, as you report,
decrypt correctly.
See what your current code does for longer input sequences. The point
is this: if your encrypt code encrypts N bytes and you decrypt the
data at the receiver side and those /original/ N bytes show up
anywhere in the decrypted output, it means AT LEAST that your
encrypt/decrypt processes are 'mirrors' like they should be. It also
means the decrypt code uses the same IV as the encrypt code --
assuming there's an IV used AT ALL.
Say you encrypt a sequence
1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ...
then the ENcrypted byte stream should NOT contain this sequence
anywhere (after all, it's encrypted!)
When the receiver fetches this data (which was sent to it) and
DEcrypts it should show one of these DEcrypted data sequences:
a) 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ...
b) abc1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ...
c) 1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ...xyz
or b+c): abc1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ...xyz
When you don't see any of these, your encrypt/decrypt code does not
use the proper keys, IVs, algorithms, whatever. From your previous
messages I gather this is NOT your problem as you get to see the (b),
(c) or (b+c) case instead (which one, I am not sure from reading your
messages).
Case (a): perfect. This is what you'd expect
case (b): this can ONLY happen when encrypt+decrypt produce/process
the _exact_ same encrypted data. (When you use CBC style.)
This means that EITHER you fed the encrypt code a pointer/length
sequence which was wrong as it pointed at the 'abc' instead of '123'
start there, OR somewhere between the output of the DEcrypt and your
debug/display code, you prepend the 'abc' in there AFTER decrypting;
usual suspect in both case: bugs in your own 'pointer arithmetic'
code.
case (c): can happen when EITHER you feed the ENcrypter an input
sequence with an incorrect (too large) length, so random 'xyz' will be
included in the encryption operation, OR as above: length value after
decryption gets modified so the extra 'xyz' at the tail is 'included'
somewhere while passing the decrypted data to the debug/display code.
Usual suspect: incorrect treatment of strings which are assumed to be
NUL-terminated but aren't. Other incorrect length-manipulating
assumptions in your sender/encrypt and/or client/decrypt code. Etc.
A special case which can also cause this is when no length is encoded
in the data feed to the decrypter, which then has to 'guestimate' the
output (decrypted) length, while the encrypter you use 'pads' the data
with zero or random content to ensure block alignment and/or other
algorithm-specific requirements are met. This applies to some
algorithms, not all, IIRC. (Don't ask me for a list off the top of my
head; I don't know them by heart.)
case b+c): mix of b+c; the mere fact that the input sequence
1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ... is visible after decryption
means that at least client and server use matching keys, algorithms
and IVs.
So if any of b/c/b+c applies to your situation, it means you are
either adding those extra header and/or tail bytes yourself before
encrypting or after decrypting.
WARNING: before you say 'yes, this happens here too' TEST with SEVERAL
data sequences of DIFFERENT content AND length. Just to satisfy Mr.
Murphy.
Last but not least, I wonder why you've written this code. I am
probably guessing wrong here, but from what I read in your messages,
you are using an SSL connection between client and server to pass
data. Then it looks to me like you are writing additional symmetric
key encrypt/decrypt code here ON TOP OF THAT. I hope that I am very
wrong about that last bit in capitals; if I am correct about that bit
however, you are applying a dual layer of encryption (as SSL already
encrypts your data too), which introduces all sorts of _very_
interesting (in the sense of raised eyebrows and scratching heads)
questions.
Summarizing:
-------------------
- The exercise may be moot (when used as a second crypto layer on top
of SSL). Chance: I don't know. Very low, I hope. It just might...
- You need to test several different content / length data inputs and
check if they appear 'on the other side' after decrypting the data
there. Find out which case applies to your situation: (a), (b), (c),
(b+c) or (d)=='none of the above'. Probable faults depend on this case
identification.
- My guess from far off: problems are VERY probably caused by your
custom code manipulating pointers and or (unencrypted input) data
length values.
- My guess from far off: problems (when case (c)) MAY be due to the
use of a 'padding' crypto chain, while not storing actual (a.k.a.
'true') input data length in the data stream to be encrypted.
If anyone else reads this and sees a minor or major mistake, please
correct me. Thank you.
Ger
2008/7/28 abc_123_ok <[EMAIL PROTECTED] >:
> I can't fix my problem , anybady can help me?
>
> ________________________________
> abc_123_ok
> 2008-07-28
> ________________________________
> 发件人： abc_123_ok
> 发送时间： 2008-07-25 09:35:17
> 收件人： openssl-users@openssl.org
> 抄送：
> 主题： Re: Re: Re: hello everyone
>
> Dear Victor Duchovni，
>
> I knew what you speak as below,
> I have added the CBC padding and Mac and record head, but besides these len,
> it still have 24 bytes is more. the 24 bytes is before the application
> data.
>
> my problem still can n't be fixed.
>
>
> ________________________________
> abc_123_ok
> 2008-07-25
> ________________________________
> 发件人： Victor Duchovni
> 发送时间： 2008-07-24 22:02:49
> 收件人： openssl-users@openssl.org
> 抄送：
> 主题： Re: Re: Re: hello everyone
>
> On Thu, Jul 24, 2008 at 05:10:54PM +0800, abc_123_ok wrote:
>
> > I want to know what the 24 byte is.
>
> The TLS "record layer" uses a 5 byte header. The actual data
> is extended with a MAC, and encrypted which often adds CBC padding.
>
> You should not make any assumptions about the length of the encrypted
> data on the wire, there may also be packets for renegotiation if the
> client or server chooses to do that.
>
> --
> Viktor.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: [EMAIL PROTECTED]
mobile: +31-6-11 120 978
--------------------------------------------------
:��I"袭��r�m���?(ラ觳Z+�K ?│��1ē�x
��hラ觳[�z?ラ觳Z+�
��f�y意灿�� �f＂�h��)z{,��
