From Zeke.Evans at microfocus.com Wed Sep 1 15:36:36 2021 From: Zeke.Evans at microfocus.com (Zeke Evans) Date: Wed, 1 Sep 2021 15:36:36 +0000 Subject: client authentication status Message-ID: Hi, Is there any way to check the status of client authentication sent in a TLS 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect seems to always capture the status and return an error code if it failed but not TLS 1.3. I haven't been able to find a good way to do this after SSL_connect returns. I have to handle blocking and non-blocking sockets so calling SSL_read or SSL_peek isn't an option since those could block. If client authentication happened to fail then calling those methods would work because they will return an error but if it didn't fail then they could block. Thanks, Zeke Evans -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Wed Sep 1 15:51:20 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 1 Sep 2021 08:51:20 -0700 Subject: client authentication status In-Reply-To: References: Message-ID: <20210901155119.GV19992@akamai.com> On Wed, Sep 01, 2021 at 03:36:36PM +0000, Zeke Evans wrote: > Hi, > > Is there any way to check the status of client authentication sent in a TLS 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect seems to always capture the status and return an error code if it failed but not TLS 1.3. I haven't been able to find a good way to do this after SSL_connect returns. I have to handle blocking and non-blocking sockets so calling SSL_read or SSL_peek isn't an option since those could block. If client authentication happened to fail then calling those methods would work because they will return an error but if it didn't fail then they could block. Note that the server is allowed to ignore a client cert that it doesn't like, proceeding with the connection as if the client was unauthenticated. If you need a specific signal that the server believes the client successfully authenticated, that has to be at the application layer. Did you try a zero-length SSL_read()? My recollection is that that gets far enough into the library to see if there are pending alert messages to process. -Ben From matt at openssl.org Wed Sep 1 16:06:43 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 1 Sep 2021 17:06:43 +0100 Subject: client authentication status In-Reply-To: References: Message-ID: <9a45fafe-d448-c0f5-5b9c-6ce66cb02dc0@openssl.org> On 01/09/2021 16:36, Zeke Evans wrote: > Is there any way to check the status of client authentication sent in a > TLS 1.3 handshake after SSL_connect returns?? With TLS 1.2 SSL_connect > seems to always capture the status and return an error code if it failed > but not TLS 1.3.? I haven?t been able to find a good way to do this > after SSL_connect returns.? I have to handle blocking and non-blocking > sockets so calling SSL_read or SSL_peek isn?t an option since those > could block.? If client authentication happened to fail then calling > those methods would work because they will return an error but if it > didn?t fail then they could block. At a protocol level the handshake looks like this: Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] The handshake has completed from the perspective of one of the endpoints once it has both sent and received a "Finished" message. From the above you can see that the client receives the server's "Finished" message before it sends its "Certificate"/"CertificateVerify" and "Finished" messages back to the server. At this point "SSL_connect" returns and the client is ready to start receiving application data. From the server's perspective it is still handshaking when it receives the client's certificate (because it didn't receive the client's "Finished" message yet). So the server when send an alert at this point if the certificate is not acceptable and SSL_accept() will return with a failure. The client does not know what it will receive back from the server. It could either be application data (in the case of an accepted certificate) or an alert (in the case of a reject certificate). The only way it can find out is to attempt to read data from the connection and see what it gets back. The API to do this is SSL_read()/SSL_peek(). So, to answer your question, there is no way to check the status of client authentication without calling SSL_read()/SSL_peek(). It necessarily requires an attempt to read data from the socket in order to find that status out due to the way the protocol is designed. On 01/09/2021 16:51, Benjamin Kaduk via openssl-users wrote: > Note that the server is allowed to ignore a client cert that it doesn't like, proceeding with the connection as if the client was unauthenticated. If you need a specific signal that the server believes the client successfully authenticated, that has to be at the application layer. This is true, but ultimately the client still needs to attempt to read data from the socket to figure out what the server did. > Did you try a zero-length SSL_read()? My recollection is that that gets far enough into the library to see if there are pending alert messages to process. Again, there will only be alerts to process (related to a client certificate failure) if the client has attempted to read application data. Matt From Zeke.Evans at microfocus.com Wed Sep 1 19:34:12 2021 From: Zeke.Evans at microfocus.com (Zeke Evans) Date: Wed, 1 Sep 2021 19:34:12 +0000 Subject: client authentication status In-Reply-To: <9a45fafe-d448-c0f5-5b9c-6ce66cb02dc0@openssl.org> References: <9a45fafe-d448-c0f5-5b9c-6ce66cb02dc0@openssl.org> Message-ID: Thanks for the explanation. I figured I was headed down a dead end. This will at least help me figure out how to handle things appropriately. Zeke Evans From b20001send at gmail.com Thu Sep 2 01:03:08 2021 From: b20001send at gmail.com (Nobuo Aoki) Date: Thu, 2 Sep 2021 10:03:08 +0900 Subject: =?utf-8?Q?Re=3A_Consultation=3AAdditional_=E2=80=9Cephemeral_publ?= =?utf-8?Q?ic_key=E2=80=9D_and_=E2=80=9Cephemeral_private_key=22_implement?= =?utf-8?Q?ations_for_quictls/opens?= In-Reply-To: <01e500ac-8964-0e03-63b5-d362aede7b6f@openssl.org> References: <6B6EACB1-DA02-4B2B-AFF8-D31947867732@gmail.com> <6390231A-C646-4B8A-87F1-B5B48E8558FC@gmail.com> <7617ACF1-8EE7-497C-AAAF-52A09EA68D93@gmail.com> <01e500ac-8964-0e03-63b5-d362aede7b6f@openssl.org> Message-ID: <13806532-911E-46E5-940D-246BED777A18@gmail.com> Dear OpenSSL users Thanks for thinking about it. (Especially grateful to Mr./Ms. Mattl, Michael and Kris. ) I took a little time to clarify our questions. The attached document is a diagram of our idea of how the original protocol and TLS should work together. Objective: We want to implement QUIC-TLS, which is lightweight and secure. Specifically, we would like to implement a handshake protocol by incorporating non-standard protocols. For example, we are considering a post-quantum key exchange protocol. This is just a part of our research, and we are not considering a new standardization proposal for TLS handshaking that includes the above protocols at this stage. What we would like to hear: 1. what exactly is the structure that stores ephemeral keys in ECDHE/DHE? 2. What is the function that calculates the ephemeral public key of ECDHE/DHE and stores the value in the above structure? 3. After receiving a client hello or server hello message, where is the part that extracts the ephemeral public key of the communication partner from the received message? Also, where is the place to calculate the session key from ECDHE/DHE? Additional two information. Current situation: I'm trying to implement it using "msquic". The handshake in "msquic" uses "quictls" forked from OpenSSL, but I think the implementation of the TLS handshake is based on OpenSSL. Problem: I would like to be able to use the TLS handshake part of OpenSSL (ClientHello, ServerHello) with protocol messages on behalf of ECDHE and DHE to perform key exchange and pass the generated session key to the TLS record protocol. Nobuo Aoki (master 1st student, Japan). (It seems that the file could not be attached because of the large sending byte size. Instead, I'll share it from my university's storage. Here is the link for sharing) https://hunet-my.sharepoint.com/:i:/g/personal/mg66001_e_hiroshima-cu_ac_jp/Ecmdv1CofjZCniQ9vWFSLu4Bjfm7bYuShGcdG1J0IRZzjQ?e=p5s3uV > 2021/08/30 16:57?Matt Caswell ????: > > > > On 29/08/2021 20:41, Nobuo Aoki wrote: >> I am trying to identify the implementation >> where ?ephemeral public key? and ?ephemeral private key? can be added, > > I am unclear from your question whether you are asking how to add a new public/private key scheme for integration into TLS. Or whether you are simply asking for the location in the code where the key_share is generated. If the latter then you might look here for the client side: > > https://github.com/openssl/openssl/blob/e8e1f6d1a9e599d575431f559200018b8f822e0f/ssl/statem/extensions_clnt.c#L649-L705 > > And here for the server side: > > https://github.com/openssl/openssl/blob/e8e1f6d1a9e599d575431f559200018b8f822e0f/ssl/statem/extensions_srvr.c#L1577-L1707 > > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From murugesh.pitchaiah at gmail.com Thu Sep 2 05:19:10 2021 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Thu, 2 Sep 2021 10:49:10 +0530 Subject: x509v3-sign-rsa, x509v3-ssh-rsa and x509v3-rsa2048-sha256 In-Reply-To: <1AAA4B46-5179-4793-9D29-2E37BFA579B8@webweaving.org> References: <1AAA4B46-5179-4793-9D29-2E37BFA579B8@webweaving.org> Message-ID: Thanks for the response Dirk. I tried, but could not see the certificate public key algorithm - as x509v3-ssh-rsa or x509v3-rsa2048-sha256. I use below openssl commands to generate the user certificate: openssl req -nodes -new -x509 -keyout userkey.pem -out userreq.pem -days 365 -config openssl.cnf openssl x509 -x509toreq -in userreq.pem -signkey userkey.pem -out tmp.pem openssl ca -config openssl.cnf -extensions usr_cert -out usercert.pem -infiles tmp.pem I tried varying the bits size (1024/2048/4096) and default_md (sha1/sha256/sha512) in the openssl.cnf file. Could anyone please share the steps to generate user certificates of type: x509v3-ssh-rsa and x509v3-rsa2048-sha256 ? Thanks & Regards, Murugesh P. On 8/24/21, Dirk-Willem van Gulik wrote: > On 24 Aug 2021, at 09:47, murugesh pitchaiah > wrote: >> >> Hi, >> >> I am working on generating the x509v3 certificates for ssh user. I see >> with the default_md as 'sha256', in openssl.cnf file, the >> key/certificate is generated with algorithm type as 'x509v3-sign-rsa'. >> >> I see its signature algorithm is : >> >> Signature Algorithm: sha256WithRSAEncryption >> Public Key Algorithm: rsaEncryption >> Public-Key: (2048 bit) >> >> >> Can any one please share how to generate certificate for >> x509v3-ssh-rsa and x509v3-rsa2048-sha256 ? Basically looking for >> difference between these three type of public key algorithms ,and how >> to generate certificate of these types: >> >> x509v3-sign-rsa, x509v3-ssh-rsa and x509v3-rsa2048-sha256 >> >> Because, even for x509v3-sign-rsa - I see the size is 2048 bit and it >> is sha256. Is it something to vary in 'default_md' (or newkey rsa:size >> and -sha) fields to vary to generate these different cert types ? > > Try something like > > openssl req -new -x509 -newkey rsa:1024 -sha256 -keyout /dev/stdout -nodes > -subj /CN=foo |\ > openssl x509 -pubkey -noout | openssl rsa -text -pubin -noout > > openssl req -new -x509 -newkey rsa:1024 -sha256 -keyout /dev/stdout -nodes > -subj /CN=foo |\ > openssl x509 -text -noout | grep Signature > > And vary the newkey argument to see what it actually generates as an RSA > key. > > In this example a 1024 bit one. You can also vary sha256 to things like md5, > etc. > > Dw. From romain.geissler at amadeus.com Thu Sep 2 15:43:44 2021 From: romain.geissler at amadeus.com (Romain GEISSLER) Date: Thu, 2 Sep 2021 15:43:44 +0000 Subject: Question about constness of EVP_PKEY* arguments in public API Message-ID: <07BC610F-B02E-43CC-9192-A7B60AE4A874@amadeus.com> Hi, I have some piece of software using OpenSSL that works right now on a single thread right now. I am adding a bit more "const" in the code everywhere I can as we want to start using the same code in multithreaded environment, and potentially two threads might sign/verify/encrypt/decrypt using the same EVP_PKEY argument in multiple threads. By adding "const" I try to find what shall be protected by mutex and what shall not, in case it?s mutable. I am using the following OpenSSL API: EVP_DigestSignInit, EVP_DigestVerifyInit, EVP_PKEY_size, EVP_SealInit, EVP_OpenInit. And it seems these all take an non-const EVP_PKEY* argument. Does it mean that EVP_PKEY* have some internal state which may be updated by these API and which I should definitely not call without thread syncronization in multiple threads ? Or the API of OpenSSL just miss the "const" keyword as really the key, once read, has absolutely no state modified by these APIs ? Note: I have to support several branches of my software, the oldest branches are still using the old OpenSSL 1.0.2, other branches uses OpenSSL 1.1.1, and the latest branch uses the OpenSSL 3.0 release candidate. Cheers, Romain From matt at openssl.org Thu Sep 2 16:24:01 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Sep 2021 17:24:01 +0100 Subject: Question about constness of EVP_PKEY* arguments in public API In-Reply-To: <07BC610F-B02E-43CC-9192-A7B60AE4A874@amadeus.com> References: <07BC610F-B02E-43CC-9192-A7B60AE4A874@amadeus.com> Message-ID: <0c859930-dd85-b319-4658-d32cfa71c5f2@openssl.org> On 02/09/2021 16:43, Romain GEISSLER via openssl-users wrote: > I am using the following OpenSSL API: EVP_DigestSignInit, > EVP_DigestVerifyInit, EVP_PKEY_size, EVP_SealInit, EVP_OpenInit. And > it seems these all take an non-const EVP_PKEY* argument. Does it mean > that EVP_PKEY* have some internal state which may be updated by these > API and which I should definitely not call without thread > syncronization in multiple threads ? Or the API of OpenSSL just miss > the "const" keyword as really the key, once read, has absolutely no > state modified by these APIs ? Neither of the above. EVP_PKEY has internal state which may be modified by these API calls. However that internal state is controlled by an internal lock and is therefore thread safe. Matt From bill.c.roberts at gmail.com Thu Sep 2 21:47:21 2021 From: bill.c.roberts at gmail.com (William Roberts) Date: Thu, 2 Sep 2021 16:47:21 -0500 Subject: What to replace low-level padding operations with in OSSL 3.0? Message-ID: I have code that applies PCKS1.5 padding via RSA_padding_add_PKCS1_type_1 and strips it with RSA_padding_check_PKCS1_type_2 before sending it to the HSM for raw RSA operation to support a legacy PKCS11 interface. Is there any way to perform these tasks with OpenSSL 3.0? Thanks, Bill From dipto181 at gmail.com Thu Sep 2 23:21:22 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Thu, 2 Sep 2021 17:21:22 -0600 Subject: How to get rsa-private key in plain text format? Message-ID: Hello, Is there any command-line tool to get the plain text rsa private key like the following format from .pem file? N = D0C2ACDCF780B1E4846054BDA700F18D567247FE8BC5BA4FBCAB814E619DA63A20F65A58EE89FC0824DC9367C5725BDDC596065F1C8868E99C896F3A0CF7D7F0A785E668F2568F19BAFB8FF3BA5CDF487544EFE71010BEDB4EE16EDC3AF0A71391AD3194B42D3FD40B4E0DE12A22D8188AF03FF4E36D37BA1DA1F3C57188E60DA38C25329E48805FC7FF524761A6F010E737B927D8F67383274F8E600167A52A042E1DCA3335150C090803F9D96F6E63BEBFB153516E863F5B4CB02104077834FC5EC31A47451783931D643CE736DD1BAB40C5523858BB067FB9E490DCB5FDBBB03B9D68A8998C1347E237C477AA14B0997A84708CED05A9E24C7072B838F753 E = 010001 D = 21AFE07431CE47269083F8F8B7ABCBCEDA6DCB975457BE6662942C64091586FEE755C9A3832EAA0868665DB507A41A15F1EDF12E44ECF03D0E61111D457D730FA700D0FB0B6C13607C0F5F1DDDEB61AE9019E53A9C998F2AD5924430EEA3E9DA1B0E5F2B575DDBE86C4096B5C87661F7A7E7F7F21D0701509BBA881B4AE463F6F18C7F04AB742319E2D7319EECA136EEB0CF7B2BFA87E3A0E69FBC0E5FDC7EE6271EB2CA09DDBF7C8B57D951762708D76890E62858C1D5FC5B7E40D50913CE7797BD80F6A398FB92703FBDD33FBCB129B86E54F13EC14DA68BE139634DD1E9C01F01751C427B029AF629EED23C99726F0A0C3CEA1229E4099B588CE676975D25 P = FD1120F3E183DF72779B9B4A29FF9157C89FF8204988B6FB1211642B4D59B6A1BB306E81C040F0F822B41765FC4435A46B5090700E72B9720481EACF3624885D7A263CAC0CA559954E9382FCC7D57221CD9394C64585653664976174CAE2E7DC6A7B03DE09599B5D9501927ACC4EED5F5CBC5870E31A051AF9842945A0168E35 Q = D32E15E032B256C7DE0BDB585379EB897343ABFB8C7A86A3D798C13AE3E3F048A50DA9D7C31EB65A588CF6B9911F7B41D6F154F99B4F64839E110C30BA4B79286A4A3A3F7F0169A1D3A21F0D084CFA423E04C90C5966AC391A47F10E823C71B9716856B05BC12160DF0BA96300F8ADDC0D59E54E9CBDC7AC0EA6747DBA46C067 DP = 2004DECA7CAA16C780E2AB4F42E91716A847B53940948FB24CA2EEAD9BE7D1F7BC9B701FF29744E5E05E30E7B2775EE222C1DAC492CF692F47EAB82EE786CFCA23FE5A86DA42C186E69E3B608858354C999A26A4BF7F1543408EF6C1B439E9643604C2848162590A0A245CC834B977C72D10979010EBE5E177D884F04E450C51 DQ = 9A035E48E8305041EB9AD21994A7B233C8306E59429689632C7567573FA4993521CAD93756422BD3B008FE574F939A1CE659931387455B94F1CE950964946E841F208B628B89C83411588734C5FCFDF719ABFBC459DF1B7379CB45EEC2E4BA3BF88D93CB82DF532C86FEC646420B1B21054BAE84AAA36DDFF9BF43EDFDD063B9 QP = E7A5BC150E6A20E52920C6F24FC872B1893ED9268AA506D86EC3AA6E3B377E5F6AE0D686751CE40F684435C6F64F31888861389CE430FB271EE81D0067ED8A1BD8096FB3E4AF5839383F26F99916EED4D80CFA9B5901350A9C0AAD4E348EBCC559F92434C71DA864C13371626D9F29998748BB3C47BED31471B73ABF2E27B983 If no such tool exists, Can anyone please give me an idea, how can extract keys like the above format from a .pem file? Regards, Shariful Alam -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Sep 3 03:30:25 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 2 Sep 2021 23:30:25 -0400 Subject: How to get rsa-private key in plain text format? In-Reply-To: References: Message-ID: On Thu, Sep 02, 2021 at 05:21:22PM -0600, Shariful Alam wrote: > Is there any command-line tool to get the plain text rsa private key like > the following format from .pem file? Yes, if you're willing to tolerate slightly different labels and ":" every two nibbles.With slightly different labels and ":" every two nibbles. For example: $ openssl genrsa 512 2>&1 | openssl rsa -text -noout RSA Private-Key: (512 bit, 2 primes) modulus: 00:d6:e5:14:e0:d9:42:e4:11:81:e5:cd:33:11:24: 7f:3b:08:d7:ba:16:1e:01:05:37:65:c3:41:b8:df: 3c:df:af:a3:e0:a3:02:fc:e6:20:3d:f2:c6:cc:bf: 03:0c:c0:4b:8a:78:2b:8b:55:2e:f8:3e:81:10:e9: d9:b2:46:d2:7d publicExponent: 65537 (0x10001) privateExponent: 67:e3:59:a3:96:05:0b:83:17:3c:44:66:92:bc:05: 32:42:05:20:b6:3e:8d:19:bb:7d:5b:d6:f3:0c:21: 3e:b5:a4:bd:1d:01:02:c5:37:b9:e3:ed:fb:60:33: eb:d4:f0:9f:fd:03:6d:e9:64:42:85:3d:dd:57:51: 0c:63:57:f5 prime1: 00:f6:d6:33:68:9c:5b:3e:74:7c:95:36:e1:f3:7f: 82:0d:e7:aa:65:f4:36:51:46:c0:83:92:cc:da:60: 9d:47:83 prime2: 00:de:df:52:aa:da:a9:95:06:92:e7:32:b4:28:3c: 69:58:17:31:10:69:80:89:41:f1:6f:4b:9a:7c:3f: 36:5d:ff exponent1: 19:c9:d1:3f:29:ae:c2:bc:aa:d3:70:13:75:3c:2a: 1b:47:cb:de:b1:00:07:c7:cb:8f:33:84:21:80:9c: 8d:ff exponent2: 00:d1:48:7a:53:50:13:f0:8a:04:c6:af:f9:36:d3: 4b:c4:d9:ba:4c:04:16:1c:4d:dd:0e:ba:ba:ed:b3: 5a:35:37 coefficient: 00:9f:ec:87:75:7f:31:c3:f8:17:fc:c7:c0:f4:0e: ec:2a:a5:e4:52:e1:ed:1b:c4:5a:a8:fa:35:22:28: 1f:e5:c3 -- Viktor. From Shivakumar.Poojari at rbbn.com Fri Sep 3 04:58:06 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Fri, 3 Sep 2021 04:58:06 +0000 Subject: Replacement for CRYPTO_thread_id() & ERR_get_error_line_data() for openssl3.0 Message-ID: Hi All, We are upgrading our code to openssl 3.0. the below function we trying to replace, searched in the openssl man pages not found proper information. CRYPTO_thread_id() ERR_get_error_line_data() please suggest. thanks, shivakumar. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Sep 3 07:16:53 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Sep 2021 08:16:53 +0100 Subject: What to replace low-level padding operations with in OSSL 3.0? In-Reply-To: References: Message-ID: On 02/09/2021 22:47, William Roberts wrote: > I have code that applies PCKS1.5 padding via > RSA_padding_add_PKCS1_type_1 and strips it with > RSA_padding_check_PKCS1_type_2 before sending it to the HSM for raw > RSA operation to support a legacy PKCS11 interface. Is there any way > to perform these tasks with OpenSSL 3.0? No, there is no non-deprecated way to do this in OpenSSL 3.0. Those functions still *exist* and you may still call them, but they are deprecated. Matt From matt at openssl.org Fri Sep 3 07:23:54 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Sep 2021 08:23:54 +0100 Subject: How to get rsa-private key in plain text format? In-Reply-To: References: Message-ID: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> On 03/09/2021 00:21, Shariful Alam wrote: > Hello, > Is there?any command-line tool to get the plain text rsa private key > like the following format from .pem file? openssl rsa -in mykey.pem -noout -text Matt From matt at openssl.org Fri Sep 3 07:55:13 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Sep 2021 08:55:13 +0100 Subject: Replacement for CRYPTO_thread_id() & ERR_get_error_line_data() for openssl3.0 In-Reply-To: References: Message-ID: On 03/09/2021 05:58, Shivakumar Poojari wrote: > Hi All, > > We are upgrading our code to openssl 3.0. the below function we trying > to replace, searched in the openssl man pages not found proper information. > > CRYPTO_thread_id() The deprecated implementation of this is a no-op (always returns 0). What do you need this for? This used to be useful when locking callbacks existed. But they were removed in 1.1.0. > > ERR_get_error_line_data() You can call ERR_get_error_all() as a replacement (passing a NULL value for the "func" parameter). Matt > > > please suggest. > thanks, > shivakumar. > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. From bbrumley at gmail.com Fri Sep 3 13:49:13 2021 From: bbrumley at gmail.com (Billy Brumley) Date: Fri, 3 Sep 2021 16:49:13 +0300 Subject: How to get rsa-private key in plain text format? In-Reply-To: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> References: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> Message-ID: > > Hello, > > Is there any command-line tool to get the plain text rsa private key > > like the following format from .pem file? > > openssl rsa -in mykey.pem -noout -text It would in fact be much more educational to advocate pkey, which is cryptosystem agnostic openssl pkey -in mykey.pem -noout -text Since I would expect the rsa command to go the same was as the rsautl command in the future. Happy Friday! BBB From matt at openssl.org Fri Sep 3 13:55:30 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Sep 2021 14:55:30 +0100 Subject: How to get rsa-private key in plain text format? In-Reply-To: References: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> Message-ID: On 03/09/2021 14:49, Billy Brumley wrote: >>> Hello, >>> Is there any command-line tool to get the plain text rsa private key >>> like the following format from .pem file? >> >> openssl rsa -in mykey.pem -noout -text > > It would in fact be much more educational to advocate pkey, which is > cryptosystem agnostic Good point! Matt > > openssl pkey -in mykey.pem -noout -text > > Since I would expect the rsa command to go the same was as the rsautl > command in the future. > > Happy Friday! > > BBB > From dipto181 at gmail.com Fri Sep 3 16:24:37 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Fri, 3 Sep 2021 10:24:37 -0600 Subject: How to get rsa-private key in plain text format? In-Reply-To: References: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> Message-ID: Thank you very much. So the output of "*openssl rsa -in mykey.pem -text -noout*" is a base64 hex format? Regards, Shariful On Fri, Sep 3, 2021 at 7:55 AM Matt Caswell wrote: > > > On 03/09/2021 14:49, Billy Brumley wrote: > >>> Hello, > >>> Is there any command-line tool to get the plain text rsa private key > >>> like the following format from .pem file? > >> > >> openssl rsa -in mykey.pem -noout -text > > > > It would in fact be much more educational to advocate pkey, which is > > cryptosystem agnostic > > Good point! > > Matt > > > > > openssl pkey -in mykey.pem -noout -text > > > > Since I would expect the rsa command to go the same was as the rsautl > > command in the future. > > > > Happy Friday! > > > > BBB > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Sep 3 16:29:57 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 3 Sep 2021 17:29:57 +0100 Subject: How to get rsa-private key in plain text format? In-Reply-To: References: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> Message-ID: On 03/09/2021 17:24, Shariful Alam wrote: > Thank you very much. > So the output of "*openssl rsa -in mykey.pem -text -noout*" is a base64 > hex format? It's a hex format. "base64 hex" makes no sense. base64 is not hex, and vice versa. Matt > > Regards, > Shariful > > On Fri, Sep 3, 2021 at 7:55 AM Matt Caswell > wrote: > > > > On 03/09/2021 14:49, Billy Brumley wrote: > >>> Hello, > >>> Is there any command-line tool to get the plain text rsa > private key > >>> like the following format from .pem file? > >> > >> openssl rsa -in mykey.pem -noout -text > > > > It would in fact be much more educational to advocate pkey, which is > > cryptosystem agnostic > > Good point! > > Matt > > > > > openssl pkey -in mykey.pem -noout -text > > > > Since I would expect the rsa command to go the same was as the rsautl > > command in the future. > > > > Happy Friday! > > > > BBB > > > From dipto181 at gmail.com Fri Sep 3 16:39:21 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Fri, 3 Sep 2021 10:39:21 -0600 Subject: How to get rsa-private key in plain text format? In-Reply-To: References: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> Message-ID: > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dipto181 at gmail.com Fri Sep 3 16:40:46 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Fri, 3 Sep 2021 10:40:46 -0600 Subject: How to get rsa-private key in plain text format? In-Reply-To: References: <0791401f-746d-8eef-b4bf-10951640184d@openssl.org> Message-ID: Thank you very much Regards, Shariful Alam On Fri, Sep 3, 2021 at 10:29 AM Matt Caswell wrote: > > > On 03/09/2021 17:24, Shariful Alam wrote: > > Thank you very much. > > So the output of "*openssl rsa -in mykey.pem -text -noout*" is a base64 > > hex format? > > It's a hex format. "base64 hex" makes no sense. base64 is not hex, and > vice versa. > > Matt > > > > > Regards, > > Shariful > > > > On Fri, Sep 3, 2021 at 7:55 AM Matt Caswell > > wrote: > > > > > > > > On 03/09/2021 14:49, Billy Brumley wrote: > > >>> Hello, > > >>> Is there any command-line tool to get the plain text rsa > > private key > > >>> like the following format from .pem file? > > >> > > >> openssl rsa -in mykey.pem -noout -text > > > > > > It would in fact be much more educational to advocate pkey, which > is > > > cryptosystem agnostic > > > > Good point! > > > > Matt > > > > > > > > openssl pkey -in mykey.pem -noout -text > > > > > > Since I would expect the rsa command to go the same was as the > rsautl > > > command in the future. > > > > > > Happy Friday! > > > > > > BBB > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grahame at healthintersections.com.au Mon Sep 6 06:30:46 2021 From: grahame at healthintersections.com.au (Grahame Grieve) Date: Mon, 6 Sep 2021 16:30:46 +1000 Subject: EVP_DigestSignInit ECDSA P-256 SHA-256 Message-ID: I am implementing a JWS based specification using openSSL. My code is below, in pascal. I'm trying to reproduce this test case here: https://datatracker.ietf.org/doc/html/rfc7515#appendix-A.3.1 I get a different outcome from EVP_DigestSignInit / EVP_DigestUpdate / EVP_DigestSignFinal from that specified (MEYCIQCf4hUhJvEFLZeOE4OPWrKT_LnyyNeU_1vdXgO5gqUK2AIhAILiDUd7i-FhbspRtlM90E6oSQD6eOBgiIylORcLhQbi instead of DtEhU3ljbEg8L38VWAfUAqOyKAM6-Xx-F4GawxaepmXFCgfTjDxw5djxLa8ISlSApmWQxfKTUJqPP3-Kg6NU1Q I presume that this is because of this text in the JWS spec: "The result of the digital signature is the Elliptic Curve (EC) point (R, S), where R and S are unsigned integers. The JWS Signature is the value R || S" - is that what EVP_DigestSignFinal should return? if not, how should I get R and S? Or am I thinking about this wrong somehow? thanks Grahame Code: class function TJWTUtils.Sign_ES256(input: TBytes; key: TJWK): TBytes; var ctx : PEVP_MD_CTX; keysize : integer; len : Cardinal; pkey: PEVP_PKEY; rkey: PEC_KEY; keys : TJWKList; begin check(key <> nil, 'A key must be provided for ES256'); // 1. Load the RSA private Key from FKey rkey := key.LoadEC(true); try pkey := EVP_PKEY_new; try check(EVP_PKEY_set1_EC_KEY(pkey, rkey) = 1, 'openSSL EVP_PKEY_set1_RSA failed'); // 2. do the signing keysize := EVP_PKEY_size(pkey); SetLength(result, keysize); ctx := EVP_MD_CTX_new; try check(EVP_DigestSignInit(ctx, nil, EVP_sha256, nil, pKey) = 1, 'openSSL EVP_DigestInit_ex failed'); check(EVP_DigestUpdate(ctx, @input[0], Length(input)) = 1, 'openSSL EVP_SignUpdate failed'); check(EVP_DigestSignFinal(ctx, @result[0], @len) = 1, 'openSSL EVP_SignFinal failed'); SetLength(result, len); finally EVP_MD_CTX_free(ctx); end; finally EVP_PKEY_free(pKey); end; finally EC_KEY_free(rkey); end; Signing the content: Loading the key: function TJWK.LoadEC(privkey: boolean): PEC_KEY; var pd, px, py : PBIGNUM; pub : PEC_POINT; grp : PEC_GROUP; begin check(keyType = 'EC', 'EC Key expected in JWK, but found '+KeyType); check(hasX, 'EC Key needs an X'); check(hasY, 'EC Key needs an Y'); px := bn_decode_bin(x); py := bn_decode_bin(y); pd := bn_decode_bin(privateKey); result := EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); check(result <> nil, 'EC_KEY_new_by_curve_name = nil'); grp := EC_KEY_get0_group(result); pub := EC_POINT_new(grp); check(EC_POINT_set_affine_coordinates_GFp(grp, pub, px, py, nil) = 1, 'EC_POINT_set_affine_coordinates_GFp failed'); EC_KEY_set_public_key(result, pub); if (privkey) then begin check(hasPrivateKey, 'EC Key needs an private key'); EC_KEY_set_private_key(result, pd) end; end; -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 Benson & Grieve: Principles of Health Interoperability (Health Information Technology Standards), 4th ed - http://www.springer.com/978-3-030-56882-5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angus at magsys.co.uk Mon Sep 6 09:05:00 2021 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Mon, 6 Sep 2021 10:05 +0100 (BST) Subject: EVP_DigestSignInit ECDSA P-256 SHA-256 In-Reply-To: Message-ID: > I am implementing a JWS based specification using openSSL. My > code is below, in pascal. I'm trying to reproduce this test case > here: https://datatracker.ietf.org/doc/html/rfc7515#appendix-A.3.1 > > I get a different outcome from EVP_DigestSignInit / > EVP_DigestUpdate / You could compare your result with our Delphi JWS implementation: https://svn.overbyte.be/svn/ics/trunk/Source/OverbyteIcsSslJose.pas there is an sample app that exercises all the functions. Beware the code is changing shortly since all the RSA_ and EC_ functions are deprecated in OpenSSL 3.0. Angus From Shivakumar.Poojari at rbbn.com Mon Sep 6 11:02:30 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Mon, 6 Sep 2021 11:02:30 +0000 Subject: [EXTERNAL] Re: Replacement for CRYPTO_thread_id() & ERR_get_error_line_data() for openssl3.0 In-Reply-To: References: Message-ID: Hi In the below C file, I'm trying to update eay_sterror(line:1352) function to 3.0, In eay_sterror function deprecated functions are used CRYPTO_thread_id() ERR_get_error_line_data() https://github.com/zoulasc/racoon2/blob/master/iked/crypto_openssl.c [https://opengraph.githubassets.com/df82b8dd29e00f31e323ebecf94fd0eba5f0171e46e32afa476790bda297eb5f/zoulasc/racoon2] racoon2/crypto_openssl.c at master ? zoulasc/racoon2 The Racoon2 project is a joint effort which provides an implementation of key management system for IPsec. The implementation is called Racoon2, a successor of Racoon, which was developed by the KA... github.com please suggest the replacement, thanks, shiva kumar ________________________________ From: Matt Caswell Sent: Friday, September 3, 2021 1:25 PM To: Shivakumar Poojari ; openssl-users at openssl.org Cc: Paramashivaiah, Sunil ; Bhattacharjee, Debapriyo (c) Subject: [EXTERNAL] Re: Replacement for CRYPTO_thread_id() & ERR_get_error_line_data() for openssl3.0 On 03/09/2021 05:58, Shivakumar Poojari wrote: > Hi All, > > We are upgrading our code to openssl 3.0. the below function we trying > to replace, searched in the openssl man pages not found proper information. > > CRYPTO_thread_id() The deprecated implementation of this is a no-op (always returns 0). What do you need this for? This used to be useful when locking callbacks existed. But they were removed in 1.1.0. > > ERR_get_error_line_data() You can call ERR_get_error_all() as a replacement (passing a NULL value for the "func" parameter). Matt > > > please suggest. > thanks, > shivakumar. > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 6 12:02:10 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 6 Sep 2021 13:02:10 +0100 Subject: [EXTERNAL] Re: Replacement for CRYPTO_thread_id() & ERR_get_error_line_data() for openssl3.0 In-Reply-To: References: Message-ID: <12d1bf30-274b-7f4c-3aa7-397015620652@openssl.org> On 06/09/2021 12:02, Shivakumar Poojari wrote: > Hi > > In the below C file, I'm trying to update eay_sterror(line:1352) > function to 3.0, In eay_sterror function deprecated functions are used > > CRYPTO_thread_id() > > ERR_get_error_line_data() > That function is only used for printing information. Like I said in my previous answer the ERR_get_error_line_data() call is easy to replace with ERR_get_error_all(): diff --git a/iked/crypto_openssl.c b/iked/crypto_openssl.c index eede826..e562296 100644 --- a/iked/crypto_openssl.c +++ b/iked/crypto_openssl.c @@ -1365,7 +1365,7 @@ eay_strerror(void) es = CRYPTO_thread_id(); - while ((l = ERR_get_error_line_data(&file, &line, &data, &flags)) != 0) { + while ((l = ERR_get_error_all(&file, &line, NULL, &data, &flags)) != 0) { n = snprintf(ebuf + len, sizeof(ebuf) - len, "%lu:%s:%s:%d:%s ", es, ERR_error_string(l, buf), file, line, The CRYPTO_thread_id() call is a bit trickier. It's just a function to get hold of the current thread id. In 1.0.2 the implementation of that function looked like this: unsigned long CRYPTO_thread_id(void) { unsigned long ret = 0; if (id_callback == NULL) { # ifdef OPENSSL_SYS_WIN16 ret = (unsigned long)GetCurrentTask(); # elif defined(OPENSSL_SYS_WIN32) ret = (unsigned long)GetCurrentThreadId(); # elif defined(GETPID_IS_MEANINGLESS) ret = 1L; # elif defined(OPENSSL_SYS_BEOS) ret = (unsigned long)find_thread(NULL); # else ret = (unsigned long)getpid(); # endif } else ret = id_callback(); return (ret); } So, it calls the user set callback "id_callback", which is set via a call to CRYPTO_set_id_callback(). I don't see any evidence of that actually being called anywhere in the racoon2 code which (if that is the case) means it falls back to "getpid()" on Linux/unix or GetCurrentThreadId() on windows. You can simply replace it with direct calls to those functions to get the equivalent functionality. Whether getpid() actually gives *useful* output in this context is another question...but that's the case for the old code too. Matt > > > https://github.com/zoulasc/racoon2/blob/master/iked/crypto_openssl.c > > > > racoon2/crypto_openssl.c at master ? zoulasc/racoon2 > > The Racoon2 project is a joint effort which provides an implementation > of key management system for IPsec. The implementation is called > Racoon2, a successor of Racoon, which was developed by the KA... > github.com > > > please suggest the replacement, > > thanks, > shiva kumar > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Friday, September 3, 2021 1:25 PM > *To:* Shivakumar Poojari ; > openssl-users at openssl.org > *Cc:* Paramashivaiah, Sunil ; > Bhattacharjee, Debapriyo (c) > *Subject:* [EXTERNAL] Re: Replacement for CRYPTO_thread_id() & > ERR_get_error_line_data() for openssl3.0 > > > On 03/09/2021 05:58, Shivakumar Poojari wrote: >> Hi All, >> >> We are upgrading our code to openssl 3.0. the below function we trying >> to replace, searched in the openssl man pages not found proper information. >> >> CRYPTO_thread_id() > > The deprecated implementation of this is a no-op (always returns 0). > What do you need this for? This used to be useful when locking callbacks > existed. But they were removed in 1.1.0. > >> >> ERR_get_error_line_data() > > You can call ERR_get_error_all() as a replacement (passing a NULL value > for the "func" parameter). > > > Matt > >> >> >> please suggest. >> thanks, >> shivakumar. >> >> >> Notice: This e-mail together with any attachments may contain >> information of Ribbon Communications Inc. and its Affiliates that is >> confidential and/or proprietary for the sole use of the intended >> recipient. Any review, disclosure, reliance or distribution by others or >> forwarding without express permission is strictly prohibited. If you are >> not the intended recipient, please notify the sender immediately and >> then delete all copies, including any attachments. > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. From openssl at openssl.org Tue Sep 7 12:04:20 2021 From: openssl at openssl.org (OpenSSL) Date: Tue, 7 Sep 2021 12:04:20 +0000 Subject: OpenSSL version 3.0.0 published Message-ID: <20210907120420.GA3531@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 3.0.0 released ============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 3.0.0 of our open source toolkit for SSL/TLS. For details of the changes, see the release notes at: https://www.openssl.org/news/openssl-3.0-notes.html Specific notes on upgrading to OpenSSL 3.0 from previous versions are available in the OpenSSL Migration Guide, here: https://www.openssl.org/docs/man3.0/man7/migration_guide.html OpenSSL 3.0.0 is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0.tar.gz Size: 14978663 SHA1 checksum: 3be896f1b33bc01af874ccca701a6f700af9de20 SHA256 checksum: 59eedfcb46c25214c9bd37ed6078297b4df01d012267fe9e9eee31f61bc70536 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0.tar.gz openssl sha256 openssl-3.0.0.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAmE3US4ACgkQ1enkP335 7owe+w/9FdP6I9XEuuo5O6ZOhYyzTuS8v9DGuzIzBEsBWpsA+gfOxF5Bx4WlnGAt kB+2qfNfOgt00OrSUHntgn1+ubFvN+xteaslYsF3fN9FCPX2iQzXMPVM47UqYpA5 tCm0XrJo+PAZB4mEnOH6QBXZWPTE7E84HGUNyS8LfYeEbbLKEcc/xQBPpRovL3fA 6TnMrAvypIwEqgljyNzuMq7iD5WDA0Y26JwjCCtk0vNOVkDQDooGQHMY180BLfQT Rk65hEt3/UkpLVCwCknrZsMWixXzTgcFb+403EPXMisyyQLEgxevrsGpQgINxraD 1JyRNnwJpIJuxl+j1oYjpdCbNQrQr7QKAj8pL5OGNVxXvyuZe9YyLrKmHvh09Q6M nxbJFQmCyrZQvxCya+YR2VU9KxkYiXbiX2pHl06qN8n3MOhtVaxJPKM6WUwJLlo9 qD9JmLtW4gXCH4qHcqnb8jS0Zoxja1bzWwgvQx1A9XI4s2drhRvXkQmt+lxEUdcM MiT3LrBgjfKgNa7XWmTOZxyLa74WyETVcjvI3ovJxiS4RAB7s7ssDVa8tnTUeeZG gtXSTv49+l0j+DQcz8nxQeILimOusHzE5JO3JvGQKPbSQbdUQbNrsbTEvz5mIMu9 k/VuvJd1ezjYySp9pnZ3UTxrB1RozJ97iupq8MSzwElkSfUigrg= =R5PX -----END PGP SIGNATURE----- From Shivakumar.Poojari at rbbn.com Wed Sep 8 13:07:34 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Wed, 8 Sep 2021 13:07:34 +0000 Subject: ENGINE API replacement for Openssl3.0 Message-ID: Hi Upgrading our code to openssl 3.0. the below function we trying to replace ENGINE_load_dynamic() Replacment for 3.0 what i found OPENSSL_init_crypto(OPENSSL_INIT_ENGINE_DYNAMIC, NULL) ENGINE_by_id("dynamic") ENGINE_ctrl_cmd_string() ENGINE_set_default() ENGINE_get_DH() ENGINE_free() Need a replacement for the above-highlighted function. I searched in man pages did not find any replacement and searched in google for sample programs also not found Thanks, shiva kumar. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Wed Sep 8 13:30:44 2021 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 08 Sep 2021 15:30:44 +0200 Subject: ENGINE API replacement for Openssl3.0 In-Reply-To: References: Message-ID: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> Hello, there is no direct replacement. The ENGINEs as a pluggable crypto modules concept is replaced with the providers concept which is much more sophisticated and capable. Please look at https://www.openssl.org/docs/man3.0/man7/migration_guide.html ENGINEs support is not removed from OpenSSL 3.0 however it is deprecated. If you cannot use deprecated functions you have to drop support for engines which means those functions just should not be called and there is no replacement. Providers allow for configuration via the default configuration file so for an application to support crypto modules in form of providers the application does not necessarily have to have any extra functions called. Just the default configuration file has to be present and the configuration of the desired provider(s) needs to be there. Tomas On Wed, 2021-09-08 at 13:07 +0000, Shivakumar Poojari wrote: > Hi > Upgrading our code to openssl 3.0. the below function we trying to > replace > > ENGINE_load_dynamic()?? > > Replacment for 3.0 what i > found?OPENSSL_init_crypto(OPENSSL_INIT_ENGINE_DYNAMIC, NULL) > > ENGINE_by_id("dynamic") > > ENGINE_ctrl_cmd_string() > > ENGINE_set_default() > > ENGINE_get_DH() > > ENGINE_free() > > Need a replacement for the above-highlighted function. I searched in > man pages did not find any replacement and searched in google for > sample programs also not found > > ? > Thanks, > shiva kumar. > > > > > > > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others > or forwarding without express permission is strictly prohibited. If you > are not the intended recipient, please notify the sender immediately > and then delete all copies, including any attachments. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From steffen at sdaoden.eu Wed Sep 8 21:31:40 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 08 Sep 2021 23:31:40 +0200 Subject: Congratulations! Missing 3.0.0 tag? Message-ID: <20210908213140.GRsmV%steffen@sdaoden.eu> Yeah? :) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From bill.c.roberts at gmail.com Wed Sep 8 21:38:32 2021 From: bill.c.roberts at gmail.com (William Roberts) Date: Wed, 8 Sep 2021 16:38:32 -0500 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210908213140.GRsmV%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> Message-ID: It's there: https://github.com/openssl/openssl/releases/tag/openssl-3.0.0 I checked it out this morning. On Wed, Sep 8, 2021, 16:32 Steffen Nurpmeso wrote: > Yeah? > :) > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Wed Sep 8 22:15:44 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Sep 2021 00:15:44 +0200 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: References: <20210908213140.GRsmV%steffen@sdaoden.eu> Message-ID: <20210908221544.0GzHK%steffen@sdaoden.eu> Hello. William Roberts wrote in : |It's there: |https://github.com/openssl/openssl/releases/tag/openssl-3.0.0 | |I checked it out this morning. Oh! I have fetch = +refs/heads/master:refs/remotes/origin/master fetch = +refs/heads/OpenSSL_1_0_2-stable:refs/remotes/origin/OpenSSL_1_0_2-stable fetch = +refs/heads/OpenSSL_1_0_1-stable:refs/remotes/origin/OpenSSL_1_0_1-stable fetch = +refs/heads/OpenSSL_1_1_0-stable:refs/remotes/origin/OpenSSL_1_1_0-stable fetch = +refs/heads/OpenSSL_1_1_1-stable:refs/remotes/origin/OpenSSL_1_1_1-stable and only saw refs/tags/openssl-3.0.0-alpha* and -beta*! I see now via ls-remote there is a new openssl-3.0 branch.. From git://git.openssl.org/openssl * [new branch] openssl-3.0 -> origin/openssl-3.0 * [new tag] openssl-3.0.0 -> openssl-3.0.0 Yes, there it is, thank you! P.S.: maybe at least release commits and tags could be signed? And/or HTTPS access to the repository ... but then i get the gut feeling that the answer to this will be "use github" or something. Ciao! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From bill.c.roberts at gmail.com Wed Sep 8 22:21:47 2021 From: bill.c.roberts at gmail.com (William Roberts) Date: Wed, 8 Sep 2021 17:21:47 -0500 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210908221544.0GzHK%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> Message-ID: On Wed, Sep 8, 2021 at 5:15 PM Steffen Nurpmeso wrote: > > Hello. > > William Roberts wrote in > : > |It's there: > |https://github.com/openssl/openssl/releases/tag/openssl-3.0.0 > | > |I checked it out this morning. > > Oh! I have > > fetch = +refs/heads/master:refs/remotes/origin/master > fetch = +refs/heads/OpenSSL_1_0_2-stable:refs/remotes/origin/OpenSSL_1_0_2-stable > fetch = +refs/heads/OpenSSL_1_0_1-stable:refs/remotes/origin/OpenSSL_1_0_1-stable > fetch = +refs/heads/OpenSSL_1_1_0-stable:refs/remotes/origin/OpenSSL_1_1_0-stable > fetch = +refs/heads/OpenSSL_1_1_1-stable:refs/remotes/origin/OpenSSL_1_1_1-stable > > and only saw refs/tags/openssl-3.0.0-alpha* and -beta*! > I see now via ls-remote there is a new openssl-3.0 branch.. > > From git://git.openssl.org/openssl > * [new branch] openssl-3.0 -> origin/openssl-3.0 > * [new tag] openssl-3.0.0 -> openssl-3.0.0 > > Yes, there it is, thank you! > > P.S.: maybe at least release commits and tags could be signed? > And/or HTTPS access to the repository ... but then i get the gut > feeling that the answer to this will be "use github" or something. > You could grab the release tarballs which have signatures https://www.openssl.org/source/ From bkaduk at akamai.com Wed Sep 8 22:22:48 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 8 Sep 2021 15:22:48 -0700 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210908221544.0GzHK%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> Message-ID: <20210908222248.GX19992@akamai.com> On Thu, Sep 09, 2021 at 12:15:44AM +0200, Steffen Nurpmeso wrote: > > P.S.: maybe at least release commits and tags could be signed? > And/or HTTPS access to the repository ... but then i get the gut > feeling that the answer to this will be "use github" or something. tag openssl-3.0.0 Tagger: Richard Levitte Date: Tue Sep 7 13:46:40 2021 +0200 OpenSSL 3.0.0 release tag -----BEGIN PGP SIGNATURE----- iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w== =pGf9 -----END PGP SIGNATURE----- looks signed to me. -Ben From steffen at sdaoden.eu Wed Sep 8 23:03:28 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Sep 2021 01:03:28 +0200 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210908222248.GX19992@akamai.com> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> Message-ID: <20210908230328.WBzAR%steffen@sdaoden.eu> Benjamin Kaduk wrote in <20210908222248.GX19992 at akamai.com>: |On Thu, Sep 09, 2021 at 12:15:44AM +0200, Steffen Nurpmeso wrote: |> |> P.S.: maybe at least release commits and tags could be signed? |> And/or HTTPS access to the repository ... but then i get the gut |> feeling that the answer to this will be "use github" or something. | |tag openssl-3.0.0 |Tagger: Richard Levitte |Date: Tue Sep 7 13:46:40 2021 +0200 | |OpenSSL 3.0.0 release tag |-----BEGIN PGP SIGNATURE----- | |iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF |O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w== |=pGf9 |-----END PGP SIGNATURE----- | |looks signed to me. That is really interesting now. If i use "git show openssl-3.0.0" i see this myself. tag openssl-3.0.0 Tagger: Richard Levitte TaggerDate: 2021-09-07 13:46:40 +0200 OpenSSL 3.0.0 release tag -----BEGIN PGP SIGNATURE----- iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w== =pGf9 -----END PGP SIGNATURE----- commit 89cd17a031 (tag: refs/tags/openssl-3.0.0) ... But if i use #?0|kent:tls-openssl.git$ alias gl1 alias gl1='git slpn -1' #?0|kent:tls-openssl.git$ git alias|grep slpn alias.slpn log --show-signature --patch --find-renames --stat --no-abbrev-commit #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: refs/tags/openssl-3.0.0) ... i do not. Hm, maybe i need to relearn git again, looking around i see a couple of projects for which this is true (Linux, wireguard-tools), for others it is not (my own project, nghttp2). Eg "alias.slo log --show-signature --oneline --graph": #?141|kent:nail.git$ git slo -1 master Reading passphrase from file descriptor 4 * 69be61071c (...) gpg: Signature made Wed 01 Sep 2021 01:19:46 PM CEST | gpg: using RSA key DF082F6AEEC8C2FF | gpg: Good signature from "Steffen Nurpmeso " | gpg: WARNING: This key is not certified with a trusted signature! | gpg: There is no indication that the signature belongs to the owner. | Primary key fingerprint: EE19 E1C1 F2F7 054F 8D39 54D8 3089 64B5 1883 A0DD | Subkey fingerprint: 8A2A 4D60 9FDC 539C 75F5 5B95 DF08 2F6A EEC8 C2FF | Clear an installed alarm(2) in fork(2)ed childs (Stephen Isard) #?0|kent:nghttp2.git$ git slo -1 fcc20334da Reading passphrase from file descriptor 4 * fcc20334da gpg: Signature made Sat 04 Sep 2021 10:26:47 AM CEST |\ gpg: using RSA key 4AEE18F83AFDEB23 | | gpg: Can't check signature: public key not found | | Merge pull request #1613 from mkauf/check_pseudo_header_chars #?0|kent:wireguard-tools.git$ git slo -1 v1.0.20210424 * ecb1ea29d7 (tag: refs/tags/v1.0.20210424) version: bump #?128|kent:linux.git$ git slo -1 v5.10.62 * f6dd002450 (tag: refs/tags/v5.10.62, refs/remotes/origin/linux-5.10.y) Linux 5.10.62 Ooops, i am totally off again. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From pauli at openssl.org Wed Sep 8 23:18:04 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Thu, 9 Sep 2021 09:18:04 +1000 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210908230328.WBzAR%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> Message-ID: With the change to (almost) semantic versioning, we also decided to make the tags easier to type. Pauli On 9/9/21 9:03 am, Steffen Nurpmeso wrote: > Benjamin Kaduk wrote in > <20210908222248.GX19992 at akamai.com>: > |On Thu, Sep 09, 2021 at 12:15:44AM +0200, Steffen Nurpmeso wrote: > |> > |> P.S.: maybe at least release commits and tags could be signed? > |> And/or HTTPS access to the repository ... but then i get the gut > |> feeling that the answer to this will be "use github" or something. > | > |tag openssl-3.0.0 > |Tagger: Richard Levitte > |Date: Tue Sep 7 13:46:40 2021 +0200 > | > |OpenSSL 3.0.0 release tag > |-----BEGIN PGP SIGNATURE----- > | > |iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF > |O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w== > |=pGf9 > |-----END PGP SIGNATURE----- > | > |looks signed to me. > > That is really interesting now. > If i use "git show openssl-3.0.0" i see this myself. > > tag openssl-3.0.0 > Tagger: Richard Levitte > TaggerDate: 2021-09-07 13:46:40 +0200 > > OpenSSL 3.0.0 release tag > -----BEGIN PGP SIGNATURE----- > > iFwEABECAB0WIQTEyrdJw09/TMBP2smnr5549wlFOwUCYTdRIAAKCRCnr5549wlF > O7wEAJ90wRuQnQYdf7RrzD7p2tf2eZhP4QCXeXX3a1IgbIgfU7WuLZ44BbXF7w== > =pGf9 > -----END PGP SIGNATURE----- > > commit 89cd17a031 (tag: refs/tags/openssl-3.0.0) > ... > > But if i use > > #?0|kent:tls-openssl.git$ alias gl1 > alias gl1='git slpn -1' > #?0|kent:tls-openssl.git$ git alias|grep slpn > alias.slpn log --show-signature --patch --find-renames --stat --no-abbrev-commit > #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 > commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: refs/tags/openssl-3.0.0) > ... > > i do not. Hm, maybe i need to relearn git again, looking around > i see a couple of projects for which this is true (Linux, > wireguard-tools), for others it is not (my own project, nghttp2). > Eg "alias.slo log --show-signature --oneline --graph": > > #?141|kent:nail.git$ git slo -1 master > Reading passphrase from file descriptor 4 > * 69be61071c (...) gpg: Signature made Wed 01 Sep 2021 01:19:46 PM CEST > | gpg: using RSA key DF082F6AEEC8C2FF > | gpg: Good signature from "Steffen Nurpmeso " > | gpg: WARNING: This key is not certified with a trusted signature! > | gpg: There is no indication that the signature belongs to the owner. > | Primary key fingerprint: EE19 E1C1 F2F7 054F 8D39 54D8 3089 64B5 1883 A0DD > | Subkey fingerprint: 8A2A 4D60 9FDC 539C 75F5 5B95 DF08 2F6A EEC8 C2FF > | Clear an installed alarm(2) in fork(2)ed childs (Stephen Isard) > > #?0|kent:nghttp2.git$ git slo -1 fcc20334da > Reading passphrase from file descriptor 4 > * fcc20334da gpg: Signature made Sat 04 Sep 2021 10:26:47 AM CEST > |\ gpg: using RSA key 4AEE18F83AFDEB23 > | | gpg: Can't check signature: public key not found > | | Merge pull request #1613 from mkauf/check_pseudo_header_chars > > #?0|kent:wireguard-tools.git$ git slo -1 v1.0.20210424 > * ecb1ea29d7 (tag: refs/tags/v1.0.20210424) version: bump > > #?128|kent:linux.git$ git slo -1 v5.10.62 > * f6dd002450 (tag: refs/tags/v5.10.62, refs/remotes/origin/linux-5.10.y) Linux 5.10.62 > > Ooops, i am totally off again. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > From bkaduk at akamai.com Wed Sep 8 23:36:39 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 8 Sep 2021 16:36:39 -0700 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210908230328.WBzAR%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> Message-ID: <20210908233639.GY19992@akamai.com> On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: > But if i use > > #?0|kent:tls-openssl.git$ alias gl1 > alias gl1='git slpn -1' > #?0|kent:tls-openssl.git$ git alias|grep slpn > alias.slpn log --show-signature --patch --find-renames --stat --no-abbrev-commit > #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 > commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: refs/tags/openssl-3.0.0) > ... > > i do not. Hm, maybe i need to relearn git again, looking around > i see a couple of projects for which this is true (Linux, > wireguard-tools), for others it is not (my own project, nghttp2). > Eg "alias.slo log --show-signature --oneline --graph": I think (off the top of my head, i.e., without consulting a reference) that `git log` (which your aliases end up at) will only display signatures on commits, but will not show the tag objects themselves. `git show` does display the tag object, and for openssl only the tag object is what is signed; the commits themselves are not signed. -Ben From steffen at sdaoden.eu Thu Sep 9 10:56:18 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Sep 2021 12:56:18 +0200 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210908233639.GY19992@akamai.com> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> <20210908233639.GY19992@akamai.com> Message-ID: <20210909105618.lWplW%steffen@sdaoden.eu> Benjamin Kaduk wrote in <20210908233639.GY19992 at akamai.com>: |On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: |> But if i use |> |> #?0|kent:tls-openssl.git$ alias gl1 |> alias gl1='git slpn -1' |> #?0|kent:tls-openssl.git$ git alias|grep slpn |> alias.slpn log --show-signature --patch --find-renames --stat --no-abbr\ |> ev-commit |> #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 |> commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: refs/tags/openssl\ |> -3.0.0) |> ... |> |> i do not. Hm, maybe i need to relearn git again, looking around |> i see a couple of projects for which this is true (Linux, |> wireguard-tools), for others it is not (my own project, nghttp2). | |I think (off the top of my head, i.e., without consulting a reference) |that `git log` (which your aliases end up at) will only display |signatures on commits, but will not show the tag objects themselves. |`git show` does display the tag object, and for openssl only the tag |object is what is signed; the commits themselves are not signed. I see. That is a logical one, thanks for the explanation. Sometimes one (Me! That is.) really would have to drop all entrenched habits, aliases and scripts and do anything anew. For example i now have learned that "push" also can be signed! (And yes, i do use commit -S and tag -s for release tags for .. many years.) |-Ben --End of <20210908233639.GY19992 at akamai.com> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rsbecker at nexbridge.com Thu Sep 9 15:24:31 2021 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Thu, 9 Sep 2021 11:24:31 -0400 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: References: <20210908213140.GRsmV%steffen@sdaoden.eu> Message-ID: <011c01d7a58e$cd007fa0$67017ee0$@nexbridge.com> When git cloning, please remember that you might have to perform a git fetch --tags to pick up all tags from the upstream repository. After that, perform a git checkout openssl-3.0.0, which will give you a disconnected HEAD, but will refer to the correct release. You can always make your own branch to point there. Do not use the openssl-3.0 branch for building 3.0.0 ? it already points to a new commit in the preparation for the subsequent release. Randall S. Becker, ITUGLIB Process Designer, Repository Manager, Occasional Porting Dude +1.416.984.9826 From: openssl-users On Behalf Of William Roberts Sent: September 8, 2021 5:39 PM To: openssl-users at openssl.org Subject: Re: Congratulations! Missing 3.0.0 tag? It's there: https://github.com/openssl/openssl/releases/tag/openssl-3.0.0 I checked it out this morning. On Wed, Sep 8, 2021, 16:32 Steffen Nurpmeso > wrote: Yeah? :) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsbecker at nexbridge.com Thu Sep 9 15:35:32 2021 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Thu, 9 Sep 2021 11:35:32 -0400 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210909105618.lWplW%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> <20210908233639.GY19992@akamai.com> <20210909105618.lWplW%steffen@sdaoden.eu> Message-ID: <012201d7a590$56df08d0$049d1a70$@nexbridge.com> On September 9, 2021 6:56 AM, Steffen Nurpmeso wrote: >Benjamin Kaduk wrote in > <20210908233639.GY19992 at akamai.com>: > |On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: > |> But if i use > |> > |> #?0|kent:tls-openssl.git$ alias gl1 > |> alias gl1='git slpn -1' > |> #?0|kent:tls-openssl.git$ git alias|grep slpn > |> alias.slpn log --show-signature --patch --find-renames --stat --no-abbr\ > |> ev-commit > |> #?0|kent:tls-openssl.git$ gl1 openssl-3.0.0 > |> commit 89cd17a031e022211684eb7eb41190cf1910f9fa (tag: refs/tags/openssl\ > |> -3.0.0) > |> ... > |> > |> i do not. Hm, maybe i need to relearn git again, looking around |> i see a couple of projects for which this is true (Linux, |> >wireguard-tools), for others it is not (my own project, nghttp2). > | > |I think (off the top of my head, i.e., without consulting a reference) |that `git log` (which your aliases end up at) will only display >|signatures on commits, but will not show the tag objects themselves. > |`git show` does display the tag object, and for openssl only the tag |object is what is signed; the commits themselves are not signed. > >I see. That is a logical one, thanks for the explanation. >Sometimes one (Me! That is.) really would have to drop all entrenched habits, aliases and scripts and do anything anew. For example i >now have learned that "push" also can be signed! (And yes, i do use commit -S and tag -s for release tags for .. many >years.) > > |-Ben > --End of <20210908233639.GY19992 at akamai.com> > >--steffen $ git tag --verify openssl-3.0.0 object 89cd17a031e022211684eb7eb41190cf1910f9fa type commit tag openssl-3.0.0 tagger Richard Levitte 1631015200 +0200 OpenSSL 3.0.0 release tag gpg: Signature made Tue Sep 7 07:46:40 2021 EDT gpg: using DSA key A7AF9E78F709453B gpg: Can't check signature: public key not found Although I do not have Richard's public key on the system where I ran the command and GitHub is not showing the verification status of the tag. -Randall From steffen at sdaoden.eu Thu Sep 9 19:25:47 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Sep 2021 21:25:47 +0200 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <012201d7a590$56df08d0$049d1a70$@nexbridge.com> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> <20210908233639.GY19992@akamai.com> <20210909105618.lWplW%steffen@sdaoden.eu> <012201d7a590$56df08d0$049d1a70$@nexbridge.com> Message-ID: <20210909192547.lML-o%steffen@sdaoden.eu> Randall S. Becker wrote in <012201d7a590$56df08d0$049d1a70$@nexbridge.com>: |On September 9, 2021 6:56 AM, Steffen Nurpmeso wrote: |>Benjamin Kaduk wrote in |> <20210908233639.GY19992 at akamai.com>: |>|On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: ... |>|I think (off the top of my head, i.e., without consulting a reference) \ |>| |that `git log` (which your aliases end up at) will only |display |>|signatures on commits, but will not show the tag objects themselves. |>|`git show` does display the tag object, and for openssl only the \ |>|tag |object is what is signed; the commits themselves are not |signed. |> |>I see. That is a logical one, thanks for the explanation. ... |$ git tag --verify openssl-3.0.0 Yes yes, ok! But like i said, wouldn't it be nice if at least release commits would be signed also, a.k.a./or when a new branch is created? In Linux for example the merge commits to the master branch are signed, in addition to the tags of the actual releases. It may even be a deja vu and i may have clamoured in the past. ... |Although I do not have Richard's public key on the system where I ran \ |the command and GitHub is not showing the verification status |of the tag. I do not know much about github. In fact i did not even know that the Linux release commits are _not_ signed, because if i look (what do _i_ know from the kernel?) then i only look at master, and there you see signed commits. And since my url= is https i do not actually verify tags. (In fact it is automated and simply diff(1)s in the difference to the version stated in the Makefile in /usr/src/linux/.) But true, the last merge before Linux 5.14 was signed, but the creation of the linux-5.14.y branch not. Ach, forget about the noise, i hope next time i finally have my head turned on before i post :) Thank you. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rsbecker at nexbridge.com Thu Sep 9 20:16:46 2021 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Thu, 9 Sep 2021 16:16:46 -0400 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210909192547.lML-o%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> <20210908233639.GY19992@akamai.com> <20210909105618.lWplW%steffen@sdaoden.eu> <012201d7a590$56df08d0$049d1a70$@nexbridge.com> <20210909192547.lML-o%steffen@sdaoden.eu> Message-ID: <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com> On September 9, 2021 3:26 PM, Steffen Nurpmeso wrote: >To: Randall S. Becker >Cc: 'Benjamin Kaduk' ; openssl-users at openssl.org >Subject: Re: Congratulations! Missing 3.0.0 tag? > >Randall S. Becker wrote in > <012201d7a590$56df08d0$049d1a70$@nexbridge.com>: > |On September 9, 2021 6:56 AM, Steffen Nurpmeso wrote: > |>Benjamin Kaduk wrote in > |> <20210908233639.GY19992 at akamai.com>: > |>|On Thu, Sep 09, 2021 at 01:03:28AM +0200, Steffen Nurpmeso wrote: > ... > |>|I think (off the top of my head, i.e., without consulting a reference) \ |>| |that `git log` (which your aliases end up at) will only >|display |>|signatures on commits, but will not show the tag objects themselves. > |>|`git show` does display the tag object, and for openssl only the \ |>|tag |object is what is signed; the commits themselves are not >|signed. > |> > |>I see. That is a logical one, thanks for the explanation. > ... > |$ git tag --verify openssl-3.0.0 > >Yes yes, ok! But like i said, wouldn't it be nice if at least release commits would be signed also, a.k.a./or when a new branch is created? >In Linux for example the merge commits to the master branch are signed, in addition to the tags of the actual releases. >It may even be a deja vu and i may have clamoured in the past. Strictly speaking, the signature on a tag is considered immutable and transitively applies the signature to the commit (it does not really, but the effect is the same). The signature on a tag becomes invalid if the underlying commit, or parents of that commit in git's Merkel Tree changes, so it is quite a strong signature. AFIAK, adding a signature to the commit itself does not really improve the strength of the signing (much), unless one implements a multi-signature structure - like the commit and signatures on three tags on the same commit. You have then implemented a three-signature authority, which basically is a Blockchain-style authority (not quite - I used "-style"), providing that you do trust the signers. I think the word for that is "over-kill" ?, but maybe not in the case of OpenSSL. -Randall From steffen at sdaoden.eu Thu Sep 9 20:34:14 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Sep 2021 22:34:14 +0200 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> <20210908233639.GY19992@akamai.com> <20210909105618.lWplW%steffen@sdaoden.eu> <012201d7a590$56df08d0$049d1a70$@nexbridge.com> <20210909192547.lML-o%steffen@sdaoden.eu> <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com> Message-ID: <20210909203414.veRMl%steffen@sdaoden.eu> Randall S. Becker wrote in <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com>: ... You are right in everything that you say. |Strictly speaking, the signature on a tag is considered immutable and \ |transitively applies the signature to the commit (it does not really, \ |but the effect is the same). The signature on a tag becomes invalid \ The tag namespace is separate though. Not that it matters in practice. Just saying. |if the underlying commit, or parents of that commit in git's Merkel \ |Tree changes, so it is quite a strong signature. AFIAK, adding a signature \ |to the commit itself does not really improve the strength of the signing \ |(much), unless one implements a multi-signature structure - like the \ |commit and signatures on three tags on the same commit. You have then \ |implemented a three-signature authority, which basically is a Blockchain\ |-style authority (not quite - I used "-style"), providing that you \ |do trust the signers. I think the word for that is "over-kill" ?, \ |but maybe not in the case of OpenSSL. Well. The thing is, to me, that commits happen much more often than tags. Tags are in a different namespace also. "Sealing the branches" with a signed commit at times helps in case of trouble, even for a distributed version control system like git, with its "hardened SHA-1" checksums. So of course all the core developers and a lot of other people have full repo clones and shall someone break in some infrastructure and mess around the OpenSSL team could simply talk and exchange hashes, and reinstantiate the master proper. For people having local clones that came in via git:// protocol even a signed commit here and there would really be nice. (For my tiny things i offer only https?, and "seal" all stable/ and release/ branches as well as master, only the development branches have no signature.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rsbecker at nexbridge.com Thu Sep 9 21:03:21 2021 From: rsbecker at nexbridge.com (Randall S. Becker) Date: Thu, 9 Sep 2021 17:03:21 -0400 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <20210909203414.veRMl%steffen@sdaoden.eu> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> <20210908233639.GY19992@akamai.com> <20210909105618.lWplW%steffen@sdaoden.eu> <012201d7a590$56df08d0$049d1a70$@nexbridge.com> <20210909192547.lML-o%steffen@sdaoden.eu> <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com> <20210909203414.veRMl%steffen@sdaoden.eu> Message-ID: <015301d7a5be$22589940$6709cbc0$@nexbridge.com> On September 9, 2021 4:34 PM, Steffen Nurpmeso wrote: >Randall S. Becker wrote in > <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com>: > ... > >You are right in everything that you say. > > |Strictly speaking, the signature on a tag is considered immutable and \ |transitively applies the signature to the commit (it does not >really, \ |but the effect is the same). The signature on a tag becomes invalid \ > >The tag namespace is separate though. Not that it matters in practice. Just saying. > > |if the underlying commit, or parents of that commit in git's Merkel \ |Tree changes, so it is quite a strong signature. AFIAK, adding a >signature \ |to the commit itself does not really improve the strength of the signing \ |(much), unless one implements a multi-signature >structure - like the \ |commit and signatures on three tags on the same commit. You have then \ |implemented a three-signature >authority, which basically is a Blockchain\ |-style authority (not quite - I used "-style"), providing that you \ |do trust the signers. I think >the word for that is "over-kill" ?, \ |but maybe not in the case of OpenSSL. > >Well. The thing is, to me, that commits happen much more often than tags. Tags are in a different namespace also. "Sealing the >branches" with a signed commit at times helps in case of trouble, even for a distributed version control system like git, with its "hardened >SHA-1" checksums. So of course all the core developers and a lot of other people have full repo clones and shall someone break in some >infrastructure and mess around the OpenSSL team could simply talk and exchange hashes, and reinstantiate the master proper. For >people having local clones that came in via git:// protocol even a signed commit here and there would really be nice. (For my tiny things i >offer only https?, and "seal" all stable/ and release/ branches as well as master, only the development branches have no signature.) The git signature structure is based on GPG signatures for one, not SHA-1. The tag namespace does not matter here. The signature becomes invalid if the combined tree of the commit the tag references changes. If the commit is replaced, the signature becomes invalid regardless of who does it. You can replace a signed commit with another signed commit but you would need to have the public side of the GPG key to validate it. A tag would not point to the new commit without breaking the signature. No one could replace Richard's signature, for example, except for Richard on the openssl-3.0.0 tag. The "breaking the infrastructure" would have to reconstruct the Merkel Tree, which, even in SHA-1 has a one in a billion chance of working, but that is unlikely to result in useful source code. So there is a certain amount of trust of the signatures of the committers - they should probably publish their public keys so we can do the validation. It might be helpful if GitHub moved to SHA-256 repositories, though. From steffen at sdaoden.eu Thu Sep 9 21:09:09 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Sep 2021 23:09:09 +0200 Subject: Congratulations! Missing 3.0.0 tag? In-Reply-To: <015301d7a5be$22589940$6709cbc0$@nexbridge.com> References: <20210908213140.GRsmV%steffen@sdaoden.eu> <20210908221544.0GzHK%steffen@sdaoden.eu> <20210908222248.GX19992@akamai.com> <20210908230328.WBzAR%steffen@sdaoden.eu> <20210908233639.GY19992@akamai.com> <20210909105618.lWplW%steffen@sdaoden.eu> <012201d7a590$56df08d0$049d1a70$@nexbridge.com> <20210909192547.lML-o%steffen@sdaoden.eu> <014c01d7a5b7$a0a7d1f0$e1f775d0$@nexbridge.com> <20210909203414.veRMl%steffen@sdaoden.eu> <015301d7a5be$22589940$6709cbc0$@nexbridge.com> Message-ID: <20210909210909.2i1PC%steffen@sdaoden.eu> Randall S. Becker wrote in <015301d7a5be$22589940$6709cbc0$@nexbridge.com>: .. |cture" would have to reconstruct the Merkel Tree, which, even in SHA-1 \ Now you digress. But i had nothing to say from the start.. Good night! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From kgoldman at us.ibm.com Thu Sep 9 23:07:16 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 9 Sep 2021 19:07:16 -0400 Subject: EVP_MAC_init - specify the hash algorithm In-Reply-To: <1eaf59cc-8570-eae6-4882-67e60fb0f345@openssl.org> References: <1eaf59cc-8570-eae6-4882-67e60fb0f345@openssl.org> Message-ID: Where does one get the parameter values? E.g., where would I see the value strings for the EVP_MAC_new algorithm and the digest parameter values. I can guess HMAC and SHA256, but are they documented? Case sensitive? Which is preferred? You use EVP_MAC_new, which is undocumented. The doc sample uses EVP_MAC_fetch. Which is preferred? On 7/13/2021 7:06 PM, Dr Paul Dale wrote: > > Your code should look more like: > > OSSL_PARAMS params[2]; > EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL); > EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac); > EVP_MAC_free(mac); /* Now or later is all good and depends on the app reusing it or not */ > > params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", 0); > params[1] = OSSL_PARAMS_construct_end(); > > EVP_MAC_init(mac_ctx, key, key_len, params); > EVP_MAC_update(mac_ctx, data1, data1_len); > EVP_MAC_update(mac_ctx, data2, data2_len); > EVP_MAC_update(mac_ctx, data3, data3_len); > EVP_MAC_final(mac_ctx, out, &out_size, out_len); > EVP_MAC_CTX_free(mac_ctx); > From pauli at openssl.org Fri Sep 10 02:50:31 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Fri, 10 Sep 2021 12:50:31 +1000 Subject: EVP_MAC_init - specify the hash algorithm In-Reply-To: References: <1eaf59cc-8570-eae6-4882-67e60fb0f345@openssl.org> Message-ID: My mistake, it's EVP_MAC_fetch not EVP_MAC_new. The names are all case insensitive and are documented in the man7 pages: https://www.openssl.org/docs/man3.0/man7/EVP_MAC-HMAC.html and https://www.openssl.org/docs/man3.0/man7/EVP_MD-SHA2.html. The HMAC parameter names and types are also there: https://www.openssl.org/docs/man3.0/man7/EVP_MAC-HMAC.html Pauli On 10/9/21 9:07 am, Ken Goldman wrote: > Where does one get the parameter values? > > E.g., where would I see the value strings for the EVP_MAC_new algorithm > and the digest parameter values. > > I can guess HMAC and SHA256, but are they documented? > > Case sensitive?? Which is preferred? > > You use EVP_MAC_new, which is undocumented.? The doc sample > uses EVP_MAC_fetch.? Which is preferred? > > On 7/13/2021 7:06 PM, Dr Paul Dale wrote: >> >> Your code should look more like: >> >> ??? OSSL_PARAMS params[2]; >> ??? EVP_MAC *mac = EVP_MAC_new(NULL, "HMAC", NULL); >> ??? EVP_MAC_CTX *mac_ctx = EVP_MAC_CTX_new(mac); >> ??? EVP_MAC_free(mac); /* Now or later is all good and depends on the >> app reusing it or not */ >> >> ??? params[0] = OSSL_PARAMS_construct_utf8_string("digest", "SHA256", >> 0); >> ??? params[1] = OSSL_PARAMS_construct_end(); >> >> ??? EVP_MAC_init(mac_ctx, key, key_len, params); >> ??? EVP_MAC_update(mac_ctx, data1, data1_len); >> ??? EVP_MAC_update(mac_ctx, data2, data2_len); >> ??? EVP_MAC_update(mac_ctx, data3, data3_len); >> ??? EVP_MAC_final(mac_ctx, out, &out_size, out_len); >> ??? EVP_MAC_CTX_free(mac_ctx); >> > > > From francescoscalise89 at gmail.com Fri Sep 10 08:28:20 2021 From: francescoscalise89 at gmail.com (francesco scalise) Date: Fri, 10 Sep 2021 10:28:20 +0200 Subject: Digitally Sign Document Message-ID: Hi. Briefly, my goal is to digitally sign a document using the API of the Cloud Signature Consortium for the remote part and openssl for the local part. First of alI I tried signing only locally, providing hard-coded certificate and private key. It works like a charm. Here, the snippet I used for the purpose. ``` *static* *void* sign_with_signer( CustomSigner &signer, X509 *cert, EVP_PKEY *pkey ) { *[...]* *int* rc; BIO *mem = BIO_new( BIO_s_mem() ); *if*( !mem ) { *[...]* } *unsigned* *int* flags = PKCS7_DETACHED | PKCS7_BINARY; PKCS7 *pkcs7 = PKCS7_sign( cert, pkey, *NULL*, mem, flags ); *if*( !pkcs7 ) { BIO_free( mem ); *[...]* } *while*( len = signer.ReadForSignature( pBuffer, uBufferLen ), len > 0 ) { rc = BIO_write( mem, pBuffer, len ); *if*( *static_cast*<*unsigned* *int*>( rc ) != len ) { PKCS7_free( pkcs7 ); BIO_free( mem ); *[...]* } } * [...]* *if*( PKCS7_final( pkcs7, mem, flags ) <= 0 ) { PKCS7_free( pkcs7 ); BIO_free( mem ); *[...]* } *bool* success = *false*; BIO *out = BIO_new( BIO_s_mem() ); *if*( !out ) { PKCS7_free( pkcs7 ); BIO_free( mem ); *[...]* } *char* *outBuff = *NULL*; *long* outLen; i2d_PKCS7_bio( out, pkcs7 ); outLen = BIO_get_mem_data( out, &outBuff ); *if*( outLen > 0 && outBuff ) { *if*( *static_cast*( outLen ) > signer.GetSignatureSize() ) { PKCS7_free( pkcs7 ); BIO_free( out ); BIO_free( mem ); *[...]* } Signature signature( outBuff, outLen ); signer.SetSignature( signature ); success = *true*; } PKCS7_free( pkcs7 ); BIO_free( out ); BIO_free( mem ); *if*( !success ) *[...]* } ``` Now using the CSC `credentials/info` API I have: ``` "cert": { "status": "valid", "certificates": [ "", "", "" ], "issuerDN": "", "serialNumber": "5AAC41CD8FA22B953640", "subjectDN": "", "validFrom": "20180101100000Z", "validTo": "20190101095959Z" }, ``` So I have to build the X509 which I need to sign the document. I guess using something like that: ``` *bool* pdf::CryptoModule::make_certificate(*const* *char* *data, X509 **out_cert) { *if*( !data || !*data ) { *return* *false*; } *if*( !out_cert ) { *return* *false*; } BIO *bio; bio = BIO_new(BIO_s_mem()); BIO_puts(bio, data); // *out_cert = PEM_read_bio_X509(bio, NULL, NULL, NULL); *out_cert = d2i_X509_bio(bio, *NULL*); *if*( !*out_cert ) { *return* *false*; } *return* *true*; } ``` But at this point I don't have the private key! Instead, CSC `signatures/signHash` will provide me the signature object to apply to the document. ``` { "signatures": [ "KedJuTob5gtvYx9qM3k3gm7kbLBwVbEQRl26S2tmXjqNND7MRGtoew==", "Idhef7xzgtvYx9qM3k3gm7kbLBwVbE98239S2tm8hUh85KKsfdowel==" ] } ``` Here is how things should work: [image: page64image25534384] At this point I would like to understand what are the openSSL APIs to use for - get the X509s - get the raw signature of the document to be passed to the Signer who will apply it. In my humble opinion the ``` PKCS7 *PKCS7_encrypt(STACK_OF(X509) *certs, BIO **in*, *const* EVP_CIPHER *cipher, *int* flags); *int* PKCS7_add_attrib_content_type(PKCS7_SIGNER_INFO *si, ASN1_OBJECT *coid); *int* PKCS7_add0_attrib_signing_time(PKCS7_SIGNER_INFO *si, ASN1_TIME *t); *int* PKCS7_add1_attrib_digest(PKCS7_SIGNER_INFO *si, *const* *unsigned* *char* *md, *int* mdlen); ``` could be what is right for me, but I'm not sure how to use it. Thank you very much and have a nice day! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Sat Sep 11 14:10:13 2021 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 11 Sep 2021 10:10:13 -0400 Subject: OpenSSL 3.0.0 on Solaris SPARC64 Message-ID: Merely an FYI that all seems to be working well. There are a few tests that fail and they are the same ones I saw in the beta releases. I can follow up with details later but for now I am curious what the directory "lib/engines-3" is for ? I get that as an empty directory and my configuration was : ./Configure solaris64-sparcv9-cc no-asm --prefix=/opt/bw shared no-engine -DPEDANTIC So the no-engine may just mean I get an empty directory result ? beta # /opt/bw/bin/openssl version OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021) beta # Looks fine and with a slight adjustment to the Makefile I do not get that annoying lib/64 directory. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From dclarke at blastwave.org Sun Sep 12 02:29:07 2021 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 11 Sep 2021 22:29:07 -0400 Subject: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu ) Message-ID: This is slightly better than the beta release : Test Summary Report ------------------- 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 90-test_ige.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 What can I dig into here to get more information and perhaps we solve these two little tests fails? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From bkaduk at akamai.com Sun Sep 12 03:39:35 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Sat, 11 Sep 2021 20:39:35 -0700 Subject: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu ) In-Reply-To: References: Message-ID: <20210912033935.GA19992@akamai.com> On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users wrote: > > This is slightly better than the beta release : > > Test Summary Report > ------------------- > 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > 90-test_ige.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > > > What can I dig into here to get more information and perhaps we solve > these two little tests fails? `make V=1 TESTS="test_internal_modes test_ige" test` -Ben From pauli at openssl.org Sun Sep 12 03:57:43 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Sun, 12 Sep 2021 13:57:43 +1000 Subject: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu ) In-Reply-To: <20210912033935.GA19992@akamai.com> References: <20210912033935.GA19992@akamai.com> Message-ID: <573d3815-0690-ecf7-bad9-5f12be8b1252@openssl.org> What Ben suggests is a great start. Note that none of the core developers have Solaris access, so that debugging could be problematic. Pauli On 12/9/21 1:39 pm, Benjamin Kaduk via openssl-users wrote: > On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users wrote: >> This is slightly better than the beta release : >> >> Test Summary Report >> ------------------- >> 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) >> Failed test: 1 >> Non-zero exit status: 1 >> 90-test_ige.t (Wstat: 256 Tests: 1 Failed: 1) >> Failed test: 1 >> Non-zero exit status: 1 >> >> >> What can I dig into here to get more information and perhaps we solve >> these two little tests fails? > `make V=1 TESTS="test_internal_modes test_ige" test` > > -Ben > From erik at efca.com Sun Sep 12 04:43:56 2021 From: erik at efca.com (Erik Forsberg) Date: Sat, 11 Sep 2021 21:43:56 -0700 Subject: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu ) In-Reply-To: <573d3815-0690-ecf7-bad9-5f12be8b1252@openssl.org> References: <573d3815-0690-ecf7-bad9-5f12be8b1252@openssl.org> Message-ID: Must be SPARC-specific, all tests pass on my x86/x64 Solaris 11.4 using latest GCC (11.2) >-- Original Message -- > >What Ben suggests is a great start. > >Note that none of the core developers have Solaris access, so that >debugging could be problematic. > > >Pauli > > >On 12/9/21 1:39 pm, Benjamin Kaduk via openssl-users wrote: >> On Sat, Sep 11, 2021 at 10:29:07PM -0400, Dennis Clarke via openssl-users wrote: >>> This is slightly better than the beta release : >>> >>> Test Summary Report >>> ------------------- >>> 03-test_internal_modes.t (Wstat: 256 Tests: 1 Failed: 1) >>> Failed test: 1 >>> Non-zero exit status: 1 >>> 90-test_ige.t (Wstat: 256 Tests: 1 Failed: 1) >>> Failed test: 1 >>> Non-zero exit status: 1 >>> >>> >>> What can I dig into here to get more information and perhaps we solve >>> these two little tests fails? >> `make V=1 TESTS="test_internal_modes test_ige" test` >> >> -Ben >> > From reinier.torenbeek at gmail.com Sun Sep 12 17:34:51 2021 From: reinier.torenbeek at gmail.com (Reinier Torenbeek) Date: Sun, 12 Sep 2021 14:34:51 -0300 Subject: Reducing the footprint of a simple application Message-ID: Hi, I have a simple application that uses OpenSSL 3.0.0 for AES-GCM encryption and decryption only. Looking at the size of the binary on disc, I see it's a few KBs when linking dynamically with libcrypto, and 4.8 MB when linking statically. Although I know the large footprint of OpenSSL is considered "a fact of life", this seems excessive. From experience with other crypto implementations, I know that the *actual* crypto functionality that I am using can fit in 10s of KBs and I would like to understand the reasons for OpenSSL's size better. I am on Linux, 64 bits, using gcc 9.3.0. Some analysis of the binary reveals (not surprisingly) that it contains many OpenSSL symbols that have nothing to do with the functionality that I am using. Those seem to get pulled in because objects get linked in as a whole and apparently the layout of the object contents are such that the symbols needed for my functionality are spread out over many different objects. It was my hope that I could mitigate this by compiling OpenSSL and my application with the flags -ffunction-sections, -fdata-sections, -Os and -flto and using --gc-sections and -flto when linking. (See 3.10 Options That Control Optimization of GCC's documentation). This did reduce the binary size by 2 MB, leaving me with almost 3 MB. Almost 90% of that was in the text section and a bit over 10% in the data section. I do not have sufficient experience with these options to assess how well the optimizations worked in this case, I think the resulting binary is still pretty large. I have not tried disabling any of the features when building OpenSSL. I suspect that may help a little bit because it may result in a decrease in size of (some) objects, but I have seen people reporting disappointing results of that on the web. Also, it does not seem to be a workable approach in general to have to figure out which build options to use and to have to rebuild OpenSSL for every type of application that I create. Did any people here try similar things, with better results? Does anybody have any other suggestions as to what I could try? And what is the explanation (or justification) for this excessive footprint? Thanks, Reinier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.lana at oracle.com Mon Sep 13 10:47:30 2021 From: jan.lana at oracle.com (Jan Lana) Date: Mon, 13 Sep 2021 12:47:30 +0200 Subject: [External] : Re: OpenSSL 3.0.0 two tests fail on Solaris 10 SPARC64 ( Oracle/Fujitsu ) In-Reply-To: References: <573d3815-0690-ecf7-bad9-5f12be8b1252@openssl.org> Message-ID: V?Sat, Sep 11, 2021 at 09:43:56PM -0700,?Erik Forsberg napsal(a): >Must be SPARC-specific, all tests pass on my x86/x64 Solaris 11.4 using latest GCC (11.2) according the latest buildbot results the tests pass https://fips.buildbot.openssl.org/#/builders/45/builds/370/steps/5/logs/stdio 61 03-test_internal_modes.t ........... ok ... 244 90-test_ige.t ...................... ok (with Studio compiler) I run the test locally on 3.0.0 release build an it pass as well (studio compiler): >>> `make V=1 TESTS="test_internal_modes test_ige" test` make depend && make _tests ( SRCTOP=../../openssl-3.0.0 \ BLDTOP=. \ PERL="/usr/perl5/5.32/bin/perl" \ FIPSKEY="f4556650ac31d35461610bac4ed81b1a181b2d8a43ea2854cbae22ca74560813" \ EXE_EXT= \ /usr/perl5/5.32/bin/perl ../../openssl-3.0.0/test/run_tests.pl test_internal_modes test_ige ) 00-prep_fipsmodule_cnf.t .. # The results of this test will end up in test-runs/prep_fipsmodule 1..1 HMAC : (Module_Integrity) : Pass SHA1 : (KAT_Digest) : Pass SHA2 : (KAT_Digest) : Pass SHA3 : (KAT_Digest) : Pass TDES : (KAT_Cipher) : Pass AES_GCM : (KAT_Cipher) : Pass AES_ECB_Decrypt : (KAT_Cipher) : Pass RSA : (KAT_Signature) : RNG : (Continuous_RNG_Test) : Pass Pass ECDSA : (PCT_Signature) : Pass ECDSA : (PCT_Signature) : Pass DSA : (PCT_Signature) : Pass TLS13_KDF_EXTRACT : (KAT_KDF) : Pass TLS13_KDF_EXPAND : (KAT_KDF) : Pass TLS12_PRF : (KAT_KDF) : Pass PBKDF2 : (KAT_KDF) : Pass SSHKDF : (KAT_KDF) : Pass KBKDF : (KAT_KDF) : Pass HKDF : (KAT_KDF) : Pass SSKDF : (KAT_KDF) : Pass X963KDF : (KAT_KDF) : Pass X942KDF : (KAT_KDF) : Pass HASH : (DRBG) : Pass CTR : (DRBG) : Pass HMAC : (DRBG) : Pass DH : (KAT_KA) : Pass ECDH : (KAT_KA) : Pass RSA_Encrypt : (KAT_AsymmetricCipher) : Pass RSA_Decrypt : (KAT_AsymmetricCipher) : Pass RSA_Decrypt : (KAT_AsymmetricCipher) : Pass INSTALL PASSED ../../util/wrap.pl ../../apps/openssl fipsinstall -module ../../providers/fips.so -provider_name fips -section_name fips_sect -out ../../test/fipsmodule.cnf => 0 ok 1 - fips install ok All tests successful. Files=1, Tests=1, 1 wallclock secs ( 0.03 usr 0.02 sys + 0.80 cusr 0.12 csys = 0.97 CPU) Result: PASS 03-test_internal_modes.t .. # The results of this test will end up in test-runs/test_internal_modes 1..1 # Subtest: ../../test/modes_internal_test 1..3 # Subtest: test_aes_cts128 1..6 # INFO: # aes_cts128_vector_17 ok 1 - iteration 1 # INFO: # aes_cts128_vector_31 ok 2 - iteration 2 # INFO: # aes_cts128_vector_32 ok 3 - iteration 3 # INFO: # aes_cts128_vector_47 ok 4 - iteration 4 # INFO: # aes_cts128_vector_48 ok 5 - iteration 5 # INFO: # aes_cts128_vector_64 ok 6 - iteration 6 ok 1 - test_aes_cts128 # Subtest: test_aes_cts128_nist 1..6 # INFO: # aes_cts128_nist_vector_17 ok 7 - iteration 1 # INFO: # aes_cts128_nist_vector_31 ok 8 - iteration 2 # INFO: # aes_cts128_nist_vector_32 ok 9 - iteration 3 # INFO: # aes_cts128_nist_vector_47 ok 10 - iteration 4 # INFO: # aes_cts128_nist_vector_48 ok 11 - iteration 5 # INFO: # aes_cts128_nist_vector_64 ok 12 - iteration 6 ok 2 - test_aes_cts128_nist # Subtest: test_gcm128 1..20 ok 13 - iteration 1 ok 14 - iteration 2 ok 15 - iteration 3 ok 16 - iteration 4 ok 17 - iteration 5 ok 18 - iteration 6 ok 19 - iteration 7 ok 20 - iteration 8 ok 21 - iteration 9 ok 22 - iteration 10 ok 23 - iteration 11 ok 24 - iteration 12 ok 25 - iteration 13 ok 26 - iteration 14 ok 27 - iteration 15 ok 28 - iteration 16 ok 29 - iteration 17 ok 30 - iteration 18 ok 31 - iteration 19 ok 32 - iteration 20 ok 3 - test_gcm128 ../../util/wrap.pl ../../test/modes_internal_test => 0 ok 1 - running modes_internal_test ok 90-test_ige.t ............. # The results of this test will end up in test-runs/test_ige 1..1 # Subtest: ../../test/igetest 1..10 ok 1 - test_ige_enc_dec ok 2 - test_ige_enc_chaining ok 3 - test_ige_dec_chaining ok 4 - test_ige_garble_forwards ok 5 - test_bi_ige_enc_dec ok 6 - test_bi_ige_garble1 ok 7 - test_bi_ige_garble2 ok 8 - test_bi_ige_garble3 # Subtest: test_ige_vectors 1..2 ok 1 - iteration 1 ok 2 - iteration 2 ok 9 - test_ige_vectors # Subtest: test_bi_ige_vectors 1..2 ok 3 - iteration 1 ok 4 - iteration 2 ok 10 - test_bi_ige_vectors ../../util/wrap.pl ../../test/igetest => 0 ok 1 - running igetest ok All tests successful. Files=2, Tests=2, 2 wallclock secs ( 0.02 usr 0.02 sys + 1.15 cusr 0.24 csys = 1.43 CPU) Result: PASS `test' is up to date. I'll try to build openssl with gcc and reproduce your issue. regards, -- Jan Lana | Systems Security Compliance and Globalization Phone: +420 221 438 800 Oracle Czech, U Trezorky 921/2, 158 00 Praha 5, Czech Republic From kory at avatarci.com Mon Sep 13 22:19:13 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Mon, 13 Sep 2021 15:19:13 -0700 Subject: OpenSSL 3.0.0 custom entropy source Message-ID: <10312BEE-8543-42EF-B7DD-F665AF89A8B7@avatarci.com> Hi, We are upgrading from OpenSSL 1.0.1g+OpenSSL-FIPS-2.0.5 to 3.0.0. Yes, I know, big jump. We have our own entropy source we use to seed the OpenSSL DRBG. This is a basic code snippet of how we set it up: DRBG_CTX *dctx = FIPS_get_default_drbg(); FIPS_drbg_init(dctx, NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); FIPS_drbg_set_callbacks(dctx, rand_get_entropy, rand_free_entropy, 0, rand_get_entropy, rand_free_entropy); Error checking has been removed in the example for the sake of brevity. I am trying to figure out how to implement this with OpenSSL 3. From what I have read in the docs, I need to create a rand provider. But I still feel like I don?t understand how it all fit together. I did look at fuzz_rand.c and fake_rand.c, and if I understood everything correctly, neither of them use an external entropy/seed source. Are there better examples of what I am looking for? Thanks, Kory From pauli at openssl.org Mon Sep 13 23:00:06 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 14 Sep 2021 09:00:06 +1000 Subject: OpenSSL 3.0.0 custom entropy source In-Reply-To: <10312BEE-8543-42EF-B7DD-F665AF89A8B7@avatarci.com> References: <10312BEE-8543-42EF-B7DD-F665AF89A8B7@avatarci.com> Message-ID: Try working from providers/implementations/rands/seed_src.c? You'll need to reimplement seed_src_generate() to use your RNG. To use your custom seed source, you can either use the OpenSSL configuration file to set a "random" section that includes a "seed" setting or you can call RAND_set_seed_source_type() early in your startup sequence. Pauli On 14/9/21 8:19 am, Kory Hamzeh wrote: > Hi, > > We are upgrading from OpenSSL 1.0.1g+OpenSSL-FIPS-2.0.5 to 3.0.0. Yes, I know, big jump. We have our own entropy source we use to seed the OpenSSL DRBG. This is a basic code snippet of how we set it up: > > DRBG_CTX *dctx = FIPS_get_default_drbg(); > FIPS_drbg_init(dctx, NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); > FIPS_drbg_set_callbacks(dctx, > rand_get_entropy, > rand_free_entropy, > 0, > rand_get_entropy, > rand_free_entropy); > > > Error checking has been removed in the example for the sake of brevity. > > I am trying to figure out how to implement this with OpenSSL 3. From what I have read in the docs, I need to create a rand provider. But I still feel like I don?t understand how it all fit together. I did look at fuzz_rand.c and fake_rand.c, and if I understood everything correctly, neither of them use an external entropy/seed source. > > Are there better examples of what I am looking for? > > Thanks, > Kory > From kory at avatarci.com Mon Sep 13 23:13:31 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Mon, 13 Sep 2021 16:13:31 -0700 Subject: openssl 3.0.0 legacy provider won't lload via config file Message-ID: <0455B902-B5BE-44F8-A951-2180D098BF2C@avatarci.com> I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far, everything seems to be working fine, except for the fact that I cannot get OpenSSL to load the legacy module when I configure /ssl/openssl.cnf as such. I can, however, load the module explicitly at run time. This is a diff of my config file against a stock openssl.cnf.dist: --- openssl.cnf.dist 2021-09-13 10:04:16.287697686 -0700 +++ openssl.cnf 2021-09-13 10:27:23.595752186 -0700 @@ -56,6 +56,7 @@ # List of providers to load [provider_sect] default = default_sect +legacy = legacy_sect # The fips section name should match the section name inside the # included fipsmodule.cnf. # fips = fips_sect @@ -69,8 +70,10 @@ # OpenSSL may not work correctly which could lead to significant system # problems including inability to remotely access the system. [default_sect] -# activate = 1 +activate = 1 +[legacy_sect] +activate = 1 You?ll notice the only changes I made was to activate the default module, define a legacy section and activate it also. This is the code snippet that gets called from main(): #ifdef LOAD_PROVIDER OSSL_PROVIDER *legacy; legacy = OSSL_PROVIDER_load(NULL, "legacy"); if (legacy == NULL) { printf("Failed to load Legacy provider\n"); exit(EXIT_FAILURE); } #endif #ifdef CALL_CRYPTO_INIT if (!OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG, NULL)) { printf("Error: crypto_init failed\n"); exit(1); } #endif if(!(e = EVP_CIPHER_CTX_new())) { printf("Could not create EVP instance\n"); return -1; } if((ret = EVP_DecryptInit_ex(e, EVP_des_ecb(), NULL, key, NULL)) != 1) { printf("DecryptInit failed\n"); return -1; } The EVP_DecryptInit_ex() fails if I compile without -DLOAD_PROVIDER. The other flag, CRYPTO_INIT does not make any difference. What is puzzling is that I can build OpenSSL natively on an x86_64 machine and using the same openssl.cnf file, the code above works and the legacy module loads without the code to explicitly load it. Any thoughts on what I may have done wrong or how to track this down? Thanks, Kory From selva.nair at gmail.com Tue Sep 14 02:08:41 2021 From: selva.nair at gmail.com (Selva Nair) Date: Mon, 13 Sep 2021 22:08:41 -0400 Subject: On reference counting keydata returned from keymgmt_load() Message-ID: Hi, When an EVP_PKEY is created with some custom data, provider's keymgmt_load() gets called. I want to keep a reference count on the keydata returned from it. But there is no call to keymgmt_free() or anything similar when the EVP_PKEY is freed. How does one keep track of references to keydata? I have something like: OSSL_STORE_open_ex(my_custom_uri, libctx, props,....) while (!OSSL_STORE_eof(ctx)) { OSSL_STORE_INFO *info = OSSL_STORE_load(ctx); switch(OSSL_STORE_INFO_get_type(info)) { case OSSL_STORE_INFO_PKEY: pkey = OSSL_STORE_INFO_get0_PKEY(info); (tried .._get1_PKEY(info) as well). .... The pkey seems to be correctly constructed with a call to my keymgmt_load() where I construct keydata from the passed in reference. On duplicating the key I do see calls to keymgmt_dup() and a matching keymgmt_free() (when the key is freed), so that part is good. I'm still figuring out the new interface and likely doing something wrong. Thanks, Selva -------------- next part -------------- An HTML attachment was scrubbed... URL: From selva.nair at gmail.com Tue Sep 14 05:22:36 2021 From: selva.nair at gmail.com (Selva Nair) Date: Tue, 14 Sep 2021 01:22:36 -0400 Subject: On reference counting keydata returned from keymgmt_load() In-Reply-To: References: Message-ID: Hi, Replying to self.. On Mon, Sep 13, 2021 at 10:08 PM Selva Nair wrote: > Hi, > > When an EVP_PKEY is created with some custom data, provider's > keymgmt_load() gets called. I want to keep a reference count on the keydata > returned from it. But there is no call to keymgmt_free() or anything > similar when the EVP_PKEY is freed. How does one keep track of references > to keydata? I have something like: > Please ignore the noise. OSSL_STORE_INFO_free(info) was missing and that was holding the key. Indeed keymgmt_load() is paired with keymgmt_free(). Should have checked twice before posting. Selva > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Tue Sep 14 07:03:54 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 14 Sep 2021 09:03:54 +0200 Subject: openssl 3.0.0 legacy provider won't lload via config file In-Reply-To: <0455B902-B5BE-44F8-A951-2180D098BF2C@avatarci.com> References: <0455B902-B5BE-44F8-A951-2180D098BF2C@avatarci.com> Message-ID: <43efa5a497e6aa24528751c0192a4248aa0a8168.camel@openssl.org> On Mon, 2021-09-13 at 16:13 -0700, Kory Hamzeh wrote: > I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far, everything > seems to be working fine, except for the fact that I cannot get > OpenSSL to load the legacy module when I configure /ssl/openssl.cnf > as such. I can, however, load the module explicitly at run time. > ... > > The EVP_DecryptInit_ex() fails if I compile without -DLOAD_PROVIDER. > The other flag, CRYPTO_INIT does not make any difference. What is > puzzling is that I can build OpenSSL natively on an x86_64 machine > and using the same openssl.cnf file, the code above works and the > legacy module loads without the code to explicitly load it. > > Any thoughts on what I may have done wrong or how to track this down? Could it be that your cross-compiled build expects the configuration file to be somewhere else? Have you tried to strace the application to see where it searches for the openssl.cnf? -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tomas at openssl.org Tue Sep 14 07:07:59 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 14 Sep 2021 09:07:59 +0200 Subject: Blog post about Let's Encrypt root certificate expiration and OpenSSL 1.0.2 Message-ID: <85fcaa4a7ab407cbe8d0ca3ac31642b59d5ea889.camel@openssl.org> I've written a blog post to explain the situation with the old Let's Encrypt root certificate expiration which will happen on 2021-09-30 and the behavior of OpenSSL 1.0.2 with that root certificate. Please read, if interested: https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ Regards, -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From jb-openssl at wisemo.com Tue Sep 14 09:58:49 2021 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 14 Sep 2021 11:58:49 +0200 Subject: Reducing the footprint of a simple application In-Reply-To: References: Message-ID: Hi fellow sufferer, I used to do a lot of manual patching of OpenSSL 1.0.x to remove the insane object interdependencies (such as objects named foolib.c being nexus points that bring in tonnes of irrelevant code because someone was too unfamiliar with basic library concepts to make an actual library instead of a monolithic file). However the rush to repeatedly rewrite and deprecate everything after the new people joined the OpenSSL project made maintaining the needed patches too time consuming. Some day, I will have to start over turning the 3.0.x code into an actual library while removing linker mishandling, low security RNGs and other antifeatures. On 2021-09-12 19:34, Reinier Torenbeek wrote: > Hi, > > I have a simple application that uses OpenSSL 3.0.0 for AES-GCM > encryption and decryption only. Looking at the size of the binary on > disc, I see it's a few KBs when linking dynamically with libcrypto, > and ?4.8 MB when linking statically. Although I know the large > footprint of OpenSSL is considered "a fact of life", this seems > excessive. From experience?with other crypto implementations, I know > that the *actual* crypto functionality that I am using can fit in 10s > of KBsand I would like to understand the reasons for OpenSSL's size > better. I am on Linux, 64 bits, using gcc 9.3.0. > > Some analysis of the binary reveals (not surprisingly) that it > contains many OpenSSL symbols that have nothing to do with the > functionality that I am using. Those seem to get pulled in because > objects get linked in as a whole and apparently the layout of the > object contents are such that the symbols needed for my functionality > are spread out over many different objects. > > It was my hope that I could mitigate this by compiling OpenSSL and my > application with the flags?-ffunction-sections, -fdata-sections, -Os > and -flto and using --gc-sections and -flto when linking. (See 3.10 > Options That Control Optimization > ?of > GCC's documentation).? This did reduce the binary size by 2 MB, > leaving me with almost 3 MB. Almost 90% of that was in the text > section and a bit over 10% in the data section. I do not have > sufficient experience with these options to assess how well the > optimizations worked in this case, I think the resulting binary is > still pretty large. > > I have not tried disabling any of the features when building OpenSSL. > I suspect that may help a little bit because it may result in a > decrease in size of (some) objects, but I have seen people reporting > disappointing?results of that?on?the web. Also, it does not seem to be > a workable approach in general to have to figure out which build > options to use and to have to rebuild OpenSSL for every type of > application that I create. > > Did?any people here try similar things, with better results? Does > anybody have any other suggestions as to what I could try? And what is > the explanation (or justification) for this excessive footprint? > > Thanks, > Reinier Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Tue Sep 14 10:14:15 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 14 Sep 2021 20:14:15 +1000 Subject: Reducing the footprint of a simple application In-Reply-To: References: Message-ID: <5f0c7c4c-d712-d026-1bb9-461a8fc8b591@openssl.org> > ...low security RNGs and other antifeatures. Huh????? Where?? Why plural? The only **one** I'm aware of is the one I added to stochastically flush the property cache where it doesn't need to be cryptographically secure. Pauli From kgoldman at us.ibm.com Tue Sep 14 15:11:43 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 14 Sep 2021 11:11:43 -0400 Subject: Openssl 3.0.0. EVP_PKEY_CTX vs EVP_PKEY Message-ID: Conceptually, how are these different? When do I use one vs the other? Where would I learn this? From tomas at openssl.org Tue Sep 14 15:40:51 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 14 Sep 2021 17:40:51 +0200 Subject: Openssl 3.0.0. EVP_PKEY_CTX vs EVP_PKEY In-Reply-To: References: Message-ID: <7efe8001455da03d35f4597d4be45dd54183d34b.camel@openssl.org> On Tue, 2021-09-14 at 11:11 -0400, Ken Goldman wrote: > Conceptually, how are these different? > > When do I use one vs the other? The EVP_PKEY is an object holding data (well, rather a reference, but that is fairly irrelevant) of a private key, public key, or domain parameters for asymetric crypto keys. The EVP_PKEY_CTX is an operation context - that is a context to make some operations with an EVP_PKEY such as signing/verification, encryption/decryption, key generation (starting with domain parameters EVP_PKEY), key checking. > Where would I learn this? I suppose in the manual pages - I'd start with EVP_PKEY_new and EVP_PKEY_CTX_new man pages. Yeah, the discoverability is not that good I suppose. And there is no good high level overview. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From kgoldman at us.ibm.com Tue Sep 14 18:42:03 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 14 Sep 2021 14:42:03 -0400 Subject: Openssl 3.0.0. EVP_PKEY_CTX vs EVP_PKEY In-Reply-To: <7efe8001455da03d35f4597d4be45dd54183d34b.camel@openssl.org> References: <7efe8001455da03d35f4597d4be45dd54183d34b.camel@openssl.org> Message-ID: On 9/14/2021 11:40 AM, Tomas Mraz wrote: > On Tue, 2021-09-14 at 11:11 -0400, Ken Goldman wrote: >> Conceptually, how are these different? >> >> When do I use one vs the other? > > The EVP_PKEY is an object holding data (well, rather a reference, but > that is fairly irrelevant) of a private key, public key, or domain > parameters for asymetric crypto keys. > > The EVP_PKEY_CTX is an operation context - that is a context to make > some operations with an EVP_PKEY such as signing/verification, > encryption/decryption, key generation (starting with domain parameters > EVP_PKEY), key checking. > >> Where would I learn this? > > I suppose in the manual pages - I'd start with EVP_PKEY_new and > EVP_PKEY_CTX_new man pages. Yeah, the discoverability is not that good > I suppose. And there is no good high level overview. In other words, the EVP_PKEY holds the public key. When I want to use it to encrypt / verify, I create a temporary EVP_PKEY_CTX? Is that it? Do I also use a ctx to initialize the key? Perhaps, to make the EVP_PKEY from n and e.: OSSL_PARAM_BLD_push_BN() for n and e parameters EVP_PKEY_CTX_new_from_name the RSA EVP_PKEY_fromdata using the parameters From kgoldman at us.ibm.com Tue Sep 14 23:19:11 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 14 Sep 2021 19:19:11 -0400 Subject: Openssl 3.0.0. EVP_PKEY RSA is NULL In-Reply-To: References: Message-ID: I am doing the following, but the EVP_PKEY->pkey->rsa is null. Am I misusing the API or missing a step? (error checking removed) EVP_PKEY *rsa_pub_key = NULL; EVP_PKEY_CTX *ctx = NULL; OSSL_PARAM_BLD *param_bld = NULL; OSSL_PARAM *params = NULL; BIGNUM * n = NULL; BIGNUM * e = NULL; [these bignums are initialized using bin2bn] param_bld = OSSL_PARAM_BLD_new(); irc = OSSL_PARAM_BLD_push_BN(param_bld, "n", n); irc = OSSL_PARAM_BLD_push_BN(param_bld, "e", e); params = OSSL_PARAM_BLD_to_param(param_bld); (do I perhaps need an 'end'? ctx = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL); irc = EVP_PKEY_fromdata_init(ctx); irc = EVP_PKEY_fromdata(ctx, (EVP_PKEY **)rsa_pub_key, /* freed by caller */ EVP_PKEY_PUBLIC_KEY, params); Probing rsa_pub_key here in the debugger. type = 6 references = 1 rsa = 0 (probably NULL) From matt at openssl.org Tue Sep 14 23:29:48 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Sep 2021 00:29:48 +0100 Subject: Openssl 3.0.0. EVP_PKEY RSA is NULL In-Reply-To: References: Message-ID: On 15/09/2021 00:19, Ken Goldman wrote: > I am doing the following, but the EVP_PKEY->pkey->rsa is null. > Am I misusing the API or missing a step? Neither. This is normal. EVP_PKEY->pkey->rsa is only used if you have a legacy key. Matt > > (error checking removed) > > ??? EVP_PKEY??????? *rsa_pub_key = NULL; > ??? EVP_PKEY_CTX???? *ctx = NULL; > ??? OSSL_PARAM_BLD???? *param_bld = NULL; > ??? OSSL_PARAM???????? *params = NULL; > > ??? BIGNUM *??? n = NULL; > ??? BIGNUM *??? e = NULL; > > [these bignums are initialized using bin2bn] > > ????param_bld = OSSL_PARAM_BLD_new(); > ????irc = OSSL_PARAM_BLD_push_BN(param_bld, "n", n); > ????irc = OSSL_PARAM_BLD_push_BN(param_bld, "e", e); > ????params = OSSL_PARAM_BLD_to_param(param_bld); > > (do I perhaps need an 'end'? > > ????ctx = EVP_PKEY_CTX_new_from_name(NULL, "RSA", NULL); > ????irc = EVP_PKEY_fromdata_init(ctx); > ????irc = EVP_PKEY_fromdata(ctx, (EVP_PKEY **)rsa_pub_key,??????? /* > freed by caller */ > ??????????????? EVP_PKEY_PUBLIC_KEY, params); > > Probing rsa_pub_key here in the debugger. > > > type = 6 > references = 1 > rsa = 0? (probably NULL) > From pauli at openssl.org Wed Sep 15 00:04:15 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 15 Sep 2021 10:04:15 +1000 Subject: Openssl 3.0.0. EVP_PKEY RSA is NULL In-Reply-To: References: Message-ID: On 15/9/21 9:19 am, Ken Goldman wrote: > ????irc = EVP_PKEY_fromdata_init(ctx); > ????irc = EVP_PKEY_fromdata(ctx, (EVP_PKEY **)rsa_pub_key, /* freed by > caller */ > ??????????????? EVP_PKEY_PUBLIC_KEY, params); Do you mean : ??? irc = EVP_PKEY_fromdata(ctx, &rsa_pub_key, EVP_PKEY_PUBLIC_KEY, params); here? The cast looks wrong. Pauli From kory at avatarci.com Wed Sep 15 04:46:53 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Tue, 14 Sep 2021 21:46:53 -0700 Subject: OpenSSl 3 statically linking a provider Message-ID: I have written a custom provider which I need to include (link) with my Application at link time rather than load it at run-time. The init function is defined like this: OSSL_provider_init_fn sck_provider_init; int sck_provider_init(const OSSL_CORE_HANDLE *handle, const OSSL_DISPATCH *in, const OSSL_DISPATCH **out, void **provctx) But I cannot figure out how to initialize/load it in my app. The man page for provider(7) states that it is possible to do this, but does not explain how. Is that documented somewhere? Thanks, Kory From tomas at openssl.org Wed Sep 15 06:53:40 2021 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 15 Sep 2021 08:53:40 +0200 Subject: OpenSSl 3 statically linking a provider In-Reply-To: References: Message-ID: <2d5b701f3f65f1e1148e1b85ae77e243b05799e7.camel@openssl.org> On Tue, 2021-09-14 at 21:46 -0700, Kory Hamzeh wrote: > I have written a custom provider which I need to include (link) with > my Application at link time rather than load it at run-time. The init > function is defined like this: > > OSSL_provider_init_fn sck_provider_init; > > int sck_provider_init(const OSSL_CORE_HANDLE *handle, > ?????????????????????? const OSSL_DISPATCH *in, > ?????????????????????? const OSSL_DISPATCH **out, > ?????????????????????? void **provctx) > > But I cannot figure out how to initialize/load it in my app. The man > page for provider(7) states that it is possible to do this, but does > not explain how. Is that documented somewhere? > > Thanks, > Kory Please see the manual page for the OSSL_PROVIDER_add_builtin function and the test/provfetchtest.c source code. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tomas at openssl.org Wed Sep 15 06:54:19 2021 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 15 Sep 2021 08:54:19 +0200 Subject: Openssl 3.0.0. EVP_PKEY_CTX vs EVP_PKEY In-Reply-To: References: <7efe8001455da03d35f4597d4be45dd54183d34b.camel@openssl.org> Message-ID: On Tue, 2021-09-14 at 14:42 -0400, Ken Goldman wrote: > On 9/14/2021 11:40 AM, Tomas Mraz wrote: > > On Tue, 2021-09-14 at 11:11 -0400, Ken Goldman wrote: > > > Conceptually, how are these different? > > > > > > When do I use one vs the other? > > > > The EVP_PKEY is an object holding data (well, rather a reference, > > but > > that is fairly irrelevant) of a private key, public key, or domain > > parameters for asymetric crypto keys. > > > > The EVP_PKEY_CTX is an operation context - that is a context to > > make > > some operations with an EVP_PKEY such as signing/verification, > > encryption/decryption, key generation (starting with domain > > parameters > > EVP_PKEY), key checking. > > > > > Where would I learn this? > > > > I suppose in the manual pages - I'd start with EVP_PKEY_new and > > EVP_PKEY_CTX_new man pages. Yeah, the discoverability is not that > > good > > I suppose. And there is no good high level overview. > > In other words, the EVP_PKEY holds the public key.? When I want to > use > it to encrypt / verify, I create a temporary EVP_PKEY_CTX?? Is that > it? > Do I also use a ctx to initialize the key? > > Perhaps, to make the EVP_PKEY from n and e.: > > OSSL_PARAM_BLD_push_BN() for n and e parameters > EVP_PKEY_CTX_new_from_name the RSA > EVP_PKEY_fromdata using the parameters Yes, you've got this right. There are some cases where you do not need an EVP_PKEY_CTX to get an EVP_PKEY - such as using decoders to decode a key from a file. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From Shivakumar.Poojari at rbbn.com Wed Sep 15 10:34:52 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Wed, 15 Sep 2021 10:34:52 +0000 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> Message-ID: Hi Tomas, As Engine function are deprecated I tried using providers But how to use providers to get engine functionality tried in man pages Some sample program will help, maybe some sample program will give the clear idea how to use provider Struggling in understand the providers Please share the sample program and the links to understand the providers Thanks, shiva kumar ________________________________ From: Tomas Mraz Sent: Wednesday, September 8, 2021 7:00 PM To: Shivakumar Poojari ; openssl-users at openssl.org Cc: Paramashivaiah, Sunil ; Bhattacharjee, Debapriyo (c) Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 Hello, there is no direct replacement. The ENGINEs as a pluggable crypto modules concept is replaced with the providers concept which is much more sophisticated and capable. Please look at https://clicktime.symantec.com/3NTnN1ZFia2bCryEiZnkRmY6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman7%2Fmigration_guide.html ENGINEs support is not removed from OpenSSL 3.0 however it is deprecated. If you cannot use deprecated functions you have to drop support for engines which means those functions just should not be called and there is no replacement. Providers allow for configuration via the default configuration file so for an application to support crypto modules in form of providers the application does not necessarily have to have any extra functions called. Just the default configuration file has to be present and the configuration of the desired provider(s) needs to be there. Tomas On Wed, 2021-09-08 at 13:07 +0000, Shivakumar Poojari wrote: > Hi > Upgrading our code to openssl 3.0. the below function we trying to > replace > > ENGINE_load_dynamic() > > Replacment for 3.0 what i > found OPENSSL_init_crypto(OPENSSL_INIT_ENGINE_DYNAMIC, NULL) > > ENGINE_by_id("dynamic") > > ENGINE_ctrl_cmd_string() > > ENGINE_set_default() > > ENGINE_get_DH() > > ENGINE_free() > > Need a replacement for the above-highlighted function. I searched in > man pages did not find any replacement and searched in google for > sample programs also not found > > > Thanks, > shiva kumar. > > > > > > > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others > or forwarding without express permission is strictly prohibited. If you > are not the intended recipient, please notify the sender immediately > and then delete all copies, including any attachments. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeevhi at gmail.com Wed Sep 15 11:56:51 2021 From: jeevhi at gmail.com (Jaya Muthiah) Date: Wed, 15 Sep 2021 17:26:51 +0530 Subject: OpenSSL session reuse does not work with TLS_client_method() Message-ID: I am trying to reuse SSL_SESSION as below, it works fine when I use TLSv1_2_client_method() to create context. However, it does not work when I use TLS_client_method(). if (!SSL_set_session(ssl, ssl_session)) { //code never reaches here so SSL_set_session is successful } if (SSL_connect(ssl) != 1) { return -1; } int reused = SSL_session_reused(ssl); <-- always returns zero for TLS_client_method(). ssl_session = SSL_get1_session(ssl); // for future connections Above code works fine with TLSv1_2_client_method() and SSL_session_reused() returns 1, handshake time is also reduced considerably. However, if I use TLS_client_method(), reuse does not work and SSL_session_reused() returns zero. Any idea what is wrong? OpenSSL version is 1.1.1.g -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Wed Sep 15 12:17:37 2021 From: tomas at openssl.org (Tomas Mraz) Date: Wed, 15 Sep 2021 14:17:37 +0200 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> Message-ID: I am sorry but as I said providers are not a direct replacement for ENGINEs. It is a completely different implementation of the same concept of pluggable cryptographical modules for OpenSSL. You can look at the OpenSSL manual pages for the providers. This is the starting point: https://www.openssl.org/docs/man3.0/man7/provider.html There is no tutorial as for how to implement your own provider. And as I said on the application side if the application loads an OpenSSL configuration file the providers loaded can be configured via the config file and does not require any explicit API calls from the application. I'd recommend looking at some of the test sources in the tests directory for some code examples. Tomas On Wed, 2021-09-15 at 10:34 +0000, Shivakumar Poojari wrote: > Hi?Tomas, > As Engine function are deprecated I tried using providers > > But how to use providers to get engine functionality tried in man > pages? > > Some sample program will help, maybe some sample program will give the > clear idea how to use provider? > > Struggling in understand the providers > > Please share the sample program and the links to understand the > providers > > Thanks, > shiva kumar? > From: Tomas Mraz > Sent: Wednesday, September 8, 2021 7:00 PM > To: Shivakumar Poojari ; > openssl-users at openssl.org > Cc: Paramashivaiah, Sunil ; > Bhattacharjee, Debapriyo (c) > Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0? > Hello, > > there is no direct replacement. The ENGINEs as a pluggable crypto > modules concept is replaced with the providers concept which is much > more sophisticated and capable. > > Please look at > https://clicktime.symantec.com/3NTnN1ZFia2bCryEiZnkRmY6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman7%2Fmigration_guide.html > > ENGINEs support is not removed from OpenSSL 3.0 however it is > deprecated. If you cannot use deprecated functions you have to drop > support for engines which means those functions just should not be > called and there is no replacement. > > Providers allow for configuration via the default configuration file so > for an application to support crypto modules in form of providers the > application does not necessarily have to have any extra functions > called. Just the default configuration file has to be present and the > configuration of the desired provider(s) needs to be there. > > Tomas > > > On Wed, 2021-09-08 at 13:07 +0000, Shivakumar Poojari wrote: > > Hi > > Upgrading our code to openssl 3.0. the below function we trying to > > replace > > > > ENGINE_load_dynamic()?? > > > > Replacment for 3.0 what i > > found?OPENSSL_init_crypto(OPENSSL_INIT_ENGINE_DYNAMIC, NULL) > > > > ENGINE_by_id("dynamic") > > > > ENGINE_ctrl_cmd_string() > > > > ENGINE_set_default() > > > > ENGINE_get_DH() > > > > ENGINE_free() > > > > Need a replacement for the above-highlighted function. I searched in > > man pages did not find any replacement and searched in google for > > sample programs also not found > > > > ? > > Thanks, > > shiva kumar. > > > > > > > > > > > > > > > > > > Notice: This e-mail together with any attachments may contain > > information of Ribbon Communications Inc. and its Affiliates that is > > confidential and/or proprietary for the sole use of the intended > > recipient. Any review, disclosure, reliance or distribution by others > > or forwarding without express permission is strictly prohibited. If > > you > > are not the intended recipient, please notify the sender immediately > > and then delete all copies, including any attachments. > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From petr.gotthard at advantech.cz Wed Sep 15 12:26:23 2021 From: petr.gotthard at advantech.cz (Petr Gotthard) Date: Wed, 15 Sep 2021 12:26:23 +0000 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> Message-ID: Shiva, you may also have a look at the https://github.com/provider-corner/vigenere That's (as far as I know) the most simple provider implementation available. Petr -----Original Message----- From: openssl-users On Behalf Of Tomas Mraz Sent: Wednesday, September 15, 2021 2:18 PM To: Shivakumar Poojari ; openssl-users at openssl.org Cc: Paramashivaiah, Sunil ; Bhattacharjee, Debapriyo (c) Subject: Re: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 I am sorry but as I said providers are not a direct replacement for ENGINEs. It is a completely different implementation of the same concept of pluggable cryptographical modules for OpenSSL. You can look at the OpenSSL manual pages for the providers. This is the starting point: https://www.openssl.org/docs/man3.0/man7/provider.html There is no tutorial as for how to implement your own provider. And as I said on the application side if the application loads an OpenSSL configuration file the providers loaded can be configured via the config file and does not require any explicit API calls from the application. I'd recommend looking at some of the test sources in the tests directory for some code examples. Tomas On Wed, 2021-09-15 at 10:34 +0000, Shivakumar Poojari wrote: > Hi Tomas, > As Engine function are deprecated I tried using providers > > But how to use providers to get engine functionality tried in man > pages > > Some sample program will help, maybe some sample program will give the > clear idea how to use provider > > Struggling in understand the providers > > Please share the sample program and the links to understand the > providers > > Thanks, > shiva kumar From jb-openssl at wisemo.com Wed Sep 15 13:34:00 2021 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 15 Sep 2021 15:34:00 +0200 Subject: Reducing the footprint of a simple application In-Reply-To: <5f0c7c4c-d712-d026-1bb9-461a8fc8b591@openssl.org> References: <5f0c7c4c-d712-d026-1bb9-461a8fc8b591@openssl.org> Message-ID: <3d73bd6b-7f18-253d-3155-416607a774fa@wisemo.com> On 2021-09-14 12:14, Dr Paul Dale wrote: > > > > ...low security RNGs and other antifeatures. > > Huh????? Where?? Why plural? > > The only **one** I'm aware of is the one I added to stochastically > flush the property cache where it doesn't need to be cryptographically > secure. > Some applications need more than 256 independent random bits to satisfy their security design.? Some of the newer RNGs in OpenSSL presume otherwise in their government design. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 From matt at openssl.org Wed Sep 15 15:19:03 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Sep 2021 16:19:03 +0100 Subject: OpenSSL session reuse does not work with TLS_client_method() In-Reply-To: References: Message-ID: <0d0b779d-09e9-76fc-828b-e10e7e528907@openssl.org> Was the original connection that you obtained the session from cleanly closed down? From the man pages: "A session will be automatically removed from the session cache and marked as non-resumable if the connection is not closed down cleanly, e.g. if a fatal error occurs on the connection or L is not called prior to L." https://www.openssl.org/docs/man1.1.1/man3/SSL_get_session.html You can check whether a session is valid for resumption using SSL_SESSION_is_resumable(): https://www.openssl.org/docs/man1.1.1/man3/SSL_SESSION_is_resumable.html mATT On 15/09/2021 12:56, Jaya Muthiah wrote: > I am trying to reuse SSL_SESSION as below, it works fine when I use > TLSv1_2_client_method() to create context. However, it does not work > when I use TLS_client_method(). > > ? ? if (!SSL_set_session(ssl, ssl_session)) { > ? ? ? ? ? ? //code never reaches here so SSL_set_session is successful > ? ? } > > ? ? if (SSL_connect(ssl) != 1) { > ? ? ?return -1; > ? ? } > > ? ? int reused = SSL_session_reused(ssl); <-- always returns zero for > TLS_client_method(). > > ? ? ssl_session = SSL_get1_session(ssl); // for future connections > > Above code works fine with TLSv1_2_client_method() and > SSL_session_reused() returns 1, handshake time is also reduced > considerably. However, if I use TLS_client_method(), reuse does not work > and SSL_session_reused() returns zero. > > Any idea what is wrong? OpenSSL version is 1.1.1.g From matt at openssl.org Wed Sep 15 15:39:14 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Sep 2021 16:39:14 +0100 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> Message-ID: <787fe423-afca-feca-5a55-db2b6569f6b4@openssl.org> Another, slightly more complicated, but fully self contained provider is here: https://github.com/openssl/openssl/blob/master/test/tls-provider.c And another one here: https://github.com/openssl/openssl/blob/master/test/p_test.c A minimal bare bones provider is here: https://github.com/openssl/openssl/blob/master/providers/nullprov.c The legacy provider is also worth looking at: https://github.com/openssl/openssl/blob/master/providers/legacyprov.c Matt On 15/09/2021 13:26, Petr Gotthard wrote: > Shiva, > you may also have a look at the https://github.com/provider-corner/vigenere > That's (as far as I know) the most simple provider implementation available. > > Petr > > -----Original Message----- > From: openssl-users On Behalf Of Tomas Mraz > Sent: Wednesday, September 15, 2021 2:18 PM > To: Shivakumar Poojari ; openssl-users at openssl.org > Cc: Paramashivaiah, Sunil ; Bhattacharjee, Debapriyo (c) > Subject: Re: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 > > I am sorry but as I said providers are not a direct replacement for ENGINEs. It is a completely different implementation of the same concept of pluggable cryptographical modules for OpenSSL. You can look at the OpenSSL manual pages for the providers. > > This is the starting point: > https://www.openssl.org/docs/man3.0/man7/provider.html > > There is no tutorial as for how to implement your own provider. And as I said on the application side if the application loads an OpenSSL configuration file the providers loaded can be configured via the config file and does not require any explicit API calls from the application. > > I'd recommend looking at some of the test sources in the tests directory for some code examples. > > Tomas > > On Wed, 2021-09-15 at 10:34 +0000, Shivakumar Poojari wrote: >> Hi Tomas, >> As Engine function are deprecated I tried using providers >> >> But how to use providers to get engine functionality tried in man >> pages >> >> Some sample program will help, maybe some sample program will give the >> clear idea how to use provider >> >> Struggling in understand the providers >> >> Please share the sample program and the links to understand the >> providers >> >> Thanks, >> shiva kumar > From kris at amongbytes.com Wed Sep 15 15:50:42 2021 From: kris at amongbytes.com (Kris Kwiatkowski) Date: Wed, 15 Sep 2021 16:50:42 +0100 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: <787fe423-afca-feca-5a55-db2b6569f6b4@openssl.org> References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> <787fe423-afca-feca-5a55-db2b6569f6b4@openssl.org> Message-ID: <98b1217f-c644-65b5-0b11-5b79316c78ab@amongbytes.com> Can you point to instructions on how to load provider it into OpenSSL? Is there something similar to "[engine_section]", that can be used to configure loading from openssl.conf? BR, Kris On 9/15/21 4:39 PM, Matt Caswell wrote: > Another, slightly more complicated, but fully self contained provider is > here: > > https://github.com/openssl/openssl/blob/master/test/tls-provider.c > > And another one here: > > https://github.com/openssl/openssl/blob/master/test/p_test.c > > A minimal bare bones provider is here: > > https://github.com/openssl/openssl/blob/master/providers/nullprov.c > > The legacy provider is also worth looking at: > > https://github.com/openssl/openssl/blob/master/providers/legacyprov.c > > Matt > > On 15/09/2021 13:26, Petr Gotthard wrote: >> Shiva, >> you may also have a look at the https://github.com/provider-corner/vigenere >> That's (as far as I know) the most simple provider implementation available. >> >> Petr >> >> -----Original Message----- >> From: openssl-users On Behalf Of Tomas Mraz >> Sent: Wednesday, September 15, 2021 2:18 PM >> To: Shivakumar Poojari ; openssl-users at openssl.org >> Cc: Paramashivaiah, Sunil ; Bhattacharjee, Debapriyo (c) >> Subject: Re: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 >> >> I am sorry but as I said providers are not a direct replacement for ENGINEs. It is a completely different implementation of the same concept of pluggable cryptographical modules for OpenSSL. You can look at the OpenSSL manual pages for the providers. >> >> This is the starting point: >> https://www.openssl.org/docs/man3.0/man7/provider.html >> >> There is no tutorial as for how to implement your own provider. And as I said on the application side if the application loads an OpenSSL configuration file the providers loaded can be configured via the config file and does not require any explicit API calls from the application. >> >> I'd recommend looking at some of the test sources in the tests directory for some code examples. >> >> Tomas >> >> On Wed, 2021-09-15 at 10:34 +0000, Shivakumar Poojari wrote: >>> Hi Tomas, >>> As Engine function are deprecated I tried using providers >>> >>> But how to use providers to get engine functionality tried in man >>> pages >>> >>> Some sample program will help, maybe some sample program will give the >>> clear idea how to use provider >>> >>> Struggling in understand the providers >>> >>> Please share the sample program and the links to understand the >>> providers >>> >>> Thanks, >>> shiva kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 15 15:57:46 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Sep 2021 16:57:46 +0100 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: <98b1217f-c644-65b5-0b11-5b79316c78ab@amongbytes.com> References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> <787fe423-afca-feca-5a55-db2b6569f6b4@openssl.org> <98b1217f-c644-65b5-0b11-5b79316c78ab@amongbytes.com> Message-ID: On 15/09/2021 16:50, Kris Kwiatkowski wrote: > Can you point to instructions on how to load provider > it into OpenSSL? > > Is there something similar to "[engine_section]", > that can be used to configure loading from openssl.conf? Yes. See the "config" man page here: https://www.openssl.org/docs/man3.0/man5/config.html In particular look at the section "Provider Configuration" You can also load providers through the API. See: https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_load.html Matt > > BR, > Kris > > On 9/15/21 4:39 PM, Matt Caswell wrote: >> Another, slightly more complicated, but fully self contained provider is >> here: >> >> https://github.com/openssl/openssl/blob/master/test/tls-provider.c >> >> And another one here: >> >> https://github.com/openssl/openssl/blob/master/test/p_test.c >> >> A minimal bare bones provider is here: >> >> https://github.com/openssl/openssl/blob/master/providers/nullprov.c >> >> The legacy provider is also worth looking at: >> >> https://github.com/openssl/openssl/blob/master/providers/legacyprov.c >> >> Matt >> >> On 15/09/2021 13:26, Petr Gotthard wrote: >>> Shiva, >>> you may also have a look at thehttps://github.com/provider-corner/vigenere >>> That's (as far as I know) the most simple provider implementation available. >>> >>> Petr >>> >>> -----Original Message----- >>> From: openssl-users On Behalf Of Tomas Mraz >>> Sent: Wednesday, September 15, 2021 2:18 PM >>> To: Shivakumar Poojari;openssl-users at openssl.org >>> Cc: Paramashivaiah, Sunil; Bhattacharjee, Debapriyo (c) >>> Subject: Re: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 >>> >>> I am sorry but as I said providers are not a direct replacement for ENGINEs. It is a completely different implementation of the same concept of pluggable cryptographical modules for OpenSSL. You can look at the OpenSSL manual pages for the providers. >>> >>> This is the starting point: >>> https://www.openssl.org/docs/man3.0/man7/provider.html >>> >>> There is no tutorial as for how to implement your own provider. And as I said on the application side if the application loads an OpenSSL configuration file the providers loaded can be configured via the config file and does not require any explicit API calls from the application. >>> >>> I'd recommend looking at some of the test sources in the tests directory for some code examples. >>> >>> Tomas >>> >>> On Wed, 2021-09-15 at 10:34 +0000, Shivakumar Poojari wrote: >>>> Hi Tomas, >>>> As Engine function are deprecated I tried using providers >>>> >>>> But how to use providers to get engine functionality tried in man >>>> pages >>>> >>>> Some sample program will help, maybe some sample program will give the >>>> clear idea how to use provider >>>> >>>> Struggling in understand the providers >>>> >>>> Please share the sample program and the links to understand the >>>> providers >>>> >>>> Thanks, >>>> shiva kumar From matt at openssl.org Wed Sep 15 16:07:59 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 15 Sep 2021 17:07:59 +0100 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> <787fe423-afca-feca-5a55-db2b6569f6b4@openssl.org> <98b1217f-c644-65b5-0b11-5b79316c78ab@amongbytes.com> Message-ID: <6d5fa8dc-1b0c-db82-3df6-33901a3c8f3a@openssl.org> On 15/09/2021 16:57, Matt Caswell wrote: > > > On 15/09/2021 16:50, Kris Kwiatkowski wrote: >> Can you point to instructions on how to load provider >> it into OpenSSL? >> >> Is there something similar to "[engine_section]", >> that can be used to configure loading from openssl.conf? > > Yes. See the "config" man page here: > > https://www.openssl.org/docs/man3.0/man5/config.html And here are some simple config files that do this: https://github.com/openssl/openssl/blob/master/test/default.cnf https://github.com/openssl/openssl/blob/master/test/default-and-fips.cnf https://github.com/openssl/openssl/blob/master/test/default-and-legacy.cnf https://github.com/openssl/openssl/blob/master/test/fips-and-base.cnf https://github.com/openssl/openssl/blob/master/test/fips.cnf Matt > > In particular look at the section "Provider Configuration" > > You can also load providers through the API. See: > > https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_load.html > > Matt > > >> >> BR, >> Kris >> >> On 9/15/21 4:39 PM, Matt Caswell wrote: >>> Another, slightly more complicated, but fully self contained provider is >>> here: >>> >>> https://github.com/openssl/openssl/blob/master/test/tls-provider.c >>> >>> And another one here: >>> >>> https://github.com/openssl/openssl/blob/master/test/p_test.c >>> >>> A minimal bare bones provider is here: >>> >>> https://github.com/openssl/openssl/blob/master/providers/nullprov.c >>> >>> The legacy provider is also worth looking at: >>> >>> https://github.com/openssl/openssl/blob/master/providers/legacyprov.c >>> >>> Matt >>> >>> On 15/09/2021 13:26, Petr Gotthard wrote: >>>> Shiva, >>>> you may also have a look at >>>> thehttps://github.com/provider-corner/vigenere >>>> That's (as far as I know) the most simple provider implementation >>>> available. >>>> >>>> Petr >>>> >>>> -----Original Message----- >>>> From: openssl-users? On Behalf Of >>>> Tomas Mraz >>>> Sent: Wednesday, September 15, 2021 2:18 PM >>>> To: Shivakumar >>>> Poojari;openssl-users at openssl.org >>>> Cc: Paramashivaiah, Sunil; >>>> Bhattacharjee, Debapriyo (c) >>>> Subject: Re: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 >>>> >>>> I am sorry but as I said providers are not a direct replacement for >>>> ENGINEs. It is a completely different implementation of the same >>>> concept of pluggable cryptographical modules for OpenSSL. You can >>>> look at the OpenSSL manual pages for the providers. >>>> >>>> This is the starting point: >>>> https://www.openssl.org/docs/man3.0/man7/provider.html >>>> >>>> There is no tutorial as for how to implement your own provider. And >>>> as I said on the application side if the application loads an >>>> OpenSSL configuration file the providers loaded can be configured >>>> via the config file and does not require any explicit API calls from >>>> the application. >>>> >>>> I'd recommend looking at some of the test sources in the tests >>>> directory for some code examples. >>>> >>>> Tomas >>>> >>>> On Wed, 2021-09-15 at 10:34 +0000, Shivakumar Poojari wrote: >>>>> Hi Tomas, >>>>> As Engine function are deprecated I tried using providers >>>>> >>>>> But how to use providers to get engine functionality tried in man >>>>> pages >>>>> >>>>> Some sample program will help, maybe some sample program will give the >>>>> clear idea how to use provider >>>>> >>>>> Struggling in understand the providers >>>>> >>>>> Please share the sample program and the links to understand the >>>>> providers >>>>> >>>>> Thanks, >>>>> shiva kumar > From openssl-users at dukhovni.org Wed Sep 15 16:10:07 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 15 Sep 2021 12:10:07 -0400 Subject: OpenSSL session reuse does not work with TLS_client_method() In-Reply-To: References: Message-ID: On Wed, Sep 15, 2021 at 05:26:51PM +0530, Jaya Muthiah wrote: > I am trying to reuse SSL_SESSION as below, it works fine when I use > TLSv1_2_client_method() to create context. However, it does not work > when I use TLS_client_method(). > [...] > if (SSL_connect(ssl) != 1) { return -1; } > int reused = SSL_session_reused(ssl); > ssl_session = SSL_get1_session(ssl); // for future connections That's because with TLS_client_method() you end up negotiating TLS 1.3, and with TLS 1.3 session tickets are sent by servers *after* the completion of the handshake. A TLS 1.3 session saved manually, immediately at the completion of the handshake will have no session tickets, and will not be able to perform resumption. The robust way to save the session state for resumption is to implement the session callbacks. For example, in Postfix, you'll find: SSL_CTX_set_session_cache_mode(client_ctx, SSL_SESS_CACHE_CLIENT | SSL_SESS_CACHE_NO_INTERNAL_STORE | SSL_SESS_CACHE_NO_AUTO_CLEAR); SSL_CTX_sess_set_new_cb(client_ctx, new_client_session_cb); static int new_client_session_cb(SSL *ssl, SSL_SESSION *session) { ... /* * The cache name (if caching is enabled in tlsmgr(8)) and the cache ID * string for this session are stored in the TLScontext. It cannot be * null at this point. */ if ((TLScontext = SSL_get_ex_data(ssl, TLScontext_index)) == 0) msg_panic("%s: null TLScontext in new session callback", myname); ... } -- Viktor. [ We all miss the little details sometimes, but I'd have expected Matt to not miss this one... ] From kris at amongbytes.com Wed Sep 15 17:18:11 2021 From: kris at amongbytes.com (Kris Kwiatkowski) Date: Wed, 15 Sep 2021 18:18:11 +0100 Subject: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 In-Reply-To: <6d5fa8dc-1b0c-db82-3df6-33901a3c8f3a@openssl.org> References: <2b9e7e3cee703af26c5c49bc56c9e22d2dbfa9ed.camel@openssl.org> <787fe423-afca-feca-5a55-db2b6569f6b4@openssl.org> <98b1217f-c644-65b5-0b11-5b79316c78ab@amongbytes.com> <6d5fa8dc-1b0c-db82-3df6-33901a3c8f3a@openssl.org> Message-ID: <18B82797-7EA7-4D1E-93CF-FA57FF7FBA0D@amongbytes.com> Great, thanks! On 15 September 2021 17:07:59 BST, Matt Caswell wrote: > > >On 15/09/2021 16:57, Matt Caswell wrote: >> >> >> On 15/09/2021 16:50, Kris Kwiatkowski wrote: >>> Can you point to instructions on how to load provider >>> it into OpenSSL? >>> >>> Is there something similar to "[engine_section]", >>> that can be used to configure loading from openssl.conf? >> >> Yes. See the "config" man page here: >> >> https://www.openssl.org/docs/man3.0/man5/config.html > >And here are some simple config files that do this: > >https://github.com/openssl/openssl/blob/master/test/default.cnf >https://github.com/openssl/openssl/blob/master/test/default-and-fips.cnf >https://github.com/openssl/openssl/blob/master/test/default-and-legacy.cnf >https://github.com/openssl/openssl/blob/master/test/fips-and-base.cnf >https://github.com/openssl/openssl/blob/master/test/fips.cnf > >Matt > > >> >> In particular look at the section "Provider Configuration" >> >> You can also load providers through the API. See: >> >> https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_load.html >> >> Matt >> >> >>> >>> BR, >>> Kris >>> >>> On 9/15/21 4:39 PM, Matt Caswell wrote: >>>> Another, slightly more complicated, but fully self contained provider is >>>> here: >>>> >>>> https://github.com/openssl/openssl/blob/master/test/tls-provider.c >>>> >>>> And another one here: >>>> >>>> https://github.com/openssl/openssl/blob/master/test/p_test.c >>>> >>>> A minimal bare bones provider is here: >>>> >>>> https://github.com/openssl/openssl/blob/master/providers/nullprov.c >>>> >>>> The legacy provider is also worth looking at: >>>> >>>> https://github.com/openssl/openssl/blob/master/providers/legacyprov.c >>>> >>>> Matt >>>> >>>> On 15/09/2021 13:26, Petr Gotthard wrote: >>>>> Shiva, >>>>> you may also have a look at >>>>> thehttps://github.com/provider-corner/vigenere >>>>> That's (as far as I know) the most simple provider implementation >>>>> available. >>>>> >>>>> Petr >>>>> >>>>> -----Original Message----- >>>>> From: openssl-users? On Behalf Of >>>>> Tomas Mraz >>>>> Sent: Wednesday, September 15, 2021 2:18 PM >>>>> To: Shivakumar >>>>> Poojari;openssl-users at openssl.org >>>>> Cc: Paramashivaiah, Sunil; >>>>> Bhattacharjee, Debapriyo (c) >>>>> Subject: Re: [EXTERNAL] Re: ENGINE API replacement for Openssl3.0 >>>>> >>>>> I am sorry but as I said providers are not a direct replacement for >>>>> ENGINEs. It is a completely different implementation of the same >>>>> concept of pluggable cryptographical modules for OpenSSL. You can >>>>> look at the OpenSSL manual pages for the providers. >>>>> >>>>> This is the starting point: >>>>> https://www.openssl.org/docs/man3.0/man7/provider.html >>>>> >>>>> There is no tutorial as for how to implement your own provider. And >>>>> as I said on the application side if the application loads an >>>>> OpenSSL configuration file the providers loaded can be configured >>>>> via the config file and does not require any explicit API calls from >>>>> the application. >>>>> >>>>> I'd recommend looking at some of the test sources in the tests >>>>> directory for some code examples. >>>>> >>>>> Tomas >>>>> >>>>> On Wed, 2021-09-15 at 10:34 +0000, Shivakumar Poojari wrote: >>>>>> Hi Tomas, >>>>>> As Engine function are deprecated I tried using providers >>>>>> >>>>>> But how to use providers to get engine functionality tried in man >>>>>> pages >>>>>> >>>>>> Some sample program will help, maybe some sample program will give the >>>>>> clear idea how to use provider >>>>>> >>>>>> Struggling in understand the providers >>>>>> >>>>>> Please share the sample program and the links to understand the >>>>>> providers >>>>>> >>>>>> Thanks, >>>>>> shiva kumar >> > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Wed Sep 15 22:24:15 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Thu, 16 Sep 2021 08:24:15 +1000 Subject: Reducing the footprint of a simple application In-Reply-To: <3d73bd6b-7f18-253d-3155-416607a774fa@wisemo.com> References: <5f0c7c4c-d712-d026-1bb9-461a8fc8b591@openssl.org> <3d73bd6b-7f18-253d-3155-416607a774fa@wisemo.com> Message-ID: <164e0585-fd36-1036-feeb-b26d497f7feb@openssl.org> Jakob, That's reasonable, although I wouldn't use the word "low" to describe it. I did try to include 10.1.2 from NIST's SP 800-90C but it didn't make it. There is nothing preventing the use of the existing DRBGs with longer digests which Could increase number of bits. Pauli On 15/9/21 11:34 pm, Jakob Bohm via openssl-users wrote: > On 2021-09-14 12:14, Dr Paul Dale wrote: >> >> >> > ...low security RNGs and other antifeatures. >> >> Huh????? Where?? Why plural? >> >> The only **one** I'm aware of is the one I added to stochastically >> flush the property cache where it doesn't need to be >> cryptographically secure. >> > Some applications need more than 256 independent random bits to > satisfy their > security design.? Some of the newer RNGs in OpenSSL presume otherwise > in their > government design. > > > Enjoy > > Jakob From jeevhi at gmail.com Thu Sep 16 02:41:44 2021 From: jeevhi at gmail.com (Jaya Muthiah) Date: Thu, 16 Sep 2021 08:11:44 +0530 Subject: Getting SSL_SESSION remaining lifetime In-Reply-To: References: Message-ID: I am trying to get the remaining lifetime of the ticket so that server can decide to renew ticket or not I have defined callback like this, and it is working. However, the SSL_SESSION_get_ticket_lifetime_hint() always returns zero. SSL_CTX_set_session_ticket_cb(ctx->ctx, ticket_gen_cb, ticket_dec_cb, NULL); SSL_TICKET_RETURN ticket_dec_cb(SSL *s, SSL_SESSION *ss, const unsigned char *keyname, size_t keyname_len, SSL_TICKET_STATUS status, void *arg) { SSL_TICKET_RETURN res; int lifetime = 0; switch (status) { case SSL_TICKET_EMPTY: case SSL_TICKET_NO_DECRYPT: res = SSL_TICKET_RETURN_IGNORE_RENEW; break; case SSL_TICKET_SUCCESS: //get_session_ticket_appdata(ssl, ssl_session); res = SSL_TICKET_RETURN_USE; break; case SSL_TICKET_SUCCESS_RENEW: lifetime = SSL_SESSION_get_ticket_lifetime_hint(ss); //res = SSL_TICKET_RETURN_USE_RENEW; // generate new ticket res = SSL_TICKET_RETURN_USE; // reuse old break; default: res = SSL_TICKET_RETURN_IGNORE; } return res; } Is this the right way? Can someone help please? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeevhi at gmail.com Thu Sep 16 02:53:20 2021 From: jeevhi at gmail.com (Jaya Muthiah) Date: Thu, 16 Sep 2021 08:23:20 +0530 Subject: SSL_SESSION - sending custom data to the client Message-ID: Is it possible to send custom data to the client along with the ticket? I tried using SSL_SESSION_set1_ticket_appdata but it didn't work. From openssl-users at dukhovni.org Thu Sep 16 03:18:23 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 15 Sep 2021 23:18:23 -0400 Subject: Getting SSL_SESSION remaining lifetime In-Reply-To: References: Message-ID: On Thu, Sep 16, 2021 at 08:11:44AM +0530, Jaya Muthiah wrote: > I am trying to get the remaining lifetime of the ticket so that server can > decide to renew ticket or not In Postfix, I rotate ticket keys every hour, and sessions are valid for two hours. For the first hour when they were issued by the current ticket the ticket is accepted without forcing a new ticket to be generated. Durign the second hour when accepting tickets signed by the previous key, a fresh ticket is generated. I don't rely on OpenSSL to tell me the ticket age, it is implied by the key id. Since ticket keys should be rotated anyway, something like that might also work for you. What I haven't yet built is a mechanism to rotate keys consistely across multiple machines in a load-balancer pool. That would be generally useful. -- Viktor. From jeevhi at gmail.com Thu Sep 16 06:19:51 2021 From: jeevhi at gmail.com (Jaya Muthiah) Date: Thu, 16 Sep 2021 11:49:51 +0530 Subject: Will TLSv1.3 always send session ticket? Message-ID: As I can read from the documents mentioned below, "or not at all" worries me. Is there a situation when a session ticket is not sent at all (other than when reused)? https://www.openssl.org/docs/manmaster/man3/SSL_CTX_sess_set_new_cb.html Note that in TLSv1.3, sessions are established after the main handshake has completed. The server decides when to send the client the session information and this may occur some time after the end of the handshake (or not at all). https://wiki.openssl.org/index.php/TLS1.3#Sessions In TLSv1.3 sessions are not established until after the main handshake has completed. The server sends a separate post-handshake message to the client containing the session details. Typically this will happen soon after the handshake has completed, but it could be sometime later (or not at all). From matt at openssl.org Thu Sep 16 07:56:28 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Sep 2021 08:56:28 +0100 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: References: Message-ID: <0607b87b-d075-494c-3d40-6e0d13d4a141@openssl.org> On 16/09/2021 07:19, Jaya Muthiah wrote: > As I can read from the documents mentioned below, "or not at all" > worries me. Is there a situation when a session ticket is not sent at > all (other than when reused)? TLSv1.3 does not require the server to send any tickets if it decides not to. By default in OpenSSL a server will send 2 session tickets after a normal handshake, or 1 session ticket after a resumption handshake. There is nothing in the spec about that, so other libraries are very likely to have different policies and defaults. In OpenSSL it is possible to configure the a server to set the number of tickets that are sent - including down to 0. So, yes, there may be situations where the server does not send a session ticket. Matt From jeevhi at gmail.com Thu Sep 16 08:58:13 2021 From: jeevhi at gmail.com (Jaya Muthiah) Date: Thu, 16 Sep 2021 14:28:13 +0530 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: References: Message-ID: > TLSv1.3 does not require the server to send any tickets if it decides not to. What makes it decide NO TO. Here I am particularly interested in OpenSSL implementation only. > In OpenSSL it is possible to configure the server to set the number of tickets that are sent - including down to 0. I understand that part that, my query was for any condition not in the user's hand. So let me rephrase - if openssl is configured to send one ticket by calling SSL_CTX_set_num_tickets(), is there a condition under which OpenSSL will not send session tickets? From matt at openssl.org Thu Sep 16 09:05:44 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Sep 2021 10:05:44 +0100 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: References: Message-ID: On 16/09/2021 09:58, Jaya Muthiah wrote: >> TLSv1.3 does not require the server to send any tickets if it decides not to. > What makes it decide NO TO. Here I am particularly interested in > OpenSSL implementation only. > >> In OpenSSL it is possible to configure the server to set the number of tickets that are sent - including down to 0. > > I understand that part that, my query was for any condition not in the > user's hand. So let me rephrase - if openssl is configured to send one > ticket by calling SSL_CTX_set_num_tickets(), is there a condition > under which OpenSSL will not send session tickets? > No. Unless you configure the server otherwise OpenSSL will always send session ticket(s) in TLSv1.3. Matt From hkario at redhat.com Thu Sep 16 14:11:49 2021 From: hkario at redhat.com (Hubert Kario) Date: Thu, 16 Sep 2021 16:11:49 +0200 Subject: Getting =?iso-8859-1?Q?SSL=5FSESSION_remaining_lifetime?= In-Reply-To: References: Message-ID: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > I am trying to get the remaining lifetime of the ticket so that > server can decide to renew ticket or not TLS 1.3 tickets are single use. If the ticket was used by a client, and you expect it to make a connection in the future, server needs to send a new one. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From bkaduk at akamai.com Thu Sep 16 14:28:47 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 16 Sep 2021 07:28:47 -0700 Subject: Getting SSL_SESSION remaining lifetime In-Reply-To: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> References: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> Message-ID: <20210916142846.GE19992@akamai.com> On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > I am trying to get the remaining lifetime of the ticket so that server > > can decide to renew ticket or not > > TLS 1.3 tickets are single use. If the ticket was used by a client, and > you expect it to make a connection in the future, server needs to send a new > one. Single-use tickets are only a protocol requirement when 0-RTT data is used. The OpenSSL implementation even allows the libssl-internal enforcement of single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html). OpenSSL as a client also has some measures to encourate single-use tickets, which I have a PR open to provide a knob to disable: https://github.com/openssl/openssl/pull/16598 . -Ben From hkario at redhat.com Thu Sep 16 14:57:03 2021 From: hkario at redhat.com (Hubert Kario) Date: Thu, 16 Sep 2021 16:57:03 +0200 Subject: Getting =?iso-8859-1?Q?SSL=5FSESSION_remaining_lifetime?= In-Reply-To: <20210916142846.GE19992@akamai.com> References: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> <20210916142846.GE19992@akamai.com> Message-ID: <7e02d2fc-9e09-47f0-a398-d7e0a3dd3dac@redhat.com> On Thursday, 16 September 2021 16:28:47 CEST, Benjamin Kaduk wrote: > On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: >> On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: >>> >>> I am trying to get the remaining lifetime of the ticket so that server >>> can decide to renew ticket or not >> >> TLS 1.3 tickets are single use. If the ticket was used by a client, and >> you expect it to make a connection in the future, server needs >> to send a new >> one. > > Single-use tickets are only a protocol requirement when 0-RTT data is used. > The OpenSSL implementation even allows the libssl-internal enforcement of > single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at > https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html). > OpenSSL as a client also has some measures to encourate single-use tickets, > which I have a PR open to provide a knob to disable: > https://github.com/openssl/openssl/pull/16598 . They're single use not only because of replay but also because of privacy reasons, as reuse of a ticket indicates that the same client did send it. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From bkaduk at akamai.com Thu Sep 16 15:01:17 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 16 Sep 2021 08:01:17 -0700 Subject: Getting SSL_SESSION remaining lifetime In-Reply-To: <7e02d2fc-9e09-47f0-a398-d7e0a3dd3dac@redhat.com> References: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> <20210916142846.GE19992@akamai.com> <7e02d2fc-9e09-47f0-a398-d7e0a3dd3dac@redhat.com> Message-ID: <20210916150116.GF19992@akamai.com> On Thu, Sep 16, 2021 at 04:57:03PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 16:28:47 CEST, Benjamin Kaduk wrote: > > On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > > > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > > > > > I am trying to get the remaining lifetime of the ticket so that server > > > > can decide to renew ticket or not > > > > > > TLS 1.3 tickets are single use. If the ticket was used by a client, and > > > you expect it to make a connection in the future, server needs to > > > send a new > > > one. > > > > Single-use tickets are only a protocol requirement when 0-RTT data is used. > > The OpenSSL implementation even allows the libssl-internal enforcement of > > single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at > > https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_b4HS_rcA$ ). > > OpenSSL as a client also has some measures to encourate single-use tickets, > > which I have a PR open to provide a knob to disable: > > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/16598__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_YPrcg6yw$ . > > They're single use not only because of replay but also because of privacy > reasons, as reuse of a ticket indicates that the same client did send it. Yes. But the protocol itself only encourages single-use for privacy reasons. The protocol does not *require* single-use in that case. -Ben From openssl-users at dukhovni.org Thu Sep 16 15:59:48 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Sep 2021 11:59:48 -0400 Subject: Getting SSL_SESSION remaining lifetime In-Reply-To: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> References: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> Message-ID: On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > I am trying to get the remaining lifetime of the ticket so that > > server can decide to renew ticket or not > > TLS 1.3 tickets are single use. If the ticket was used by a client, > and you expect it to make a connection in the future, server needs to > send a new one. This is wrong both in terms of specification and the extant OpenSSL implementation. The Postfix SMTP server arranges to accept multi-use tickets without reissuing replacement tickets when the original ticket is still good for reuse. Ticket reuse is well suited to the MTA-to-MTA use-case where "privacy" is not only a concern but in fact undesirable. MTAs often reject traffic from senders with no PTR records, generic PTR records, poor IP reputation, .... The Internet does not solely consist of browser traffic from portable devices at wifi hotspots to taboo web sites. -- Viktor. From openssl-users at dukhovni.org Thu Sep 16 16:20:05 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Sep 2021 12:20:05 -0400 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: References: Message-ID: On Thu, Sep 16, 2021 at 10:05:44AM +0100, Matt Caswell wrote: > No. Unless you configure the server otherwise OpenSSL will always send > session ticket(s) in TLSv1.3. It may be worth mentioning a discussion from some time back on the TLSWG list started by David Benjamin that notes that in TLS 1.3 it is not always opportune for the server to send post-handshake session resumption tickets unless it is also sending some application data. If the application protocol in question has the client sending first and delivering a large request to the server before attempting to read a response, an "unsolicited" transmission of session tickets from server to client may cause an application protocol deadlock if the client's TCP window is not large enough to accommodate the session tickets withour any client-side reads. This situation can with some justification be argued to be a defect in the TLS 1.3 protocol. I don't recall whether OpenSSL makes any effort to or supports deferring the transmission of session tickets until just before the first application data transmission from server to client (or else perhaps just before responding to a received close-notify with a reciprocal close-notify) -- Viktor. From bkaduk at akamai.com Thu Sep 16 16:30:18 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 16 Sep 2021 09:30:18 -0700 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: References: Message-ID: <20210916163018.GG19992@akamai.com> On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > I don't recall whether OpenSSL makes any effort to or supports deferring > the transmission of session tickets until just before the first > application data transmission from server to client (or else perhaps > just before responding to a received close-notify with a reciprocal > close-notify) It's not the default behavior, but is supported: you can configure the SSL/SSL_CTX to send zero tickets by default and then manually call SSL_new_session_ticket(), which defers the transmission until there is another write or explicit SSL_do_handshake() call. -Ben From openssl-users at dukhovni.org Thu Sep 16 16:40:55 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Sep 2021 12:40:55 -0400 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: <20210916163018.GG19992@akamai.com> References: <20210916163018.GG19992@akamai.com> Message-ID: On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users wrote: > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > > > I don't recall whether OpenSSL makes any effort to or supports deferring > > the transmission of session tickets until just before the first > > application data transmission from server to client (or else perhaps > > just before responding to a received close-notify with a reciprocal > > close-notify) > > It's not the default behavior, but is supported: you can configure the > SSL/SSL_CTX to send zero tickets by default and then manually call > SSL_new_session_ticket(), which defers the transmission until there is another > write or explicit SSL_do_handshake() call. So nothing built-in... What I had in mind was a built-in behaviour of the library to delay session ticket transmission until there's a first opportunity to send some application data, which the client application can be reasonably expected to read at that point. If this is left entirely to applications, many of the less sophisticated ones might not know to consider the issue. In my SMTP use-cases, after STARTTLS, the client is expected to send a short "EHLO" command, and then turn around and read a server response, so deadlock would require a very small TCP window on the server side, and/or an unreasonably large (many kilobytes) client EHLO name. So Postfix does not take any application-layer steps to postpone session ticket transmission. I also would not to send session tickets without an indication that the client did not present a sufficiently fresh ticket, so handling session ticket generation in the application logic would become even more complex... -- Viktor. From bkaduk at akamai.com Thu Sep 16 16:49:31 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 16 Sep 2021 09:49:31 -0700 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: References: <20210916163018.GG19992@akamai.com> Message-ID: <20210916164930.GH19992@akamai.com> On Thu, Sep 16, 2021 at 12:40:55PM -0400, Viktor Dukhovni wrote: > On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users wrote: > > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > > > > > I don't recall whether OpenSSL makes any effort to or supports deferring > > > the transmission of session tickets until just before the first > > > application data transmission from server to client (or else perhaps > > > just before responding to a received close-notify with a reciprocal > > > close-notify) > > > > It's not the default behavior, but is supported: you can configure the > > SSL/SSL_CTX to send zero tickets by default and then manually call > > SSL_new_session_ticket(), which defers the transmission until there is another > > write or explicit SSL_do_handshake() call. > > So nothing built-in... What I had in mind was a built-in behaviour of > the library to delay session ticket transmission until there's a first > opportunity to send some application data, which the client application > can be reasonably expected to read at that point. While I'm not opposed to having some turnkey solution built in, I do think that the current default of sending tickets immediately after the handshake is the correct *default* behavior. That makes the new session (with ticket and resumption capability) available to clients right after the handshake, instead of needing to wait until some actual data from the server arrives. I'd be interested in hearing your thoughts about what an API/config would look like to enable the delayed-send behavior. -Ben From hkario at redhat.com Thu Sep 16 16:50:40 2021 From: hkario at redhat.com (Hubert Kario) Date: Thu, 16 Sep 2021 18:50:40 +0200 Subject: Getting =?iso-8859-1?Q?SSL=5FSESSION_remaining_lifetime?= In-Reply-To: References: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> Message-ID: <8615a8da-48e5-423a-b562-fc6a8a15ec79@redhat.com> On Thursday, 16 September 2021 17:59:48 CEST, Viktor Dukhovni wrote: > The Internet does not solely consist of browser traffic from portable > devices at wifi hotspots to taboo web sites. taboo web sites are not the only reason to expect privacy... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From openssl-users at dukhovni.org Thu Sep 16 16:59:40 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Sep 2021 12:59:40 -0400 Subject: Getting SSL_SESSION remaining lifetime In-Reply-To: <8615a8da-48e5-423a-b562-fc6a8a15ec79@redhat.com> References: <2ff258d5-b703-47ff-92ce-2a392d9af13f@redhat.com> <8615a8da-48e5-423a-b562-fc6a8a15ec79@redhat.com> Message-ID: On Thu, Sep 16, 2021 at 06:50:40PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 17:59:48 CEST, Viktor Dukhovni wrote: > > The Internet does not solely consist of browser traffic from portable > > devices at wifi hotspots to taboo web sites. > > taboo web sites are not the only reason to expect privacy... Indeed, but there are also applications in which client "privacy" is both unavailable and undesirable. One size does not fit all. -- Viktor. From openssl-users at dukhovni.org Thu Sep 16 17:11:47 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 16 Sep 2021 13:11:47 -0400 Subject: Will TLSv1.3 always send session ticket? In-Reply-To: <20210916164930.GH19992@akamai.com> References: <20210916163018.GG19992@akamai.com> <20210916164930.GH19992@akamai.com> Message-ID: On Thu, Sep 16, 2021 at 09:49:31AM -0700, Benjamin Kaduk via openssl-users wrote: > I'd be interested in hearing your thoughts about what an API/config would look > like to enable the delayed-send behavior. A simple boolean SSL_CONF_CMD called something like: -ticket_delay, or -ticket_data_prepend would cause the ticket generation to be deferred until the first application data write from server to client. The API would be either a direct call to set the boolean, or an indirect action via the SSL_CONF layer. This would require a new bit to set the policy in the SSL_CTX that would be inherited by any derived SSL handles. The first data transmission would inspect the desired ticket count computed during the handshake, and send that many tickets, resetting the count to zero. The current immediate transmission of tickets would merely squirrel away the number of tickets to send with the first batch of data. -- Viktor. From kory at avatarci.com Fri Sep 17 18:55:14 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Fri, 17 Sep 2021 11:55:14 -0700 Subject: openssl 3.0.0 legacy provider won't lload via config file In-Reply-To: <43efa5a497e6aa24528751c0192a4248aa0a8168.camel@openssl.org> References: <0455B902-B5BE-44F8-A951-2180D098BF2C@avatarci.com> <43efa5a497e6aa24528751c0192a4248aa0a8168.camel@openssl.org> Message-ID: <793F4B74-B253-4054-B513-FF303D33912A@avatarci.com> > On Sep 14, 2021, at 12:03 AM, Tomas Mraz wrote: > > On Mon, 2021-09-13 at 16:13 -0700, Kory Hamzeh wrote: >> I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far, everything >> seems to be working fine, except for the fact that I cannot get >> OpenSSL to load the legacy module when I configure /ssl/openssl.cnf >> as such. I can, however, load the module explicitly at run time. >> > ... >> >> The EVP_DecryptInit_ex() fails if I compile without -DLOAD_PROVIDER. >> The other flag, CRYPTO_INIT does not make any difference. What is >> puzzling is that I can build OpenSSL natively on an x86_64 machine >> and using the same openssl.cnf file, the code above works and the >> legacy module loads without the code to explicitly load it. >> >> Any thoughts on what I may have done wrong or how to track this down? > > Could it be that your cross-compiled build expects the configuration > file to be somewhere else? Have you tried to strace the application to > see where it searches for the openssl.cnf? OK, I ran strace and notice what might be a bug in OpenSSL 3.0.0. Let me first start by saying that we run a mixture of OpenSSL 1.0.1g and OpenSSL 3.0.0. We are planning to upgrade all of the apps to 3.0.0, but some of the vendors have not upgraded yet. The 1.0.1g config directory is /ssl. I configured OpenSSL 3.0.0 to use /ssl-3 for its config files as follows: ./Configure linux-armv4 -march=armv7-a shared enable-fips --cross-compile-prefix=arm-none-linux-gnueabi- --prefix=/ --openssldir=/ssl-3 The Makefile confirms this: OPENSSLDIR=/ssl-3 I make and make install like this: make DESTDIR=$INSTALL_DIR install_ssldirs install_sw install_fips where $INSTALL_DIR is where we build the rootfs structure. I can see that it created $INSTALL_DIR/ssl-3. But an stace of the apps show: open("/ssl/openssl.cnf", O_RDONLY|O_LARGEFILE) = 3 If I: export OPENSSL_CONF="/ssl-3/openssl.cnf? before I run my apps, everything works. But this is disconcerting. Any thoughts or feedback? Thanks, Kory From 215104920 at qq.com Sat Sep 18 03:34:49 2021 From: 215104920 at qq.com (=?utf-8?B?MjE1MTA0OTIw?=) Date: Sat, 18 Sep 2021 11:34:49 +0800 Subject: Does the openssl support RFC5755: Group. Role. Access Identify? Message-ID: Hi. There  Could you give me some help?  Thanks a lot.  BRs Mystic  -------------- next part -------------- An HTML attachment was scrubbed... URL: From dipto181 at gmail.com Mon Sep 20 01:03:06 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Sun, 19 Sep 2021 19:03:06 -0600 Subject: Calling OpenSSL functions from custom openssl engine causing segmentation fault? Message-ID: Hello, I have installed OpenSSL 1.1.1c. I'm trying to make a custom OpenSSL engine for RSA. The following sample code is copied from the engine *e_dasync.c. * Following is a sample code for my RSA engine (*rsa-engine.c*), =================================== */* Engine Id and Name */static const char *engine_rsa_id = "rsa-engine-new";static const char *engine_rsa_name = "RSA engine for testing";// data encryption functionstatic int eng_rsa_pub_enc(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding) { printf("RSA Engine is encrypting using public key\n"); return RSA_meth_get_pub_enc(RSA_PKCS1_OpenSSL()) (flen,from,to,rsa,padding);}// signature verifystatic int eng_rsa_pub_dec(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding) { printf("Signature verification\n"); return 0;}// signaturestatic int eng_rsa_priv_enc(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding){ printf("Signature method:\n"); return 0;}// data decryptionstatic int eng_rsa_priv_dec(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding){ printf("decryption method:\n"); return 0; }static RSA_METHOD *test_rsa_method = NULL;static int bind_dasync(ENGINE *e){ /* Setup RSA_METHOD */ if ((test_rsa_method = RSA_meth_new("Test RSA Engine", 0)) == NULL || RSA_meth_set_pub_enc(test_rsa_method, eng_rsa_pub_enc) == 0 || RSA_meth_set_pub_dec(test_rsa_method, eng_rsa_pub_dec) == 0 || RSA_meth_set_priv_enc(test_rsa_method, eng_rsa_priv_enc) == 0 || RSA_meth_set_priv_dec(test_rsa_method, eng_rsa_priv_dec) == 0 ) { return 0; } /* Ensure the dasync error handling is set up */ if (!ENGINE_set_id(e, engine_rsa_id) || !ENGINE_set_name(e, engine_rsa_name) || !ENGINE_set_RSA(e, test_rsa_method) ) { return 0; } return 1;}static int bind_helper(ENGINE *e, const char *id){ if (!bind_dasync(e)){ printf("2_Error: Inside Bind helper\n"); return 0; } return 1;}IMPLEMENT_DYNAMIC_BIND_FN(bind_helper)IMPLEMENT_DYNAMIC_CHECK_FN()* =================================== My *Makefile *looks like the following, =================================== *rsa-engine: gcc -g -fPIC -c rsa-engine.c gcc -g -shared -o librsa_engine.so -L./libdune rsa-engine.o -Bdynamic -lcrypto -lpthread mv librsa_engine.so rsa-engine-new.so sudo cp rsa-engine-new.so /opt/openssl/lib/engines-1.1/clean: rm -f *.o *.d *.so rsa-engine* =================================== My code compiles. When I try to do encryption using the following command, ========================= *openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out msg.enc -engine rsa-engine-new* ========================= I get a segmentation fault, ================================ *engine "rsa-engine-new" set.RSA Engine is encrypting using public keySegmentation fault (core dumped)* ================================ Do I need to Compile this sample engine with the OpenSSL in order for it to work? Regards, Shariful Alam -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Mon Sep 20 07:05:42 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 20 Sep 2021 09:05:42 +0200 Subject: Does the openssl support RFC5755: Group. Role. Access Identify? In-Reply-To: References: Message-ID: As this requires support for Attribute Certificates which is not currently present in OpenSSL neither RFC 5755 is supported. Regards, Tomas On Sat, 2021-09-18 at 11:34 +0800, 215104920 via openssl-users wrote: > Hi. There? > Could you give me some help?? > Thanks a lot.? > > > BRs > Mystic? -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tomas at openssl.org Mon Sep 20 07:18:39 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 20 Sep 2021 09:18:39 +0200 Subject: openssl 3.0.0 legacy provider won't lload via config file In-Reply-To: <793F4B74-B253-4054-B513-FF303D33912A@avatarci.com> References: <0455B902-B5BE-44F8-A951-2180D098BF2C@avatarci.com> <43efa5a497e6aa24528751c0192a4248aa0a8168.camel@openssl.org> <793F4B74-B253-4054-B513-FF303D33912A@avatarci.com> Message-ID: <0038c2af23a7178119864bfbc434af70407a5f54.camel@openssl.org> This is really weird. The OPENSSLDIR as in the Makefile should be applied during the build. If you do strings does it show the ssl-3? Is it possible that you have some other build of openssl-3.0 with incorrect (default) OPENSSLDIR lying on the system somewhere? Please open an GitHub issue so we can investigate this further. Tomas Mraz On Fri, 2021-09-17 at 11:55 -0700, Kory Hamzeh wrote: > > > > On Sep 14, 2021, at 12:03 AM, Tomas Mraz wrote: > > > > On Mon, 2021-09-13 at 16:13 -0700, Kory Hamzeh wrote: > > > I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far, > > > everything > > > seems to be working fine, except for the fact that I cannot get > > > OpenSSL to load the legacy module when I configure > > > /ssl/openssl.cnf > > > as such. I can, however, load the module explicitly at run time. > > > > > ... > > > > > > The EVP_DecryptInit_ex() fails if I compile without - > > > DLOAD_PROVIDER. > > > The other flag, CRYPTO_INIT does not make any difference. What is > > > puzzling is that I can build OpenSSL natively on an x86_64 > > > machine > > > and using the same openssl.cnf file, the code above works and the > > > legacy module loads without the code to explicitly load it. > > > > > > Any thoughts on what I may have done wrong or how to track this > > > down? > > > > Could it be that your cross-compiled build expects the > > configuration > > file to be somewhere else? Have you tried to strace the application > > to > > see where it searches for the openssl.cnf? > > OK, I ran strace and notice what might be a bug in OpenSSL 3.0.0. > > Let me first start by saying that we run a mixture of OpenSSL 1.0.1g > and OpenSSL 3.0.0. We are planning to upgrade all of the apps to > 3.0.0, but some of the vendors have not upgraded yet. > > The 1.0.1g config directory is /ssl. > > I configured OpenSSL 3.0.0 to use /ssl-3 for its config files as > follows: > > ./Configure linux-armv4 -march=armv7-a shared enable-fips --cross- > compile-prefix=arm-none-linux-gnueabi- --prefix=/ --openssldir=/ssl-3 > > The Makefile confirms this: > > OPENSSLDIR=/ssl-3 > > I make and make install like this: > > ?make DESTDIR=$INSTALL_DIR install_ssldirs install_sw install_fips > > where $INSTALL_DIR is where we build the rootfs structure. I can see > that it created $INSTALL_DIR/ssl-3. > > But an stace of the apps show: > > open("/ssl/openssl.cnf", O_RDONLY|O_LARGEFILE) = 3 > > If I: > > export OPENSSL_CONF="/ssl-3/openssl.cnf? > > before I run my apps, everything works. But this is disconcerting. > > Any thoughts or feedback? > > Thanks, > Kory > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From beldmit at gmail.com Mon Sep 20 07:49:39 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 20 Sep 2021 09:49:39 +0200 Subject: Calling OpenSSL functions from custom openssl engine causing segmentation fault? In-Reply-To: References: Message-ID: Hello, Usually you don't, and if you compile it against the same major release, no problems happen. I'd suggest you to look at the backtrace. On Mon, Sep 20, 2021 at 3:03 AM Shariful Alam wrote: > Hello, > I have installed OpenSSL 1.1.1c. I'm trying to make a custom OpenSSL > engine for RSA. The following sample code is copied from the engine > *e_dasync.c. * > > > Following is a sample code for my RSA engine (*rsa-engine.c*), > =================================== > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > */* Engine Id and Name */static const char *engine_rsa_id = > "rsa-engine-new";static const char *engine_rsa_name = "RSA engine for > testing";// data encryption functionstatic int eng_rsa_pub_enc(int flen, > const unsigned char *from, unsigned char *to, RSA *rsa, int padding) { > printf("RSA Engine is encrypting using public key\n"); return > RSA_meth_get_pub_enc(RSA_PKCS1_OpenSSL()) > (flen,from,to,rsa,padding);}// signature verifystatic int > eng_rsa_pub_dec(int flen, const unsigned char *from, > unsigned char *to, RSA *rsa, int padding) { printf("Signature > verification\n"); return 0;}// signaturestatic int eng_rsa_priv_enc(int > flen, const unsigned char *from, unsigned char *to, RSA *rsa, int > padding){ printf("Signature method:\n"); return 0;}// data > decryptionstatic int eng_rsa_priv_dec(int flen, const unsigned char *from, > unsigned char *to, RSA *rsa, int padding){ printf("decryption > method:\n"); return 0; }static RSA_METHOD *test_rsa_method = NULL;static > int bind_dasync(ENGINE *e){ /* Setup RSA_METHOD */ if > ((test_rsa_method = RSA_meth_new("Test RSA Engine", 0)) == NULL || > RSA_meth_set_pub_enc(test_rsa_method, eng_rsa_pub_enc) == 0 || > RSA_meth_set_pub_dec(test_rsa_method, eng_rsa_pub_dec) == 0 || > RSA_meth_set_priv_enc(test_rsa_method, eng_rsa_priv_enc) == 0 || > RSA_meth_set_priv_dec(test_rsa_method, eng_rsa_priv_dec) == 0 ) > { return 0; } /* Ensure the dasync error handling is set up > */ if (!ENGINE_set_id(e, engine_rsa_id) || !ENGINE_set_name(e, > engine_rsa_name) || !ENGINE_set_RSA(e, test_rsa_method) ) > { return 0; } return 1;}static int bind_helper(ENGINE *e, > const char *id){ if (!bind_dasync(e)){ printf("2_Error: Inside > Bind helper\n"); return 0; } return > 1;}IMPLEMENT_DYNAMIC_BIND_FN(bind_helper)IMPLEMENT_DYNAMIC_CHECK_FN()* > =================================== > > My *Makefile *looks like the following, > =================================== > > > > > > > > *rsa-engine: gcc -g -fPIC -c rsa-engine.c gcc -g -shared -o > librsa_engine.so -L./libdune rsa-engine.o -Bdynamic -lcrypto -lpthread mv > librsa_engine.so rsa-engine-new.so sudo cp rsa-engine-new.so > /opt/openssl/lib/engines-1.1/clean: rm -f *.o *.d *.so rsa-engine* > =================================== > > My code compiles. When I try to do encryption using the following command, > ========================= > *openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out msg.enc > -engine rsa-engine-new* > ========================= > > I get a segmentation fault, > ================================ > > > *engine "rsa-engine-new" set.RSA Engine is encrypting using public > keySegmentation fault (core dumped)* > ================================ > > Do I need to Compile this sample engine with the OpenSSL in order for it > to work? > > Regards, > Shariful Alam > > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shivakumar.Poojari at rbbn.com Mon Sep 20 13:59:04 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Mon, 20 Sep 2021 13:59:04 +0000 Subject: No subject Message-ID: Hi #define of BIOerr and BUFerr is deprecated in openssl3.0 # ifndef OPENSSL_NO_DEPRECATED_3_0 #define BIOerr(f, r) ERR_raise_data(ERR_LIB_BIO, (r), NULL) # define BUFerr(f, r) ERR_raise_data(ERR_LIB_BUF, (r), NULL) #endif The BIOerr and BUFerr are used in the code something like below BIOerr(BIO_F_BIO_NEW_MEM_BUF, BIO_R_NULL_PARAMETER); BIOerr(BIO_F_MEM_WRITE, BIO_R_NULL_PARAMETER); BIOerr(BIO_F_MEM_WRITE, BIO_R_WRITE_TO_READ_ONLY_BIO); BIOerr(BIO_F_MEM_WRITE, BIO_R_NULL_PARAMETER); BUFerr(BUF_F_BUF_MEM_NEW, ERR_R_MALLOC_FAILURE); BUFerr(BUF_F_BUF_MEM_GROW, ERR_R_MALLOC_FAILURE); BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE); Now im trying to replace with void ERR_raise(int lib, int reason); But how do i manage "f" paramater which is highlighted in #define please suggest, thanks, shiva kumar Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 20 14:13:35 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Sep 2021 15:13:35 +0100 Subject: In-Reply-To: References: Message-ID: On 20/09/2021 14:59, Shivakumar Poojari wrote: > But how do i manage "f" paramater? which is highlighted in #define You don't. We no longer use F codes. Just drop that value. Matt > > please suggest, > > thanks, > shiva kumar > > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. From Shivakumar.Poojari at rbbn.com Mon Sep 20 14:38:04 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Mon, 20 Sep 2021 14:38:04 +0000 Subject: [EXTERNAL] Re: In-Reply-To: References: Message-ID: Thanks Matt! ________________________________ From: openssl-users on behalf of Matt Caswell Sent: Monday, September 20, 2021 7:43 PM To: openssl-users at openssl.org Subject: [EXTERNAL] Re: On 20/09/2021 14:59, Shivakumar Poojari wrote: > But how do i manage "f" paramater which is highlighted in #define You don't. We no longer use F codes. Just drop that value. Matt > > please suggest, > > thanks, > shiva kumar > > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kory at avatarci.com Mon Sep 20 16:07:48 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Mon, 20 Sep 2021 09:07:48 -0700 Subject: openssl 3.0.0 legacy provider won't lload via config file In-Reply-To: <0038c2af23a7178119864bfbc434af70407a5f54.camel@openssl.org> References: <0455B902-B5BE-44F8-A951-2180D098BF2C@avatarci.com> <43efa5a497e6aa24528751c0192a4248aa0a8168.camel@openssl.org> <793F4B74-B253-4054-B513-FF303D33912A@avatarci.com> <0038c2af23a7178119864bfbc434af70407a5f54.camel@openssl.org> Message-ID: <066A0095-A9C3-4208-BFB9-839B4CDBD062@avatarci.com> Hi Tomas, It looks correct. This is on the ARM target: sc3822> find / -name libcrypto.so.3 -print /lib/libcrypto.so.3 sc3822> strings /lib/libcrypto.so.3 | grep /ssl /ssl-3//ct_log_list.cnf OPENSSLDIR: "/ssl-3/" /ssl-3/ /ssl-3//private /ssl-3//certs /ssl-3//cert.pem sc3822> I will open an issue. Kory > On Sep 20, 2021, at 12:18 AM, Tomas Mraz wrote: > > This is really weird. The OPENSSLDIR as in the Makefile should be > applied during the build. If you do strings does > it show the ssl-3? Is it possible that you have some other build of > openssl-3.0 with incorrect (default) OPENSSLDIR lying on the system > somewhere? > > Please open an GitHub issue so we can investigate this further. > > Tomas Mraz > > > On Fri, 2021-09-17 at 11:55 -0700, Kory Hamzeh wrote: >> >> >>> On Sep 14, 2021, at 12:03 AM, Tomas Mraz wrote: >>> >>> On Mon, 2021-09-13 at 16:13 -0700, Kory Hamzeh wrote: >>>> I have cross-compiled OpenSSL 3.0.0 for the ARMv7. So far, >>>> everything >>>> seems to be working fine, except for the fact that I cannot get >>>> OpenSSL to load the legacy module when I configure >>>> /ssl/openssl.cnf >>>> as such. I can, however, load the module explicitly at run time. >>>> >>> ... >>>> >>>> The EVP_DecryptInit_ex() fails if I compile without - >>>> DLOAD_PROVIDER. >>>> The other flag, CRYPTO_INIT does not make any difference. What is >>>> puzzling is that I can build OpenSSL natively on an x86_64 >>>> machine >>>> and using the same openssl.cnf file, the code above works and the >>>> legacy module loads without the code to explicitly load it. >>>> >>>> Any thoughts on what I may have done wrong or how to track this >>>> down? >>> >>> Could it be that your cross-compiled build expects the >>> configuration >>> file to be somewhere else? Have you tried to strace the application >>> to >>> see where it searches for the openssl.cnf? >> >> OK, I ran strace and notice what might be a bug in OpenSSL 3.0.0. >> >> Let me first start by saying that we run a mixture of OpenSSL 1.0.1g >> and OpenSSL 3.0.0. We are planning to upgrade all of the apps to >> 3.0.0, but some of the vendors have not upgraded yet. >> >> The 1.0.1g config directory is /ssl. >> >> I configured OpenSSL 3.0.0 to use /ssl-3 for its config files as >> follows: >> >> ./Configure linux-armv4 -march=armv7-a shared enable-fips --cross- >> compile-prefix=arm-none-linux-gnueabi- --prefix=/ --openssldir=/ssl-3 >> >> The Makefile confirms this: >> >> OPENSSLDIR=/ssl-3 >> >> I make and make install like this: >> >> make DESTDIR=$INSTALL_DIR install_ssldirs install_sw install_fips >> >> where $INSTALL_DIR is where we build the rootfs structure. I can see >> that it created $INSTALL_DIR/ssl-3. >> >> But an stace of the apps show: >> >> open("/ssl/openssl.cnf", O_RDONLY|O_LARGEFILE) = 3 >> >> If I: >> >> export OPENSSL_CONF="/ssl-3/openssl.cnf? >> >> before I run my apps, everything works. But this is disconcerting. >> >> Any thoughts or feedback? >> >> Thanks, >> Kory >> > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > From kgoldman at us.ibm.com Mon Sep 20 20:46:49 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 20 Sep 2021 16:46:49 -0400 Subject: openssl 3.0.0 equivalent to RSA_get0_key Message-ID: ... and RSA_get0_factors. I know about EVP_PKEY_get_bn_param(). However, that allocates new bignums. Therefore, the caller has to say, if >3.0.0, free them, else don't. The deprecated get0 functions just returned pointers that did not have to be separately freed. Is there a call to pass in an EVP_PKEY and get references to existing n,e,p, not allocated bignums? From pauli at openssl.org Mon Sep 20 22:50:56 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 21 Sep 2021 08:50:56 +1000 Subject: openssl 3.0.0 equivalent to RSA_get0_key In-Reply-To: References: Message-ID: <870ebd45-8f2d-846d-4a95-56eeb960d51d@openssl.org> No. The deprecated functions are not going away any time soon but there is no direct replacement. Pauli On 21/9/21 6:46 am, Ken Goldman wrote: > ... and RSA_get0_factors. > > I know about EVP_PKEY_get_bn_param().? However, that allocates new > bignums.? Therefore, the caller has to say, if >3.0.0, free them, else > don't. > > The deprecated get0 functions just returned pointers that did not have > to be separately freed. > > Is there a call to pass in an EVP_PKEY and get references to existing > n,e,p, not allocated bignums? > From 1nagarjun1 at gmail.com Tue Sep 21 06:49:31 2021 From: 1nagarjun1 at gmail.com (Nagarjun J) Date: Tue, 21 Sep 2021 12:19:31 +0530 Subject: Openssl aes-256 ctr drbg Message-ID: Hi, What is the Number of Bytes Returned by aes-256 ctr drbg ? Thanks, Nagarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Tue Sep 21 07:10:55 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 21 Sep 2021 17:10:55 +1000 Subject: Openssl aes-256 ctr drbg In-Reply-To: References: Message-ID: The number you asked for typically. Pauli On 21/9/21 4:49 pm, Nagarjun J wrote: > Hi, > What is the Number of Bytes Returned by aes-256 ctr drbg ? > > Thanks, > Nagarjun -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Tue Sep 21 14:50:33 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Tue, 21 Sep 2021 15:50:33 +0100 Subject: No subject Message-ID: Hello I was wondering how to migrate to a provider for Openssl 3.0 an engine for openssl 1.0.2 that was simply defining on an RSA_METHOD structure the method for modular exponentiation for RSA and getting call parameters from RSA_get_ex_data(), in order then to use an hw accelerator. Other methods were not re-defined . What should I do for making it a provider to run with Openssl 3.0? I cannot find this in the list of possible operations. Thank you Antonio -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Tue Sep 21 14:52:52 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Tue, 21 Sep 2021 15:52:52 +0100 Subject: RSA_METHOD on provider Message-ID: Hello I was wondering how to migrate to a provider for Openssl 3.0 an engine for openssl 1.0.2 that was simply defining on an RSA_METHOD structure the method for modular exponentiation for RSA and getting call parameters from RSA_get_ex_data(), in order then to use an hw accelerator. Other methods were not re-defined . What should I do for making it a provider to run with Openssl 3.0? I cannot find this in the list of possible operations. Thank you Antonio -------------- next part -------------- An HTML attachment was scrubbed... URL: From 215104920 at qq.com Wed Sep 22 01:54:33 2021 From: 215104920 at qq.com (=?utf-8?B?MjE1MTA0OTIw?=) Date: Wed, 22 Sep 2021 09:54:33 +0800 Subject: Does the openssl support RFC5755: Group. Role. Access Identify? In-Reply-To: References: Message-ID: Hi, there Is there a way to implement the different access identity for the different cert? For example, by setting the custom field, then the code the read it from the cert.  BRs Mystic ------------------ Original ------------------ From: "Tomas Mraz" From kory at avatarci.com Wed Sep 22 17:44:30 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Wed, 22 Sep 2021 10:44:30 -0700 Subject: OpenSSL 3.0.0 FIPS compatible ECDH-KAS Message-ID: I have an OpenSSL app which performs ECDH-KAS using openssl-1.0.1g + openssl-fips-2.0.5. It needs to be FIPS compatible. The app was written using the low level ECDH functions similar to what is documented here: https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman#Using_the_Low_Level_APIs According to the OpenSSL 3.0.0 Wiki, I MUST rewrite my code to use the high level EVP functions if I want FIPS compatibility. If so, I was going to follow the EVP example at the top of the same URL above. However, I can use some help. Using the EVP example on that page, when and which methods do I need to fetch? If I just add this at the top: EVP_set_default_properties(NULL, "fips=yes?); will that be enough? Thanks, Kory From pauli at openssl.org Wed Sep 22 22:29:09 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Thu, 23 Sep 2021 08:29:09 +1000 Subject: OpenSSL 3.0.0 FIPS compatible ECDH-KAS In-Reply-To: References: Message-ID: <275ce773-30a8-4382-66a6-2b2375cc73bb@openssl.org> Adding that should be enough to force only FIPS validated algorithms are used. Just doing that isn't enough, there is more you are going to need to do.? E.g. you will need to load the FIPS and base providers either via config or explicitly. It's possible to set the default properties via config too. Everything is documented and I'd recommend starting with the migration guide manual page and working from there. In my opinion, the 1.0 -> 1.1 transition is the more onerous part. Pauli On 23/9/21 3:44 am, Kory Hamzeh wrote: > I have an OpenSSL app which performs ECDH-KAS using openssl-1.0.1g + openssl-fips-2.0.5. It needs to be FIPS compatible. The app was written using the low level ECDH functions similar to what is documented here: > > https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman#Using_the_Low_Level_APIs > > According to the OpenSSL 3.0.0 Wiki, I MUST rewrite my code to use the high level EVP functions if I want FIPS compatibility. If so, I was going to follow the EVP example at the top of the same URL above. > > However, I can use some help. Using the EVP example on that page, when and which methods do I need to fetch? If I just add this at the top: > > EVP_set_default_properties(NULL, "fips=yes?); > > will that be enough? > > Thanks, > Kory > > > > From Christophe_Truc at bmc.com Thu Sep 23 11:59:30 2021 From: Christophe_Truc at bmc.com (Truc, Christophe) Date: Thu, 23 Sep 2021 11:59:30 +0000 Subject: OpenSSL and GCM mode Message-ID: Hi, I was wondering why it is currently impossible to encrypt a private key using GCM mode (eg using aes-256-gcm). This cannot be done using the openssl command line tool or using the library and API. This was not doable in version 1.0.2 and is still not possible with version 3. Is this a limitation or something that OpenSSL does not implement? In this case, could it be added in a future patch? Thank you, Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shivakumar.Poojari at rbbn.com Thu Sep 23 12:20:29 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Thu, 23 Sep 2021 12:20:29 +0000 Subject: Replacement for BIO_get_port(), BIO_get_host_ip() Message-ID: Hi BIO_get_port(), BIO_get_host_ip(), were deprecated in OpenSSL 1.1.0. Trying for replacement for OpenSSl 3.0 Gone through the below man page, with suggested function how do i get port& host_ip https://www.openssl.org/docs/manmaster/man3/BIO_connect.html please suggest, Thanks, Shiva kumar /docs/manmaster/man3/BIO_connect.html - OpenSSL NAME. BIO_socket, BIO_bind, BIO_connect, BIO_listen, BIO_accept_ex, BIO_closesocket - BIO socket communication setup routines. SYNOPSIS #include int BIO_socket(int domain, int socktype, int protocol, int options); int BIO_bind(int sock, const BIO_ADDR *addr, int options); int BIO_connect(int sock, const BIO_ADDR *addr, int options); int BIO_listen(int sock, const BIO_ADDR *addr ... www.openssl.org Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Zeke.Evans at microfocus.com Thu Sep 23 17:24:47 2021 From: Zeke.Evans at microfocus.com (Zeke Evans) Date: Thu, 23 Sep 2021 17:24:47 +0000 Subject: FIPS validation and documents Message-ID: I noticed the OpenSSL FIPS Provider is not listed on the CMVP Modules In Process List. Assuming this is the 3.0 FIPS module that was just released. Nice work on getting to this point. Which platforms is the module being validated on? I haven't seen an official list if that was published somewhere. Are there plans to publish the FIPS documents? When and where do you think we'll see those? Thanks, Zeke Evans Micro Focus -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Sep 23 19:30:39 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Sep 2021 20:30:39 +0100 Subject: FIPS validation and documents In-Reply-To: References: Message-ID: <6c9e08c1-bf7d-0663-a0e2-919cfa17c342@openssl.org> On 23/09/2021 18:24, Zeke Evans wrote: > > I noticed the OpenSSL FIPS Provider is not listed on the CMVP Modules > In Process List.? Assuming this is the 3.0 FIPS module that was just > released.? Nice work on getting to this point.? Which platforms is the > module being validated on?? I haven?t seen an official list if that > was published somewhere.? Are there plans to publish the FIPS > documents?? When and where do you think we?ll see those? > Co-incidentally? I just wrote a blog post about this: https://www.openssl.org/blog/blog/2021/09/22/OpenSSL3-fips-submission/ I'm not sure what the plans are for publishing FIPS documents. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shivakumar.Poojari at rbbn.com Fri Sep 24 06:05:29 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Fri, 24 Sep 2021 06:05:29 +0000 Subject: Replacement for BIO_get_port(), BIO_get_host_ip() Message-ID: Hi BIO_get_port(), BIO_get_host_ip(), were deprecated in OpenSSL 1.1.0. Trying for replacement for OpenSSl 3.0 Gone through the below man page, but not found alternative function. https://www.openssl.org/docs/manmaster/man3/BIO_connect.html please suggest, Thanks, Shiva kumar Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Fri Sep 24 10:55:49 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Fri, 24 Sep 2021 11:55:49 +0100 Subject: RSA provider use example Message-ID: Hello Is there any app or command in the current Openssl master repository that initialises and uses the new RSA provider? I would like to see how the RSA* context parameter is filled in and used, but I can't find an example using the RSA provider. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From angus at magsys.co.uk Fri Sep 24 11:16:00 2021 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Fri, 24 Sep 2021 12:16 +0100 (BST) Subject: RSA provider use example In-Reply-To: Message-ID: > I would like to see how the RSA* context parameter is filled in > and used, but I can't find an example using the RSA provider. This is an example I just created by building a OSSL_PARAM array with OSSL_PARAM_construct_xx and calling EVP_PKEY_get_params. I've been wondering if this is more efficient than getting the parameters one at a time using multiple EVP_PKEY_get_xx_param which also calls EVP_PKEY_get_params. I've removed trailing nulls from the unsigned integer fields where the returned data size is always the buffer size. RSA Key Parameters: Param Key: bits, type: Integer, len: 4 = 2048 Param Key: security-bits, type: Integer, len: 4 = 112 Param Key: max-size, type: Integer, len: 4 = 256 Param Key: e, type: UInteger, len: 1024 = 01000100 Param Key: n, type: UInteger, len: 1024 = CBE73B4395545CA90A5CE459EEDE322D0F8EFCA775C641626CE156C82B4482F3AAEA048A 73AD41A55F95FA330C858473D2A5C9F1AE771D2B9FE41B43178CFDCBC952725AFD06DA27 6F1F5298B8DE5E08F9DED442B57798A01DE09746FDF3ED920385AADDAFD391139595F3F1 37BD4DADE7F43FBA65BFF9EC4CBCF1A7A7A43D53183CE057797A60B28F326569C3B56B06 F7FD4FF310DA44AC1FFC1E81FA2480CCA9265D14AA99B0956A7ECBDAE94151E95D73ED67 2AC2BC654DA516D3A9F5C5C9CFC51B41EFC05A232AA40700C64A2DBD3D0EBFFE33BC0157 8FFB6E8CE06B28D448E2E18C42982A1DD2C73BB7D8B0A8B79DE20128586283036C03FD26 497BEE92 Param Key: d, type: UInteger, len: 1024 = 91ED9788089647F342094199DDF8097801CD30866D19E854649D16B5585311DDDC015AEB 7885AF558084A88911D00FF9315A5C943136655B91F11886970A9508176C3F1325E0D4B4 E7C6D4B44FEE74B96F1C42E0C40367A6213D74D9391AB01825F68A5F3D2A78241B600089 B3FF68D9DA2BA7D14E6F96255AAEB0A2906C22AA85308EC17DD4372A622C908D2ECB0A9E AA55773BE7C3C60D794D2E8628C71E95CB18A689BAB0385A20A5220521B71B1B5FB17A2D E47C8AEE7088B594B41A0C2A84DE0283CC72C96145761F7CE66768B004991B6F1725DF19 951A12C70DFDDAF36FBE9A8D218E085E8E69B604FE9772617A5E0721937626F6339A4A74 5C5DAB06 Param Key: rsa-factor1, type: UInteger, len: 1024 = 8D2CBBDD31C6B7F88AFAC5F935DF5CED43D83D296B5B389B1CC2CE741C217594F64490D0 D904D433AEBC4572240B6BD4D5B0C69AC96FC561447D759E97DA80CF07B5D559EF777785 84445221EB20599FCD0B2236DCA7786DD7CAB1FB1AA9A6B8DE1AB80E74201CF27BEC1479 542945632114590E1FA160FFC4833B0E2122CCBE Param Key: rsa-factor2, type: UInteger, len: 1024 = B70BD9C4340422CD11A6443AF3B86E557B6EC0F4DA981CC25FB9DD7A8E548A794BC7775D 3EFC3EB91B242CA1C7925B8CE887B3817E3CE3B15F9C400E3710D29C62485413C76A8377 08E3708A7D9FDE29964F2C0893E74498B6330F9C15C7A235A60B37AFB4E397E3C16F4F5A F146CC2674F98C4D4CC079B4310BE85FA2C124C5 Param Key: rsa-exponent1, type: UInteger, len: 1024 = B9708BB779BA7984AB023E60FBD1263CBA4490D64ECFDE2C319FE29907F5F02B7570D181 2F3F3EEEECEFEA1A9A9FCD2D9C373D74BB76CF709B3BEAB0879F61157550621C60B6A9F5 2D4E83A9B5DAE6B859DED1A775797BDB720F06A0FD9FF9B7F3EBEFD58CEC73B580EA67F6 8BFF385923EB6C0D06B8ED3867D902B36136A20F Param Key: rsa-exponent2, type: UInteger, len: 1024 = 152C82D495DD9CD6CF2327999B2B52C1F91BA352CDD2051CE8EE4D8EDE0D3C9B76B629AF EE1DC90A52CD5CC9B6B1A481CF549D1720A7DB59C89B13ABAC1677A50CB8814EE7F671B2 1D42F48AC74448738030278126FF8ABF06AC566FCF1F081BB72F9511202D06EF30A941FE 36660B4E9C745E0A1E5D66F6898A32226A9FC6B9 Param Key: rsa-coefficient1, type: UInteger, len: 1024 = 0C7F4DBEBAAEC38C0E636872F33803584AF8B00E7FF4799054A4C4BF56DB145D6914A4D8 9AB5C8F05C2794AC723BA26EF9E7FED4D3DFB6D710222A21EFA030C9A5E7175E36D072E7 74E1BB760BEF735672E3113A8D3F11BD227312A49077EDE7EC22D210972F8F28C832836B 58D414535641469B9D79378A16ACA582EC54BA3E Param Key: default-digest, type: String, len: 6 = SHA256 Total key parameters: 12 Angus From pauli at openssl.org Fri Sep 24 11:17:48 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Fri, 24 Sep 2021 21:17:48 +1000 Subject: RSA provider use example In-Reply-To: References: Message-ID: <6e78f9db-ed86-65d4-f8ae-27f8adf75a49@openssl.org> What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c 3.0 doesn't use the RSA structure in the non-deprecated public API. You probably want the EVP_PKEY_fromdata call. Pauli On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: > Hello > Is there any app or command in the current Openssl master repository > that initialises and uses the new RSA provider? > I would like to see how the RSA* context parameter is filled in and > used, but I can't find an example using the RSA provider. > > > Thank you > From matt at openssl.org Fri Sep 24 11:19:48 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Sep 2021 12:19:48 +0100 Subject: RSA provider use example In-Reply-To: References: Message-ID: <60b5055c-4b8c-5664-4808-96b7fb9b4a68@openssl.org> On 24/09/2021 11:55, Antonio Santagiuliana wrote: > Hello > Is there any app or command in the current Openssl master repository > that initialises and uses the new RSA provider? > I would like to see how the RSA* context parameter is filled in and > used, but I can't find an example using the RSA provider. There is no such thing as an "RSA provider". Probably what you mean to ask is there such an example of using RSA with the default provider. There is a demo of using RSA to encrypt/decrypt that is about the be added to the repo in this PR: https://github.com/openssl/openssl/pull/16283 There are some examples of RSA key generation, as well as descriptions of all the various RSA params that are available on this man page: https://www.openssl.org/docs/man3.0/man7/RSA.html There is an example of doing signature/verification here: https://github.com/openssl/openssl/blob/master/demos/signature/EVP_Signature_demo.c This last one isn't RSA specific. It's actually using EC - but most of the code (with the exception of the "get_key" function) would be identical for RSA. Matt From pauli at openssl.org Fri Sep 24 11:20:54 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Fri, 24 Sep 2021 21:20:54 +1000 Subject: RSA provider use example In-Reply-To: References: Message-ID: <891d4457-1b49-b3b3-f542-def6bff0fb71@openssl.org> On 24/9/21 9:15 pm, Angus Robertson - Magenta Systems Ltd wrote: > I've been wondering if this is more efficient than getting the > parameters one at a time using multiple EVP_PKEY_get_xx_param which > also calls EVP_PKEY_get_params. I'd be surprised if there was a lot of difference. If I had to give a guess (and it is a guess), I'd go for ever so slightly more efficient your way. Pauli From matt at openssl.org Fri Sep 24 11:21:47 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Sep 2021 12:21:47 +0100 Subject: RSA provider use example In-Reply-To: <6e78f9db-ed86-65d4-f8ae-27f8adf75a49@openssl.org> References: <6e78f9db-ed86-65d4-f8ae-27f8adf75a49@openssl.org> Message-ID: <1e56b6fa-e5e7-b8e0-77e2-f390defa1cdf@openssl.org> On 24/09/2021 12:17, Dr Paul Dale wrote: > What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c > 3.0 doesn't use the RSA structure in the non-deprecated public API. > > You probably want the EVP_PKEY_fromdata call. An example of building an RSA key from its constituent parts is available on the EVP_PKEY_fromdata() man page: https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html Matt > > > Pauli > > > On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: >> Hello >> Is there any app or command in the current Openssl master repository >> that initialises and uses the new RSA provider? >> I would like to see how the RSA* context parameter is filled in and >> used, but I can't find an example using the RSA provider. >> >> >> Thank you >> > From Shivakumar.Poojari at rbbn.com Fri Sep 24 12:53:18 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Fri, 24 Sep 2021 12:53:18 +0000 Subject: Replacement for BIO_get_port(), BIO_get_host_ip() In-Reply-To: References: Message-ID: Gentle reminder. Thanks, Shiva Kumar ________________________________ From: Shivakumar Poojari Sent: Friday, September 24, 2021 11:35 AM To: openssl-users at openssl.org Cc: Paramashivaiah, Sunil ; Kumar Mishra, Sanjeev Subject: Replacement for BIO_get_port(), BIO_get_host_ip() Hi BIO_get_port(), BIO_get_host_ip(), were deprecated in OpenSSL 1.1.0. Trying for replacement for OpenSSl 3.0 Gone through the below man page, but not found alternative function. https://www.openssl.org/docs/manmaster/man3/BIO_connect.html please suggest, Thanks, Shiva kumar Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Fri Sep 24 13:49:23 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Fri, 24 Sep 2021 14:49:23 +0100 Subject: RSA provider use example In-Reply-To: <1e56b6fa-e5e7-b8e0-77e2-f390defa1cdf@openssl.org> References: <6e78f9db-ed86-65d4-f8ae-27f8adf75a49@openssl.org> <1e56b6fa-e5e7-b8e0-77e2-f390defa1cdf@openssl.org> Message-ID: Hello , thank you all for the replies. Very useful. I have seen in Openssl/crypto/RSA/rsa_local.h the definition of rsa_st has a pointer to RSA_METHOD and I can't see this filled in in any of the examples' set up or initializations, where is it filled in for the default provider , for the RSA algorithm? I can see the methods pointers are used later down in the call chain from RSA_private_decrypt() in providers/implementation/asymciphers/rsa_enc but I can't find where these methods' pointers are set and I would like to understand how I could pass a different method pointer in the parameters for a different mod_exp operation , for example, or how I could set it on a completely new RSA implementation mimicking the one in the default provider but with different methods where I need them changed, minimizing the differences with the default provider's RSA. Thank you On Fri, 24 Sep 2021, 12:22 Matt Caswell, wrote: > > > On 24/09/2021 12:17, Dr Paul Dale wrote: > > What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c > > 3.0 doesn't use the RSA structure in the non-deprecated public API. > > > > You probably want the EVP_PKEY_fromdata call. > > An example of building an RSA key from its constituent parts is > available on the EVP_PKEY_fromdata() man page: > > https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html > > Matt > > > > > > > > Pauli > > > > > > On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: > >> Hello > >> Is there any app or command in the current Openssl master repository > >> that initialises and uses the new RSA provider? > >> I would like to see how the RSA* context parameter is filled in and > >> used, but I can't find an example using the RSA provider. > >> > >> > >> Thank you > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Sep 24 14:02:28 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Sep 2021 15:02:28 +0100 Subject: RSA provider use example In-Reply-To: References: <6e78f9db-ed86-65d4-f8ae-27f8adf75a49@openssl.org> <1e56b6fa-e5e7-b8e0-77e2-f390defa1cdf@openssl.org> Message-ID: On 24/09/2021 14:49, Antonio Santagiuliana wrote: > Hello , thank you all for the replies. Very useful. > I have seen in Openssl/crypto/RSA/rsa_local.h the definition of rsa_st > has a pointer to RSA_METHOD and I can't see this filled in in any of the > examples' set up or initializations, where is it filled in for the > default provider , for the RSA algorithm? > I can see the methods pointers are used later down in the call chain > from RSA_private_decrypt() in > providers/implementation/asymciphers/rsa_enc but I can't find where > these methods' pointers are set and I would like to understand how I > could pass a different method pointer in the parameters for a different > mod_exp operation , for example, or how I could set it on a completely > new RSA implementation mimicking the one in the default provider but > with different methods where I need them changed, minimizing the > differences with the default provider's RSA. The default RSA_METHOD structure to use can be set via RSA_set_default_method(): https://www.openssl.org/docs/man3.0/man3/RSA_set_default_method.html You can construct such an RSA_METHOD using the functions described here: https://www.openssl.org/docs/man3.0/man3/RSA_meth_new.html However all of the above is considered deprecated and legacy and may be removed from a future version of OpenSSL. Instead you are supposed to implement such things in a new provider. For example see: https://www.openssl.org/docs/man3.0/man7/provider-base.html https://www.openssl.org/docs/man3.0/man7/provider.html https://www.openssl.org/docs/man3.0/man7/provider-signature.html https://www.openssl.org/docs/man3.0/man7/provider-keymgmt.html Matt > Thank you > > > On Fri, 24 Sep 2021, 12:22 Matt Caswell, > wrote: > > > > On 24/09/2021 12:17, Dr Paul Dale wrote: > > What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c > > 3.0 doesn't use the RSA structure in the non-deprecated public API. > > > > You probably want the EVP_PKEY_fromdata call. > > An example of building an RSA key from its constituent parts is > available on the EVP_PKEY_fromdata() man page: > > https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html > > > Matt > > > > > > > > Pauli > > > > > > On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: > >> Hello > >> Is there any app or command in the current Openssl master > repository > >> that initialises and uses the new RSA provider? > >> I would like to see how the RSA* context parameter is filled in and > >> used, but I can't find an example using the RSA provider. > >> > >> > >> Thank you > >> > > > From santantonioswap at gmail.com Fri Sep 24 15:51:46 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Fri, 24 Sep 2021 16:51:46 +0100 Subject: RSA provider use example In-Reply-To: References: <6e78f9db-ed86-65d4-f8ae-27f8adf75a49@openssl.org> <1e56b6fa-e5e7-b8e0-77e2-f390defa1cdf@openssl.org> Message-ID: Thank you for your reply. I'm still a bit confused though. In /providers/implementations/asymcipher/rsa_enc.c I find function rsa_decrypt() that calls RSA_private_decrypt(prsactx->rsa) I haven't found other implementation of this RSA_private_decrypt() apart from the one in crypto/RSA/rsa_crypt.c , where the RSA argument passed is used to call this: rsa->meth->rsa_priv_dec() I can't find where this pointer to method was set up. I can't find it in the init of the default provider's rsa_enc.c and if the app requesting this default RSA can't use the set_method() because deprecated, how is this rsa_priv_dec pointer set up?where is the set up of it? Thank you On Fri, 24 Sep 2021, 15:02 Matt Caswell, wrote: > > > On 24/09/2021 14:49, Antonio Santagiuliana wrote: > > Hello , thank you all for the replies. Very useful. > > I have seen in Openssl/crypto/RSA/rsa_local.h the definition of rsa_st > > has a pointer to RSA_METHOD and I can't see this filled in in any of the > > examples' set up or initializations, where is it filled in for the > > default provider , for the RSA algorithm? > > I can see the methods pointers are used later down in the call chain > > from RSA_private_decrypt() in > > providers/implementation/asymciphers/rsa_enc but I can't find where > > these methods' pointers are set and I would like to understand how I > > could pass a different method pointer in the parameters for a different > > mod_exp operation , for example, or how I could set it on a completely > > new RSA implementation mimicking the one in the default provider but > > with different methods where I need them changed, minimizing the > > differences with the default provider's RSA. > > The default RSA_METHOD structure to use can be set via > RSA_set_default_method(): > > https://www.openssl.org/docs/man3.0/man3/RSA_set_default_method.html > > You can construct such an RSA_METHOD using the functions described here: > > https://www.openssl.org/docs/man3.0/man3/RSA_meth_new.html > > However all of the above is considered deprecated and legacy and may be > removed from a future version of OpenSSL. > > Instead you are supposed to implement such things in a new provider. For > example see: > > https://www.openssl.org/docs/man3.0/man7/provider-base.html > https://www.openssl.org/docs/man3.0/man7/provider.html > https://www.openssl.org/docs/man3.0/man7/provider-signature.html > https://www.openssl.org/docs/man3.0/man7/provider-keymgmt.html > > > Matt > > > > Thank you > > > > > > On Fri, 24 Sep 2021, 12:22 Matt Caswell, > > wrote: > > > > > > > > On 24/09/2021 12:17, Dr Paul Dale wrote: > > > What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c > > > 3.0 doesn't use the RSA structure in the non-deprecated public > API. > > > > > > You probably want the EVP_PKEY_fromdata call. > > > > An example of building an RSA key from its constituent parts is > > available on the EVP_PKEY_fromdata() man page: > > > > https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html > > > > > > Matt > > > > > > > > > > > > > Pauli > > > > > > > > > On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: > > >> Hello > > >> Is there any app or command in the current Openssl master > > repository > > >> that initialises and uses the new RSA provider? > > >> I would like to see how the RSA* context parameter is filled in > and > > >> used, but I can't find an example using the RSA provider. > > >> > > >> > > >> Thank you > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayf0ster at roadrunner.com Fri Sep 24 17:50:12 2021 From: jayf0ster at roadrunner.com (Jay Foster) Date: Fri, 24 Sep 2021 10:50:12 -0700 Subject: OpenSSL SSL_CTX_set_default_verify_paths Slow Message-ID: While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to 3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths() function is much slower in 3.0.0.? In 1.0.0 it would take about 0.1 seconds and in 3.0.0 it takes over 3 seconds. strace indicates that the extra time is during the actual reading of the cert.pem file. OpenSSL 1.0.2u: 1583? 17:41:43.233288 getuid32()??????? = 0 1583? 17:41:43.234439 geteuid32()?????? = 0 1583? 17:41:43.235379 getgid32()??????? = 0 1583? 17:41:43.236314 getegid32()?????? = 0 1583? 17:41:43.237285 open("/usr/local/ssl/cert.pem", O_RDONLY|O_LARGEFILE) = 4 1583? 17:41:43.238790 fstat64(4, {st_mode=S_IFREG|0666, st_size=79902, ...}) = 0 1583? 17:41:43.241239 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f38000 1583? 17:41:43.242257 read(4, "# Version: 1.51\n-----BEGIN CERTI"..., 4096) = 4096 1583? 17:41:43.244713 read(4, "NXozS7Gas44XRrIsQxzgHVGzbjHjhMM5"..., 4096) = 4096 1583? 17:41:43.249735 read(4, "hT37ha88HQfqDjrw43bAuEbFrskLMmrz"..., 4096) = 4096 1583? 17:41:43.258402 read(4, "vT0Lwdd8KkMaOIG+YD/is\nI19wKTakyY"..., 4096) = 4096 1583? 17:41:43.266628 read(4, "QQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ"..., 4096) = 4096 1583? 17:41:43.272394 read(4, "hG5QbutC+5yqHLkP88Oe\nLe3hwcyV07e"..., 4096) = 4096 1583? 17:41:43.280053 read(4, "wA3ekEzeOEz4vMQGn+H\nLL729fdC4uW/"..., 4096) = 4096 1583? 17:41:43.286542 read(4, "M48vCR85mLK4b19p71XZQvk/iXttmkQ3"..., 4096) = 4096 1583? 17:41:43.291246 read(4, "HdWdAgMBAAGjQjBA\nMA8GA1UdEwEB/wQ"..., 4096) = 4096 1583? 17:41:43.297614 read(4, "Lpyo7RJlbmr2EkRT\ncDCVw5wrWCs9CHR"..., 4096) = 4096 1583? 17:41:43.303533 read(4, "9IVVO5EFdkKrqeKM+2x\nLXY2JtwE65/3"..., 4096) = 4096 1583? 17:41:43.310932 read(4, "F8R+GuqSVzRmZTRouNjWwl2tVZi4Ut0\n"..., 4096) = 4096 1583? 17:41:43.316617 read(4, "WRJ2p\nmj6q1WZmAT7qSeaiNbz69t2Vjp"..., 4096) = 4096 1583? 17:41:43.322393 read(4, "R5B3LjiKY0QP6x93SGVvdh2azrsw\n/FQ"..., 4096) = 4096 1583? 17:41:43.329364 read(4, "TE1MDYzMDAwMDAwMFoXDTI1MDYyOTIzN"..., 4096) = 4096 1583? 17:41:43.334562 read(4, "oXkJKtv3\nL7IezMdeatiDh6GX70k1Pnc"..., 4096) = 4096 1583? 17:41:43.341086 read(4, "CAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1e"..., 4096) = 4096 1583? 17:41:43.347563 read(4, "gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHk"..., 4096) = 4096 1583? 17:41:43.352496 read(4, "wQFMAMB\nAf8wDgYDVR0PAQH/BAQDAgGG"..., 4096) = 4096 1583? 17:41:43.359379 read(4, "Mk7BPZ7hm/ELNKjD+Jo2FR3qyH\nB5T0Y"..., 4096) = 2078 1583? 17:41:43.363656 read(4, "", 4096) = 0 1583? 17:41:43.364918 close(4)????????? = 0 1583? 17:41:43.365884 munmap(0xb6f38000, 4096) = 0 1583? 17:41:43.371532 getuid32()??????? = 0 1583? 17:41:43.372463 geteuid32()?????? = 0 1583? 17:41:43.373396 getgid32()??????? = 0 1583? 17:41:43.374531 getegid32()?????? = 0 1583? 17:41:43.375540 timer_delete(0x1) = 0 OpenSSL 3.0.0: 1580? 17:19:03.601282 getuid32()??????? = 0 1580? 17:19:03.602289 geteuid32()?????? = 0 1580? 17:19:03.603231 getgid32()??????? = 0 1580? 17:19:03.604166 getegid32()?????? = 0 1580? 17:19:03.605141 open("/usr/lib/ssl-3/cert.pem", O_RDONLY|O_LARGEFILE) = 4 1580? 17:19:03.606731 fstat64(4, {st_mode=S_IFREG|0666, st_size=79902, ...}) = 0 1580? 17:19:03.609420 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ff1000 1580? 17:19:03.610449 read(4, "# Version: 1.51\n-----BEGIN CERTI"..., 4096) = 4096 1580? 17:19:03.612808 read(4, "NXozS7Gas44XRrIsQxzgHVGzbjHjhMM5"..., 4096) = 4096 1580? 17:19:03.713691 read(4, "hT37ha88HQfqDjrw43bAuEbFrskLMmrz"..., 4096) = 4096 1580? 17:19:03.906236 read(4, "vT0Lwdd8KkMaOIG+YD/is\nI19wKTakyY"..., 4096) = 4096 1580? 17:19:04.098848 read(4, "QQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ"..., 4096) = 4096 1580? 17:19:04.197974 read(4, "hG5QbutC+5yqHLkP88Oe\nLe3hwcyV07e"..., 4096) = 4096 1580? 17:19:04.344133 read(4, "wA3ekEzeOEz4vMQGn+H\nLL729fdC4uW/"..., 4096) = 4096 1580? 17:19:04.490050 read(4, "M48vCR85mLK4b19p71XZQvk/iXttmkQ3"..., 4096) = 4096 1580? 17:19:04.589137 read(4, "HdWdAgMBAAGjQjBA\nMA8GA1UdEwEB/wQ"..., 4096) = 4096 1580? 17:19:04.736698 read(4, "Lpyo7RJlbmr2EkRT\ncDCVw5wrWCs9CHR"..., 4096) = 4096 1580? 17:19:04.836338 read(4, "9IVVO5EFdkKrqeKM+2x\nLXY2JtwE65/3"..., 4096) = 4096 1580? 17:19:04.985568 read(4, "F8R+GuqSVzRmZTRouNjWwl2tVZi4Ut0\n"..., 4096) = 4096 1580? 17:19:05.087120 read(4, "WRJ2p\nmj6q1WZmAT7qSeaiNbz69t2Vjp"..., 4096) = 4096 1580? 17:19:05.189130 read(4, "R5B3LjiKY0QP6x93SGVvdh2azrsw\n/FQ"..., 4096) = 4096 1580? 17:19:05.343106 read(4, "TE1MDYzMDAwMDAwMFoXDTI1MDYyOTIzN"..., 4096) = 4096 1580? 17:19:05.441340 read(4, "oXkJKtv3\nL7IezMdeatiDh6GX70k1Pnc"..., 4096) = 4096 1580? 17:19:05.588597 read(4, "CAQ8AMIIBCgKCAQEA4jvhEXLeqKTTo1e"..., 4096) = 4096 1580? 17:19:05.736050 read(4, "gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHk"..., 4096) = 4096 1580? 17:19:05.896427 read(4, "wQFMAMB\nAf8wDgYDVR0PAQH/BAQDAgGG"..., 4096) = 4096 1580? 17:19:06.277284 read(4, "Mk7BPZ7hm/ELNKjD+Jo2FR3qyH\nB5T0Y"..., 4096) = 2078 1580? 17:19:06.473966 read(4, "", 4096) = 0 1580? 17:19:06.475169 close(4)????????? = 0 1580? 17:19:06.476206 munmap(0xb6ff1000, 4096) = 0 1580? 17:19:06.492602 getuid32()??????? = 0 1580? 17:19:06.493604 geteuid32()?????? = 0 1580? 17:19:06.494605 getgid32()??????? = 0 1580? 17:19:06.495607 getegid32()?????? = 0 1580? 17:19:06.496665 getuid32()??????? = 0 1580? 17:19:06.497666 geteuid32()?????? = 0 1580? 17:19:06.508460 getgid32()??????? = 0 1580? 17:19:06.509462 getegid32()?????? = 0 1580? 17:19:06.510544 timer_delete(0x1) = 0 Why so slow? Jay From simonkbaby at gmail.com Sat Sep 25 05:06:38 2021 From: simonkbaby at gmail.com (SIMON BABY) Date: Fri, 24 Sep 2021 22:06:38 -0700 Subject: query on PEM_write_bio_PKCS8PrivateKey Message-ID: Hi Team, I have a query. I see the below API is used to write the private key in encrypted PKCS#8 format. *PEM_write_bio_PKCS8PrivateKey()* and *PEM_write_PKCS8PrivateKey()* write a private key in an EVP_PKEY structure in PKCS#8 EncryptedPrivateKeyInfo format using PKCS#5 v2.0 password based encryption algorithms. Do we have an API for converting the encrypted private key file to an unencrypted private key file in PKCS#8 format? Regards Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Sat Sep 25 13:46:46 2021 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 25 Sep 2021 15:46:46 +0200 Subject: OpenSSL 3.0.0 custom entropy source In-Reply-To: References: <10312BEE-8543-42EF-B7DD-F665AF89A8B7@avatarci.com> Message-ID: <280f29bd-53c7-669d-8a63-ff0be3305012@wisemo.com> So is there no longer an API to feed entropy to the default or FIPS default RNG? Creating an entire provider just to feed input to the FIPS provider seems overkill. On 2021-09-14 01:00, Dr Paul Dale wrote: > Try working from providers/implementations/rands/seed_src.c? You'll > need to reimplement seed_src_generate() to use your RNG. > > To use your custom seed source, you can either use the OpenSSL > configuration file to set a "random" section that includes a "seed" > setting or you can call RAND_set_seed_source_type() early in your > startup sequence. > > > Pauli > > On 14/9/21 8:19 am, Kory Hamzeh wrote: >> Hi, >> >> We are upgrading from OpenSSL 1.0.1g+OpenSSL-FIPS-2.0.5 to 3.0.0. >> Yes, I know, big jump. We have our own entropy source we use to seed >> the OpenSSL DRBG. This is a basic code snippet of how we set it up: >> >> ???????? DRBG_CTX *dctx = FIPS_get_default_drbg(); >> ???????? FIPS_drbg_init(dctx, NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); >> ???????? FIPS_drbg_set_callbacks(dctx, >> rand_get_entropy, >> rand_free_entropy, >> ?????????????????????????????????????????????????? 0, >> rand_get_entropy, >> rand_free_entropy); >> >> >> Error checking has been removed in the example for the sake of brevity. >> >> I am trying to figure out? how to implement this with OpenSSL 3. From >> what I have read in the docs, I need to create a rand provider. But I >> still feel like I don?t understand how it all fit together. I did >> look at fuzz_rand.c and fake_rand.c, and if I understood everything >> correctly, neither of them use an external entropy/seed source. >> >> Are there better examples of what I am looking for? >> >> Thanks, >> Kory >> > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 From kory at avatarci.com Sat Sep 25 19:46:24 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Sat, 25 Sep 2021 12:46:24 -0700 Subject: OpenSSL 3.0.0 custom entropy source In-Reply-To: <280f29bd-53c7-669d-8a63-ff0be3305012@wisemo.com> References: <10312BEE-8543-42EF-B7DD-F665AF89A8B7@avatarci.com> <280f29bd-53c7-669d-8a63-ff0be3305012@wisemo.com> Message-ID: <4E64F7D6-6D06-41BB-B097-AD9B54775D00@avatarci.com> Correct, you need to create a provider. Look at providers/implementations/rands/seed_src.c as an example. You'll need to reimplement seed_src_generate() to use your RNG. Your seed source will need to be wrapped in a provider and registered using a name of your choice. See providers/defltprov.c and search for "seed?. To use your custom seed source, you can either use the OpenSSL configuration file to set a "random" section that includes a "seed" setting or you can call RAND_set_seed_source_type() early in your startup sequence. If you link in your provider, you will need to call OSSL_PROVIDER_add_builtin() with the name and init function before you call OSSL_PROVIDER_load() to load it. Then call OSSL_PROVIDER_load() for all of the other providers (default, base, FIPS, etc). > On Sep 25, 2021, at 6:46 AM, Jakob Bohm via openssl-users wrote: > > So is there no longer an API to feed entropy to the default or FIPS default RNG? > > Creating an entire provider just to feed input to the FIPS provider seems overkill. > > On 2021-09-14 01:00, Dr Paul Dale wrote: >> Try working from providers/implementations/rands/seed_src.c You'll need to reimplement seed_src_generate() to use your RNG. >> >> To use your custom seed source, you can either use the OpenSSL configuration file to set a "random" section that includes a "seed" setting or you can call RAND_set_seed_source_type() early in your startup sequence. >> >> >> Pauli >> >> On 14/9/21 8:19 am, Kory Hamzeh wrote: >>> Hi, >>> >>> We are upgrading from OpenSSL 1.0.1g+OpenSSL-FIPS-2.0.5 to 3.0.0. Yes, I know, big jump. We have our own entropy source we use to seed the OpenSSL DRBG. This is a basic code snippet of how we set it up: >>> >>> DRBG_CTX *dctx = FIPS_get_default_drbg(); >>> FIPS_drbg_init(dctx, NID_aes_256_ctr, DRBG_FLAG_CTR_USE_DF); >>> FIPS_drbg_set_callbacks(dctx, >>> rand_get_entropy, >>> rand_free_entropy, >>> 0, >>> rand_get_entropy, >>> rand_free_entropy); >>> >>> >>> Error checking has been removed in the example for the sake of brevity. >>> >>> I am trying to figure out how to implement this with OpenSSL 3. From what I have read in the docs, I need to create a rand provider. But I still feel like I don?t understand how it all fit together. I did look at fuzz_rand.c and fake_rand.c, and if I understood everything correctly, neither of them use an external entropy/seed source. >>> >>> Are there better examples of what I am looking for? >>> >>> Thanks, >>> Kory >>> >> > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shivakumar.Poojari at rbbn.com Mon Sep 27 08:17:37 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Mon, 27 Sep 2021 08:17:37 +0000 Subject: [EXTERNAL] Re: Replacement for BIO_get_port(), BIO_get_host_ip() In-Reply-To: <0101017c1892502f-dd39cfad-1e85-4abb-b971-5d26102cad21-000000@us-west-2.amazonses.com> References: <0101017c1892502f-dd39cfad-1e85-4abb-b971-5d26102cad21-000000@us-west-2.amazonses.com> Message-ID: Hi jordan, I sent one mail previously with same subject around Thu 9/23/2021 5:50 PM(IST) But not received any respond back, usually I use to get response with in 12hr. Hi all Im not able to find any replacement for BIO_get_port(), BIO_get_host_ip() In stack overflow i seen some suggestion https://stackoverflow.com/questions/58282542/openssl-1-1-1d-gives-the-error-on-deprecatedin-1-1-0-in-bio-h [https://cdn.sstatic.net/Sites/stackoverflow/Img/apple-touch-icon at 2.png?v=73d79a89bded] python - OpenSSL 1.1.1d gives the error on DEPRECATEDIN_1_1_0 in bio.h - Stack Overflow I had used the earlier version OpenSSL 1.0.2s which ran perfectly as there was no such usage of DEPRECATEDIN_1_1_0 in bio.h while the new version 1.1.1d encloses the functions like BIO_get_port using stackoverflow.com For BIO_get_port() alternative getservbyname() For BIO_get_host_ip()alternative gethostbyname() But these alternative functions are used in BIO_get_port(), BIO_get_host_ip() itself in openssl version 1.0.1 Please suggest the alternative function, or some suggestions to move forward . Thanks, Shivakumar ________________________________ From: Jordan Brown Sent: Friday, September 24, 2021 9:40 PM To: Shivakumar Poojari Subject: [EXTERNAL] Re: Replacement for BIO_get_port(), BIO_get_host_ip() On 9/24/2021 5:53 AM, Shivakumar Poojari wrote: Gentle reminder. You sent a question at somewhere between 2300 and 0200 US time, depending on the time zone, and then you sent a reminder seven hours later, at between 0600 and 0900 US time? You might get a reply from somebody somewhere else in the world, but I think most of the people are in the US. There's a decent chance that prime contributors (in Pacific time, UTC-7) were asleep for that entire time. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 27 09:35:42 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Sep 2021 10:35:42 +0100 Subject: Replacement for BIO_get_port(), BIO_get_host_ip() In-Reply-To: References: Message-ID: On 24/09/2021 07:05, Shivakumar Poojari wrote: > Hi > BIO_get_port(), BIO_get_host_ip(),? were deprecated in OpenSSL 1.1.0. > Trying for replacement for OpenSSl 3.0 > > Gone through the below man page, but not found alternative function. > > https://www.openssl.org/docs/manmaster/man3/BIO_connect.html > > > please suggest, These functions are deprecated because they only support IPv4. Instead you can use BIO_lookup() (or possibly BIO_lookup_ex()) to lookup the given host/service (first and second parameters to BIO_lookup() respectively). Equivalent 3rd/4th/5th parameters to BIO_lookup() might be BIO_LOOKUP_CLIENT, AF_INET (for IPv4) and SOCK_STREAM (for TCP). This will return you an initialised BIO_ADDRINFO() object (which you will have to later free using BIO_ADDRINFO_free()). From the BIO_ADDRINFO object you can get a pointer to an underlying BIO_ADDR using BIO_ADDRINFO_address(addrinfo). Finally you can use BIO_ADDR_rawaddress() to get address info, or BIO_ADDR_rawport() to get port info: See: https://www.openssl.org/docs/man3.0/man3/BIO_lookup.html https://www.openssl.org/docs/man3.0/man3/BIO_ADDR_rawaddress.html Matt From matt at openssl.org Mon Sep 27 09:49:39 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Sep 2021 10:49:39 +0100 Subject: RSA provider use example In-Reply-To: References: <6e78f9db-ed86-65d4-f8ae-27f8adf75a49@openssl.org> <1e56b6fa-e5e7-b8e0-77e2-f390defa1cdf@openssl.org> Message-ID: On 24/09/2021 16:51, Antonio Santagiuliana wrote: > Thank you for your reply. > I'm still a bit confused though. > In /providers/implementations/asymcipher/rsa_enc.c I find function > rsa_decrypt() that calls RSA_private_decrypt(prsactx->rsa) > I haven't found other implementation of this RSA_private_decrypt() apart > from the one in crypto/RSA/rsa_crypt.c , where the RSA argument passed > is used to call this: > rsa->meth->rsa_priv_dec() > I can't find where this pointer to method was set up. I can't find it in > the init of the default provider's rsa_enc.c and if the app requesting > this default RSA can't use the set_method() because deprecated, how is > this rsa_priv_dec pointer set up?where is the set up of it? The default method for an RSA object is initialised in RSA_new() here: https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_lib.c#L93 The global default RSA method is initialised here: https://github.com/openssl/openssl/blob/8b6a7da304d4fdd0de38ddd6037d8a02491e3e4e/crypto/rsa/rsa_ossl.c#L52-L62 This includes the default pointer for the rsa_priv_dec() function. An app *can* request an alternative default through RSA_set_default_method(). It is deprecated not removed - so it is still supported. But this is not the way you are supposed to do things any more. Applications that don't use any deprecated functions will always end up in the default method if using the default provider. If you want a different RSA implementation then you should not use the default provider. Matt > Thank you > > > > On Fri, 24 Sep 2021, 15:02 Matt Caswell, > wrote: > > > > On 24/09/2021 14:49, Antonio Santagiuliana wrote: > > Hello , thank you all for the replies. Very useful. > > I have seen in Openssl/crypto/RSA/rsa_local.h the definition of > rsa_st > > has a pointer to RSA_METHOD and I can't see this filled in in any > of the > > examples' set up or initializations, where is it filled in for the > > default provider , for the RSA algorithm? > > I can see the methods pointers are used later down in the call chain > > from RSA_private_decrypt() in > > providers/implementation/asymciphers/rsa_enc but I can't find where > > these methods' pointers are set and I would like to understand how I > > could pass a different method pointer in the parameters for a > different > > mod_exp operation , for example, or how I could set it on a > completely > > new RSA implementation mimicking the one in the default provider but > > with different methods where I need them changed, minimizing the > > differences with the default provider's RSA. > > The default RSA_METHOD structure to use can be set via > RSA_set_default_method(): > > https://www.openssl.org/docs/man3.0/man3/RSA_set_default_method.html > > > You can construct such an RSA_METHOD using the functions described here: > > https://www.openssl.org/docs/man3.0/man3/RSA_meth_new.html > > > However all of the above is considered deprecated and legacy and may be > removed from a future version of OpenSSL. > > Instead you are supposed to implement such things in a new provider. > For > example see: > > https://www.openssl.org/docs/man3.0/man7/provider-base.html > > https://www.openssl.org/docs/man3.0/man7/provider.html > > https://www.openssl.org/docs/man3.0/man7/provider-signature.html > > https://www.openssl.org/docs/man3.0/man7/provider-keymgmt.html > > > > Matt > > > > Thank you > > > > > > On Fri, 24 Sep 2021, 12:22 Matt Caswell, > > >> wrote: > > > > > > > >? ? ?On 24/09/2021 12:17, Dr Paul Dale wrote: > >? ? ? > What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c > >? ? ? > 3.0 doesn't use the RSA structure in the non-deprecated > public API. > >? ? ? > > >? ? ? > You probably want the EVP_PKEY_fromdata call. > > > >? ? ?An example of building an RSA key from its constituent parts is > >? ? ?available on the EVP_PKEY_fromdata() man page: > > > > https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html > > > > ? > > > > >? ? ?Matt > > > > > >? ? ? > > >? ? ? > > >? ? ? > Pauli > >? ? ? > > >? ? ? > > >? ? ? > On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: > >? ? ? >> Hello > >? ? ? >> Is there any app or command in the current Openssl master > >? ? ?repository > >? ? ? >> that initialises and uses the new RSA provider? > >? ? ? >> I would like to see how the RSA* context parameter is > filled in and > >? ? ? >> used, but I can't find an example using the RSA provider. > >? ? ? >> > >? ? ? >> > >? ? ? >> Thank you > >? ? ? >> > >? ? ? > > > > From matt at openssl.org Mon Sep 27 10:10:35 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Sep 2021 11:10:35 +0100 Subject: query on PEM_write_bio_PKCS8PrivateKey In-Reply-To: References: Message-ID: <877a8561-f9a1-c778-24b0-1956c89d3a1b@openssl.org> On 25/09/2021 06:06, SIMON BABY wrote: > Hi Team, > I have a query. I see the below API is used to write the private?key in > encrypted PKCS#8 format. > / > / > / > PEM_write_bio_PKCS8PrivateKey()/?and /PEM_write_PKCS8PrivateKey()/?write > a private key in an EVP_PKEY?structure in PKCS#8 EncryptedPrivateKeyInfo > format using PKCS#5 v2.0 password based encryption algorithms. > > Do we have an API for converting the encrypted private key file to an > unencrypted private?key file in?PKCS#8 format? The end of the quoted paragraph says: "If I is NULL then no encryption is used and a PKCS#8 PrivateKeyInfo structure is used instead." So simply supply NULL for the cipher argument to those same functions and you will get an unencrypted private key in PKCS#8 format. Matt From mcr at sandelman.ca Mon Sep 27 14:33:03 2021 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 27 Sep 2021 10:33:03 -0400 Subject: OpenSSL SSL_CTX_set_default_verify_paths Slow In-Reply-To: References: Message-ID: <8134.1632753183@localhost> Jay Foster wrote: > While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to > 3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths() > function is much slower in 3.0.0.? In 1.0.0 it would take about 0.1 > seconds and in 3.0.0 it takes over 3 seconds. Based upon your straces, the time is spend in the OS. Are you running this on the same system? That's still very slow... I wonder if you have a failing disk. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jayf0ster at roadrunner.com Mon Sep 27 15:24:27 2021 From: jayf0ster at roadrunner.com (Jay Foster) Date: Mon, 27 Sep 2021 08:24:27 -0700 Subject: OpenSSL SSL_CTX_set_default_verify_paths Slow In-Reply-To: <8134.1632753183@localhost> References: <8134.1632753183@localhost> Message-ID: <8754c09e-ee3b-0bbe-c3b2-b9383a579eb0@roadrunner.com> On 9/27/21 7:33 AM, Michael Richardson wrote: > Jay Foster wrote: > > While migrating some applications from OpenSSL 1.0.2 (and 1.1.1) to > > 3.0.0, I have noticed that the SSL_CTX_set_default_verify_paths() > > function is much slower in 3.0.0.? In 1.0.0 it would take about 0.1 > > seconds and in 3.0.0 it takes over 3 seconds. > > Based upon your straces, the time is spend in the OS. > Are you running this on the same system? Exact same machine. > That's still very slow... I wonder if you have a failing disk. I don't think so.? The file system is a UBIFS on nand flash, and it works with 1.0.2 and 1.1.1.? Even 1.1.1 is a *little* bit slower than 1.0.2, but nowhere near as much slower as 3.0.0. It looks like the OpenSSL library is reading the cert.pem file in 4KB blocks at a time and doing some processing on the data read. It appears that this processing is what is taking longer. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > From tomas at openssl.org Mon Sep 27 15:32:22 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 27 Sep 2021 17:32:22 +0200 Subject: OpenSSL SSL_CTX_set_default_verify_paths Slow In-Reply-To: <8754c09e-ee3b-0bbe-c3b2-b9383a579eb0@roadrunner.com> References: <8134.1632753183@localhost> <8754c09e-ee3b-0bbe-c3b2-b9383a579eb0@roadrunner.com> Message-ID: On Mon, 2021-09-27 at 08:24 -0700, Jay Foster wrote: > On 9/27/21 7:33 AM, Michael Richardson wrote: > > Jay Foster wrote: > > ???? > While migrating some applications from OpenSSL 1.0.2 (and > > 1.1.1) to > > ???? > 3.0.0, I have noticed that the > > SSL_CTX_set_default_verify_paths() > > ???? > function is much slower in 3.0.0.? In 1.0.0 it would take > > about 0.1 > > ???? > seconds and in 3.0.0 it takes over 3 seconds. > > > > Based upon your straces, the time is spend in the OS. > > Are you running this on the same system? > Exact same machine. > > That's still very slow... I wonder if you have a failing disk. > > I don't think so.? The file system is a UBIFS on nand flash, and it > 1.0.2, but nowhere near as much slower as 3.0.0. > > blocks at a time and doing some processing on the data read. It > appears > that this processing is what is taking longer. Yes, unfortunately the decoding takes much longer on 3.0.0. I suppose there is some major optimization to be done in 3.1. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From openssl-users at dukhovni.org Mon Sep 27 15:31:33 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 27 Sep 2021 11:31:33 -0400 Subject: OpenSSL SSL_CTX_set_default_verify_paths Slow In-Reply-To: <8754c09e-ee3b-0bbe-c3b2-b9383a579eb0@roadrunner.com> References: <8134.1632753183@localhost> <8754c09e-ee3b-0bbe-c3b2-b9383a579eb0@roadrunner.com> Message-ID: > On 27 Sep 2021, at 11:24 am, Jay Foster wrote: > > I don't think so. The file system is a UBIFS on nand flash, and it works with 1.0.2 and 1.1.1. Even 1.1.1 is a *little* bit slower than 1.0.2, but nowhere near as much slower as 3.0.0. > > It looks like the OpenSSL library is reading the cert.pem file in 4KB blocks at a time and doing some processing on the data read. It appears that this processing is what is taking longer. OpenSSL 3.0.0 has a new OSSL_DECODER API, it may still need some performance tuning? For example, in Postfix + OpenSSL 3.0.0 I'm decoding the compiled-in DER DH group via: +static void load_builtin(void) +{ + EVP_PKEY *tmp = 0; + OSSL_DECODER_CTX *d; + const unsigned char *endp = builtin_der; + size_t dlen = sizeof(builtin_der); + + d = OSSL_DECODER_CTX_new_for_pkey(&tmp, "DER", NULL, "DH", + OSSL_KEYMGMT_SELECT_DOMAIN_PARAMETERS, + NULL, NULL); + /* Check decode succeeds and consumes all data (final dlen == 0) */ + if (d && OSSL_DECODER_from_data(d, &endp, &dlen) && tmp && !dlen) { + dhp = tmp; + } else { + EVP_PKEY_free(tmp); + msg_warn("error loading compiled-in DH parameters"); + tls_print_errors(); + } + OSSL_DECODER_CTX_free(d); +} IIRC the loading of certificates now uses this API. There was perhaps also some work on new X509_STORE infrastructure. Performance issues in the new code are not implausible, and I hope can be addressed in upcoming releases. -- Viktor. From kgoldman at us.ibm.com Mon Sep 27 19:15:27 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 27 Sep 2021 15:15:27 -0400 Subject: EVP_EncryptInit_ex2() operation Message-ID: Does it make sense to initialize the context once and then use it multiple times, or is cleaner to create a new one from the raw key byte string each time? I've seen sample code that uses this to 'reset' the context for a new encryption. EVP_EncryptInit_ex2(e, NULL, NULL, NULL, NULL); 1. Is this guaranteed? Documented? 2. Does the iv get reset as well? 3. Is the padding retained, or must I call EVP_CIPHER_CTX_set_padding() again? From dipto181 at gmail.com Mon Sep 27 23:06:14 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Mon, 27 Sep 2021 17:06:14 -0600 Subject: Why custom RSA engine is not calling default RSA method? Message-ID: Hello, I have the following simple RSA engine code from *e_dasync.c. * Following code compiles and works. Until now, I was under the impression that if I do not supply an alternative method in function *bind_dasync(), the *engine will use the default method. However, it doesn't seem to be the case. If I comment out line 37 and try to perform an encryption operation with the following command, *"openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out msg.enc -engine rsa-engine-new" * I get segmentation errors. Can anyone please tell me why this is happening? ============================================================================== 1. /* Engine Id and Name */ 2. static const char *engine_rsa_id = "rsa-engine-new"; 3. static const char *engine_rsa_name = "RSA engine for testing"; 4. 5. // data encryption function 6. static int eng_rsa_pub_enc(int flen, const unsigned char *from, 7. unsigned char *to, RSA *rsa, int padding) { 8. printf("Encryption\n"); 9. return 0; 10. } 11. 12. // signature verify 13. static int eng_rsa_pub_dec(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding){ 14. printf("Signature verify:\n"); 15. return 0; 16. } 17. 18. // signature 19. static int eng_rsa_priv_enc(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding){ 20. printf("Signature:\n"); 21. return 0; 22. } 23. 24. // data decryption 25. static int eng_rsa_priv_dec(int flen, const unsigned char *from, unsigned char *to, RSA *rsa, int padding){ 26. printf("Decryption\n"); 27. return 0; 28. } 29. 30. 31. static RSA_METHOD *test_rsa_method = NULL; 32. 33. 34. static int bind_dasync(ENGINE *e){ 35. /* Setup RSA_METHOD */ 36. if ((test_rsa_method = RSA_meth_new("Test RSA method", 0)) == NULL 37. // || RSA_meth_set_pub_enc(test_rsa_method, eng_rsa_pub_enc) == 0 38. || RSA_meth_set_pub_dec(test_rsa_method, eng_rsa_pub_dec) == 0 39. || RSA_meth_set_priv_enc(test_rsa_method, eng_rsa_priv_enc) == 0 40. || RSA_meth_set_priv_dec(test_rsa_method, eng_rsa_priv_dec) == 0 41. ) { 42. 43. return 0; 44. } 45. 46. /* Ensure the dasync error handling is set up */ 47. 48. if (!ENGINE_set_id(e, engine_rsa_id) 49. || !ENGINE_set_name(e, engine_rsa_name) 50. || !ENGINE_set_RSA(e, test_rsa_method) 51. ) { 52. return 0; 53. } 54. return 1; 55. } 56. 57. static int bind_helper(ENGINE *e, const char *id){ 58. if (!bind_dasync(e)){ 59. printf("2_Error: Inside Bind helper\n"); 60. return 0; 61. } 62. return 1; 63. } 64. 65. IMPLEMENT_DYNAMIC_BIND_FN(bind_helper) 66. IMPLEMENT_DYNAMIC_CHECK_FN() ============================================================================== Regards, Shariful Alam -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Tue Sep 28 07:12:26 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 28 Sep 2021 09:12:26 +0200 Subject: EVP_EncryptInit_ex2() operation In-Reply-To: References: Message-ID: <6f3be0a5f5c60c6ae951cacae994efd0be400da9.camel@openssl.org> On Mon, 2021-09-27 at 15:15 -0400, Ken Goldman wrote: > Does it make sense to initialize the context once and then use it > multiple times, or is cleaner to create a new one from the raw key > byte string each time? It is not necessary. The reinitialization is supported to avoid recreating key schedule if the key used is the same. > I've seen sample code that uses this to 'reset' the context for a new > encryption. > > ????????EVP_EncryptInit_ex2(e, NULL, NULL, NULL, NULL); > > 1. Is this guaranteed?? Documented? We do not change the behavior of existing operations and modes (or at least not intentionally). This call is even tested at least for some ciphers and modes. However the documentation of it is missing. > 2. Does the iv get reset as well? Only for some modes (namely CBC, CFB, OFB) due to history. > 3. Is the padding retained, or must I call > EVP_CIPHER_CTX_set_padding() again? It should be retained. It is initialized only when a new key is set. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From beldmit at gmail.com Tue Sep 28 07:40:46 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Tue, 28 Sep 2021 09:40:46 +0200 Subject: Why custom RSA engine is not calling default RSA method? In-Reply-To: References: Message-ID: Dear Shariful, Could you please also provide a stack trace of your segfault? On Tue, Sep 28, 2021 at 1:06 AM Shariful Alam wrote: > Hello, > I have the following simple RSA engine code from *e_dasync.c. * Following > code compiles and works. Until now, I was under the impression that if I do > not supply an alternative method in function *bind_dasync(), the *engine > will use the default method. However, it doesn't seem to be the case. If I > comment out line 37 and try to perform an encryption operation with the > following command, > > *"openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out > msg.enc -engine rsa-engine-new" * > > I get segmentation errors. > > Can anyone please tell me why this is happening? > > > ============================================================================== > > 1. /* Engine Id and Name */ > 2. static const char *engine_rsa_id = "rsa-engine-new"; > 3. static const char *engine_rsa_name = "RSA engine for testing"; > 4. > 5. // data encryption function > 6. static int eng_rsa_pub_enc(int flen, const unsigned char *from, > 7. unsigned char *to, RSA *rsa, int padding) > { > 8. printf("Encryption\n"); > 9. return 0; > 10. } > 11. > 12. // signature verify > 13. static int eng_rsa_pub_dec(int flen, const unsigned char *from, > unsigned char *to, RSA *rsa, int padding){ > 14. printf("Signature verify:\n"); > 15. return 0; > 16. } > 17. > 18. // signature > 19. static int eng_rsa_priv_enc(int flen, const unsigned char *from, > unsigned char *to, RSA *rsa, int padding){ > 20. printf("Signature:\n"); > 21. return 0; > 22. } > 23. > 24. // data decryption > 25. static int eng_rsa_priv_dec(int flen, const unsigned char *from, > unsigned char *to, RSA *rsa, int padding){ > 26. printf("Decryption\n"); > 27. return 0; > 28. } > 29. > 30. > 31. static RSA_METHOD *test_rsa_method = NULL; > 32. > 33. > 34. static int bind_dasync(ENGINE *e){ > 35. /* Setup RSA_METHOD */ > 36. if ((test_rsa_method = RSA_meth_new("Test RSA method", 0)) == > NULL > 37. // || RSA_meth_set_pub_enc(test_rsa_method, > eng_rsa_pub_enc) == 0 > 38. || RSA_meth_set_pub_dec(test_rsa_method, eng_rsa_pub_dec) > == 0 > 39. || RSA_meth_set_priv_enc(test_rsa_method, > eng_rsa_priv_enc) == 0 > 40. || RSA_meth_set_priv_dec(test_rsa_method, > eng_rsa_priv_dec) == 0 > 41. ) { > 42. > 43. return 0; > 44. } > 45. > 46. /* Ensure the dasync error handling is set up */ > 47. > 48. if (!ENGINE_set_id(e, engine_rsa_id) > 49. || !ENGINE_set_name(e, engine_rsa_name) > 50. || !ENGINE_set_RSA(e, test_rsa_method) > 51. ) { > 52. return 0; > 53. } > 54. return 1; > 55. } > 56. > 57. static int bind_helper(ENGINE *e, const char *id){ > 58. if (!bind_dasync(e)){ > 59. printf("2_Error: Inside Bind helper\n"); > 60. return 0; > 61. } > 62. return 1; > 63. } > 64. > 65. IMPLEMENT_DYNAMIC_BIND_FN(bind_helper) > 66. IMPLEMENT_DYNAMIC_CHECK_FN() > > > ============================================================================== > > Regards, > Shariful Alam > > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From dipto181 at gmail.com Tue Sep 28 15:45:52 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Tue, 28 Sep 2021 09:45:52 -0600 Subject: Why custom RSA engine is not calling default RSA method? In-Reply-To: References: Message-ID: Dear Dmitry, Thank you for your response. Here is the stack trace ============================================================================================================================= $ strace openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out msg.enc -engine rsa-engine-new execve("/usr/bin/openssl", ["openssl", "rsautl", "-encrypt", "-inkey", "public.pem", "-pubin", "-in", "msg.txt", "-out", "msg.enc", "-engine", "rsa-engine-new"], [/* 65 vars */]) = 0 brk(NULL) = 0x1634000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=103650, ...}) = 0 mmap(NULL, 103650, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3997ce3000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/opt/openssl_test/lib/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\327\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1713040, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3997ce2000 mmap(NULL, 2836448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3997823000 mprotect(0x7f39978cb000, 2097152, PROT_NONE) = 0 mmap(0x7f3997acb000, 53248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa8000) = 0x7f3997acb000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/opt/openssl_test/lib/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0p\7\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=6286208, ...}) = 0 mmap(NULL, 5508104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f39972e2000 mprotect(0x7f39975f3000, 2093056, PROT_NONE) = 0 mmap(0x7f39977f2000, 188416, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x310000) = 0x7f39977f2000 mmap(0x7f3997820000, 11272, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3997820000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260`\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=138696, ...}) = 0 mmap(NULL, 2212904, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f39970c5000 mprotect(0x7f39970dd000, 2093056, PROT_NONE) = 0 mmap(0x7f39972dc000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7f39972dc000 mmap(0x7f39972de000, 13352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f39972de000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\t\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1868984, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3997ce1000 mmap(NULL, 3971488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3996cfb000 mprotect(0x7f3996ebb000, 2097152, PROT_NONE) = 0 mmap(0x7f39970bb000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c0000) = 0x7f39970bb000 mmap(0x7f39970c1000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f39970c1000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\r\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=14608, ...}) = 0 mmap(NULL, 2109680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3996af7000 mprotect(0x7f3996afa000, 2093056, PROT_NONE) = 0 mmap(0x7f3996cf9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f3996cf9000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3997ce0000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3997cdf000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3997cde000 arch_prctl(ARCH_SET_FS, 0x7f3997cdf700) = 0 mprotect(0x7f39970bb000, 16384, PROT_READ) = 0 mprotect(0x7f3996cf9000, 4096, PROT_READ) = 0 mprotect(0x7f39972dc000, 4096, PROT_READ) = 0 mprotect(0x7f39977f2000, 176128, PROT_READ) = 0 mprotect(0x7f3997acb000, 32768, PROT_READ) = 0 mprotect(0x6ac000, 4096, PROT_READ) = 0 mprotect(0x7f3997cfd000, 4096, PROT_READ) = 0 munmap(0x7f3997ce3000, 103650) = 0 set_tid_address(0x7f3997cdf9d0) = 6006 set_robust_list(0x7f3997cdf9e0, 24) = 0 rt_sigaction(SIGRTMIN, {0x7f39970cab50, [], SA_RESTORER|SA_SIGINFO, 0x7f39970d6390}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7f39970cabe0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7f39970d6390}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 brk(NULL) = 0x1634000 brk(0x1655000) = 0x1655000 futex(0x7f39978213d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f39978213e4, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f39978213ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f3997821368, FUTEX_WAKE_PRIVATE, 2147483647) = 0 rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x7f3996d304c0}, {SIG_DFL, [], 0}, 8) = 0 futex(0x7f3997821530, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f3997821400, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f3997821408, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f399781f880, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f399781f940, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f399781f94c, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f39978213f4, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f3997821438, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f3997821440, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/opt/openssl_test/ssl/openssl.cnf", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=11162, ...}) = 0 read(3, "#\n# OpenSSL example configuratio"..., 4096) = 4096 read(3, "\n# MASK:XXXX a literal mask valu"..., 4096) = 4096 read(3, "ts=CA:FALSE\n\n# Here are some exa"..., 4096) = 2970 brk(0x1676000) = 0x1676000 read(3, "", 4096) = 0 close(3) = 0 futex(0x7f3997821410, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f3997ad7698, FUTEX_WAKE_PRIVATE, 2147483647) = 0 sysinfo({uptime=2961, loads=[30016, 30688, 27392], totalram=16689545216, freeram=12341272576, sharedram=140345344, bufferram=240164864, totalswap=1023406080, freeswap=1023406080, procs=922, totalhigh=0, freehigh=0, mem_unit=1}) = 0 futex(0x7f3997ad7778, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7f3996cfa0a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/opt/openssl_test/lib/engines-1.1/rsa-engine-new.so", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p0\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=143576, ...}) = 0 mmap(NULL, 2241392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f39968d3000 mprotect(0x7f39968ea000, 2093056, PROT_NONE) = 0 mmap(0x7f3996ae9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7f3996ae9000 mmap(0x7f3996aeb000, 45936, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3996aeb000 close(3) = 0 mprotect(0x7f3996ae9000, 4096, PROT_READ) = 0 write(2, "engine \"rsa-engine-new\" set.\n", 29engine "rsa-engine-new" set. ) = 29 open("public.pem", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0664, st_size=451, ...}) = 0 read(3, "-----BEGIN PUBLIC KEY-----\nMIIBI"..., 4096) = 451 brk(0x1674000) = 0x1674000 close(3) = 0 open("msg.txt", O_RDONLY) = 3 open("msg.enc", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 fstat(3, {st_mode=S_IFREG|0664, st_size=72, ...}) = 0 read(3, "Hi. This is a test message. Hope"..., 4096) = 72 read(3, "", 4096) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} --- +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped) ============================================================================================================================= I was trying using gdb to debug the error. I get to until RSA_public_encrypt(), then if I step in, I get the segmentation fault, ================================================================================================== bt #0 0x0000000000000000 in ?? () #1 0x00007ffff77dbfc0 in RSA_public_encrypt (flen=72, from=0x6d8860 "Hi. This is a test message. Hope to see some performace gain with this.\nme", to=0x6d8a70 "x\353;\367\377\177", rsa=0x6d8540, padding=1) at crypto/rsa/rsa_crpt.c:30 #2 0x00000000004479a7 in rsautl_main (argc=0, argv=0x7fffffffde10) at apps/rsautl.c:248 #3 0x00000000004379fa in do_cmd (prog=0x6d5930, argc=11, argv=0x7fffffffde10) at apps/openssl.c:564 #4 0x0000000000436e4d in main (argc=11, argv=0x7fffffffde10) at apps/openssl.c:183 ================================================================================================== To my understanding, instead of pointing to the default encryption function, it is pointing to 0x0000000000000000, thus causing the segmentation fault. Thanks, Shariful On Tue, Sep 28, 2021 at 1:40 AM Dmitry Belyavsky wrote: > Dear Shariful, > > Could you please also provide a stack trace of your segfault? > > On Tue, Sep 28, 2021 at 1:06 AM Shariful Alam wrote: > >> Hello, >> I have the following simple RSA engine code from *e_dasync.c. * Following >> code compiles and works. Until now, I was under the impression that if I do >> not supply an alternative method in function *bind_dasync(), the *engine >> will use the default method. However, it doesn't seem to be the case. If I >> comment out line 37 and try to perform an encryption operation with the >> following command, >> >> *"openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out >> msg.enc -engine rsa-engine-new" * >> >> I get segmentation errors. >> >> Can anyone please tell me why this is happening? >> >> >> ============================================================================== >> >> 1. /* Engine Id and Name */ >> 2. static const char *engine_rsa_id = "rsa-engine-new"; >> 3. static const char *engine_rsa_name = "RSA engine for testing"; >> 4. >> 5. // data encryption function >> 6. static int eng_rsa_pub_enc(int flen, const unsigned char *from, >> 7. unsigned char *to, RSA *rsa, int >> padding) { >> 8. printf("Encryption\n"); >> 9. return 0; >> 10. } >> 11. >> 12. // signature verify >> 13. static int eng_rsa_pub_dec(int flen, const unsigned char *from, >> unsigned char *to, RSA *rsa, int padding){ >> 14. printf("Signature verify:\n"); >> 15. return 0; >> 16. } >> 17. >> 18. // signature >> 19. static int eng_rsa_priv_enc(int flen, const unsigned char *from, >> unsigned char *to, RSA *rsa, int padding){ >> 20. printf("Signature:\n"); >> 21. return 0; >> 22. } >> 23. >> 24. // data decryption >> 25. static int eng_rsa_priv_dec(int flen, const unsigned char *from, >> unsigned char *to, RSA *rsa, int padding){ >> 26. printf("Decryption\n"); >> 27. return 0; >> 28. } >> 29. >> 30. >> 31. static RSA_METHOD *test_rsa_method = NULL; >> 32. >> 33. >> 34. static int bind_dasync(ENGINE *e){ >> 35. /* Setup RSA_METHOD */ >> 36. if ((test_rsa_method = RSA_meth_new("Test RSA method", 0)) == >> NULL >> 37. // || RSA_meth_set_pub_enc(test_rsa_method, >> eng_rsa_pub_enc) == 0 >> 38. || RSA_meth_set_pub_dec(test_rsa_method, eng_rsa_pub_dec) >> == 0 >> 39. || RSA_meth_set_priv_enc(test_rsa_method, >> eng_rsa_priv_enc) == 0 >> 40. || RSA_meth_set_priv_dec(test_rsa_method, >> eng_rsa_priv_dec) == 0 >> 41. ) { >> 42. >> 43. return 0; >> 44. } >> 45. >> 46. /* Ensure the dasync error handling is set up */ >> 47. >> 48. if (!ENGINE_set_id(e, engine_rsa_id) >> 49. || !ENGINE_set_name(e, engine_rsa_name) >> 50. || !ENGINE_set_RSA(e, test_rsa_method) >> 51. ) { >> 52. return 0; >> 53. } >> 54. return 1; >> 55. } >> 56. >> 57. static int bind_helper(ENGINE *e, const char *id){ >> 58. if (!bind_dasync(e)){ >> 59. printf("2_Error: Inside Bind helper\n"); >> 60. return 0; >> 61. } >> 62. return 1; >> 63. } >> 64. >> 65. IMPLEMENT_DYNAMIC_BIND_FN(bind_helper) >> 66. IMPLEMENT_DYNAMIC_CHECK_FN() >> >> >> ============================================================================== >> >> Regards, >> Shariful Alam >> >> > > -- > SY, Dmitry Belyavsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kory at avatarci.com Tue Sep 28 17:17:03 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Tue, 28 Sep 2021 10:17:03 -0700 Subject: FIPS_selftest_drbg_all() Message-ID: <632A23F2-D67E-4656-A642-BFC8FC7D32D5@avatarci.com> Hello, For our FIPS 140-2 POST KAT sequence, I use FIPS_selftest_drbg() and FIPS_selftest_drbg_all() from openssl-fips-2.0.5. I was wondering what would be the best way to perform the same functionality with OpenSSL 3.0.0. Thanks, Kory From kory at avatarci.com Wed Sep 29 00:07:27 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Tue, 28 Sep 2021 17:07:27 -0700 Subject: FIPS_selftest_drbg_all() In-Reply-To: <632A23F2-D67E-4656-A642-BFC8FC7D32D5@avatarci.com> References: <632A23F2-D67E-4656-A642-BFC8FC7D32D5@avatarci.com> Message-ID: <16895939-9174-4461-B07C-2880B47A3D5B@avatarci.com> Never mind the question about FIPS_selftest_drbg_all(). I saw what is being done in the openssl app. However, I am looking for something similar to FIPS_set_error_callbacks() as a general solution. ERR_errors_print_cb() looks like it immediately invoked the callback on previous errors? > On Sep 28, 2021, at 10:17 AM, Kory Hamzeh wrote: > > Hello, > > For our FIPS 140-2 POST KAT sequence, I use FIPS_selftest_drbg() and FIPS_selftest_drbg_all() from openssl-fips-2.0.5. I was wondering what would be the best way to perform the same functionality with OpenSSL 3.0.0. > > Thanks, > Kory > From beldmit at gmail.com Wed Sep 29 16:59:26 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 29 Sep 2021 18:59:26 +0200 Subject: Why custom RSA engine is not calling default RSA method? In-Reply-To: References: Message-ID: Dear Shariful, Yes. You have to provide all the RSA_METHO functions your app is going to use. On Tue, Sep 28, 2021 at 5:46 PM Shariful Alam wrote: > Dear Dmitry, > Thank you for your response. > > Here is the stack trace > > > I was trying using gdb to debug the error. I get to until > RSA_public_encrypt(), then if I step in, I get the segmentation fault, > > ================================================================================================== > bt > #0 0x0000000000000000 in ?? () > #1 0x00007ffff77dbfc0 in RSA_public_encrypt (flen=72, from=0x6d8860 "Hi. > This is a test message. Hope to see some performace gain with this.\nme", > to=0x6d8a70 "x\353;\367\377\177", rsa=0x6d8540, padding=1) at > crypto/rsa/rsa_crpt.c:30 > #2 0x00000000004479a7 in rsautl_main (argc=0, argv=0x7fffffffde10) at > apps/rsautl.c:248 > #3 0x00000000004379fa in do_cmd (prog=0x6d5930, argc=11, > argv=0x7fffffffde10) at apps/openssl.c:564 > #4 0x0000000000436e4d in main (argc=11, argv=0x7fffffffde10) at > apps/openssl.c:183 > > ================================================================================================== > > To my understanding, instead of pointing to the default encryption > function, it is pointing to 0x0000000000000000, thus causing the > segmentation fault. > > > Thanks, > Shariful > > > > On Tue, Sep 28, 2021 at 1:40 AM Dmitry Belyavsky > wrote: > >> Dear Shariful, >> >> Could you please also provide a stack trace of your segfault? >> >> On Tue, Sep 28, 2021 at 1:06 AM Shariful Alam wrote: >> >>> Hello, >>> I have the following simple RSA engine code from *e_dasync.c. * Following >>> code compiles and works. Until now, I was under the impression that if I do >>> not supply an alternative method in function *bind_dasync(), the *engine >>> will use the default method. However, it doesn't seem to be the case. If I >>> comment out line 37 and try to perform an encryption operation with the >>> following command, >>> >>> *"openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out >>> msg.enc -engine rsa-engine-new" * >>> >>> I get segmentation errors. >>> >>> Can anyone please tell me why this is happening? >>> >>> >>> ============================================================================== >>> >>> 1. /* Engine Id and Name */ >>> 2. static const char *engine_rsa_id = "rsa-engine-new"; >>> 3. static const char *engine_rsa_name = "RSA engine for testing"; >>> 4. >>> 5. // data encryption function >>> 6. static int eng_rsa_pub_enc(int flen, const unsigned char *from, >>> 7. unsigned char *to, RSA *rsa, int >>> padding) { >>> 8. printf("Encryption\n"); >>> 9. return 0; >>> 10. } >>> 11. >>> 12. // signature verify >>> 13. static int eng_rsa_pub_dec(int flen, const unsigned char *from, >>> unsigned char *to, RSA *rsa, int padding){ >>> 14. printf("Signature verify:\n"); >>> 15. return 0; >>> 16. } >>> 17. >>> 18. // signature >>> 19. static int eng_rsa_priv_enc(int flen, const unsigned char *from, >>> unsigned char *to, RSA *rsa, int padding){ >>> 20. printf("Signature:\n"); >>> 21. return 0; >>> 22. } >>> 23. >>> 24. // data decryption >>> 25. static int eng_rsa_priv_dec(int flen, const unsigned char *from, >>> unsigned char *to, RSA *rsa, int padding){ >>> 26. printf("Decryption\n"); >>> 27. return 0; >>> 28. } >>> 29. >>> 30. >>> 31. static RSA_METHOD *test_rsa_method = NULL; >>> 32. >>> 33. >>> 34. static int bind_dasync(ENGINE *e){ >>> 35. /* Setup RSA_METHOD */ >>> 36. if ((test_rsa_method = RSA_meth_new("Test RSA method", 0)) >>> == NULL >>> 37. // || RSA_meth_set_pub_enc(test_rsa_method, >>> eng_rsa_pub_enc) == 0 >>> 38. || RSA_meth_set_pub_dec(test_rsa_method, >>> eng_rsa_pub_dec) == 0 >>> 39. || RSA_meth_set_priv_enc(test_rsa_method, >>> eng_rsa_priv_enc) == 0 >>> 40. || RSA_meth_set_priv_dec(test_rsa_method, >>> eng_rsa_priv_dec) == 0 >>> 41. ) { >>> 42. >>> 43. return 0; >>> 44. } >>> 45. >>> 46. /* Ensure the dasync error handling is set up */ >>> 47. >>> 48. if (!ENGINE_set_id(e, engine_rsa_id) >>> 49. || !ENGINE_set_name(e, engine_rsa_name) >>> 50. || !ENGINE_set_RSA(e, test_rsa_method) >>> 51. ) { >>> 52. return 0; >>> 53. } >>> 54. return 1; >>> 55. } >>> 56. >>> 57. static int bind_helper(ENGINE *e, const char *id){ >>> 58. if (!bind_dasync(e)){ >>> 59. printf("2_Error: Inside Bind helper\n"); >>> 60. return 0; >>> 61. } >>> 62. return 1; >>> 63. } >>> 64. >>> 65. IMPLEMENT_DYNAMIC_BIND_FN(bind_helper) >>> 66. IMPLEMENT_DYNAMIC_CHECK_FN() >>> >>> >>> ============================================================================== >>> >>> Regards, >>> Shariful Alam >>> >>> >> >> -- >> SY, Dmitry Belyavsky >> > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.gotthard at centrum.cz Wed Sep 29 18:13:39 2021 From: petr.gotthard at centrum.cz (Petr Gotthard) Date: Wed, 29 Sep 2021 20:13:39 +0200 Subject: =?utf-8?q?tpm2=2Dopenssl=2C_a_TPM_2=2E0_provider_for_OpenSSL_3=2E0_released?= Message-ID: <20210929201339.162A8E3E@centrum.cz> Hello, I just released a first version of the tpm2-openssl provider. TPM is a hardware crypto-processor, which can generate, store, and use cryptographic keys. The tpm2-openssl is a provider for integration of TPM 2.0 to OpenSSL 3.0, which makes (some) functions of a TPM 2.0 chip accessible via the standard OpenSSL API (EVP) and command-line tools. See the README for more details: https://github.com/tpm2-software/tpm2-openssl I'd like to express my gratitude to the OpenSSL team, who helped me to find the right approach, fixed bugs and accepted pull requests that made this work possible. Thank you very much! ? Kind Regards, Petr ? From steffen at sdaoden.eu Wed Sep 29 20:30:29 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 29 Sep 2021 22:30:29 +0200 Subject: openssl(1) 3.0 crash Message-ID: <20210929203029.opnD9%steffen@sdaoden.eu> Hello. I first thought it was musl related but the AlpineLinux bug report turned out to be wrong, i can easily reproduce it anywhere, it is just that the according script only runs there: #?0|kent:$ export LD_LIBRARY_PATH=~/usr-kent-crux-linux-x86_64/opt/.ossl3/lib64/ #?0|kent:$ ~/usr-kent-crux-linux-x86_64/opt/.ossl3/bin/openssl bla Invalid command 'bla'; type "help" for a list. #?1|kent:$ ~/usr-kent-crux-linux-x86_64/opt/.ossl3/bin/openssl chacha20 Segmentation fault #?139|kent:$ Works with "enc -chacha20". --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From openssl-users at dukhovni.org Wed Sep 29 20:59:51 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Sep 2021 16:59:51 -0400 Subject: openssl(1) 3.0 crash In-Reply-To: <20210929203029.opnD9%steffen@sdaoden.eu> References: <20210929203029.opnD9%steffen@sdaoden.eu> Message-ID: On Wed, Sep 29, 2021 at 10:30:29PM +0200, Steffen Nurpmeso wrote: > I first thought it was musl related but the AlpineLinux bug report > turned out to be wrong, i can easily reproduce it anywhere, it is > just that the according script only runs there: > > #?0|kent:$ export LD_LIBRARY_PATH=~/usr-kent-crux-linux-x86_64/opt/.ossl3/lib64/ > #?0|kent:$ ~/usr-kent-crux-linux-x86_64/opt/.ossl3/bin/openssl bla > Invalid command 'bla'; type "help" for a list. > #?1|kent:$ ~/usr-kent-crux-linux-x86_64/opt/.ossl3/bin/openssl chacha20 > Segmentation fault > #?139|kent:$ You should open an issue on Github. The immediate cause is: 46 static void warn_deprecated(const FUNCTION *fp) 47 { 48 if (fp->deprecated_version != NULL) -> 49 BIO_printf(bio_err, "The command %s was deprecated in version %s.", 50 fp->name, fp->deprecated_version); ... but in the case of the "chacha20" command, fp->deprecated_version was not initialised: $10 = { type = FT_cipher name = 0x00007ffeefbff47a "chacha20" func = 0x0000000100021d30 (openssl`enc_main at enc.c:105) help = 0x00007ffeefbff1b0 deprecated_alternative = 0x00007ffeefbff0b0 "" deprecated_version = 0xef60232fcf210011 "" } and so printing the version of OpenSSL in which it was deprecated crashes. The caller is at fault: 392 static int do_cmd(LHASH_OF(FUNCTION) *prog, int argc, char *argv[]) 393 { 394 FUNCTION f, *fp; 395 396 if (argc <= 0 || argv[0] == NULL) 397 return 0; 398 f.name = argv[0]; 399 fp = lh_FUNCTION_retrieve(prog, &f); 400 if (fp == NULL) { 401 if (EVP_get_digestbyname(argv[0])) { 402 f.type = FT_md; 403 f.func = dgst_main; 404 fp = &f; 405 } else if (EVP_get_cipherbyname(argv[0])) { 406 f.type = FT_cipher; 407 f.func = enc_main; 408 fp = &f; 409 } 410 } 411 if (fp != NULL) { 412 if (fp->deprecated_alternative != NULL) 413 warn_deprecated(fp); 414 return fp->func(argc, argv); 415 } The code is missing "f.deprecated_alternative = NULL" between lines 409 and 410, or else after each of 403 and 407. -- Viktor. From openssl-users at dukhovni.org Wed Sep 29 21:14:45 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Sep 2021 17:14:45 -0400 Subject: openssl(1) 3.0 crash In-Reply-To: References: <20210929203029.opnD9%steffen@sdaoden.eu> Message-ID: On Wed, Sep 29, 2021 at 04:59:51PM -0400, Viktor Dukhovni wrote: > 400 if (fp == NULL) { > 401 if (EVP_get_digestbyname(argv[0])) { > 402 f.type = FT_md; > 403 f.func = dgst_main; > 404 fp = &f; > 405 } else if (EVP_get_cipherbyname(argv[0])) { > 406 f.type = FT_cipher; > 407 f.func = enc_main; > 408 fp = &f; > 409 } > 410 } > > The code is missing "f.deprecated_alternative = NULL" between lines > 409 and 410, or else after each of 403 and 407. A better fix, that emits the intended deprecation warning would be: --- a/apps/openssl.c +++ b/apps/openssl.c @@ -392,6 +392,7 @@ int help_main(int argc, char **argv) static int do_cmd(LHASH_OF(FUNCTION) *prog, int argc, char *argv[]) { FUNCTION f, *fp; + static char alt_buf[256]; if (argc <= 0 || argv[0] == NULL) return 0; @@ -401,12 +402,16 @@ static int do_cmd(LHASH_OF(FUNCTION) *prog, int argc, char *argv[]) if (EVP_get_digestbyname(argv[0])) { f.type = FT_md; f.func = dgst_main; + (void) BIO_snprintf(alt_buf, sizeof(alt_buf), "dgst -%s", argv[0]); fp = &f; } else if (EVP_get_cipherbyname(argv[0])) { f.type = FT_cipher; f.func = enc_main; + (void) BIO_snprintf(alt_buf, sizeof(alt_buf), "enc -%s", argv[0]); fp = &f; } + f.deprecated_alternative = alt_buf; + f.deprecated_version = "3.0.0"; } if (fp != NULL) { if (fp->deprecated_alternative != NULL) -- Viktor. From openssl-users at dukhovni.org Wed Sep 29 22:06:28 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Sep 2021 18:06:28 -0400 Subject: openssl(1) 3.0 crash In-Reply-To: References: <20210929203029.opnD9%steffen@sdaoden.eu> Message-ID: On Wed, Sep 29, 2021 at 05:14:45PM -0400, Viktor Dukhovni wrote: > A better fix, that emits the intended deprecation warning would be: > > --- a/apps/openssl.c > +++ b/apps/openssl.c > [...] Opened as pull request https://github.com/openssl/openssl/pull/16714 addressing issue: https://github.com/openssl/openssl/issues/16713 -- Viktor. From pauli at openssl.org Thu Sep 30 00:05:38 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Thu, 30 Sep 2021 10:05:38 +1000 Subject: tpm2-openssl, a TPM 2.0 provider for OpenSSL 3.0 released In-Reply-To: <20210929201339.162A8E3E@centrum.cz> References: <20210929201339.162A8E3E@centrum.cz> Message-ID: <0f35f12e-86a2-396f-b3a3-1b3eef383a45@openssl.org> Great work! Pauli On 30/9/21 4:13 am, Petr Gotthard wrote: > Hello, > > I just released a first version of the tpm2-openssl provider. > > TPM is a hardware crypto-processor, which can generate, store, and use cryptographic keys. The tpm2-openssl is a provider for integration of TPM 2.0 to OpenSSL 3.0, which makes (some) functions of a TPM 2.0 chip accessible via the standard OpenSSL API (EVP) and command-line tools. > > See the README for more details: https://github.com/tpm2-software/tpm2-openssl > > I'd like to express my gratitude to the OpenSSL team, who helped me to find the right approach, fixed bugs and accepted pull requests that made this work possible. Thank you very much! > > Kind Regards, > Petr > > From steffen at sdaoden.eu Thu Sep 30 12:48:39 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 30 Sep 2021 14:48:39 +0200 Subject: openssl(1) 3.0 crash In-Reply-To: References: <20210929203029.opnD9%steffen@sdaoden.eu> Message-ID: <20210930124839.RN2mc%steffen@sdaoden.eu> Viktor Dukhovni wrote in : |On Wed, Sep 29, 2021 at 10:30:29PM +0200, Steffen Nurpmeso wrote: ... |> #?1|kent:$ ~/usr-kent-crux-linux-x86_64/opt/.ossl3/bin/openssl chacha20 |> Segmentation fault Thanks for fixing this so fast. ... |You should open an issue on Github. The immediate cause is: ... I finally (re)created a github account to cause less burden the next trivial time. But i do not understand a jingle word of what you both talk about in the issues you referenced. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From openssl-users at dukhovni.org Thu Sep 30 13:58:50 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 30 Sep 2021 09:58:50 -0400 Subject: openssl(1) 3.0 crash In-Reply-To: <20210930124839.RN2mc%steffen@sdaoden.eu> References: <20210929203029.opnD9%steffen@sdaoden.eu> <20210930124839.RN2mc%steffen@sdaoden.eu> Message-ID: On Thu, Sep 30, 2021 at 02:48:39PM +0200, Steffen Nurpmeso wrote: > Thanks for fixing this so fast. > > ... > |You should open an issue on Github. The immediate cause is: > ... > > I finally (re)created a github account to cause less burden the next > trivial time. But i do not understand a jingle word of what you both > talk about in the issues you referenced. No worries, It appears that in posts upthread I misunderstood the intent of the new code in 3.0.0. The "openssl { | }" commands are not after all deprecated in 3.0.0, it was just that the pointer to their deprecation status was not initialised to NULL. So the fix is a one-liner to zero out the structure `f`, ensuring a NULL deprecation status. -- Viktor From openssl at linuxpowered.net Thu Sep 30 16:43:54 2021 From: openssl at linuxpowered.net (nate) Date: Thu, 30 Sep 2021 09:43:54 -0700 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration Message-ID: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> Hello there I support an app stack over here and a short time ago one of the devs contacted me saying that they were getting some SSL cert errors connecting to a server. Investigating things it turns out to be the Let's encrypt CA cert expiration that happened recently, that server is managed by someone else so they are trying to get them to fix it. While investigating I saw some strange behavioral differences between OpenSSL 1.0 and 1.1 specifically regarding checking of the CA cert. If I run this on OpenSSL 1.0.2g (Ubuntu 16.04) openssl s_client -connect bad_server_name:443 -servername bad_server_name (the server in question uses SNI) I get at the end a clear: Verify return code: 10 (certificate has expired) If I run on the same OpenSSL: openssl s_client -connect bad_server_name:443 -servername bad_server_name | openssl x509 -noout -dates I get these dates: notAfter=Sep 30 14:01:15 2021 GMT notBefore=Aug 31 17:59:09 2021 GMT notAfter=Nov 29 17:59:08 2021 GMT Which clearly shows the expired cert. If I try the same on OpenSSL 1.1.1f (Ubuntu 20.04), I get only the server cert not the CA cert dates: notBefore=Aug 31 17:59:09 2021 GMT notAfter=Nov 29 17:59:08 2021 GMT Also on the first command there is no error saying the cert is expired on OpenSSL 1.1.1f additional differences it seems 1.1.1f defaults to a verify depth of 2 and 1.0.2g goes at least to 3 (perhaps more). If I add -verify 3 to 1.1.1f to connect the first bit of output is: verify depth is 3 depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 (even if I set verify depth to 10 it doesn't report anything higher than the cert above) However on 1.0.2g I get this as the first bit of output: depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 verify error:num=10:certificate has expired Can someone point me to the syntax for 1.1.1f that would get it to verify the CA? Or is this a bug (maybe already fixed in a newer version not sure). I am unsure why Let's encrypt would allow any certs to be signed with a CA cert that was about to expire(especially given their low cert expiration times) but that's their issue. thanks nate From matt at openssl.org Thu Sep 30 16:50:40 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 30 Sep 2021 17:50:40 +0100 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> Message-ID: <978bb992-d861-2202-be82-23adfdfdb700@openssl.org> See: https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ Matt On 30/09/2021 17:43, nate wrote: > Hello there > > I support an app stack over here and a short time ago one of the devs > contacted me saying > that they were getting some SSL cert errors connecting to a server. > > Investigating things it turns out to be the Let's encrypt CA cert > expiration that > happened recently, that server is managed by someone else so they are > trying to > get them to fix it. > > While investigating I saw some strange behavioral differences between > OpenSSL 1.0 and > 1.1 specifically regarding checking of the CA cert. > > If I run this on OpenSSL 1.0.2g (Ubuntu 16.04) > > openssl s_client -connect bad_server_name:443 -servername bad_server_name > (the server in question uses SNI) > > I get at the end a clear: > Verify return code: 10 (certificate has expired) > > If I run on the same OpenSSL: > > openssl s_client -connect bad_server_name:443 -servername > bad_server_name | openssl x509 -noout -dates > > I get these dates: > notAfter=Sep 30 14:01:15 2021 GMT > notBefore=Aug 31 17:59:09 2021 GMT > notAfter=Nov 29 17:59:08 2021 GMT > > Which clearly shows the expired cert. > > If I try the same on OpenSSL 1.1.1f (Ubuntu 20.04), I get only the > server cert > not the CA cert dates: > notBefore=Aug 31 17:59:09 2021 GMT > notAfter=Nov 29 17:59:08 2021 GMT > > Also on the first command there is no error saying the cert is expired > on OpenSSL 1.1.1f > > additional differences it seems 1.1.1f defaults to a verify depth of 2 > and 1.0.2g goes at least > to 3 (perhaps more). > > If I add -verify 3 to 1.1.1f to connect the first bit of output is: > verify depth is 3 > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > (even if I set verify depth to 10 it doesn't report anything higher than > the cert above) > > However on 1.0.2g I get this as the first bit of output: > depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 > verify error:num=10:certificate has expired > > Can someone point me to the syntax for 1.1.1f that would get it to > verify the CA? Or is this > a bug (maybe already fixed in a newer version not sure). > > I am unsure why Let's encrypt would allow any certs to be signed with a > CA cert that > was about to expire(especially given their low cert expiration times) > but that's their > issue. > > thanks > > nate > From openssl at linuxpowered.net Thu Sep 30 17:12:28 2021 From: openssl at linuxpowered.net (nate) Date: Thu, 30 Sep 2021 10:12:28 -0700 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: <978bb992-d861-2202-be82-23adfdfdb700@openssl.org> References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> <978bb992-d861-2202-be82-23adfdfdb700@openssl.org> Message-ID: <4d5fa48d4037ee0bbfdec7b7f4733054@linuxpowered.net> On 2021-09-30 9:50, Matt Caswell wrote: > See: > > https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ ok thanks! That is interesting and explains some things. One more Q for you, this app uses a custom CA certs file (so doesn't rely on the OS trusted). Though it seems after further testing even when telling openssl s_client to look at a specific CA file it looks at it, and also looks at the OS stuff as well if there is a CA with the OS and not in the custom CA file (which has about 113 CAs in it). Not a big deal will all be fixed when they update the cert. thanks again nate From openssl at linuxpowered.net Thu Sep 30 17:15:04 2021 From: openssl at linuxpowered.net (nate) Date: Thu, 30 Sep 2021 10:15:04 -0700 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: <4d5fa48d4037ee0bbfdec7b7f4733054@linuxpowered.net> References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> <978bb992-d861-2202-be82-23adfdfdb700@openssl.org> <4d5fa48d4037ee0bbfdec7b7f4733054@linuxpowered.net> Message-ID: <997bbc9b58c346ad7d3dd5bd1c443172@linuxpowered.net> On 2021-09-30 10:12, nate wrote: > That is interesting and explains some things. One more Q for you, this > app Oops sorry no more Qs, I was going to write one then I realized that OpenSSL appends the OS certs on top of the custom CA cert file which I wasn't expecting, updated my email forgot to remove that bit. nate From openssl-users at dukhovni.org Thu Sep 30 17:51:44 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 30 Sep 2021 13:51:44 -0400 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> Message-ID: On Thu, Sep 30, 2021 at 09:43:54AM -0700, nate wrote: > If I run this on OpenSSL 1.0.2g (Ubuntu 16.04) > > openssl s_client -connect bad_server_name:443 -servername bad_server_name > > I get at the end a clear: Verify return code: 10 (certificate has expired) This is because OpenSSL 1.0.2 looks at the peer's certificate chain before looking in the trust store. > If I run on the same OpenSSL: > > openssl s_client -connect bad_server_name:443 -servername bad_server_name | openssl x509 -noout -dates This is *not* the correct way to see all the expiration dates in the chain. It will show only the leaf certificate dates. The right incantation is: $ openssl s_client -connect bad_server_name:443 -servername bad_server_name | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout -text | egrep 'not(Before|After)' > If I try the same on OpenSSL 1.1.1f (Ubuntu 20.04), I get only the > server cert > not the CA cert dates: > notBefore=Aug 31 17:59:09 2021 GMT > notAfter=Nov 29 17:59:08 2021 GMT Expected behaviour, you've only asked for the EE cert details. > Also on the first command there is no error saying the cert is expired > on OpenSSL 1.1.1f OpenSSL 1.1.1 looks for issuer certificates first in the trust store and only then in the peer chain. > additional differences it seems 1.1.1f defaults to a verify depth of 2 > and 1.0.2g goes at least > to 3 (perhaps more). Expected, because it finds the ISRG root in the trust store, and so ignores the cross-cert in the peer's chain. Another potential issue (not in this case) is that the Let's Encrypt R3 intermediate issuing CA certificate (same subject DN and public key) is available in two different forms: * One issued by ISRG, still valid * Another issued by DST, expired yesterday. Correctly configured systems that use the Let's Encrypt "full_chain.pem" file are using the ISRG version, and should not have any issues, provided the client system is using OpenSSL 1.1.1 and has the ISRG root CA Servers that update only the Let's encrypt "cert.pem" file and provide the rest of the chain independently, or somehow otherwise manage to be stuck with the DST-signed "R3" now have certificate chains that will fail to validate. -- Viktor. From openssl at linuxpowered.net Thu Sep 30 18:26:14 2021 From: openssl at linuxpowered.net (nate) Date: Thu, 30 Sep 2021 11:26:14 -0700 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> Message-ID: On 2021-09-30 10:51, Viktor Dukhovni wrote: >> I get at the end a clear: Verify return code: 10 (certificate has >> expired) > > This is because OpenSSL 1.0.2 looks at the peer's certificate chain > before looking in the trust store. Ok, good to know, thanks! > >> If I run on the same OpenSSL: >> >> openssl s_client -connect bad_server_name:443 -servername >> bad_server_name | openssl x509 -noout -dates > > This is *not* the correct way to see all the expiration dates in the > chain. It will show only the leaf certificate dates. The right > incantation is: > > $ openssl s_client -connect bad_server_name:443 -servername > bad_server_name | > openssl crl2pkcs7 -nocrl -certfile /dev/stdin | > openssl pkcs7 -print_certs -noout -text | > egrep 'not(Before|After)' At least in this case the command you supplied appears to provide less information: (OpenSSL 1.0.2g) depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 verify error:num=10:certificate has expired notAfter=Sep 30 14:01:15 2021 GMT (OpenSSL 1.0.2g with -trusted_first option) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = bad_server_name verify return:1 (OpenSSL 1.1.1f) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = bad_server_name verify return:1 than the one I did(which I found with a web search earlier today), though that is an edge case for sure since it is only showing the CA that is expired. Tried it on other sites and it doesn't show the CA info. Is there a command sequence that could get openssl to show all dates in the tree whether it is being served by the server or checked in the local trusted store? I assume your command is intended to do that, but it doesn't for me. > Correctly configured systems that use the Let's Encrypt > "full_chain.pem" > file are using the ISRG version, and should not have any issues, > provided the client system is using OpenSSL 1.1.1 and has the ISRG root > CA yes I got that from a link another person posted, thanks! Though I realized that this app stack uses an embedded openssl 1.0.2u which isn't possible to upgrade at this time so the easiest solution is to fix the cert on the remote end, it's a very small site so not concerned about compatibility with super old clients. Been blocked on upgrading the OS on these app servers for 4+ months now, not that upgrading Ubuntu would help since the app uses it's own openssl anyway. Doing a major openssl change on the app itself would probably be a big change that would be done by staff that aren't at the org anymore. So not expecting that to happen anytime soon. The app openssl is only used for outbound connections, all inbound ssl is handled on external load balancers. thanks nate From openssl-users at dukhovni.org Thu Sep 30 18:36:05 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 30 Sep 2021 14:36:05 -0400 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> Message-ID: On Thu, Sep 30, 2021 at 11:26:14AM -0700, nate wrote: > > This is *not* the correct way to see all the expiration dates in the > > chain. It will show only the leaf certificate dates. The right > > incantation is: > > > > $ openssl s_client -connect bad_server_name:443 -servername bad_server_name | > > openssl crl2pkcs7 -nocrl -certfile /dev/stdin | > > openssl pkcs7 -print_certs -noout -text | > > egrep 'not(Before|After)' > > At least in this case the command you supplied appears to provide less > information: > > (OpenSSL 1.0.2g) > depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3 > verify error:num=10:certificate has expired > notAfter=Sep 30 14:01:15 2021 GMT Ah, you also need to add "-showcerts" to s_client and best to separate stdout and stderr in order to avoid confusion due to error text leaking through, sender stderr to /dev/null: $ openssl s_client -showcerts \ -connect bad_server_name:443 \ -servername bad_server_name 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout -text | egrep 'not(Before|After)' or write the errors to a separate file. > (OpenSSL 1.0.2g with -trusted_first option) > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = bad_server_name > verify return:1 Good. > (OpenSSL 1.1.1f) > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = bad_server_name > verify return:1 Ditto. > Is there a command sequence that could get openssl to show all dates in > the tree whether it is being served by the server or checked in the > local trusted store? The "crl2pkcs7 -nocrl -certfile /dev/stdin" command piped to "pkcs7 -print_certs -text" is how to see the full chain. > I assume your command is intended to do that, but > it doesn't for me. I neglected to suggest "-showcerts". -- Viktor. From openssl at linuxpowered.net Thu Sep 30 19:34:32 2021 From: openssl at linuxpowered.net (nate) Date: Thu, 30 Sep 2021 12:34:32 -0700 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> Message-ID: <8ce0768aafdf6d76358dd37f5582c303@linuxpowered.net> On 2021-09-30 11:36, Viktor Dukhovni wrote: > Ah, you also need to add "-showcerts" to s_client and best to separate > stdout and stderr in order to avoid confusion due to error text leaking > through, sender stderr to /dev/null: > > $ openssl s_client -showcerts \ > -connect bad_server_name:443 \ > -servername bad_server_name 2>/dev/null | > openssl crl2pkcs7 -nocrl -certfile /dev/stdin | > openssl pkcs7 -print_certs -noout -text | > egrep 'not(Before|After)' > > or write the errors to a separate file. That almost worked.. but because the first openssl command never completes the other commands just wait.. I poked around and found that sending Q to the command gets it to exit so I came up with this: echo "Q" | openssl s_client -showcerts -connect yehat.aphroland.org:443 \ -servername yehat.aphroland.org 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout -text | grep "\(Issuer:\|Subject:\|Not Before:\|Not After :\)" which does the trick for me, used one of my personal servers to test thanks for the help! nate From openssl-users at dukhovni.org Thu Sep 30 19:55:03 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 30 Sep 2021 15:55:03 -0400 Subject: openssl 1.0 vs 1.1 s_client verify CA cert expiration In-Reply-To: <8ce0768aafdf6d76358dd37f5582c303@linuxpowered.net> References: <384d1543b527b8cd614f22dcfc497cc1@linuxpowered.net> <8ce0768aafdf6d76358dd37f5582c303@linuxpowered.net> Message-ID: > On 30 Sep 2021, at 3:34 pm, nate wrote: > >> $ openssl s_client -showcerts \ >> -connect bad_server_name:443 \ >> -servername bad_server_name 2>/dev/null | >> openssl crl2pkcs7 -nocrl -certfile /dev/stdin | >> openssl pkcs7 -print_certs -noout -text | >> egrep 'not(Before|After)' >> or write the errors to a separate file. > > > That almost worked.. but because the first openssl command > never completes the other commands just wait.. > > I poked around and found that sending Q to the command gets it > to exit so I came up with this: > > echo "Q" | [...] True, I forgot that I usually write: $ sleep 2 | openssl s_client ... which generally gives s_client enough time to complete the handshake, and then it exits when it sees EOF on stdin. The "Q" is perhaps cleaner. -- Viktor. From steffen at sdaoden.eu Thu Sep 30 21:06:33 2021 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 30 Sep 2021 23:06:33 +0200 Subject: openssl(1) 3.0 crash In-Reply-To: References: <20210929203029.opnD9%steffen@sdaoden.eu> <20210930124839.RN2mc%steffen@sdaoden.eu> Message-ID: <20210930210633.zdIFn%steffen@sdaoden.eu> Viktor Dukhovni wrote in : |On Thu, Sep 30, 2021 at 02:48:39PM +0200, Steffen Nurpmeso wrote: |> Thanks for fixing this so fast. |> ... |>|You should open an issue on Github. The immediate cause is: |> ... |> |> I finally (re)created a github account to cause less burden the next |> trivial time. But i do not understand a jingle word of what you both |> talk about in the issues you referenced. | |No worries, It appears that in posts upthread I misunderstood the |intent of the new code in 3.0.0. The "openssl { | }" |commands are not after all deprecated in 3.0.0, it was just that the |pointer to their deprecation status was not initialised to NULL. | |So the fix is a one-liner to zero out the structure `f`, ensuring |a NULL deprecation status. Thank you, yes. My very problem was related to the github related speech both of you talk :) But: it nonetheless happens often enough since i am not so deep in TLS and also SMTP as you are. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)