Re: RFC 4130 checksum in SHA1
Ok following your quoted note, I got the asn1 structure to see what was inside there: Which value contains the hash you mention? Is it the messageDigest? Thanks jkoehring wrote: Another way to look at it is when the original AS2 message is signed, the MIC for the MDN should be exactly the same as the hash used in the calculation of the signature for the multipart/signed. $ openssl asn1parse -in SIGB64-pk7.txt 0:d=0 hl=4 l=1101 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT:pkcs7-signedData 15:d=1 hl=4 l=1086 cons: cont [ 0 ] 19:d=2 hl=4 l=1082 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01 26:d=3 hl=2 l= 11 cons: SET 28:d=4 hl=2 l= 9 cons: SEQUENCE 30:d=5 hl=2 l= 5 prim: OBJECT:sha1 37:d=5 hl=2 l= 0 prim: NULL 39:d=3 hl=2 l= 11 cons: SEQUENCE 41:d=4 hl=2 l= 9 prim: OBJECT:pkcs7-data 52:d=3 hl=4 l= 643 cons: cont [ 0 ] 56:d=4 hl=4 l= 639 cons: SEQUENCE 60:d=5 hl=4 l= 488 cons: SEQUENCE 64:d=6 hl=2 l= 3 cons: cont [ 0 ] 66:d=7 hl=2 l= 1 prim: INTEGER :02 69:d=6 hl=2 l= 4 prim: INTEGER :468D29E6 75:d=6 hl=2 l= 13 cons: SEQUENCE 77:d=7 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption 88:d=7 hl=2 l= 0 prim: NULL 90:d=6 hl=3 l= 131 cons: SEQUENCE 93:d=7 hl=2 l= 11 cons: SET 95:d=8 hl=2 l= 9 cons: SEQUENCE 97:d=9 hl=2 l= 3 prim: OBJECT:countryName 102:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX 106:d=7 hl=2 l= 14 cons: SET 108:d=8 hl=2 l= 12 cons: SEQUENCE 110:d=9 hl=2 l= 3 prim: OBJECT:postalCode 115:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260 122:d=7 hl=2 l= 11 cons: SET 124:d=8 hl=2 l= 9 cons: SEQUENCE 126:d=9 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 131:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL 135:d=7 hl=2 l= 18 cons: SET 137:d=8 hl=2 l= 16 cons: SEQUENCE 139:d=9 hl=2 l= 3 prim: OBJECT:localityName 144:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey 155:d=7 hl=2 l= 26 cons: SET 157:d=8 hl=2 l= 24 cons: SEQUENCE 159:d=9 hl=2 l= 3 prim: OBJECT:organizationName 164:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed 183:d=7 hl=2 l= 12 cons: SET 185:d=8 hl=2 l= 10 cons: SEQUENCE 187:d=9 hl=2 l= 3 prim: OBJECT:organizationalUnitName 192:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG 197:d=7 hl=2 l= 25 cons: SET 199:d=8 hl=2 l= 23 cons: SEQUENCE 201:d=9 hl=2 l= 3 prim: OBJECT:commonName 206:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed 224:d=6 hl=2 l= 30 cons: SEQUENCE 226:d=7 hl=2 l= 13 prim: UTCTIME :070705172702Z 241:d=7 hl=2 l= 13 prim: UTCTIME :080704172702Z 256:d=6 hl=3 l= 131 cons: SEQUENCE 259:d=7 hl=2 l= 11 cons: SET 261:d=8 hl=2 l= 9 cons: SEQUENCE 263:d=9 hl=2 l= 3 prim: OBJECT:countryName 268:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX 272:d=7 hl=2 l= 14 cons: SET 274:d=8 hl=2 l= 12 cons: SEQUENCE 276:d=9 hl=2 l= 3 prim: OBJECT:postalCode 281:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260 288:d=7 hl=2 l= 11 cons: SET 290:d=8 hl=2 l= 9 cons: SEQUENCE 292:d=9 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 297:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL 301:d=7 hl=2 l= 18 cons: SET 303:d=8 hl=2 l= 16 cons: SEQUENCE 305:d=9 hl=2 l= 3 prim: OBJECT:localityName 310:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey 321:d=7 hl=2 l= 26 cons: SET 323:d=8 hl=2 l= 24 cons: SEQUENCE 325:d=9 hl=2 l= 3 prim: OBJECT:organizationName 330:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed 349:d=7 hl=2 l= 12 cons: SET 351:d=8 hl=2 l= 10 cons: SEQUENCE 353:d=9 hl=2 l= 3 prim: OBJECT:organizationalUnitName 358:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG 363:d=7 hl=2 l= 25 cons: SET 365:d=8 hl=2 l= 23 cons: SEQUENCE 367:d=9 hl=2 l= 3 prim: OBJECT:commonName 372:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed 390:d=6 hl=3 l= 159 cons: SEQUENCE 393:d=7 hl=2 l= 13 cons: SEQUENCE 395:d=8 hl=2 l= 9 prim: OBJECT:rsaEncryption 406:d=8 hl=2 l= 0 prim: NULL 408:d=7 hl=3 l= 141 prim: BIT STRING 552:d=5 hl=2 l= 13 cons: SEQUENCE 554:d=6 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption 565:d=6 hl=2 l= 0 prim: NULL 567:d=5 hl=3 l= 129 prim: BIT STRING 699:d=3 hl=4 l= 402 cons: SET 703:d=4 hl=4 l= 398 cons: SEQUENCE 707:d=5 hl=2 l= 1 prim: INTEGER :01 710:d=5 hl=3 l= 140 cons: SEQUENCE 713:d=6 hl=3 l= 131 cons: SEQUENCE 716:d=7 hl=2 l= 11 cons: SET 718:d=8 hl=2 l= 9 cons: SEQUENCE 720:d=9 hl=2 l= 3 prim: OBJECT:countryName 725:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX 729:d=7 hl=2 l= 14
Re: RFC 4130 checksum in SHA1
Oh Boy!! Eureka, Yes the HEX number in messageDigest converted to base64 gives me the MIC that the trading partner expects, though, I can not figure out how this value is obtained based on the original content between the first and second boundary. I calculated the message digest for this original content in SHA1 obtaining a binary data which I then convert to base64 using openssl, but in all variations of end of line with mime without mime header (the rfc 1767 header for EDI object), with end of line at the end of the EDI record, and I don't get the same value that comes out from the signature in the second part of the signed message. I also used an online tool for translating all sorts of numbers at http://www.paulschou.com/tools/xlate/ and pasting my original content on first box of this translator, gives me a completely new SHA1 value. %-|. Linux has one straightforward sha1sum GNU command to do the same without openssl, and it gives the same result as the one obtained with openssl, so I don't think I'm using the tool in a wrong way because it only needs the name of the file...WHAT DO YOU THINK? The rfc 4130 mentions precisely what you said: a. The message integrity check (MIC or Message Digest), is decrypted using the sender's public key. (I use as1parse, and get the messageDigest record) b. A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used. c. The MIC extracted from the message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality. jkoehring wrote: Yes, I believe the messageDigest in the ASN.1 dump is, indeed, the hash of the data that was signed. -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18098049.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
How can I compile OpenSSL so that I can include it in my product
Hi, I would like to bundle libssl library with our product. I see that RSA has strict patent restrictions, which makes libssl difficult to bundle. How can i rebuild libssl to include only DSA and not RSA? If I get around doing that, can i then build libssl with my product? thanks sathish
Re: RFC 4130 checksum in SHA1
Yes, I believe the messageDigest in the ASN.1 dump is, indeed, the hash of the data that was signed. javierm wrote: Ok following your quoted note, I got the asn1 structure to see what was inside there: Which value contains the hash you mention? Is it the messageDigest? Thanks jkoehring wrote: Another way to look at it is when the original AS2 message is signed, the MIC for the MDN should be exactly the same as the hash used in the calculation of the signature for the multipart/signed. $ openssl asn1parse -in SIGB64-pk7.txt 0:d=0 hl=4 l=1101 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT:pkcs7-signedData 15:d=1 hl=4 l=1086 cons: cont [ 0 ] 19:d=2 hl=4 l=1082 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :01 26:d=3 hl=2 l= 11 cons: SET 28:d=4 hl=2 l= 9 cons: SEQUENCE 30:d=5 hl=2 l= 5 prim: OBJECT:sha1 37:d=5 hl=2 l= 0 prim: NULL 39:d=3 hl=2 l= 11 cons: SEQUENCE 41:d=4 hl=2 l= 9 prim: OBJECT:pkcs7-data 52:d=3 hl=4 l= 643 cons: cont [ 0 ] 56:d=4 hl=4 l= 639 cons: SEQUENCE 60:d=5 hl=4 l= 488 cons: SEQUENCE 64:d=6 hl=2 l= 3 cons: cont [ 0 ] 66:d=7 hl=2 l= 1 prim: INTEGER :02 69:d=6 hl=2 l= 4 prim: INTEGER :468D29E6 75:d=6 hl=2 l= 13 cons: SEQUENCE 77:d=7 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption 88:d=7 hl=2 l= 0 prim: NULL 90:d=6 hl=3 l= 131 cons: SEQUENCE 93:d=7 hl=2 l= 11 cons: SET 95:d=8 hl=2 l= 9 cons: SEQUENCE 97:d=9 hl=2 l= 3 prim: OBJECT:countryName 102:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX 106:d=7 hl=2 l= 14 cons: SET 108:d=8 hl=2 l= 12 cons: SEQUENCE 110:d=9 hl=2 l= 3 prim: OBJECT:postalCode 115:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260 122:d=7 hl=2 l= 11 cons: SET 124:d=8 hl=2 l= 9 cons: SEQUENCE 126:d=9 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 131:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL 135:d=7 hl=2 l= 18 cons: SET 137:d=8 hl=2 l= 16 cons: SEQUENCE 139:d=9 hl=2 l= 3 prim: OBJECT:localityName 144:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey 155:d=7 hl=2 l= 26 cons: SET 157:d=8 hl=2 l= 24 cons: SEQUENCE 159:d=9 hl=2 l= 3 prim: OBJECT:organizationName 164:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed 183:d=7 hl=2 l= 12 cons: SET 185:d=8 hl=2 l= 10 cons: SEQUENCE 187:d=9 hl=2 l= 3 prim: OBJECT:organizationalUnitName 192:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG 197:d=7 hl=2 l= 25 cons: SET 199:d=8 hl=2 l= 23 cons: SEQUENCE 201:d=9 hl=2 l= 3 prim: OBJECT:commonName 206:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed 224:d=6 hl=2 l= 30 cons: SEQUENCE 226:d=7 hl=2 l= 13 prim: UTCTIME :070705172702Z 241:d=7 hl=2 l= 13 prim: UTCTIME :080704172702Z 256:d=6 hl=3 l= 131 cons: SEQUENCE 259:d=7 hl=2 l= 11 cons: SET 261:d=8 hl=2 l= 9 cons: SEQUENCE 263:d=9 hl=2 l= 3 prim: OBJECT:countryName 268:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX 272:d=7 hl=2 l= 14 cons: SET 274:d=8 hl=2 l= 12 cons: SEQUENCE 276:d=9 hl=2 l= 3 prim: OBJECT:postalCode 281:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260 288:d=7 hl=2 l= 11 cons: SET 290:d=8 hl=2 l= 9 cons: SEQUENCE 292:d=9 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 297:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL 301:d=7 hl=2 l= 18 cons: SET 303:d=8 hl=2 l= 16 cons: SEQUENCE 305:d=9 hl=2 l= 3 prim: OBJECT:localityName 310:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey 321:d=7 hl=2 l= 26 cons: SET 323:d=8 hl=2 l= 24 cons: SEQUENCE 325:d=9 hl=2 l= 3 prim: OBJECT:organizationName 330:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed 349:d=7 hl=2 l= 12 cons: SET 351:d=8 hl=2 l= 10 cons: SEQUENCE 353:d=9 hl=2 l= 3 prim: OBJECT:organizationalUnitName 358:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG 363:d=7 hl=2 l= 25 cons: SET 365:d=8 hl=2 l= 23 cons: SEQUENCE 367:d=9 hl=2 l= 3 prim: OBJECT:commonName 372:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed 390:d=6 hl=3 l= 159 cons: SEQUENCE 393:d=7 hl=2 l= 13 cons: SEQUENCE 395:d=8 hl=2 l= 9 prim: OBJECT:rsaEncryption 406:d=8 hl=2 l= 0 prim: NULL 408:d=7 hl=3 l= 141 prim: BIT STRING 552:d=5 hl=2 l= 13 cons: SEQUENCE 554:d=6 hl=2 l= 9 prim: OBJECT:md5WithRSAEncryption 565:d=6 hl=2 l= 0 prim: NULL 567:d=5 hl=3 l= 129 prim: BIT STRING 699:d=3 hl=4 l= 402 cons: SET 703:d=4 hl=4 l= 398 cons: SEQUENCE 707:d=5 hl=2 l= 1 prim: INTEGER :01 710:d=5 hl=3 l= 140 cons: SEQUENCE 713:d=6
Re: RFC 4130 checksum in SHA1
Technically, the mime-type application/xml requires that ALL content be encoded in UTF-8. (This is an artifact of XML itself specifying that it is always UTF-8.) If it's not valid UTF-8, then it's not valid XML, which (depending on your environment) may not even need to be evaluated for its signature. -Kyle H On Tue, Jun 24, 2008 at 12:18 PM, javierm [EMAIL PROTECTED] wrote: Oh Boy!! Eureka, Yes the HEX number in messageDigest converted to base64 gives me the MIC that the trading partner expects, though, I can not figure out how this value is obtained based on the original content between the first and second boundary. I calculated the message digest for this original content in SHA1 obtaining a binary data which I then convert to base64 using openssl, but in all variations of end of line with mime without mime header (the rfc 1767 header for EDI object), with end of line at the end of the EDI record, and I don't get the same value that comes out from the signature in the second part of the signed message. I also used an online tool for translating all sorts of numbers at http://www.paulschou.com/tools/xlate/ and pasting my original content on first box of this translator, gives me a completely new SHA1 value. . Linux has one straightforward sha1sum GNU command to do the same without openssl, and it gives the same result as the one obtained with openssl, so I don't think I'm using the tool in a wrong way because it only needs the name of the file...WHAT DO YOU THINK? The rfc 4130 mentions precisely what you said: a. The message integrity check (MIC or Message Digest), is decrypted using the sender's public key. (I use as1parse, and get the messageDigest record) b. A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used. c. The MIC extracted from the message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality. jkoehring wrote: Yes, I believe the messageDigest in the ASN.1 dump is, indeed, the hash of the data that was signed. View this message in context: Re: RFC 4130 checksum in SHA1 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 [EMAIL PROTECTED]
Re: How can I compile OpenSSL so that I can include it in my product
The patent on the RSA algorithm expired several years ago, in 2003. -Kyle H On Tue, Jun 24, 2008 at 6:44 AM, sathish subramanian [EMAIL PROTECTED] wrote: Hi, I would like to bundle libssl library with our product. I see that RSA has strict patent restrictions, which makes libssl difficult to bundle. How can i rebuild libssl to include only DSA and not RSA? If I get around doing that, can i then build libssl with my product? thanks sathish __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: How can I compile OpenSSL so that I can include it in my product
On Tue, Jun 24, 2008 at 01:21:09PM -0700, Kyle Hamilton wrote: The patent on the RSA algorithm expired several years ago, in 2003. http://en.wikipedia.org/wiki/RSA#History -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Generating keys to be used in a specific implementation
Hello all! I have an desktop/server agent that listen for TCP connections to process some information. And now i´m trying to implement privacy and authentication to this application, to unsure that only my trusted application interact with these TCP agents. I started reading the article http://www.rtfm.com/openssl-examples/ and I understood how to start working with the contexts and use the IO objects, but I need to understand which kind of keys I need to use to do this job because this example come with pre-created keys don't saying nothing about it's creation. Im posting here because all examples that I found at internet is about private keys and certificate requests to use with HTTPS. Basicaly I need to know how to create two compatibles private keys to communicate with the agent. The agent, that listen for the connections, needs a key that could not be used to connect in another agents because it will be the same in all desktops and servers at the network and only the trusted clients will have the key that permit to connect on all agents. Another problem is that I'm not sure if It really needs a self-signed certificate to authenticate the clients in a scenario that is already implemented a method with fixed pair of private keys. Someone could help me in this objective? Examples, articles and documentations will be apreciated. Thanks :P Renato A. Ferreira
RE: Generating keys to be used in a specific implementation
I have an desktop/server agent that listen for TCP connections to process some information. And now i´m trying to implement privacy and authentication to this application, to unsure that only my trusted application interact with these TCP agents. Another problem is that I'm not sure if It really needs a self-signed certificate to authenticate the clients in a scenario that is already implemented a method with fixed pair of private keys. Someone could help me in this objective? Examples, articles and documentations will be apreciated. Since you have complete control over both ends (right?) then you can just generate keys and certificates following any web page and then hard code each side to check for the key it's expecting from the other side. You can generate a key with 'openssl genrsa -out key.pem 1024'. You can generate a self-signed certificate by following the instructions: http://www.akadia.com/services/ssh_test_certificate.html http://sial.org/howto/openssl/self-signed/ If you are 100% sure both ends will always be trusted, you can simply include the server certificate, client certificate, and client key in the client. You include the client certificate, client key, and server certificate in the server. Then just confirm that the other side is using the proper certificate. Note that this means compromising one client compromises them all. It's more complex, but arguably, the right approach is to create your own CA. Issue a client to the server with a common name the clients check for. Issue each client its own certificate for a different key with a different common name. This will mean that compromising one client doesn't compromise them all and will also allow the server to securely determine what client it's talking to. This will also require less specialized coding, since you can simply hard code the CA's certificate in the client and server, and then they don't need any special code to recognize the clients -- just tell OpenSSL that our CA certificate is the only CA. If you choose to go that way: http://www.octaldream.com/~scottm/talks/ssl/opensslca.html http://sial.org/howto/openssl/ca/ DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Decrypting Fragmented packets
Hi, I am using EVP_DecryptUpdate() and EVP_DecryptFinal_ex() to decrypt a SSL packet that I have captured. The cipher that I am using AES256 and I can read the application data in cleartext as a result. The problem comes if the application data size 8, which I think has something to do with me using a block cipher. I can't seem to decrypt the data then. Anyways, after inspecting the packet dumps, I realized that sometimes I get fragmented packets. For Example, 17 03 01 00 20 85 99 2a 94 4d 0e 56 2c 81 bc fc 4d c9 32 aa 85 46 90 02 6d 4e b6 c6 da 4b d9 82 e9 ab cf 77 e7 17 03 01 00 20 76 68 51 17 9e 86 d4 20 6e 31 3e 7a 96 17 d5 cd c0 ba 5c cd ba 11 2b 18 b1 8d d8 3c 15 3d e9 c7 This is actually two packets that are using the SSL application protocol, each of size 0x20 (The second packet starts on line 3, 6th byte onwards). While decrypting, should both these packets be merged together and hence treated as a single packet of size 0x40 or should packet be processed separately. Since, we are using a block cipher of size 256 bits(32 bytes), will it even make a difference? Thanks and Regards, Vijay Kotari
