Re: about the sequence number field
Dear, I have 2 questions about this sequence number in TLS: 1)What is the value of finished's sequence number? It is zero? 2) Is there any command line with OpenSSLto have the MAC? Thank you, -Bdr Swaminathan P wrote: Those were great replies. Thanks Lev and Geoff. Guess I'll have to put more thought into this. Thanks again, swami On Wed, 19 Nov 2003, Geoff Thorpe wrote: On November 19, 2003 07:16 pm, Swaminathan P wrote: I have a question anout the use of sequence number as a part of the input to the hash function during the MAC calculation. Does that security concerns? Would the security aspects of theSSL be affected if the sequence number is not used as a part of the input to the hash funtion for MAC calculation? As Les pointed out, this helps detect replay (or removal) attacks. It also forces the underlying transport to be reliable and ordered, so that the SSL/TLS encapsulation in turn presents what appears to be a reliable and ordered channel to the user of the protocol. For example, it doesn't stop you trying to run SSL/TLS over something like UDP that does not these sorts of guarantees, but this aspect of the SSL/TLS protocol will allow you to detect (in theory) if the packets arrive out of order or don't turn up at all. It will not *recover* from such problems though, so this sequence number trick is simply to verify reliability of the transport, without providing any recovery mechanism if the ordering and reliability assumptions aren't met. But there's two far more fundamental problems with trying to bypass this ordering issue anyway. (1) the ciphering used to en/decrypt the payloads of SSL/TLS records (after the initial handshake has agreed parameters) is typically stateful, so if you get records duplicated, removed, or out-of-order, then en/decryption will start misreading all subsequent records as senseless noise. (2) during a handshake or a renegotiation, the "finished" messages use MAC calculations over *all* the previous handshake messages *in order*. Note that "all" and "in order" mean that if you lose reliability during the handshake or renegotiation phase, you get the SSL/TLS equivalent of a "carrier disconnect" - no amount of sequencing logic in the application protocol will matter as this corruption in the handshake protocol will prevent application protocol data from being exchanged anyway. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES_CBC decryption
Thus spake mohanlal jangir [EMAIL PROTECTED] I was looking into the AES CBC code available at http://openbsd.secsup.org/src/lib/libssl/src/crypto/aes/ For testing this, I wrote small code (attached in mail). The Encryption seems OK but Decryption is failing. I think, I am doing some mistake. Could you please look into the code and give me some hints about decryption. Minor bug: the AES CBC function doesn't correctly handle in==out. Please retry with in!=out. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: AES_CBC decryption
In message [EMAIL PROTECTED] on Fri, 19 Dec 2003 10:49:49 -0600, Stephen Sprunk [EMAIL PROTECTED] said: stephen Thus spake mohanlal jangir [EMAIL PROTECTED] stephen I was looking into the AES CBC code available at stephen http://openbsd.secsup.org/src/lib/libssl/src/crypto/aes/ stephen For testing this, I wrote small code (attached in mail). stephen The Encryption seems OK but Decryption is failing. I think, stephen I am doing some mistake. Could you please look into the stephen code and give me some hints about decryption. stephen stephen Minor bug: the AES CBC function doesn't correctly handle stephen in==out. Is that something you have actually observed, or are you guessing? As far as I can read the code, in==out should be supported, or we would remove some of the memcpy() in there... If what you say is true and reproducable, I'd like to know, because that's a bug that I wish to correct. - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. You don't have to be rich, a $10 donation is appreciated! -- Richard Levitte \ Tunnlandsvägen 3 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: AES_CBC decryption
You have to reinitialize the IV before decryption. Thanks, James -Original Message- From: mohanlal jangir [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 6:45 AM To: [EMAIL PROTECTED] Subject: AES_CBC decryption Hi, I was looking into the AES CBC code available at http://openbsd.secsup.org/src/lib/libssl/src/crypto/aes/ For testing this, I wrote small code (attached in mail). The Encryption seems OK but Decryption is failing. I think, I am doing some mistake. Could you please look into the code and give me some hints about decryption. Regards Mohanlal __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #743] Bug in AES_cbc_encrypt
I was notified today of the existence of this ticket. My appologies for missing it. The patch included in this ticket was applied almost two months ago, so I'm resolving this ticket. [EMAIL PROTECTED] - Fri Oct 24 09:29:09 2003]: The function AES_cbc_encrypt has a bug when its input and output parameters are the same which causes it to incorrectly update the IV. All other OpenSSL ..._cbc_encrypt functions happily accept input==output, I don't see a valid reason why AES would be the exception. The attached patch fixes the problem, but a revisitation of the AES CBC functions may be in order in order to optimise (I'm sure it's got to be possible to encrypt/decrypt without memcpying so much) -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com -- Richard Levitte [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
PEM manual page error
The PEM(3) manual page specifies a way to read a certificate in PEM format
from a BIO:
=== cut ===
Although the PEM routines take several arguments in almost
all applications most of them are set to 0 or NULL.
Read a certificate in PEM format from a BIO:
X509 *x;
x = PEM_read_bio(bp, NULL, 0, NULL);
if (x == NULL)
{
/* Error */
}
=== cut ===
It is erroneous and misleading because
1. There is no PEM_read_bio() function described in that manual page.
2. The actual PEM_read_bio() declaration is
int PEM_read_bio(BIO *bp, char **name, char **header, unsigned char **data,
long *len);
which does not have the semantics compatible with the usage case wshown
in the manual page.
Surprisingly though, if there is no -BEGIN sequence in the provided
BIO pointer bp, the PEM_read_bio() _will_ return 0, and x==NULL will be
evaluated to true. Hovewer, if bp contains the valid PEM data, the program
will just crash because of unchecked
*name=nameB-data;
in the PEM_read_bio() implementation.
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
EVP_CipherUpdate usage is incorrect in EVP_EncryptInit(3)
The manual page on EVP_EncryptInit contains the incorrect usage case for
EVP_CipherUpdate.
If EVP_CipherUpdate() fails, the caller is still supposed to invoke a
EVP_CIPHER_CTX_cleanup() function. In this example taken from the manual
page, the function just returns with 0 error code right when the
EVP_CipherUpdate fails without doing so.
=== cut ===
EVP_CipherInit_ex(ctx, NULL, NULL, key, iv, do_encrypt);
for(;;)
{
inlen = fread(inbuf, 1, 1024, in);
if(inlen = 0) break;
if(!EVP_CipherUpdate(ctx, outbuf, outlen, inbuf,
inlen)
)
{
/* Error */
return 0;
}
fwrite(outbuf, 1, outlen, out);
}
if(!EVP_CipherFinal_ex(ctx, outbuf, outlen))
{
/* Error */
return 0;
}
fwrite(outbuf, 1, outlen, out);
EVP_CIPHER_CTX_cleanup(ctx);
return 1;
}
=== cut ===
--
Lev Walkin
[EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
