Re: we have an issue: bad mac
Dave Thompson dthompson@... writes: From: owner-openssl-users@... On Behalf Of Johnson, Chris E (OGA) Sent: Wednesday, 10 August, 2011 11:45 I typed in a term window in a linux machine the following command. $ openssl s_client -connect rsa6.fema.gov:7004 When the results are displayed there are two lines that show an error. 47661220128736:error:140943FC: SSL routines: SSL3_READ_BYTES: sslv3 alert bad record mac:s3_pkt.c:1193:SSL alert number 20 47661220128736:error:140790E5:SSL routines:SSL23_WRITE: ssl handshake failure: s23_lib.c:177: Assuming from the name and the port that this is the RSA Authentication Manager 7 Self Service console, it only supports SSLv3 and one cipher which has to be specified manually. Try setting the cipher by hand, using your command : $ openssl s_client -connect rsa6.fema.gov:7004 -ssl3 -cipher RC4-SHA Adding these settings worked for us, YMMV .. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EVP_CipherUpdate Out Buffer Size
Hello, I have a question concerning the size of the out buffer filled by EVP_CipherUpdate() and EVP_CipherFinal(). The evp man page gives the following description: EVP_EncryptUpdate() encrypts inl bytes from the buffer in and writes the encrypted version to out. [...] The amount of data written depends on the block alignment of the encrypted data: as a result the amount of data written may be anything from zero bytes to (inl + cipher_block_size - 1). If padding is enabled (the default) then EVP_EncryptFinal_ex() encrypts the ``final'' data, that is any data that remains in a partial block. I observed the following behaviour of EVP_CipherUpdate(). It fills the out buffer with (int)(inSize / cipher_block_size) blocks of data. The remaining bytes of data are written to the buffer when calling EVP_CipherFinal(). During my tests the size of the decrypted buffer always equalled the size of the encrypted buffer and vice versa. But if I understand the man page correctly this behaviour is not guaranteed as EVP_EncryptUpdate() could fill up the partial block with data and write (inl + cipher_block_size - 1) bytes to the out buffer. Is this correct and if so how can I know where my en-/decrypted data ends in the buffer? Does it still always equal the size of the in buffer even if more data is written to the out buffer? Thanks a lot for your help. Cheers Nico Flink
RE: Revocation with a renewed/rekeyed Root CA
- U1, U2, U3 are end-user certificates, issued by CA1 - U1 is revoked, and the CRL is published (lets call it CRLg1) The problem here is that you can't trust a CRL when its signature key is compromised. I think that this is not the reason. If a signature key is compromised but used to revoke itself: it can be a genuine authentic revocation (e.g. as reaction to the compromise) and it should be accepted as revocation, -- or -- it can be a forged revocation by a malicious entity made possible because of a compromise and in case of a proven compromise, permanent revocation seems very reasonable, doesn't it? oki, Steffen End of message. -- About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
length of RSA_public_encrypt out buffer
Hi I search the mailarchives as well as stackoverflow for a answer. No success. I just want to know how large my out-buffer must be when doing a RSA_public_encrypt. In the docs i read the size must be RSA_size(RSA *). In my case i'd like to encrypt files. So i read the whole file into a mem-buffer. So how large should i malloc my out-buffer? Or do you use any other function to encrypt files with a RSA public key? Thanks -- Jonas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Differences between RSA and ECDSA - Conceptual and Practical
Jakob Bohm jb-openssl-Ov0D3Su7/I/qt0dzr+a...@public.gmane.org writes: [...] As explained above, 192 bit DSA and ECDSA only works with 192 bit hashes (and only one hash algorithm is allowed for each private/public key pair). You can use larger digests (SHA-512, for example), but the digest will be truncated before processing with ECDSA (or DSA). (This behaviour is specified in the relevant standard.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Differences between RSA and ECDSA - Conceptual and Practical
On 10/18/2011 2:18 PM, Bruce Stephens wrote: Jakob Bohmjb-openssl-Ov0D3Su7/I/qt0dzr+a...@public.gmane.org writes: [...] As explained above, 192 bit DSA and ECDSA only works with 192 bit hashes (and only one hash algorithm is allowed for each private/public key pair). You can use larger digests (SHA-512, for example), but the digest will be truncated before processing with ECDSA (or DSA). (This behaviour is specified in the relevant standard.) I did mention that in passing under my item 2 (where I mentioned use of 192-bit-truncated-SHA-224 as one allowed 192 bit hash algorithm for use with ECDSA-192). I don't remember if the current FIPS-180 actually allows truncating to (below) the size of the next smaller standard SHA-2 variant, though there may be a special case allowing 160-bit-truncated-SHA-224 for use in former SHA-1 applications. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re:length of RSA_public_encrypt out buffer
RSA_size(RSA *) told you the max length of every RSA encryption needed. RSA encryption is not designed to encrypt the large files because of its high cost.It is common to use a symmetric algorithm to encrypt the large data and the RSA algorithm is used to encrypt the key that the symmetric algorithm needed. If you want to use RSA to encrypt large files, you may seperate the file into ceil(FILE_SIZE%RSA_size(key)) pieces and each piece has a length of RSA_size(key)(which is the length of you buffer).Then, you need to encrypt each pieces. Note, In my experience, the length of the RSA encryptin's output is not always the same.It may be impossible for you to decrpt your files.So I think you should use a fixed block size for each of your encryption text. At 2011-10-18 22:13:15,Jonas Schnelli jonas.schne...@include7.ch wrote: Hi I search the mailarchives as well as stackoverflow for a answer. No success. I just want to know how large my out-buffer must be when doing a RSA_public_encrypt. In the docs i read the size must be RSA_size(RSA *). In my case i'd like to encrypt files. So i read the whole file into a mem-buffer. So how large should i malloc my out-buffer? Or do you use any other function to encrypt files with a RSA public key? Thanks -- Jonas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Differences between RSA and ECDSA - Conceptual and Practical
Jakob Bohm jb-openssl-Ov0D3Su7/I/qt0dzr+a...@public.gmane.org writes: [...] I did mention that in passing under my item 2 (where I mentioned use of 192-bit-truncated-SHA-224 as one allowed 192 bit hash algorithm for use with ECDSA-192). OK, sorry, I missed that. I don't remember if the current FIPS-180 actually allows truncating to (below) the size of the next smaller standard SHA-2 variant, though there may be a special case allowing 160-bit-truncated-SHA-224 for use in former SHA-1 applications. My reading of FIPS 180-4 (section 7) is that it does allow quite general truncation. (I skipped to section 7, though, so perhaps that's restricted elsewhere.) FIPS 186-3 seems to permit larger digest sizes to be used (section 4.2), It is recommended that the security strength of the (L, N) pair and the security strength of the hash function used for the generation of digital signatures be the same unless an agreement has been made between participating entities to use a stronger hash function. (it goes on to describe the truncation to be performed). For Federal Government entities other than CAs it gives specific combinations to be used, and similarly for CAs. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problem with signature verification on microchip embedded controller
Hi, I'm trying to implement certificate signature verification (certificates are generated and signed using OpenSSL) on a Microchip pic controller. The Microchip PIC controller doesn't support OpenSSL libraries, but it does have an encryption/decryption function. I was successful in getting a SSL connection between PIC controller and a web server. My next step is to setup signature verification on the PIC controller. After reading PKCS#1 V2.1 RSA Cryptography Standard (http://www.rsa.com/rsalabs/node.asp?id=2125) I realized that encryption is essentially the same as signature verification and decryption is the same as signing. More specifically both encryption and verification uses the public key and the following formula: m = s^e mod n. Where s is the signature or the message, e is the public exponent, n is the modulus and m is the encrypted message or decoded signature. Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. In order to verify the certificate, I generate the SHA1 hash of the certificate; Decode signature using CA's public key and encryption algorithm. Remove the padding from the decoded signature, the result hash should be equal to the SHA1 hash of the certificate. However, I cannot get the two hash values to be equal. I tried to verify my assumption and PIC controller results using OpenSSL command line. openssl rsautl -in signature.txt -verify -asn1parse -inkey pubkey.pem -pubin db e8 c6 cb 78 19 3c 0f-fd 96 1c 4f ed bd b2 34 45 60 bf 65 this matches the hash value I'm getting from PIC controller openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb This is my signature 7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4 0f66 db3a a3c1 a254 5be5 11d3 a691 63ef 0cf2 ec59 c48b 25ad 8881 9ed2 5230 bcd6 This is my public key (I'm using a very small key just for testing, will make it larger once everything works) 96 FE CB 59 37 AE 8C 9C 6C 7A 01 50 0F D6 4F B4 E2 EC 45 D1 88 4E 1F 2D B7 1E 4B AD 76 4D 1F F1 B0 CD 09 6F E5 B7 43 CA F8 14 FE 31 B2 06 F8 7B Exponent is 01 00 01 I'm wondering are my assumptions wrong that I cannot use encryption algorithm for decoding signature? or I'm doing something else wrong. Thank you for any help. Conan -- View this message in context: http://old.nabble.com/Problem-with-signature-verification-on-microchip-embedded-controller-tp32677043p32677043.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: EVP_CipherUpdate Out Buffer Size
On Tue, Oct 18, 2011 at 6:47 AM, Nico Flink fl...@coolux.de wrote: I have a question concerning the size of the out buffer filled by EVP_CipherUpdate() and EVP_CipherFinal(). The evp man page gives the following description: EVP_EncryptUpdate() encrypts inl bytes from the buffer in and writes the encrypted version to out. […] The amount of data written depends on the block alignment of the encrypted data: as a result the amount of data written may be anything from zero bytes to (inl + cipher_block_size - 1). If padding is enabled (the default) then EVP_EncryptFinal_ex() encrypts the ``final'' data, that is any data that remains in a partial block. I observed the following behaviour of EVP_CipherUpdate(). It fills the out buffer with (int)(inSize / cipher_block_size) blocks of data. The remaining bytes of data are written to the buffer when calling EVP_CipherFinal(). During my tests the size of the decrypted buffer always equalled the size of the encrypted buffer and vice versa. But if I understand the man page correctly this behaviour is not guaranteed as EVP_EncryptUpdate() could fill up the partial block with data and write (inl + cipher_block_size - 1) bytes to the out buffer. Is this correct and if so how can I know where my en-/decrypted data ends in the buffer? Does it still always equal the size of the in buffer even if more data is written to the out buffer? inl + cipher_block_size - 1 is a maximum size. The actual size is returned to you in . The idea is to give you the size of the maximum buffer needed. You alloc the maximum size, and then only use outlen bytes within that buffer. See the logic in crypto/evp/evp_enc.c. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL and Solaris zones
I don't have much information, but maybe someone has had a similar problem. I am building my distribution of Apache Web Server (and Tomcat). I include in my tarball a compiled version of openssl, apr, apr-util and apache with several modules including mod_jk I build the components above in a physical machine running Solaris 10, create the tar ball and deploy it in another system (possibly in different directory, so we use LD_LIBRARY_PATH to point to the right set of libraries) All this has worked wonderful for quite some time. We have over the years updated several of the components with minor adjustment to our build. Currently we are using apache 2.2.20 with openssl 1.0.0d Recently our IT department decided to use Solaris zones; so they deployed the same tarball in a zone. It works fine for most of the users of the system, except for two of them. Their requests time out. The apache access and error logs don't show anything, but we were able to narrow it down to the SSL handshaking failing. So far, it seems that building openssl in the target machine (the solaris zone) fixes the problem; but I really want to distribute a compiled version of all libraries rather than building it in the target machine. So I was wondering if anybody has experienced a similar problem with OpenSSL when building it in a Soalris physical (global zone) machine but deploying it in a zone. -Jorge __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Problem with signature verification on microchip embedded controller
From: owner-openssl-us...@openssl.org On Behalf Of TSCOconan Sent: Tuesday, 18 October, 2011 14:57 I'm trying to implement certificate signature verification snip on a Microchip pic controller. snip After reading PKCS#1 V2.1 snip I realized that encryption is essentially the same as signature verification and decryption is the same as signing. snip Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. Raw RSA encrypt/decrypt are the same as verify/sign, but the standard paddings are different. (PKCS#1 type2 padding for encrypt is similar to type1 padding for sign but not identical, and it proved vulnerable in application so it was mostly superseded by OAEP which is very different. And encrypt is pad-then-modexp-pub while verify is modexp-pub-then-unpad.) In order to verify the certificate, snip usual openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. Yes. (To be exact, removing type 01, at least 8 IIRC FF's, and delimiter 00; those are all part of the padding.) However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb I'm not sure what that encryption primitive is doing. Does it take any kind of setting to do padding or not? If it is doing any real padding it should reject your call because no padding scheme can encrypt a 384-bit (or even 376-bit) value with a 384-bit key. Maybe it is failing to return the error or you are failing to recognize it. If it is supposed to be doing unpadded something is wrong. snip data This is my public key (I'm using a very small key just for testing, will make it larger once everything works) I suggest you use a key large enough to give OAEP some elbow room, at least 512. Then try encrypting several known short values like 01; 01 02; 01 02 03; etc. and see if rsautl -decrypt -raw or -oaep gives them back. (Or maybe -pkcs, but as noted that is rare these days.) Increase up to the length you need (about 48 bytes). If you can get raw-encrypt to match, you can use it for the modexp-pub part of verify. (And the rest is, as you correctly described, relatively simple.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and Solaris zones
On Tue, Oct 18, 2011 at 04:08:17PM -0400, Jorge Medina wrote: I don't have much information, but maybe someone has had a similar problem. I am building my distribution of Apache Web Server (and Tomcat). I include in my tarball a compiled version of openssl, apr, apr-util and apache with several modules including mod_jk Have you tried doing a pldd to verify that /usr/sfw/lib/libcrypt.so didn't get linked in? I build the components above in a physical machine running Solaris 10, create the tar ball and deploy it in another system (possibly in different directory, so we use LD_LIBRARY_PATH to point to the right set of libraries) All this has worked wonderful for quite some time. We have over the years updated several of the components with minor adjustment to our build. Currently we are using apache 2.2.20 with openssl 1.0.0d Recently our IT department decided to use Solaris zones; so they deployed the same tarball in a zone. It works fine for most of the users of the system, except for two of them. Their requests time out. The apache access and error logs don't show anything, but we were able to narrow it down to the SSL handshaking failing. So far, it seems that building openssl in the target machine (the solaris zone) fixes the problem; but I really want to distribute a compiled version of all libraries rather than building it in the target machine. So I was wondering if anybody has experienced a similar problem with OpenSSL when building it in a Soalris physical (global zone) machine but deploying it in a zone. -Jorge __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL documentation
Hi, Is there any material available that shows flows of one-way/two-ssl and different types of CA architectures ? We use two-way SSL and generate CSR's and update expired certificates and we are aware of the basic points. I have browsed the NIST website. Thanks, Mohan DISCLAIMER: ==The information contained in this e-mail message may be privileged and/or confidential and protected from disclosure under applicable law. It is intended only for the individual to whom or entity to which it is addressed as shown at the beginning of the message. If the reader of this message is not the intended recipient, or if the employee or agent responsible for delivering the message is not an employee or agent of the intended recipient, you are hereby notified that any review, dissemination,distribution, use, or copying of this message is strictly prohibited. If you have received this message in error, please notify us immediately by return e-mail and permanently delete this message and your reply to the extent it includes this message. Any views or opinions presented in this message or attachments are those of the author and do not necessarily represent those of the Company. All e-mails and attachments sent and received are subject to monitoring, reading, and archival by the Company.==
