Re: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
On Thu, Mar 26, 2015 at 10:42:21AM +0530, Mukesh Yadav wrote: HI, I have a query for SSl cipher on Openssl-1.0.1h Have an application which is using library compiled with openssl-1.0.1h. Application is failing in func SSL_CTX_set_cipher_list() when input is RC4-MD5+RC4-SHA and it gets succeed when input is RC4-SHA. Not sure whether RC4-MD5 is disabled by default on openssl-1.0.1h. Earlier application was using openssl-0.9.8d. There it used to work fine.. If that is the case, is there a way to enable RC4-MD5 on openssl-1.0.1h. Tried looking opensource link, couldn't find a way to explicitly enable this algorithm or even if it is diabled by default. Any Inputs for same will be appreciated.. You seem to be using invalid cipher string syntax. : is a delimiter there. openssl ciphers RC4-MD5:RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
Thanks Marcus. It worked when changed + to :. I am wondering is this newly introduced?. Application compiled with openssl-0.9.8d used to work when Cipher string has '+'.or ':' On 26 March 2015 at 15:23, Marcus Meissner meiss...@suse.de wrote: On Thu, Mar 26, 2015 at 10:42:21AM +0530, Mukesh Yadav wrote: HI, I have a query for SSl cipher on Openssl-1.0.1h Have an application which is using library compiled with openssl-1.0.1h. Application is failing in func SSL_CTX_set_cipher_list() when input is RC4-MD5+RC4-SHA and it gets succeed when input is RC4-SHA. Not sure whether RC4-MD5 is disabled by default on openssl-1.0.1h. Earlier application was using openssl-0.9.8d. There it used to work fine.. If that is the case, is there a way to enable RC4-MD5 on openssl-1.0.1h. Tried looking opensource link, couldn't find a way to explicitly enable this algorithm or even if it is diabled by default. Any Inputs for same will be appreciated.. You seem to be using invalid cipher string syntax. : is a delimiter there. openssl ciphers RC4-MD5:RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How to get encryption strength?
Hi Steve, as far as I can see this works only if the application embedding openssl is the ssl client; but how can this be achieved from the server's point of view? Thanks Dirk On 25.03.2015 16:35, Dr. Stephen Henson wrote: On Wed, Mar 25, 2015, Dirk Menstermann wrote: Hello, which API function can I use to obtain the bit strength of the key exchange (size of the DH or ECDH parameters)? There is the function SSL_get_cipher_bits, but this is only for the symmetric cipher, not including the key exchange. This is only supported in OpenSSL 1.0.2 and later. You can call SSL_get_server_tmp_key() to get the peer temporary key. This returns an EVP_PKEY structue which you can then analyse further. Check out the function ssl_print_tmp_key() in apps/s_cb.c for a simple example. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
I am wondering is this newly introduced?. No it's not new. Application compiled with openssl-0.9.8d used to work when Cipher string has '+'.or ':' That release is nearly 10 years old (Sep 2006) And are you sure it worked? + tended to mean add, so :+ worked... -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Memory leak issue
Hello Openssl Users, Currently we are facing a memory leak issue in the following scenario. We are allocating dynamic memory to a appctx and we are setting this appctx to the session using the function SSL_SESSION_set_app_data(). My understanding is that, this appctx will be updated as part of ex_data present at SSL_SESSION data structure. As part of SSL_SESSION_free(), i see that crypto_free_ex_data() gets called. But, we are seeing that appctx is not being free'd through openssl. Is there any function do i need to update for free_func() to get this appctx to be free'd? And my understanding is if SSL Caching is present, this ex_data also gets saved as part of SSL_SESSION data. Hence, at application we are unable to judge when to free this appctx. Hence, we would like to get this free'd when openssl frees its SSL Session. Please provide me appropriate function to call/to set at/to openssl to get this appctx free'd by openssl when SSL_Session is being freed. Thanks in advance. Rajeswari. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ChaCha20/Poly1305 in OpenSSL?
On Wed, Mar 25, 2015 at 12:36 PM, Salz, Rich rs...@akamai.com wrote: I see Adam Langley's patch here: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a8646510b Any ideas why it was not accepted or not merged? (I'm assuming it was not merged because it was rejected for some reason). I thought his patch came before the IETF final doc, which changed some things. It appears we are also waiting on the cipher suite values. See Cipher suite values for ChaCha20/Poly1305?, http://www.ietf.org/mail-archive/web/tls/current/msg15719.html. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On 03/26/2015 01:00 PM, Marcus Meissner wrote: ... Unfortunately FIPS 140-2 validation conflicts rather violently with open source software (and with software engineering best practice in general, for that matter). Even if some benevolent benefactor ponied up the quarter megabuck it would take to do an open source based kernel crypto validation, it would be fossilized code obsolete before the validation was even approved. Linux got to be as good as it is due to constant refinement and improvement; FIPS validation presumes that it is possible to write perfect code in one shot and that the environment that code runs in never changes. This is not true. Both Redhat and SUSE have certified or are currently in the process of certifying the Linux Kernel as a cryptographic module and it is not as hard as you make it. ... As you note *binary* validations are a lot easier. Many such Level 1 software validations have been done (something like a thousand), including ones by Red Hat, SuSE, and hundreds of private label *binary* validations based on the OpenSSL FIPS Object Module (many using that code verbatium). In fact the majority of all Level 1 software validations are derived from OpenSSL code. We've done a number of those private label vaildations ourselves, incidentally. But, as someone who has been at ground zero of each of the only open source based FIPS 140-2 validations that have ever been done I can tell you that those are *much* harder. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On Thu, Mar 26, 2015 at 10:57:28AM -0400, Steve Marquess wrote: On 03/25/2015 06:26 PM, jone...@teksavvy.com wrote: On Wed, 25 Mar 2015 17:03:04 -0400 Steve Marquess marqu...@openssl.com wrote: I wasn't aware the Linux kernel (the real one, not proprietary commercial derivatives) had a FIPS mode. Please enlighten me. It could very well be that the word 'mode' is not the right one. 'option' would perhaps be better. This article from 2009 sets the foundation: http://www.guerilla-ciso.com/archives/793 I wonder, 6 years later, what the kernel fips option implies. Maybe I could try to contact Neil Horman andéor look into the sources. That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS doesn't get you any closer to FIPS 140-2 validated kernel cryptography. Unfortunately FIPS 140-2 validation conflicts rather violently with open source software (and with software engineering best practice in general, for that matter). Even if some benevolent benefactor ponied up the quarter megabuck it would take to do an open source based kernel crypto validation, it would be fossilized code obsolete before the validation was even approved. Linux got to be as good as it is due to constant refinement and improvement; FIPS validation presumes that it is possible to write perfect code in one shot and that the environment that code runs in never changes. This is not true. Both Redhat and SUSE have certified or are currently in the process of certifying the Linux Kernel as a cryptographic module and it is not as hard as you make it. The scope is the cryptographic module abstraction layer and even includes loadable modules. Integrity checking is done in the initrd for vmlinuz and via the module signatures also used for UEFI secure boot. crypto/testmgr.c contains the power up selftests. CAVS testing is external, driven over a specific kernel module. There is no binary only blob involved, the paper work will however list an explicit version of a specific kernel release. And the bucks are more in the low 5 digit bucks range. FWIW, here is Redhats last security policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1901.pdf Ciao, Marcus ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On 26/03/2015 16:56, Steve Marquess wrote: On 03/26/2015 11:30 AM, John Foley wrote: We looked at this very briefly a couple of years ago. In theory, there may be a way to achieve the goal as a loadable kernel module (a.k.a. device driver). The idea would be to have a kernel module that provides crypto support. This kernel module would be the FIPS object module, with the FIPS boundary drawn around the kernel module. This would be loaded at run time like any other device driver when FIPS mode needed to be enabled. There is likely some kernel work required to allow the ciphers in the kernel module to be injected into the crypto flow within the kernel. The other issue is getting the kernel to automatically run the FIPS integrity test on the module at load time. We looked at it in quite a bit of detail about two years ago also, to the point of developing a formal proposal for a prospective sponsor. Yes, a loadable module is the way to go. We had worked out how to do the POST at module load (including an actual implementation). But, as with any open source based FIPS validation it would have been expensive and risky, and the end result would still have been fossilized code that would always be a painfully awkward fit in the Linux ecosystem. We'd still consider tackling that, with financial sponsorship, but we have no prospects for such. -Steve M. Hypothetically speaking, would it be possible to use the OpenSSL FIPS module with an appropriate outside the boundary kernel module wrapper around it to form yet another platform for one of the validation numbers? Technically, the kernel module wrapper would interact with the same blob API that a FIPS-enabled OpenSSL uses, so there would be little or no change to FIPS module build and security guide for such additional kernel mode platforms. Inside the boundary changes would be needed only to the extent that the FIPS blob makes direct system calls, since the kernel is not a normal POSIX-like environment when seen from a kernel mode module. If the CMVP bureaucracy insists on a specific kernel version for the platform number, this should be one of the Long Term Support kernel releases to maximize longevity (assuming that regular OS patching within a version number is still accepted as same platform). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2a CMS encrypt with ECDH EnvelopedData fails?
On Thu, Mar 26, 2015, Chris Madden wrote: Hi, I am playing with openssl 1.0.2a - specifically CMS support for ECC. But what I think should work doesn't. Commands used and parsed data shown. (I gave an RSA example as a known good working example) ./openssl version OpenSSL 1.0.2a 19 Mar 2015 echo -n 12345678123456781234567812345678 sess.txt # 32 byte plaintext #EC fails ./openssl ecparam -name prime192v1 -genkey -out ecc.key ./openssl req -x509 -new -key ecc.key -out ecc.crt ./openssl cms -encrypt -in sess.txt -out encsess.bin -outform PEM ecc.crt ./openssl cms -decrypt -in encsess.bin -out decsess.txt -inform PEM -inkey ecc.key Error decrypting CMS structure error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529: RSA can decrypt without knowing the certificate but currently EC cannot. So try including the option -recip ecc.crt when you decrypt. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS: Any setup required for using a default DRBG ?
From: jonetsu jone...@teksavvy.com Date: 03/26/15 11:11 Is FIPS_mode_set(1) taking care of setting up a default DRBG ? Yes. It does. When using post_cb() from fips_test_suite.c in for instance the fips_hmac.c demo, with only but a FIPS_mode_set(1) call, it is reported that the four DRBGs are tested: DRBG AES-256-CTR DF, DRBG AES-256-CTR, DRBG SHA256 and DRBG HMAC-SHA256, amongst others. After FIPS_mode_set(1) is executed along with the POST tests, a call to RAND_pseudo_bytes() will not run the tests again. In this context, when do occur the DRBG continuous tests as shown in table 6b of the 2.0.9 Security Policy ? Is there a need to actually call FIPS_selftest() ? Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On 26/03/2015 22:29, Steve Marquess wrote: On 03/26/2015 01:41 PM, Jakob Bohm wrote: On 26/03/2015 16:56, Steve Marquess wrote: On 03/26/2015 11:30 AM, John Foley wrote: We looked at this very briefly a couple of years ago. In theory, there may be a way to achieve the goal as a loadable kernel module (a.k.a. device driver). The idea would be to have a kernel module that provides crypto support. This kernel module would be the FIPS object module, with the FIPS boundary drawn around the kernel module. This would be loaded at run time like any other device driver when FIPS mode needed to be enabled. There is likely some kernel work required to allow the ciphers in the kernel module to be injected into the crypto flow within the kernel. The other issue is getting the kernel to automatically run the FIPS integrity test on the module at load time. We looked at it in quite a bit of detail about two years ago also, to the point of developing a formal proposal for a prospective sponsor. Yes, a loadable module is the way to go. We had worked out how to do the POST at module load (including an actual implementation). But, as with any open source based FIPS validation it would have been expensive and risky, and the end result would still have been fossilized code that would always be a painfully awkward fit in the Linux ecosystem. We'd still consider tackling that, with financial sponsorship, but we have no prospects for such. -Steve M. Hypothetically speaking, would it be possible to use the OpenSSL FIPS module with an appropriate outside the boundary kernel module wrapper around it to form yet another platform for one of the validation numbers? Possibly. The approach we tentatively settled on was to keep and validate the existing kernel crypto code (non OpenSSL!) with the cruft to satisfy FIPS 140-2 (the POST, and also the test suite software for the algorithm testing). The hard part isn't the crypto code; it's everything else. By keeping the existing interoperable crypto API we'd get the most bank for the buck. Technically, the kernel module wrapper would interact with the same blob API that a FIPS-enabled OpenSSL uses, so there would be little or no change to FIPS module build and security guide for such additional kernel mode platforms. Inside the boundary changes would be needed only to the extent that the FIPS blob makes direct system calls, since the kernel is not a normal POSIX-like environment when seen from a kernel mode module. This could work if you weren't worried about compatibility with existing kernel crypto usage. The current OpenSSL FIPS module code would still need non-trivial massaging though. The point would be that the wrapper takes calls in the existing Linux kernel form and then implement each such call in terms of the functionality exposed by the existing OpenSSL FIPS blob. For instance if the Linux kernel has an API that sets up and performs AES CBC encryption, this would get mapped to OpenSSL FIPS blob calls that do AES CBC encryption. This is all facilitated by the existing ability of the Linux kernel to support multiple implementations of each needed primitive. If the CMVP bureaucracy insists on a specific kernel version for the platform number, this should be one of the Long Term Support kernel releases to maximize longevity (assuming that regular OS patching within a version number is still accepted as same platform). Worse: it would need to be validated on every Operational Environment (OE): meaning every Linux distribution: Debian N.M for every N and M, Fedora N.M, Ubuntu N.M, CentOS N.M, ... As the (unpatched upstream) kernel does not rely on the distribution above it, the platform would not include the user mode. This is similar to how a validation for running inside the core of a virtualization platform such as VMWare ESXi 5.1 or RedHat N.M libvirt/kvm does not include the guest OS in the platform for its validation. Of cause using the validation on a Vendor patched kernel such as RedHat N.M patched Linux kernel 3.2 or Debian 7.8 patched Linux kernel 3.2 would obviously be a different platform than kernel.org vanilla Linux kernel 3.2. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.0.2a CMS encrypt with ECDH EnvelopedData fails?
Hi, I am playing with openssl 1.0.2a - specifically CMS support for ECC. But what I think should work doesn't. Commands used and parsed data shown. (I gave an RSA example as a known good working example) ./openssl version OpenSSL 1.0.2a 19 Mar 2015 echo -n 12345678123456781234567812345678 sess.txt # 32 byte plaintext #EC fails ./openssl ecparam -name prime192v1 -genkey -out ecc.key ./openssl req -x509 -new -key ecc.key -out ecc.crt ./openssl cms -encrypt -in sess.txt -out encsess.bin -outform PEM ecc.crt ./openssl cms -decrypt -in encsess.bin -out decsess.txt -inform PEM -inkey ecc.key Error decrypting CMS structure error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529: RSA can decrypt without knowing the certificate but currently EC cannot. So try including the option -recip ecc.crt when you decrypt. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org Many thanks Steve for the prompt response! That fixed it. Chris ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Encryption length, OpenSSL_add_all_algorithms, and OpenSSL_add_all_ciphers questions
Hi Phil, or is the encrypted length put into the encrypted information so an EVP call is available to retrieve it? It is NOT the case. May not be the answer you expected : The encrypted length is length of clear text + size of 1 cipher block if padding is enabled. https://www.openssl.org/docs/crypto/EVP_EncryptInit.html is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers) and the corresponding EVP_cleanup call necessary for each encrypt and decrypt ? NO, and It should NOT, especially in multi-threaded applications : A typical application will call OpenSSL_add_all_algorithms() initially and EVP_cleanup() before exiting. https://www.openssl.org/docs/crypto/OpenSSL_add_all_algorithms.html Also : https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption Hope this helps, Regards, Michel. De : openssl-users [mailto:openssl-users-boun...@openssl.org] De la part de Philip Bellino Envoyé : jeudi 26 mars 2015 15:53 À : openssl-users@openssl.org Objet : [openssl-users] Encryption length, OpenSSL_add_all_algorithms, and OpenSSL_add_all_ciphers questions I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords with cipher des_ede3_cbc as follows: encrypt routines: EVP_CIPHER_CTX_init EVP_EncryptInit_ex EVP_EncryptUpdate EVP_EncryptFinal_ex EVP_CIPHER_CTX_cleanup decrypt routines: EVP_CIPHER_CTX_init EVP_DecryptInit_ex EVP_DecryptUpdate EVP_DecryptFinal_ex EVP_CIPHER_CTX_cleanup similar to examples found here: http://www.openssl.org/docs/crypto/EVP_CIPHER_CTX_init.html#EXAMPLES Passwords are encrypted and stored when created, and decrypted at a later time to compare against the password given upon login. None of the examples show determining the length of the encrypted information via an EVP call in order to pass that information to the decryption routines. Should I assume it is incumbent upon the coder to store the encrypted length when storing the encrypted password, for retrieval later? Or is the encrypted length put into the encrypted information so an EVP call is available to retrieve it? I believe from all the information I see that it is the former. Please confirm this for me. Also, is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers) and the corresponding EVP_cleanup call necessary for each encrypt and decrypt? My encryption and decryption seem to be working without calling those routines but after seeing them used (for examples in test/evp_test.c), I don't understand why. Any insight that can be shared would be most appreciated. Thank you. Phil Bellino Principal Software Engineer | MRV Communications Inc. 300 Apollo Drive | Chelmsford, MA 01824 Phone: 978-674-6870 | Fax: 978-674-6799 www.mrv.com MRV-email http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform Image supprimée par l'expéditeur. E-Banner The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On 03/26/2015 01:41 PM, Jakob Bohm wrote: On 26/03/2015 16:56, Steve Marquess wrote: On 03/26/2015 11:30 AM, John Foley wrote: We looked at this very briefly a couple of years ago. In theory, there may be a way to achieve the goal as a loadable kernel module (a.k.a. device driver). The idea would be to have a kernel module that provides crypto support. This kernel module would be the FIPS object module, with the FIPS boundary drawn around the kernel module. This would be loaded at run time like any other device driver when FIPS mode needed to be enabled. There is likely some kernel work required to allow the ciphers in the kernel module to be injected into the crypto flow within the kernel. The other issue is getting the kernel to automatically run the FIPS integrity test on the module at load time. We looked at it in quite a bit of detail about two years ago also, to the point of developing a formal proposal for a prospective sponsor. Yes, a loadable module is the way to go. We had worked out how to do the POST at module load (including an actual implementation). But, as with any open source based FIPS validation it would have been expensive and risky, and the end result would still have been fossilized code that would always be a painfully awkward fit in the Linux ecosystem. We'd still consider tackling that, with financial sponsorship, but we have no prospects for such. -Steve M. Hypothetically speaking, would it be possible to use the OpenSSL FIPS module with an appropriate outside the boundary kernel module wrapper around it to form yet another platform for one of the validation numbers? Possibly. The approach we tentatively settled on was to keep and validate the existing kernel crypto code (non OpenSSL!) with the cruft to satisfy FIPS 140-2 (the POST, and also the test suite software for the algorithm testing). The hard part isn't the crypto code; it's everything else. By keeping the existing interoperable crypto API we'd get the most bank for the buck. Technically, the kernel module wrapper would interact with the same blob API that a FIPS-enabled OpenSSL uses, so there would be little or no change to FIPS module build and security guide for such additional kernel mode platforms. Inside the boundary changes would be needed only to the extent that the FIPS blob makes direct system calls, since the kernel is not a normal POSIX-like environment when seen from a kernel mode module. This could work if you weren't worried about compatibility with existing kernel crypto usage. The current OpenSSL FIPS module code would still need non-trivial massaging though. If the CMVP bureaucracy insists on a specific kernel version for the platform number, this should be one of the Long Term Support kernel releases to maximize longevity (assuming that regular OS patching within a version number is still accepted as same platform). Worse: it would need to be validated on every Operational Environment (OE): meaning every Linux distribution: Debian N.M for every N and M, Fedora N.M, Ubuntu N.M, CentOS N.M, ... -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Encryption length, OpenSSL_add_all_algorithms, and OpenSSL_add_all_ciphers questions
On 26 March 2015 at 14:53, Philip Bellino pbell...@mrv.com wrote: I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords with cipher des_ede3_cbc as follows: Your design is fundamentally flawed. You should be hashing passwords using bcrypt, pbkdf or similar not encrypting them. Regards Rich. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] QNX cross-compiled openssl with fips
Hello,
i have been able to cross-compile openssl with fips module and what i
want now is to use it within my project which is using C++. According to
the manual https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B i have
to modify fipsld to fipsld++. Everything works properly if i'm compiling
my own libraries which are being linked with static crypto.a but if i'm
going to compile some tests which are linking with those libraries i get
this error:
/usr/lib/fips_premain.o: In function `FINGERPRINT_premain()':
/usr/lib/fips_premain.c:103: undefined reference to `FIPS_text_start()'
/usr/lib/fips_premain.c:116: undefined reference to
`FIPS_incore_fingerprint(unsigned char*, unsigned int)'
According to the manual, problem occurs with C++ linker, but i have it
modified in fipsld++ so that now PREMAIN_DSO looks like:
-x c ${PREMAIN_C} -x none \
and this does not help. On Linux with gcc this was helpful but on QNX
cross compilation it does not.
I would be pleased if somebody could point me what am i doing wrong...
--
Piotr Łobacz
Biuro Systemów i Oprogramowania
RADMOR S.A.
tel. (58) 6996 929
e-mail: piotr.lob...@radmor.com.pl
www.radmor.com.pl
RADMOR S.A., ul. Hutnicza 3, 81-212 Gdynia
NIP: 586-010-21-39
REGON: 190432077
KRS: 074029 (Sąd Rejonowy Gdańsk-Północ w Gdańsku)
Kapitał zakładowy wpłacony: 9 282 830 PLN
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.0.2a CMS encrypt with ECDH EnvelopedData fails?
Hi, I am playing with openssl 1.0.2a - specifically CMS support for ECC. But what I think should work doesn't. Commands used and parsed data shown. (I gave an RSA example as a known good working example) ./openssl version OpenSSL 1.0.2a 19 Mar 2015 echo -n 12345678123456781234567812345678 sess.txt # 32 byte plaintext #EC fails ./openssl ecparam -name prime192v1 -genkey -out ecc.key ./openssl req -x509 -new -key ecc.key -out ecc.crt ./openssl cms -encrypt -in sess.txt -out encsess.bin -outform PEM ecc.crt ./openssl cms -decrypt -in encsess.bin -out decsess.txt -inform PEM -inkey ecc.key Error decrypting CMS structure error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529: EnvelopedData -- ./openssl asn1parse -in encsess.bin 0:d=0 hl=4 l= 312 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT:pkcs7-envelopedData 15:d=1 hl=4 l= 297 cons: cont [ 0 ] 19:d=2 hl=4 l= 293 cons: SEQUENCE 23:d=3 hl=2 l= 1 prim: INTEGER :02 26:d=3 hl=3 l= 234 cons: SET 29:d=4 hl=3 l= 231 cons: cont [ 1 ] 32:d=5 hl=2 l= 1 prim: INTEGER :03 35:d=5 hl=2 l= 65 cons: cont [ 0 ] 37:d=6 hl=2 l= 63 cons: cont [ 1 ] 39:d=7 hl=2 l= 9 cons: SEQUENCE 41:d=8 hl=2 l= 7 prim: OBJECT:id-ecPublicKey 50:d=7 hl=2 l= 50 prim: BIT STRING 102:d=5 hl=2 l= 28 cons: SEQUENCE 104:d=6 hl=2 l= 9 prim: OBJECT :dhSinglePass-stdDH-sha1kdf-scheme 115:d=6 hl=2 l= 15 cons: SEQUENCE 117:d=7 hl=2 l= 11 prim: OBJECT:id-smime-alg-CMS3DESwrap 130:d=7 hl=2 l= 0 prim: NULL 132:d=5 hl=3 l= 128 cons: SEQUENCE 135:d=6 hl=2 l= 126 cons: SEQUENCE 137:d=7 hl=2 l= 82 cons: SEQUENCE 139:d=8 hl=2 l= 69 cons: SEQUENCE 141:d=9 hl=2 l= 11 cons: SET 143:d=10 hl=2 l= 9 cons: SEQUENCE 145:d=11 hl=2 l= 3 prim: OBJECT:countryName 150:d=11 hl=2 l= 2 prim: PRINTABLESTRING :AU 154:d=9 hl=2 l= 19 cons: SET 156:d=10 hl=2 l= 17 cons: SEQUENCE 158:d=11 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 163:d=11 hl=2 l= 10 prim: UTF8STRING:Some-State 175:d=9 hl=2 l= 33 cons: SET 177:d=10 hl=2 l= 31 cons: SEQUENCE 179:d=11 hl=2 l= 3 prim: OBJECT:organizationName 184:d=11 hl=2 l= 24 prim: UTF8STRING:Internet Widgits Pty Ltd 210:d=8 hl=2 l= 9 prim: INTEGER :C09819AB3ECC9A05 221:d=7 hl=2 l= 40 prim: OCTET STRING [HEX DUMP]:2511DF2DBEC0F758E8CE3F35ECDD84757DEEC011633478BF00C18226FEDCD19BE5ABECEB9A735F99 263:d=3 hl=2 l= 51 cons: SEQUENCE 265:d=4 hl=2 l= 9 prim: OBJECT:pkcs7-data 276:d=4 hl=2 l= 20 cons: SEQUENCE 278:d=5 hl=2 l= 8 prim: OBJECT:des-ede3-cbc 288:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:E924DA6FC08FC3AC 298:d=4 hl=2 l= 16 prim: cont [ 0 ] cmadden@ubuntu:~/openssl-1.0.2a/apps$ Private Key cat ecc.key -BEGIN EC PARAMETERS- BggqhkjOPQMBAQ== -END EC PARAMETERS- -BEGIN EC PRIVATE KEY- MF8CAQEEGM+L8hosGlnyrOjVsCfQ5kaj42XQ1182b6AKBggqhkjOPQMBAaE0AzIA BMVGw0n/7hFdEkgi3wGOueh9P4FGBp1qL6ibDcaQUd9R6W+rFKM5LPnZ7awp2URt sw== -END EC PRIVATE KEY- Public Key Cert ./openssl asn1parse -in ecc.crt 0:d=0 hl=4 l= 434 cons: SEQUENCE 4:d=1 hl=4 l= 359 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim: INTEGER :02 13:d=2 hl=2 l= 9 prim: INTEGER :C09819AB3ECC9A05 24:d=2 hl=2 l= 10 cons: SEQUENCE 26:d=3 hl=2 l= 8 prim: OBJECT:ecdsa-with-SHA256 36:d=2 hl=2 l= 69 cons: SEQUENCE 38:d=3 hl=2 l= 11 cons: SET 40:d=4 hl=2 l= 9 cons: SEQUENCE 42:d=5 hl=2 l= 3 prim: OBJECT:countryName 47:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU 51:d=3 hl=2 l= 19 cons: SET 53:d=4 hl=2 l= 17 cons: SEQUENCE 55:d=5 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 60:d=5 hl=2 l= 10 prim: UTF8STRING:Some-State 72:d=3 hl=2 l= 33 cons: SET 74:d=4 hl=2 l= 31 cons: SEQUENCE 76:d=5 hl=2 l= 3 prim: OBJECT:organizationName 81:d=5 hl=2 l= 24 prim: UTF8STRING:Internet Widgits Pty Ltd 107:d=2 hl=2 l= 30 cons: SEQUENCE 109:d=3 hl=2 l= 13 prim: UTCTIME :150326134803Z 124:d=3 hl=2 l= 13 prim: UTCTIME :150425134803Z 139:d=2 hl=2 l= 69 cons: SEQUENCE 141:d=3 hl=2 l= 11 cons: SET 143:d=4 hl=2 l= 9 cons: SEQUENCE 145:d=5 hl=2 l= 3 prim: OBJECT:countryName 150:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU 154:d=3 hl=2 l= 19 cons: SET 156:d=4 hl=2 l= 17 cons: SEQUENCE 158:d=5 hl=2 l= 3 prim: OBJECT:stateOrProvinceName 163:d=5 hl=2 l= 10 prim: UTF8STRING:Some-State 175:d=3 hl=2 l= 33 cons: SET 177:d=4 hl=2 l= 31 cons: SEQUENCE 179:d=5 hl=2 l= 3 prim: OBJECT
Re: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
On Thu, Mar 26, 2015 at 07:56:38PM +0530, Mukesh Yadav wrote: :~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers RC4-MD5+RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 That's a bug. Between two ciphers + means AND. Right after : a + means move to the end. No cipher is both RC4-MD5 AND RC4-SHA. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
We looked at this very briefly a couple of years ago. In theory, there may be a way to achieve the goal as a loadable kernel module (a.k.a. device driver). The idea would be to have a kernel module that provides crypto support. This kernel module would be the FIPS object module, with the FIPS boundary drawn around the kernel module. This would be loaded at run time like any other device driver when FIPS mode needed to be enabled. There is likely some kernel work required to allow the ciphers in the kernel module to be injected into the crypto flow within the kernel. The other issue is getting the kernel to automatically run the FIPS integrity test on the module at load time. On 03/26/2015 10:57 AM, Steve Marquess wrote: On 03/25/2015 06:26 PM, jone...@teksavvy.com wrote: On Wed, 25 Mar 2015 17:03:04 -0400 Steve Marquess marqu...@openssl.com wrote: I wasn't aware the Linux kernel (the real one, not proprietary commercial derivatives) had a FIPS mode. Please enlighten me. It could very well be that the word 'mode' is not the right one. 'option' would perhaps be better. This article from 2009 sets the foundation: http://www.guerilla-ciso.com/archives/793 I wonder, 6 years later, what the kernel fips option implies. Maybe I could try to contact Neil Horman andéor look into the sources. That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS doesn't get you any closer to FIPS 140-2 validated kernel cryptography. Unfortunately FIPS 140-2 validation conflicts rather violently with open source software (and with software engineering best practice in general, for that matter). Even if some benevolent benefactor ponied up the quarter megabuck it would take to do an open source based kernel crypto validation, it would be fossilized code obsolete before the validation was even approved. Linux got to be as good as it is due to constant refinement and improvement; FIPS validation presumes that it is possible to write perfect code in one shot and that the environment that code runs in never changes. -Steve M. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On 03/25/2015 06:26 PM, jone...@teksavvy.com wrote: On Wed, 25 Mar 2015 17:03:04 -0400 Steve Marquess marqu...@openssl.com wrote: I wasn't aware the Linux kernel (the real one, not proprietary commercial derivatives) had a FIPS mode. Please enlighten me. It could very well be that the word 'mode' is not the right one. 'option' would perhaps be better. This article from 2009 sets the foundation: http://www.guerilla-ciso.com/archives/793 I wonder, 6 years later, what the kernel fips option implies. Maybe I could try to contact Neil Horman andéor look into the sources. That reference gives a pretty good explanation. CONFIG_CRYPTO_FIPS doesn't get you any closer to FIPS 140-2 validated kernel cryptography. Unfortunately FIPS 140-2 validation conflicts rather violently with open source software (and with software engineering best practice in general, for that matter). Even if some benevolent benefactor ponied up the quarter megabuck it would take to do an open source based kernel crypto validation, it would be fossilized code obsolete before the validation was even approved. Linux got to be as good as it is due to constant refinement and improvement; FIPS validation presumes that it is possible to write perfect code in one shot and that the environment that code runs in never changes. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
That's Right.. here is O/p Openssl-0.9.8d: :~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers RC4-MD5:RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 :~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers RC4-MD5+RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 Openssl-1.0.1h: :~/openssl-1.0.1h_install/usr/local/bin# ./openssl ciphers RC4-MD5:RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 :~/openssl-1.0.1h_install/usr/local/bin# ./openssl ciphers RC4-MD5+RC4-SHA -v Error in cipher list 4159309472:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1314: Thanks Mukesh On 26 March 2015 at 18:44, Salz, Rich rs...@akamai.com wrote: I am wondering is this newly introduced?. No it's not new. Application compiled with openssl-0.9.8d used to work when Cipher string has '+'.or ':' That release is nearly 10 years old (Sep 2006) And are you sure it worked? + tended to mean add, so :+ worked... -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS Linux kernel documentation ?
On 03/26/2015 11:30 AM, John Foley wrote: We looked at this very briefly a couple of years ago. In theory, there may be a way to achieve the goal as a loadable kernel module (a.k.a. device driver). The idea would be to have a kernel module that provides crypto support. This kernel module would be the FIPS object module, with the FIPS boundary drawn around the kernel module. This would be loaded at run time like any other device driver when FIPS mode needed to be enabled. There is likely some kernel work required to allow the ciphers in the kernel module to be injected into the crypto flow within the kernel. The other issue is getting the kernel to automatically run the FIPS integrity test on the module at load time. We looked at it in quite a bit of detail about two years ago also, to the point of developing a formal proposal for a prospective sponsor. Yes, a loadable module is the way to go. We had worked out how to do the POST at module load (including an actual implementation). But, as with any open source based FIPS validation it would have been expensive and risky, and the end result would still have been fossilized code that would always be a painfully awkward fit in the Linux ecosystem. We'd still consider tackling that, with financial sponsorship, but we have no prospects for such. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Encryption length, OpenSSL_add_all_algorithms, and OpenSSL_add_all_ciphers questions
I am using OpenSSL-1.0.2a EVP routines to encrypt and decrypt passwords with cipher des_ede3_cbc as follows: encrypt routines: EVP_CIPHER_CTX_init EVP_EncryptInit_ex EVP_EncryptUpdate EVP_EncryptFinal_ex EVP_CIPHER_CTX_cleanup decrypt routines: EVP_CIPHER_CTX_init EVP_DecryptInit_ex EVP_DecryptUpdate EVP_DecryptFinal_ex EVP_CIPHER_CTX_cleanup similar to examples found here: http://www.openssl.org/docs/crypto/EVP_CIPHER_CTX_init.html#EXAMPLES Passwords are encrypted and stored when created, and decrypted at a later time to compare against the password given upon login. None of the examples show determining the length of the encrypted information via an EVP call in order to pass that information to the decryption routines. Should I assume it is incumbent upon the coder to store the encrypted length when storing the encrypted password, for retrieval later? Or is the encrypted length put into the encrypted information so an EVP call is available to retrieve it? I believe from all the information I see that it is the former. Please confirm this for me. Also, is calling OpenSSL_add_all_algorithms (or OpenSSL_add_all_ciphers) and the corresponding EVP_cleanup call necessary for each encrypt and decrypt? My encryption and decryption seem to be working without calling those routines but after seeing them used (for examples in test/evp_test.c), I don't understand why. Any insight that can be shared would be most appreciated. Thank you. Phil Bellino Principal Software Engineer | MRV Communications Inc. 300 Apollo Drive | Chelmsford, MA 01824 Phone: 978-674-6870 | Fax: 978-674-6799 www.mrv.com [MRV-email] [E-Banner]http://www.mrv.com/landing/video-datasheet-mrvs-optidriver-platform The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is RC4-MD5 disabled on Openssl-1.0.1h
Thanks Viktor for clarification. So in case we need to use SSL_CTX_set_cipher_list(), we should use : for multiple Ciphers. and + working in old releases for same scenario can be treated as bug.. Thanks Mukesh On 26 March 2015 at 20:24, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Mar 26, 2015 at 07:56:38PM +0530, Mukesh Yadav wrote: :~/openssl-0.9.8d_install/usr/local/bin# ./openssl ciphers RC4-MD5+RC4-SHA -v RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 That's a bug. Between two ciphers + means AND. Right after : a + means move to the end. No cipher is both RC4-MD5 AND RC4-SHA. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] FIPS: Any setup required for using a default DRBG ?
Hello, Is FIPS_mode_set(1) taking care of setting up a default DRBG ? Would a subsequent call to RAND_pseudo_bytes() for instance be using the default DRBG ( 256-bit CTR AES ?) There are quite a few DRBG-related FIPS methods described in the User Guide, and one that is called FIPS_get_default_drbg(). Does this have to be actually called ? I'm asking since I added in crypto/o_fips.c a FIPS_post_set_callback() in FIPS_set_mode() with a case switch on FIPS_TEST_DRBG (amongst others). SHA256, HMAC-SHA256, AES-128-CBC, AES-256-CTR amongst others are reported to be tested, although there's no sign of the FIPS_TEST_DRBG. Nor FIPS_TEST_CONTINUOUS for that matter. Wouldn't the DRBG be tested in a 'continuous' way before each use ? - thanks. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
