Re: ifdef OPENSSL_NO_COMP
On Mon, Dec 20, 2010 at 07:21:54PM -0500, Bhola Ray wrote: > I have noticed the above flag in our openssl code in several c and h files. > > If I use > > #define OPENSSL_NO_COMP 1 > > in the right include file, and build the libcrypto.a and libssl.a > then in that build > Do not do this by hand. > Is it correct, can anyone comment on that...thanks in advance. Example: ./Configure no-zlib no-krb5 no-rc5 no-idea threads shared linux-x86_64 make depend make The "no-zlib" flag disables compression at compile time. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Pls some basic c code to generate key pair using openssl
Hi,
Here are the basic calls needed to generate an ECC key (this example
uses NSA Suite B curve P-256) :
int curveId = OBJ_sn2nid("prime256v1");
EC_GROUP* pGroup = EC_GROUP_new_by_curve_name(curveId);
EC_KEY* pKey = EC_KEY_new();
EC_KEY_set_group(pKey, pGroup);
EC_KEY_generate_key(pKey));
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
On 12/19/2010 8:47 AM, akdin wrote:
I am a new user of openssl. If anybody post basic C code to generate ecc key
pairsusing openssl it will give me an insight to produce further .
Ur help will be highly appreciable.,
regards
akdin
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: ifdef OPENSSL_NO_COMP
On Mon, Dec 20, 2010, Bhola Ray wrote: > I have noticed the above flag in our openssl code in several c and h files. > > If I use > > #define OPENSSL_NO_COMP 1 > > in the right include file, and build the libcrypto.a and libssl.a > then in that build > > there would be No Compression. > > Is it correct, can anyone comment on that...thanks in advance. > You don't actually need to specify that: no compression is the default. Compression is enabled if you include the appropriate zlib options. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ifdef OPENSSL_NO_COMP
I have noticed the above flag in our openssl code in several c and h files. If I use #define OPENSSL_NO_COMP 1 in the right include file, and build the libcrypto.a and libssl.a then in that build there would be No Compression. Is it correct, can anyone comment on that...thanks in advance. Regards, bhola
FIPS 1.2.2 out range of signed 32bit displacement
I just grabbed the openssl-fips-1.2.2 archive from the site and ran into an error. System: > cat /etc/SuSE-release SUSE Linux Enterprise Desktop 11 (x86_64) VERSION = 11 PATCHLEVEL = 1 > ./config fipscanisterbuild > make gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -c -o md5-x86_64.o md5-x86_64.s md5-x86_64.s: Assembler messages: md5-x86_64.s:41: Error: 0xd76aa478 out range of signed 32bit displacement md5-x86_64.s:50: Error: 0xe8c7b756 out range of signed 32bit displacement md5-x86_64.s:68: Error: 0xc1bdceee out range of signed 32bit displacement md5-x86_64.s:77: Error: 0xf57c0faf out range of signed 32bit displacement md5-x86_64.s:95: Error: 0xa8304613 out range of signed 32bit displacement md5-x86_64.s:104: Error: 0xfd469501 out range of signed 32bit displacement md5-x86_64.s:122: Error: 0x8b44f7af out range of signed 32bit displacement md5-x86_64.s:131: Error: 0x5bb1 out range of signed 32bit displacement md5-x86_64.s:140: Error: 0x895cd7be out range of signed 32bit displacement md5-x86_64.s:158: Error: 0xfd987193 out range of signed 32bit displacement md5-x86_64.s:167: Error: 0xa679438e out range of signed 32bit displacement md5-x86_64.s:187: Error: 0xf61e2562 out range of signed 32bit displacement md5-x86_64.s:196: Error: 0xc040b340 out range of signed 32bit displacement md5-x86_64.s:214: Error: 0xe9b6c7aa out range of signed 32bit displacement md5-x86_64.s:223: Error: 0xd62f105d out range of signed 32bit displacement md5-x86_64.s:241: Error: 0xd8a1e681 out range of signed 32bit displacement md5-x86_64.s:250: Error: 0xe7d3fbc8 out range of signed 32bit displacement md5-x86_64.s:268: Error: 0xc33707d6 out range of signed 32bit displacement md5-x86_64.s:277: Error: 0xf4d50d87 out range of signed 32bit displacement md5-x86_64.s:295: Error: 0xa9e3e905 out range of signed 32bit displacement md5-x86_64.s:304: Error: 0xfcefa3f8 out range of signed 32bit displacement md5-x86_64.s:322: Error: 0x8d2a4c8a out range of signed 32bit displacement md5-x86_64.s:332: Error: 0xfffa3942 out range of signed 32bit displacement md5-x86_64.s:340: Error: 0x8771f681 out range of signed 32bit displacement md5-x86_64.s:356: Error: 0xfde5380c out range of signed 32bit displacement md5-x86_64.s:364: Error: 0xa4beea44 out range of signed 32bit displacement md5-x86_64.s:380: Error: 0xf6bb4b60 out range of signed 32bit displacement md5-x86_64.s:388: Error: 0xbebfbc70 out range of signed 32bit displacement md5-x86_64.s:404: Error: 0xeaa127fa out range of signed 32bit displacement md5-x86_64.s:412: Error: 0xd4ef3085 out range of signed 32bit displacement md5-x86_64.s:428: Error: 0xd9d4d039 out range of signed 32bit displacement md5-x86_64.s:436: Error: 0xe6db99e5 out range of signed 32bit displacement md5-x86_64.s:452: Error: 0xc4ac5665 out range of signed 32bit displacement md5-x86_64.s:463: Error: 0xf4292244 out range of signed 32bit displacement md5-x86_64.s:481: Error: 0xab9423a7 out range of signed 32bit displacement md5-x86_64.s:490: Error: 0xfc93a039 out range of signed 32bit displacement md5-x86_64.s:508: Error: 0x8f0ccc92 out range of signed 32bit displacement md5-x86_64.s:517: Error: 0xffeff47d out range of signed 32bit displacement md5-x86_64.s:526: Error: 0x85845dd1 out range of signed 32bit displacement md5-x86_64.s:544: Error: 0xfe2ce6e0 out range of signed 32bit displacement md5-x86_64.s:553: Error: 0xa3014314 out range of signed 32bit displacement md5-x86_64.s:571: Error: 0xf7537e82 out range of signed 32bit displacement md5-x86_64.s:580: Error: 0xbd3af235 out range of signed 32bit displacement md5-x86_64.s:598: Error: 0xeb86d391 out range of signed 32bit displacement make[2]: *** [md5-x86_64.o] Error 1 make[2]: Leaving directory `/home/sprotsman/workspace/openssl-fips-1.2.2/crypto/md5' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/sprotsman/workspace/openssl-fips-1.2.2/crypto' make: *** [build_crypto] Error 1 Any ideas appreciated. Thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Substitute for openssl command
> From: owner-openssl-us...@openssl.org On Behalf Of Rui Francisco
> Sent: Monday, 20 December, 2010 10:07
(Also on -dev, answering -users only, this is not a -dev question.)
> I'm trying to implement the following code to substitute the
> following
> openssl command
>
> openssl dgst -sha1 -sign myKey.pem something.txt | openssl enc -base64
>
> I'm using Delphi and the Opensll lib developed by Marco Ferrante
> (http://www.disi.unige.it/person/FerranteM/delphiopenssl/)
>
> The code is producing the hash
> '6676627A363352673862555A4D69464432376969'
>
> instead of
>
> Am1K5+CP4LDNVDZYvcLYGpnu8/1b+WWkzgoe8sbZhvk6QFzFvNN77Zsq+cHNm5
> 2jCVSEDgWL
> Am1K5+GHgPS1wcT8ZG7w6KgVq+2/VgOU+xKNt0lcC3gouyarZvcZpZclIReDgL
h6m3nv8DYY
> Am1K5+HKAOQc+eCi/BQ4LqUnuJrca+7emgb/kpU=
>
Aside: is that correct? Could you have miscopied that, or it been
corrupted somewhere? I find it *very* unlikely that the same 4+ bytes
(~6chars) recur at exactly 54-byte (72-char) intervals, giving a
signature that is 137 bytes long. Also my Outlook broke the lines
differently in quoting; perhaps this is just some kind of mail glitch?
> Does anybody have any suggestions on what i am doing wrong ?
>
> Thank you
> Rui Francisco
>
Assuming Delphi is not materially different from Pascal
and that library/adapter doesn't do anything too silly:
> var
> mdLength, b64Length: integer;
> Len: cardinal;
> mdctx: EVP_MD_CTX;
> inbuf, outbuf: array [0..1023] of char;
> memout, b64: pBIO;
> mdValue: array [0..EVP_MAX_MD_SIZE] of byte;
>
If you really wanted a hash you only need MAX_MD_SIZE-1
(i.e. for N bytes numbered from 0 the highest is N-1)
but as below you actually want a signature not a hash.
The size of a signature depends on your private key,
and there is no absolute maximum, although for both RSA
and DSA sizes over 4096 bits = 512 bytes are currently
impractical and rarely if ever used, especially if you
need/want to interoperate with other software. If you
control the generation/issuance of the key(s) used here,
you may have tighter bounds. But except ECDSA, it will
still be significantly larger than any plausible hash.
> key: pEVP_PKEY;
> msg : String;
> begin
> msg:='2010-05-18;2010-05-18T11:22:19;FAC 001/14;3.12; ';
> StrPCopy(inbuf, msg);
> InitOpenSSL;
> key:=ReadPrivateKey('private_key.txt','');
> EVP_DigestInit(@mdctx, EVP_sha1());
Why is this written with empty arglist () when others
aren't? I thought Pascal always omits the unneeded ().
> EVP_DigestUpdate(@mdctx, @inbuf, StrLen(inbuf));
> EVP_DigestFinal(@mdctx, @outbuf, Len);
>
This ignores the key and does a hash, not a signature.
Use the EVP_Sign* routines instead.
>
> b64 := BIO_new(BIO_f_base64);
> memout := BIO_new(BIO_s_mem);
> b64 := BIO_push(b64, memout);
> BIO_write(b64, @outbuf, Len);
> BIO_flush(b64);
> b64Length := BIO_read(memout, @outbuf, 1024);
> outbuf[b64Length-1] := #0;
>
This will clobber the last newline (linebreak)
in the base64-ed data but not the earlier ones.
That's a very unusual and rather confusing format.
> FreeOpenSSL;
>
> BinToHex(outbuf, inbuf,Len);
> inbuf[2*Len]:=#0;
> result:= StrPas(inbuf);
Assuming that converts binary-outbuf to hex-inbuf,
that's a very odd thing to do, and certainly not
what your reference openssl commands above do.
The whole point of base64 is that it is printable,
so converting it further to hex makes no sense.
And the length of the base64-ed data in output
is b64Length or b64Length-1 (depending) NOT Len
(which is very different); read your own code.
Your (sample) output does look like the hex
of some base64 value truncated to 20 chars
(though not one I can reproduce from your data).
Finally, I see no error checking in your code.
Unless the adapter and/or Delphi handles this for you,
you should check and do at least minimal reporting;
if something ever does go wrong, it's much better to
catch it as close to the point of problem as possible.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SSL cert chain validation & timestamp issues
On Mon, Dec 20, 2010 at 10:49:57AM -0800, travis+ml-open...@subspacefield.org wrote: > libnss, at least on Linux, checks that the signing cert (chain) is valid > at the time of signature - as opposed to present time. (It may check > present time as well - not sure on that) > > This makes for problems if you renew the cert, since the new cert will > have a creation (start) date of the current time, after the object was > signed. A signed object (S/MIME, CMS) normally carries the certificate chain (at time of signing) with it. So certificate renewal in no-way impedes signature verification. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL cert chain validation & timestamp issues
So a friend ran into this lately; libnss, at least on Linux, checks that the signing cert (chain) is valid at the time of signature - as opposed to present time. (It may check present time as well - not sure on that) This makes for problems if you renew the cert, since the new cert will have a creation (start) date of the current time, after the object was signed. Can anyone think of why this would be a good thing? If one actually trusted the signature date, someone could lie by backdating the object. Also, we're unsure how to create a new cert that's still valid for the range - I think we're gonna have the person set their system clock back, since I don't think openssl command line actually prompts for a creation date. -- Good code works on most inputs; correct code works on all inputs. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpS5s8DPhrKJ.pgp Description: PGP signature
Re: Decrypting SSL packets with the keys retrieved from openssl
I don't think Wireshark will be able to decrypt any packet without the
appropriate keys. I can already capture packets using wireshark or with any
application that uses winpcap, but the problem is decrypting them in order
to see what the application is really talking to the server. And the keys I
retrieved as I explained before isn't working. So I didn't understand what
you meant with wireshark, can you specify?
Michael S. Zick-4 wrote:
>
> On Mon December 20 2010, Yigit wrote:
>>
>> Hello all,
>> I have seen one or two related previous subjects but they didn't solve my
>> problem. So I am posting a new one.
>>
>> There is an application on my computer which connects to a server using
>> openssl. I have to see their traffic which means either I decrypt all
>> sniffed packets or I print all decrypted packets to a file inside
>> openssl.
>>
>
> Or: Wireshark
> Just ask Google, they know wireshark
>
> Mike
>> The application uses SSLv3 (method version : 768). And it almost always
>> uses
>> the cipher suite TLS-DHE-RSA-AES-256-CBC-SHA.
>>
>> Now, I have edited the ssl3_setup_key_block function in s3_enc.c file. At
>> the end of the function, I print the master key, key block, client random
>> and server random to a file. I retrieve those by calling;
>> Master key : s->s3->master_key (with the length of
>> s->s3->master_key_length
>> which is naturally 48 bytes),
>> Key Block : s->s3->tmp.key_block,
>> Client Random : s->s3->client_random,
>> Server Random : s->s3->server_random
>>
>> I recompile openssl package with this and replace the dll which the
>> application uses and it prints these to the file.
>>
>> Now, as far as I know, the key block must have a structure like;
>> {
>> Client Write MAC Secret (20 bytes for this cipher suite)
>> Server Write MAC Secret (20 bytes)
>> Client Write Secret (32 bytes)
>> Server Write Secret (32 bytes)
>> Client Write IV (16 bytes)
>> Server Write IV (16 bytes)
>> }
>>
>> However, whatever I tried, I couldn't successfully decrypt any packet
>> with
>> the keys and IV's I got from this key block. It gives no meaningful
>> output.
>> By the way, I start decrypting packets discarding the first 5 bytes which
>> are; 17h (Content Type : Application data), 03h 00h (Version : SSLv3) XX
>> XX
>> (Length of message in bytes). In addition, again as far as I know, any
>> decrypted packet must have the structure of :
>> {
>> Plain Text (since there is no compression used),
>> MAC Field,
>> Padding,
>> Padding Length
>> }
>> And I couldn't see anything that seemed like padding and padding-length
>> from
>> my decryptions, so I can deduce that the keys or IVs I use are definitely
>> false ones, unless my decryption method is bugged. I use a 3rd party
>> library
>> to decrypt aes256 and I wrote the code to apply the cbc mode myself, but
>> I
>> am pretty sure there are no mistakes there.
>>
>> Now, http://www.ietf.org/rfc/rfc2246.txt explains how to calculate the
>> key
>> block from master key, client random and master random. So when I
>> calculate
>> the key block from these variables, the resulting key block is different
>> from the one printed on the file. And I think it suggests I am doing
>> something fundamentally wrong. And the decryptions which are performed by
>> this "calculated key block" also produce meaningless outputs.
>>
>> http://www.ietf.org/rfc/rfc2246.txt also says, for "exportable" cipher
>> suites, client write secrets and server write secrets need another
>> operation
>> in order to obtain final write keys. Now, I don't know what "exportable"
>> means in this case and although I think this cipher suite is not
>> exportable,
>> I produced final write secrets from write secrets accordingly. And
>> decryptions using these are also resulted with failure.
>>
>> Alternatively, I edited the SSL_write and SSL_read functions to print
>> decrypted or unencrypted packets to another file. But it always prints
>> "òS^#cYJC". So I am stuck there too.
>>
>> If anyone sees what my flaw is, what I am doing wrong and what I should
>> do,
>> I will appreciate the help.
>>
>> Best regards, thanks in advance,
>> Yigit
>>
>
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
>
--
View this message in context:
http://old.nabble.com/Decrypting-SSL-packets-with-the-keys-retrieved-from-openssl-tp30498813p30499457.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Decrypting SSL packets with the keys retrieved from openssl
On Mon December 20 2010, Yigit wrote:
>
> Hello all,
> I have seen one or two related previous subjects but they didn't solve my
> problem. So I am posting a new one.
>
> There is an application on my computer which connects to a server using
> openssl. I have to see their traffic which means either I decrypt all
> sniffed packets or I print all decrypted packets to a file inside openssl.
>
Or: Wireshark
Just ask Google, they know wireshark
Mike
> The application uses SSLv3 (method version : 768). And it almost always uses
> the cipher suite TLS-DHE-RSA-AES-256-CBC-SHA.
>
> Now, I have edited the ssl3_setup_key_block function in s3_enc.c file. At
> the end of the function, I print the master key, key block, client random
> and server random to a file. I retrieve those by calling;
> Master key : s->s3->master_key (with the length of s->s3->master_key_length
> which is naturally 48 bytes),
> Key Block : s->s3->tmp.key_block,
> Client Random : s->s3->client_random,
> Server Random : s->s3->server_random
>
> I recompile openssl package with this and replace the dll which the
> application uses and it prints these to the file.
>
> Now, as far as I know, the key block must have a structure like;
> {
> Client Write MAC Secret (20 bytes for this cipher suite)
> Server Write MAC Secret (20 bytes)
> Client Write Secret (32 bytes)
> Server Write Secret (32 bytes)
> Client Write IV (16 bytes)
> Server Write IV (16 bytes)
> }
>
> However, whatever I tried, I couldn't successfully decrypt any packet with
> the keys and IV's I got from this key block. It gives no meaningful output.
> By the way, I start decrypting packets discarding the first 5 bytes which
> are; 17h (Content Type : Application data), 03h 00h (Version : SSLv3) XX XX
> (Length of message in bytes). In addition, again as far as I know, any
> decrypted packet must have the structure of :
> {
> Plain Text (since there is no compression used),
> MAC Field,
> Padding,
> Padding Length
> }
> And I couldn't see anything that seemed like padding and padding-length from
> my decryptions, so I can deduce that the keys or IVs I use are definitely
> false ones, unless my decryption method is bugged. I use a 3rd party library
> to decrypt aes256 and I wrote the code to apply the cbc mode myself, but I
> am pretty sure there are no mistakes there.
>
> Now, http://www.ietf.org/rfc/rfc2246.txt explains how to calculate the key
> block from master key, client random and master random. So when I calculate
> the key block from these variables, the resulting key block is different
> from the one printed on the file. And I think it suggests I am doing
> something fundamentally wrong. And the decryptions which are performed by
> this "calculated key block" also produce meaningless outputs.
>
> http://www.ietf.org/rfc/rfc2246.txt also says, for "exportable" cipher
> suites, client write secrets and server write secrets need another operation
> in order to obtain final write keys. Now, I don't know what "exportable"
> means in this case and although I think this cipher suite is not exportable,
> I produced final write secrets from write secrets accordingly. And
> decryptions using these are also resulted with failure.
>
> Alternatively, I edited the SSL_write and SSL_read functions to print
> decrypted or unencrypted packets to another file. But it always prints
> "òS^#cYJC". So I am stuck there too.
>
> If anyone sees what my flaw is, what I am doing wrong and what I should do,
> I will appreciate the help.
>
> Best regards, thanks in advance,
> Yigit
>
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Substitute for openssl command
Hi,
I'm trying to implement the following code to substitute the following
openssl command
openssl dgst -sha1 -sign myKey.pem something.txt | openssl enc -base64
I'm using Delphi and the Opensll lib developed by Marco Ferrante
(http://www.disi.unige.it/person/FerranteM/delphiopenssl/)
The code is producing the hash '6676627A363352673862555A4D69464432376969'
instead of
Am1K5+CP4LDNVDZYvcLYGpnu8/1b+WWkzgoe8sbZhvk6QFzFvNN77Zsq+cHNm52jCVSEDgWLGHgPS1wcT8ZG7w6KgVq+2/VgOU+xKNt0lcC3gouyarZvcZpZclIReDgLh6m3nv8DYYHKAOQc+eCi/BQ4LqUnuJrca+7emgb/kpU=
Does anybody have any suggestions on what i am doing wrong ?
Thank you
Rui Francisco
var
mdLength, b64Length: integer;
Len: cardinal;
mdctx: EVP_MD_CTX;
inbuf, outbuf: array [0..1023] of char;
memout, b64: pBIO;
mdValue: array [0..EVP_MAX_MD_SIZE] of byte;
key: pEVP_PKEY;
msg : String;
begin
msg:='2010-05-18;2010-05-18T11:22:19;FAC 001/14;3.12; ';
StrPCopy(inbuf, msg);
InitOpenSSL;
key:=ReadPrivateKey('private_key.txt','');
EVP_DigestInit(@mdctx, EVP_sha1());
EVP_DigestUpdate(@mdctx, @inbuf, StrLen(inbuf));
EVP_DigestFinal(@mdctx, @outbuf, Len);
b64 := BIO_new(BIO_f_base64);
memout := BIO_new(BIO_s_mem);
b64 := BIO_push(b64, memout);
BIO_write(b64, @outbuf, Len);
BIO_flush(b64);
b64Length := BIO_read(memout, @outbuf, 1024);
outbuf[b64Length-1] := #0;
FreeOpenSSL;
BinToHex(outbuf, inbuf,Len);
inbuf[2*Len]:=#0;
result:= StrPas(inbuf);
end;
--
Rui Francisco - blackmo...@gmail.com
São João dos Montes - Portugal
Tel: +351 934162200
-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Decrypting SSL packets with the keys retrieved from openssl
Hello all,
I have seen one or two related previous subjects but they didn't solve my
problem. So I am posting a new one.
There is an application on my computer which connects to a server using
openssl. I have to see their traffic which means either I decrypt all
sniffed packets or I print all decrypted packets to a file inside openssl.
The application uses SSLv3 (method version : 768). And it almost always uses
the cipher suite TLS-DHE-RSA-AES-256-CBC-SHA.
Now, I have edited the ssl3_setup_key_block function in s3_enc.c file. At
the end of the function, I print the master key, key block, client random
and server random to a file. I retrieve those by calling;
Master key : s->s3->master_key (with the length of s->s3->master_key_length
which is naturally 48 bytes),
Key Block : s->s3->tmp.key_block,
Client Random : s->s3->client_random,
Server Random : s->s3->server_random
I recompile openssl package with this and replace the dll which the
application uses and it prints these to the file.
Now, as far as I know, the key block must have a structure like;
{
Client Write MAC Secret (20 bytes for this cipher suite)
Server Write MAC Secret (20 bytes)
Client Write Secret (32 bytes)
Server Write Secret (32 bytes)
Client Write IV (16 bytes)
Server Write IV (16 bytes)
}
However, whatever I tried, I couldn't successfully decrypt any packet with
the keys and IV's I got from this key block. It gives no meaningful output.
By the way, I start decrypting packets discarding the first 5 bytes which
are; 17h (Content Type : Application data), 03h 00h (Version : SSLv3) XX XX
(Length of message in bytes). In addition, again as far as I know, any
decrypted packet must have the structure of :
{
Plain Text (since there is no compression used),
MAC Field,
Padding,
Padding Length
}
And I couldn't see anything that seemed like padding and padding-length from
my decryptions, so I can deduce that the keys or IVs I use are definitely
false ones, unless my decryption method is bugged. I use a 3rd party library
to decrypt aes256 and I wrote the code to apply the cbc mode myself, but I
am pretty sure there are no mistakes there.
Now, http://www.ietf.org/rfc/rfc2246.txt explains how to calculate the key
block from master key, client random and master random. So when I calculate
the key block from these variables, the resulting key block is different
from the one printed on the file. And I think it suggests I am doing
something fundamentally wrong. And the decryptions which are performed by
this "calculated key block" also produce meaningless outputs.
http://www.ietf.org/rfc/rfc2246.txt also says, for "exportable" cipher
suites, client write secrets and server write secrets need another operation
in order to obtain final write keys. Now, I don't know what "exportable"
means in this case and although I think this cipher suite is not exportable,
I produced final write secrets from write secrets accordingly. And
decryptions using these are also resulted with failure.
Alternatively, I edited the SSL_write and SSL_read functions to print
decrypted or unencrypted packets to another file. But it always prints
"òS^#cYJC". So I am stuck there too.
If anyone sees what my flaw is, what I am doing wrong and what I should do,
I will appreciate the help.
Best regards, thanks in advance,
Yigit
--
View this message in context:
http://old.nabble.com/Decrypting-SSL-packets-with-the-keys-retrieved-from-openssl-tp30498813p30498813.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
