From chintuhema at gmail.com Wed Feb 1 04:38:51 2017 From: chintuhema at gmail.com (Hema Murthy) Date: Wed, 1 Feb 2017 10:08:51 +0530 Subject: [openssl-users] Openssl 1.0.2k compilation issues In-Reply-To: References: Message-ID: Hi, Am trying to upgrade openssl 1.0.1p to 1.0.2k and the compilation breaks with the below error and am using Ubuntu 10.04.1 In file included from req.c:84: comp.h:28: error: redefinition of typedef 'COMP_METHOD' ../../Build/target/usr/include/openssl/ossl_typ.h:181: error: previous declaration of 'COMP_METHOD' was here Am very new to this work and will be of great help if you can give me pointers in resolving the above issue. Awaiting for reply. Thanks in advance, Hema -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Feb 1 14:09:39 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 1 Feb 2017 14:09:39 +0000 Subject: [openssl-users] Openssl 1.0.2k compilation issues In-Reply-To: References: Message-ID: >Am trying to upgrade openssl 1.0.1p to 1.0.2k and the compilation breaks with the below error and am using Ubuntu 10.04.1 >In file included from req.c:84: >comp.h:28: error: redefinition of typedef 'COMP_METHOD' >../../Build/target/usr/include/openssl/ossl_typ.h:181: error: previous declaration of 'COMP_METHOD' was here Something is strange. Scrub your build area and restart. ; sed -n -e25,30p crypto/comp/comp.h int (*expand) (COMP_CTX *ctx, unsigned char *out, unsigned int olen, unsigned char *in, unsigned int ilen); /* * The following two do NOTHING, but are kept for backward compatibility */ ; sed -n -e181p crypto/ossl_typ.h typedef struct comp_method_st COMP_METHOD; ; From devang.kubavat at in.abb.com Wed Feb 1 11:26:30 2017 From: devang.kubavat at in.abb.com (Devang Kubavat) Date: Wed, 1 Feb 2017 11:26:30 +0000 Subject: [openssl-users] SSL_CTX_set_timeout does not work properly Message-ID: Hi, I am using Ticket based Session Resumption in my application. I need to control 'timeout of the session'. So as per the document I can set the timeout of the session using SSL_CTX_set_timeout(SSL_CTX *ctx, long t); I used SSL_CTX_set_timeout(ctx, 500); I am able to resume the session up to 500 seconds and after 500 seconds, the session fails to resume which is as expected. But when I set t=0 in SSL_CTX_set_timeout(ctx,0), I am getting different behavior. Session is resumed up to 7200 seconds. Wireshark log shows Ticket Lifetime Hint: 7200 seconds. According to me the session should not resume. Can anyone please help me why it is behaving like this. Best Regards, Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Feb 1 22:11:31 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Feb 2017 22:11:31 +0000 Subject: [openssl-users] SSL_CTX_set_timeout does not work properly In-Reply-To: References: Message-ID: <20170201221130.GJ28349@mournblade.imrryr.org> On Wed, Feb 01, 2017 at 11:26:30AM +0000, Devang Kubavat wrote: > But when I set t=0 in SSL_CTX_set_timeout(ctx,0), I am getting different behavior. > Session is resumed up to 7200 seconds. Wireshark log shows Ticket Lifetime Hint: 7200 seconds. Instead of setting a zero-timeout, just disable session resumption: SSL_CTX_set_options(ctx, SSL_OP_NO_TICKET); SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); -- Viktor. From rsalz at akamai.com Thu Feb 2 18:31:10 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 2 Feb 2017 18:31:10 +0000 Subject: [openssl-users] Heads up -- RT tickets moving to GH issues Message-ID: <549831b2648e466fb66be830fc39a802@usma1ex-dag1mb3.msg.corp.akamai.com> Just to let you know, we found a tool to migrate RT to GitHub issues and will be doing that shortly. This will just about double the number of open issues we have and, unfortunately, push the existing (active ones) down a few pages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.chris.clark at gmail.com Fri Feb 3 18:55:44 2017 From: a.chris.clark at gmail.com (Chris Clark) Date: Fri, 3 Feb 2017 10:55:44 -0800 Subject: [openssl-users] How to detect AES-NI compatible CPU Message-ID: My application links to OpenSSL 1.1.0 dynamically, and I would like to be able to determine if the CPU supports the AES-NI instruction set. Is there an OpenSSL API that can do this? -Chris From rsalz at akamai.com Fri Feb 3 19:01:03 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Feb 2017 19:01:03 +0000 Subject: [openssl-users] How to detect AES-NI compatible CPU In-Reply-To: References: Message-ID: <8424feae21b041f89667b995cb943589@usma1ex-dag1mb3.msg.corp.akamai.com> > My application links to OpenSSL 1.1.0 dynamically, and I would like to be able > to determine if the CPU supports the AES-NI instruction set. > Is there an OpenSSL API that can do this? Look at man3/OPENSSL_ia32cap.pod ? From openssl-users at dukhovni.org Fri Feb 3 19:17:16 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 3 Feb 2017 14:17:16 -0500 Subject: [openssl-users] How to detect AES-NI compatible CPU In-Reply-To: <8424feae21b041f89667b995cb943589@usma1ex-dag1mb3.msg.corp.akamai.com> References: <8424feae21b041f89667b995cb943589@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: > On Feb 3, 2017, at 2:01 PM, Salz, Rich via openssl-users wrote: > > Look at man3/OPENSSL_ia32cap.pod ? Perhaps more convenient: https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_ia32cap.html Note, there is no public C-API to access the underlying vector. -- Viktor. From noloader at gmail.com Fri Feb 3 19:29:08 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 3 Feb 2017 14:29:08 -0500 Subject: [openssl-users] How to detect AES-NI compatible CPU In-Reply-To: References: Message-ID: On Fri, Feb 3, 2017 at 1:55 PM, Chris Clark wrote: > My application links to OpenSSL 1.1.0 dynamically, and I would like to > be able to determine if the CPU supports the AES-NI instruction set. > Is there an OpenSSL API that can do this? Also note that even though the machine is capable of AES-NI, it does not mean OpenSSL will use the hardware acceleration. If you call AES_encrypt (and friends), then you get the "software-only" implementation. If you disable the feature in the environment with OPENSSL_ia32cap="~0x200000200000000", then you get the "software-only" implementation To use AES-NI, and other hardware accelerators like ARMv8's instructions, you have to use the EVP interface. Jeff From brandon.shiers at wyoming.com Fri Feb 3 17:37:12 2017 From: brandon.shiers at wyoming.com (Brandon Shiers) Date: Fri, 3 Feb 2017 09:37:12 -0800 Subject: [openssl-users] Issue on Windows Server 2003 Resigning Expired CA certificate Message-ID: <20170203093712.262F9ED@m0087797.ppops.net> An HTML attachment was scrubbed... URL: From noloader at gmail.com Fri Feb 3 21:10:54 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 3 Feb 2017 16:10:54 -0500 Subject: [openssl-users] Issue on Windows Server 2003 Resigning Expired CA certificate In-Reply-To: <20170203093712.262F9ED@m0087797.ppops.net> References: <20170203093712.262F9ED@m0087797.ppops.net> Message-ID: On Fri, Feb 3, 2017 at 12:37 PM, Brandon Shiers wrote: > I have a client that has a CA certificate that has expired. > > They are running Windows Server 2003 and OpenSSL 0.9.8d and FreeRadius for > authentiaction. Their certificate expired yesterday afternoon and I've been > trying to get it resigned but I'm getting the following eerrors: > > E:\OpenSSL\bin\PEM\demoCA\private>e:\openssl\bin\openssl verify > e:\openssl\bin\c > acert.pem > Error opening certificate file e:\openssl\bin\cacert.pem > 3964:error:02001002:system library:fopen:No such file or > directory:.\crypto\bio\ > bss_file.c:352:fopen('e:\openssl\bin\cacert.pem','rb') > 3964:error:20074002:BIO routines:FILE_CTRL:system > lib:.\crypto\bio\bss_file.c:35 > 4: > unable to load certificate Check the OpenSSL conf file first: http://stackoverflow.com/q/16658038. You might find the the error is due to the openssl.cfg file, and not the cacert.pem file. Jeff From tkirby at hotlink.com Sat Feb 4 04:56:12 2017 From: tkirby at hotlink.com (Tim Kirby) Date: Fri, 3 Feb 2017 20:56:12 -0800 Subject: [openssl-users] Interoperating with a legacy client. Message-ID: I'm writing a server to support a legacy client that uses OpenSSL to secure its communication. The client is using OpenSSL 1.0.1j, and I have no control over that. I'm using the 1.0.1 version of OpenSSL supplied with my OS for the server side, but that is out of convenience rather than necessity. My server appears to be working at least semi-correctly, but I have a problem with established connections being terminated by the server side, and I have run out of troubleshooting ideas. The client will happily connect to my server, we complete the handshake, and start exchanging encrypted application data. Then, it seems like the client wants to renegotiate, because it sends the server a ClientHello across the established connection. But something is clearly not right, because the server responds with a fatal alert and terminates the connection. I can watch the connection with wireshark, so I can see in detail what's going on, but the client's behavior doesn't make sense to me. The typical interaction looks like this: The client connects to the server. The initial ClientHello advertises TLS 1.2 with a record version of 1.0, and includes TLS_EMPTY_RENEGOTIATION_INFO_SCSV in the cipher suites. Our ServerHello response includes a zero-length renegotiation_info extension. This all seems reasonable. The negotiation settles on TLS 1.2, and subsequent application data records are sent at that version. At this point, everything seems fine. After sending some amount of application data, the client then seems to want to renegotiate. It sends another ClientHello. At this point, things have gone wrong. The second ClientHello looks very, very similar to the one sent in the initial handshake. The record version is again 1.0, the TLS_EMPTY_RENEGOTIATION_INFO_SCSV is included in the cipher suites, and there's no renegotiation_info extension present. So, if the connection is using TLS 1.2, the server terminates the connection with a version mismatch alert when it sees the second ClientHello. If I force the server to use TLS 1.0, then the server terminates the connection because of the SCSV present in the ClientHello during renegotiation. I'm at a loss. It seems like the client is misbehaving, if the second ClientHello it sends is supposed to be a renegotiation attempt. But misbehaving or not, I still need to interoperate with this client. Is there something I can do on the server side to be compatible with this client? Is it possible that I'm causing the client's behavior through something I'm doing as the server? I may be able to provide a sanitized packet trace or packet dissections showing the exact behavior I'm seeing, if that would be helpful or interesting. Any further troubleshooting options would be welcome. -- Tim Kirby From rjkmurray40 at gmail.com Sat Feb 4 07:38:52 2017 From: rjkmurray40 at gmail.com (Ryan Murray) Date: Sat, 4 Feb 2017 04:08:52 -0330 Subject: [openssl-users] Interoperating with a legacy client. In-Reply-To: References: Message-ID: I made writing to you to ask the team to dispatch some much more then needed assets for hardware upgrades. I have created a way bill under hacker one or support at hackerone.com and desperately need this as soon as possible rather then the back burner. Much more breaking news and head when I get out of the stone age. Thanks KS for passing message along Best regards Sincerely, Ryan Murray On Feb 4, 2017 1:36 AM, "Tim Kirby" wrote: > > I'm writing a server to support a legacy client that uses OpenSSL to > secure its communication. The client is using OpenSSL 1.0.1j, and I > have no control over that. I'm using the 1.0.1 version of OpenSSL > supplied with my > OS for the server side, but that is out of convenience rather than > necessity. > > My server appears to be working at least semi-correctly, but I have a > problem with established > connections being terminated by the server side, and I have run out of > troubleshooting ideas. > > The client will happily connect to my server, we complete the handshake, > and start exchanging > encrypted application data. Then, it seems like the client wants to > renegotiate, because it sends the > server a ClientHello across the established connection. But something is > clearly not right, because > the server responds with a fatal alert and terminates the connection. > > I can watch the connection with wireshark, so I can see in detail what's > going on, but the client's > behavior doesn't make sense to me. > > The typical interaction looks like this: > > The client connects to the server. > > The initial ClientHello advertises TLS 1.2 with a record version of 1.0, > and includes TLS_EMPTY_RENEGOTIATION_INFO_SCSV > in the cipher suites. Our ServerHello response includes a zero-length > renegotiation_info extension. This all seems reasonable. > > The negotiation settles on TLS 1.2, and subsequent application data > records are sent at that version. At this point, everything > seems fine. > > After sending some amount of application data, the client then seems to > want to renegotiate. It sends another ClientHello. > > At this point, things have gone wrong. The second ClientHello looks very, > very similar to the one sent in the initial handshake. > The record version is again 1.0, the TLS_EMPTY_RENEGOTIATION_INFO_SCSV is > included in the cipher suites, and there's no > renegotiation_info extension present. > > So, if the connection is using TLS 1.2, the server terminates the > connection with a > version mismatch alert when it sees the second ClientHello. > > If I force the server to use TLS 1.0, then the server terminates the > connection because > of the SCSV present in the ClientHello during renegotiation. > > I'm at a loss. It seems like the client is misbehaving, if the second > ClientHello it sends is supposed to be > a renegotiation attempt. But misbehaving or not, I still need to > interoperate with this client. > > Is there something I can do on the server side to be compatible with this > client? Is it possible that I'm > causing the client's behavior through something I'm doing as the server? > > I may be able to provide a sanitized packet trace or packet dissections > showing the exact behavior I'm seeing, if that would be > helpful or interesting. > > Any further troubleshooting options would be welcome. > > -- > Tim Kirby > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumanpaul1987 at gmail.com Sat Feb 4 22:23:27 2017 From: sumanpaul1987 at gmail.com (Suman Paul) Date: Sat, 4 Feb 2017 14:23:27 -0800 Subject: [openssl-users] DTLS Server with support for both EC and RSA keys References: Message-ID: Hi, I have a server that implements DTLS using OpenSSL 1.0.1 but supports only RSA keys as of today. I want to add support to this server to accept EC keys to be able to implement the newer ECDHE-ECDSA cipher suites while retaining support for RSA. Any pointers as to how to go about this? What I believe is that each kind of key would need a different SSL_CTX object. So I want to switch to the correct context for the SSL session as per the cipher supported by the client (maybe from the cipher list advertised in the ClientHello). Is that the best way of implementing this? Thanks Suman From rschm2 at unh.newhaven.edu Sat Feb 4 22:00:11 2017 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Sat, 4 Feb 2017 22:00:11 +0000 Subject: [openssl-users] Inserting cipher into speed.c Message-ID: Hello, Thanks to everyones help here I was able to insert a new cipher into OpenSSL. However, for performance reasons I'd like to begin testing the speed of my cipher and compare to other already implemented ciphers. I went ahead and started editing the ./apps/speed.c file to insert the new cipher but ran into some strange output.... (See below). Here's what I've edited so far in speed.c: 1) Included header of my cipher 2) Updated ALGOR_NUM from 30 to 31 (~line 134) 3) Inserted a static declaration for the loop (~line 200) just like AES's 4) Updated the list of possible ciphers to chose (~line 241) 5) Added the new cipher as a define (~line 420) 6) Added cipher to the OPT_PAIR doit_choices (~line 423) 7) Created the actual Nightgale_loop (followed how AES had its implementation) 8) Added the call to the loop in speed_main() Any ideas for such odd output? Seems like it's choosing default output. Doing nightgale for 3s on 16 size blocks: 2147483647 nightgale's in 0.64s Doing nightgale for 3s on 64 size blocks: 2147483647 nightgale's in 0.66s Doing nightgale for 3s on 256 size blocks: 2147483647 nightgale's in 0.68s Doing nightgale for 3s on 1024 size blocks: 2147483647 nightgale's in 0.78s Doing nightgale for 3s on 8192 size blocks: 2147483647 nightgale's in 0.67s Doing nightgale for 3s on 16384 size blocks: 2147483647 nightgale's in 0.67s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -Wa,--noexecstack The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes nightgale 53687091.17k 208240838.50k 808464431.81k 2819260582.73k 26256994083.92k 52513988167.83k Thank you, Rob Schmicker -------------- next part -------------- An HTML attachment was scrubbed... URL: From Walter.H at mathemainzel.info Sun Feb 5 20:26:27 2017 From: Walter.H at mathemainzel.info (Walter H.) Date: Sun, 05 Feb 2017 21:26:27 +0100 Subject: [openssl-users] openssl s_client Message-ID: <58978A73.9000306@mathemainzel.info> Hello, openssl s_client -connect mailhost:25 -starttls smtp displays this: CONNECTED(00000003) depth=0 OU = Domain Control Validated, CN = ... verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 OU = Domain Control Validated, CN = ... verify error:num=27:certificate not trusted verify return:1 depth=0 OU = Domain Control Validated, CN = ... verify error:num=21:unable to verify the first certificate verify return:1 the question: is this caused by a config problem on the serverside or on the client side (host running openssl)? Thanks, Walter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3827 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-users at dukhovni.org Sun Feb 5 20:46:53 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 5 Feb 2017 15:46:53 -0500 Subject: [openssl-users] openssl s_client In-Reply-To: <58978A73.9000306@mathemainzel.info> References: <58978A73.9000306@mathemainzel.info> Message-ID: <094486A0-B7C5-481C-8A1A-3988D6BA5135@dukhovni.org> > On Feb 5, 2017, at 3:26 PM, Walter H. via openssl-users wrote: > > openssl s_client -connect mailhost:25 -starttls smtp > > displays this: > > CONNECTED(00000003) > depth=0 OU = Domain Control Validated, CN = ... > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 OU = Domain Control Validated, CN = ... > verify error:num=27:certificate not trusted > verify return:1 > depth=0 OU = Domain Control Validated, CN = ... > verify error:num=21:unable to verify the first certificate > verify return:1 > > the question: is this caused by a config problem on the serverside or on the client side (host running openssl)? Neither. This is generally expected. 1. Many SMTP servers have self-signed or private CA issued certificates 2. Many omit required intermediate certificates from their server chain configuration 3. You've given no indication of what CAs are present in your OpenSSL trust store. 4. You've given no indication of which mail server you're testing. -- Viktor. From mail.dipanjan.das at gmail.com Mon Feb 6 07:20:03 2017 From: mail.dipanjan.das at gmail.com (Dipanjan Das) Date: Sun, 5 Feb 2017 23:20:03 -0800 Subject: [openssl-users] Why do we try out all possible combinations of top bits in OpenSSL timing attack? Message-ID: Hi, down votefavorite In the paper titled Remote Timing Attacks are Practical , the authors mention the following: Initially our guess g of q lies between 25122512 (i.e. 2log2(N/2)2log2(N/2)) and 25112511 (i.e. 2log2(N/2)?12log2(N/2)?1). We then time the decryption of all possible combinations of the top few bits (typically 2-3). When plotted, the decryption times will show two peaks: one for q and one for p. We pick the values that bound the first peak, which in OpenSSL will always be q. I don't understand the following: - Does the initial guess of g start from an arbitrary range? - What's the rationale behind trying out top 2-3 bits? - What will the remaining bits be in this case? -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Feb 6 10:55:46 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 6 Feb 2017 10:55:46 +0000 Subject: [openssl-users] Interoperating with a legacy client. In-Reply-To: References: Message-ID: <959a1af4-5ad7-1b36-a0fb-688f71ecea4a@openssl.org> On 04/02/17 04:56, Tim Kirby wrote: > > I'm writing a server to support a legacy client that uses OpenSSL to > secure its communication. The client is using OpenSSL 1.0.1j, and I > have no control over that. I'm using the 1.0.1 version of OpenSSL > supplied with my > OS for the server side, but that is out of convenience rather than > necessity. > > My server appears to be working at least semi-correctly, but I have a > problem with established > connections being terminated by the server side, and I have run out of > troubleshooting ideas. > > The client will happily connect to my server, we complete the handshake, > and start exchanging > encrypted application data. Then, it seems like the client wants to > renegotiate, because it sends the > server a ClientHello across the established connection. But something > is clearly not right, because > the server responds with a fatal alert and terminates the connection. > > I can watch the connection with wireshark, so I can see in detail what's > going on, but the client's > behavior doesn't make sense to me. > > The typical interaction looks like this: > > The client connects to the server. > > The initial ClientHello advertises TLS 1.2 with a record version of 1.0, > and includes TLS_EMPTY_RENEGOTIATION_INFO_SCSV > in the cipher suites. Our ServerHello response includes a zero-length > renegotiation_info extension. This all seems reasonable. > > The negotiation settles on TLS 1.2, and subsequent application data > records are sent at that version. At this point, everything > seems fine. > > After sending some amount of application data, the client then seems to > want to renegotiate. It sends another ClientHello. > > At this point, things have gone wrong. The second ClientHello looks > very, very similar to the one sent in the initial handshake. > The record version is again 1.0, the TLS_EMPTY_RENEGOTIATION_INFO_SCSV > is included in the cipher suites, and there's no > renegotiation_info extension present. > > So, if the connection is using TLS 1.2, the server terminates the > connection with a > version mismatch alert when it sees the second ClientHello. > > If I force the server to use TLS 1.0, then the server terminates the > connection because > of the SCSV present in the ClientHello during renegotiation. > > I'm at a loss. It seems like the client is misbehaving, if the second > ClientHello it sends is supposed to be > a renegotiation attempt. But misbehaving or not, I still need to > interoperate with this client. This does look like the client is misbehaving for some reason. It's not behaviour I can reproduce with a 1.0.1j version of s_client. The second ClientHello should have a TLS1.2 record version, not have the SCSV ciphersuite, but instead have a renegotiation_info extension. Is the second ClientHello encrypted or in plaintext? If it is a renegotiation then it would be encrypted. I am wondering whether for some reason the client has forgotten its original connection, and is attempting a second completely new TLS connection over the same underlying TCP connection. Matt From matt at openssl.org Mon Feb 6 11:03:50 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 6 Feb 2017 11:03:50 +0000 Subject: [openssl-users] DTLS Server with support for both EC and RSA keys In-Reply-To: References: Message-ID: On 04/02/17 22:23, Suman Paul wrote: > Hi, > > I have a server that implements DTLS using OpenSSL 1.0.1 but supports > only RSA keys as of today. I want to add support to this server to > accept EC keys to be able to implement the newer ECDHE-ECDSA cipher > suites while retaining support for RSA. Any pointers as to how to go > about this? > > What I believe is that each kind of key would need a different > SSL_CTX object. So I want to switch to the correct context for the > SSL session as per the cipher supported by the client (maybe from the > cipher list advertised in the ClientHello). Is that the best way of > implementing this? No. You can add both the RSA certificate and the ECDSA certificate to the same SSL_CTX. Just call one of the SSL_CTX_use_certificate*() functions twice - once for each certificate type. Matt From Michael.Wojcik at microfocus.com Mon Feb 6 13:30:39 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 6 Feb 2017 13:30:39 +0000 Subject: [openssl-users] Why do we try out all possible combinations of top bits in OpenSSL timing attack? In-Reply-To: References: Message-ID: [Snipped HTML content, since Outlook can't quote it properly and it was garbled anyway.] openssl-users doesn't really seem like the right place to discuss this (the sci.crypt newsgroup or a relevant area of the sprawling StackOverflow empire would be better), but it's a low-traffic list, so what the heck. The OP had three questions regarding the second paragraph ("Initially, our guess g of q...") of section 3 of the classic Brumley & Boneh paper "Remote Timing Attacks are Practical". Note this paper is from 2003 and refers to OpenSSL 0.9.7. Timing attacks and timing-attack defenses have moved on considerably since then, as have other side-channel attacks. While this paper is a good introduction to the theory and general techniques, it's not a recipe for attacking modern TLS implementations. The questions and my responses: Q: Does the initial guess of?g?start from an arbitrary range? A: No. First, g *is* the guess; there is no "guess of g". Initial g and the algorithm for refining it is explained here and in the following paragraphs. g is a guess for q. N=pq, q < p. Thus q must be less than the square root of N. If N is < 2**1024 (a 1024-bit modulus), then q < 2**512. The initial range for g amounts to "g has either its most-significant bit or its second-most-significant bit set, or both". Start with binary 10000... for g. Q: What's the rationale behind trying out top 2-3 bits? A: Read the algorithm. At each iteration, it proceeds by taking a g that's been found to match q in the i-most-significant bits, and determining the (i+1)th bit. So initially you probe (using timing) the four or eight combinations of the most-significant bits, so you have a starting point. Q: What will the remaining bits be in this case? A: In what case? At this point in the algorithm you don't know them. You iterate the steps of the algorithm until you know, based on timing differences, that the more-significant half of the bits in your g match those in q (with high probability). Then, as the paper says, you use Coppersmith's algorithm to finish the factorization. (It's been a long time since I looked at Coppersmith's algorithm, so I forget how it works and what constraints there are on it.) All the side-channel attacks I can think of offhand do this sort of bit-at-a-time extraction, by the way (which gives them logarithmic time complexity obviously; note B&B characterize it as a "binary search"). So if you're learing about side-channel attacks expect to see more of this. -- Thanks & Regards, Dipanjan From mail.dipanjan.das at gmail.com Mon Feb 6 15:03:07 2017 From: mail.dipanjan.das at gmail.com (Dipanjan Das) Date: Mon, 6 Feb 2017 07:03:07 -0800 Subject: [openssl-users] Why do we try out all possible combinations of top bits in OpenSSL timing attack? In-Reply-To: References: Message-ID: On 6 February 2017 at 05:30, Michael Wojcik wrote: > > The OP had three questions regarding the second paragraph ("Initially, our > guess g of q...") of section 3 of the classic Brumley & Boneh paper "Remote > Timing Attacks are Practical". Note this paper is from 2003 and refers to > OpenSSL 0.9.7. Timing attacks and timing-attack defenses have moved on > considerably since then, as have other side-channel attacks. While this > paper is a good introduction to the theory and general techniques, it's not > a recipe for attacking modern TLS implementations. > > The questions and my responses: > > Q: Does the initial guess of g start from an arbitrary range? > > A: No. First, g *is* the guess; there is no "guess of g". Initial g and > the algorithm for refining it is explained here and in the following > paragraphs. g is a guess for q. N=pq, q < p. Thus q must be less than the > square root of N. If N is < 2**1024 (a 1024-bit modulus), then q < 2**512. > The initial range for g amounts to "g has either its most-significant bit > or its second-most-significant bit set, or both". Start with binary > 10000... for g. > > Q: What's the rationale behind trying out top 2-3 bits? > > A: Read the algorithm. At each iteration, it proceeds by taking a g that's > been found to match q in the i-most-significant bits, and determining the > (i+1)th bit. So initially you probe (using timing) the four or eight > combinations of the most-significant bits, so you have a starting point. > Thanks a lot for your responses. Probably I should have rephrased my question to make it sound clearer. In the flow of the paper, the technique to determine the top 2-3 bits was introduced before the binary search algorithm (which I understand). What is still not so clear to me what or how they "try out top 2-3 bits". Assuming we are trying out top 2 bits, I assume that 'g' is constructed as follows: - Set the two most significant bits to each one in the set => {00, 01, 10, 11}, one after another - For each of the above cases, fill the remaining 510 bits with *some* bits (are those assumed to be all zero bits?) My first doubt is, what will the remaining 510 bits of initial guess 'g' be? Determining the starting point is where I am struggling at the moment. Once I know the top bits, I perfectly understand how the i-th bit is extracted given top (i-1) bits are already known. > > Q: What will the remaining bits be in this case? > > A: In what case? At this point in the algorithm you don't know them. You > iterate the steps of the algorithm until you know, based on timing > differences, that the more-significant half of the bits in your g match > those in q (with high probability). Then, as the paper says, you use > Coppersmith's algorithm to finish the factorization. (It's been a long time > since I looked at Coppersmith's algorithm, so I forget how it works and > what constraints there are on it.) > > All the side-channel attacks I can think of offhand do this sort of > bit-at-a-time extraction, by the way (which gives them logarithmic time > complexity obviously; note B&B characterize it as a "binary search"). So if > you're learing about side-channel attacks expect to see more of this. > > -- > Thanks & Regards, > Dipanjan > -- Thanks & Regards, Dipanjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Feb 6 15:07:28 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 6 Feb 2017 15:07:28 +0000 Subject: [openssl-users] Why do we try out all possible combinations of top bits in OpenSSL timing attack? In-Reply-To: References: Message-ID: Michael was kind to post some replies. I think a better forum to discuss this is one of the following, which has more focus on cryptographic science and less on ?how do I use the CLI? http://www.metzdowd.com/mailman/listinfo/cryptography https://www.irtf.org/mailman/listinfo/cfrg -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Feb 6 15:11:32 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 6 Feb 2017 10:11:32 -0500 Subject: [openssl-users] Why do we try out all possible combinations of top bits in OpenSSL timing attack? In-Reply-To: References: Message-ID: <4A38314D-FF2D-4A91-B9B4-C06927D1147D@dukhovni.org> > On Feb 6, 2017, at 10:07 AM, Salz, Rich via openssl-users wrote: > > Michael was kind to post some replies. > > I think a better forum to discuss this is one of the following, which has more focus on cryptographic science and less on ?how do I use the CLI? > http://www.metzdowd.com/mailman/listinfo/cryptography > https://www.irtf.org/mailman/listinfo/cfrg Actually, very much NOT the CFRG list. That's an IRTF working group, and discussion needs to be about IRTF work. -- Viktor. From devang.kubavat at in.abb.com Mon Feb 6 09:58:12 2017 From: devang.kubavat at in.abb.com (Devang Kubavat) Date: Mon, 6 Feb 2017 09:58:12 +0000 Subject: [openssl-users] How to disable the DTLS stuff in openssl 1.0.2k Message-ID: Hi, I am trying to configure the OpenSSL 1.0.2k for windows. Can anyone help me How to disable the DTLS? Best Regards, Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Mon Feb 6 16:32:54 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 6 Feb 2017 10:32:54 -0600 Subject: [openssl-users] Inserting cipher into speed.c In-Reply-To: References: Message-ID: <7a527885-363e-fc5f-0ecc-c15d4832b7cb@akamai.com> On 02/04/2017 04:00 PM, Schmicker, Robert wrote: > > Hello, > > > Thanks to everyones help here I was able to insert a new cipher into > OpenSSL. > > However, for performance reasons I'd like to begin testing the speed > of my cipher and > > compare to other already implemented ciphers. > > > I went ahead and started editing the ./apps/speed.c file to insert the > new cipher but ran into some strange output.... (See below). > > IIRC you are supposed to implement the EVP interface for your cipher and use the -evp flag to speed. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From vijay.chander at gmail.com Mon Feb 6 18:41:39 2017 From: vijay.chander at gmail.com (Vijay Chander) Date: Mon, 6 Feb 2017 10:41:39 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 Message-ID: Is big number montogomery multiplication as optimized as it can be for ARM64 as compared to X86-64 from the latest openssl github ? We are not seeing vmull ( or pmull/pmull2) instructions in armv8-mont.pl. On an ARM cortex-A72 (1GHz) and E5-2620 (2.1 Ghz) we are seeing an order of 10 difference in RSA signing perf for 2048 bit keys. Ran openssl speed rsa2048 Here are the openssl speed numbers. *x86-64* [root at nuosrv2 openssl]# ./apps/openssl speed rsa2048 Doing 2048 bit private rsa's for 10s: 13134 2048 bit private RSA's in 9.97s Doing 2048 bit public rsa's for 10s: 379019 2048 bit public RSA's in 9.98s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib64/engines-1.1\"" -Wa,--noexecstack sign verify sign/s verify/s *rsa 2048 bits 0.000759s 0.000026s 1317.4 37977.9* *arm64:* [root at juno openssl]# ./apps/openssl speed rsa2048 Doing 2048 bit private rsa's for 10s: 1319 2048 bit private RSA's in 9.92s Doing 2048 bit public rsa's for 10s: 49209 2048 bit public RSA's in 9.93s OpenSSL 1.1.1-dev xx XXX xxxx built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -Wa,--noexecstack sign verify sign/s verify/s *rsa 2048 bits 0.007521s 0.000202s 133.0 4955.6* * ARM64 heavy hitters* 69.70% openssl libcrypto.so.1.1 [.] __bn_sqr8x_mont 18.64% openssl libcrypto.so.1.1 [.] __bn_mul4x_mont 4.92% openssl libcrypto.so.1.1 [.] MOD_EXP_CTIME_COPY_FROM_PREBUF 1.50% openssl libcrypto.so.1.1 [.] bn_mul_add_words * x86-64 heavy hitters* 30.93% openssl libcrypto.so.1.1 [.] __bn_sqrx8x_reduction 17.65% openssl libcrypto.so.1.1 [.] bn_sqrx8x_internal 12.65% openssl libcrypto.so.1.1 [.] mulx4x_internal 8.91% openssl libcrypto.so.1.1 [.] bn_mul_add_words 7.14% openssl libcrypto.so.1.1 [.] bn_mulx4x_mont Code looks different between x86 and ARM64. Is it due to the ISA or ARM64 not yet catching up with super efficient X86-64. Basically are we stuck with 1:5 (if we extrapolate A72 to 2Ghz) or is there an optimal code that we need to pick up for ARM64. I compiled openssl from github (latest). Any pointers will be extremely helpful. Thanks, -vijay -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkirby at hotlink.com Tue Feb 7 09:46:09 2017 From: tkirby at hotlink.com (Tim Kirby) Date: Tue, 7 Feb 2017 01:46:09 -0800 Subject: [openssl-users] Interoperating with a legacy client. In-Reply-To: <959a1af4-5ad7-1b36-a0fb-688f71ecea4a@openssl.org> References: <959a1af4-5ad7-1b36-a0fb-688f71ecea4a@openssl.org> Message-ID: On 2/6/2017 2:55 AM, Matt Caswell wrote: > This does look like the client is misbehaving for some reason. It's not > behaviour I can reproduce with a 1.0.1j version of s_client. > > The second ClientHello should have a TLS1.2 record version, not have the > SCSV ciphersuite, but instead have a renegotiation_info extension. > > Is the second ClientHello encrypted or in plaintext? If it is a > renegotiation then it would be encrypted. I am wondering whether for > some reason the client has forgotten its original connection, and is > attempting a second completely new TLS connection over the same > underlying TCP connection. Good question! I checked my traces again, and the second ClientHello is plaintext. Starting a new TLS connection over the same TCP connection as an existing, functional, TLS connection seems like a weird thing for the client to do, but that would explain a second ClientHello that looks like an initial connection. Assuming that's what's happening, is there a way I can detect it and start a new connection instead? Would it be safe to use a message callback to look for a ClientHello, do an SSL_new() with the current context, and reuse the same BIOs? Thanks. -- Tim Kirby From stm at pdflib.com Tue Feb 7 11:15:33 2017 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Tue, 7 Feb 2017 12:15:33 +0100 Subject: [openssl-users] Why is the signing-time signed attribute added unconditionally in CMS signatures? Message-ID: Hi, I'm wondering why OpenSSL adds the signing-time signed attribute unconditionally to a CMS signedData object. See function CMS_SignerInfo_sign() in source file cms_sd.c: if (CMS_signed_get_attr_by_NID(si, NID_pkcs9_signingTime, -1) < 0) { if (!cms_add1_signingTime(si, NULL)) goto err; } I found nothing in RFC 5652 that mandates the addition of the signing-time attribute. It's merely described as a "useful attribute". The unconditional addition of the signing-time attribute is a problem when using OpenSSL for the creation of PAdES-conforming PDF signatures. The ETSI standard ETSI TS 102 778-3 (PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced) explicitly requires the following: http://www.etsi.org/deliver/etsi_ts/102700_102799/10277803/01.01.02_60/ts_10277803v010102p.pdf "4.5.3 signing-time Attribute For all profiles covered in the present document the signing-time attribute shall not be used." So a CMS API flag would be useful that allows suppression of the signing-time attribute. -- Stephan From matt at openssl.org Tue Feb 7 13:21:37 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Feb 2017 13:21:37 +0000 Subject: [openssl-users] Interoperating with a legacy client. In-Reply-To: References: <959a1af4-5ad7-1b36-a0fb-688f71ecea4a@openssl.org> Message-ID: <6830f61f-7155-c657-c2a5-3451ad07c436@openssl.org> On 07/02/17 09:46, Tim Kirby wrote: > On 2/6/2017 2:55 AM, Matt Caswell wrote: >> This does look like the client is misbehaving for some reason. It's not >> behaviour I can reproduce with a 1.0.1j version of s_client. >> >> The second ClientHello should have a TLS1.2 record version, not have the >> SCSV ciphersuite, but instead have a renegotiation_info extension. >> >> Is the second ClientHello encrypted or in plaintext? If it is a >> renegotiation then it would be encrypted. I am wondering whether for >> some reason the client has forgotten its original connection, and is >> attempting a second completely new TLS connection over the same >> underlying TCP connection. > > Good question! > > I checked my traces again, and the second ClientHello is plaintext. > > Starting a new TLS connection over the same TCP connection as an > > existing, functional, TLS connection seems like a weird thing for the > > client to do, but that would explain a second ClientHello that looks > like an > > initial connection. > > > Assuming that's what's happening, is there a way I can detect it and start > > a new connection instead? Would it be safe to use a message callback to > look > > for a ClientHello, do an SSL_new() with the current context, and reuse > the same BIOs? By the time you hit the message callback OpenSSL will already have read the ClientHello record from the BIO. Therefore by the time you created a new SSL object and attempted the handshake the ClientHello would no longer be available for reading. Are you able to detect this at an application level? Is there something about the application level protocol which might indicate that the client is about to end the connection? I assume there is no close_notify alert coming from the client indicating the closure of the connection. Ideally you would detect the closure in one of the above ways. If the closure comes completely randomly and unpredictably then that's a bit more difficult to deal with - although still possible. I would probably write a custom BIO that inspects the incoming TLS records looking for a handshake record with an unencrypted ClientHello in it. If it detects one then it signals the closure to libssl - before libssl has read the data out. You can then reuse the same BIOs and context for a new SSL object. Care should be taken though to make sure that, at an application level, you treat this as a completely new connection - not a continuation of a previous connection (which would have security implications). Matt From appro at openssl.org Tue Feb 7 15:06:11 2017 From: appro at openssl.org (Andy Polyakov) Date: Tue, 7 Feb 2017 16:06:11 +0100 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: Message-ID: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> > Is big number montogomery multiplication as optimized as it can be for > ARM64 as compared to X86-64 from the latest openssl github ? > We are not seeing vmull ( or pmull/pmull2) instructions in > armv8-mont.pl . > > On an ARM cortex-A72 (1GHz) and E5-2620 (2.1 Ghz) we are seeing an > order of 10 difference in RSA signing perf for 2048 bit keys. When it comes to performance correct question actually is not what is the result in absolute terms, but how far is it from possible maximum for specific processor [taking into consideration all the factors from ISA capabilities and specific hardware implementation]. So that implying that 10x difference between processors in question is result of insufficient optimization for one is somewhat unjustified. Well, to be completely honest there are some minor tricks one can pull on ARMv8, but it will only make the gap a *little* bit smaller. Or in other words suck it up, that's the way Cortex [currently?] is. If it's so critical *and* you're in position to choose processor, then Samsung Mongoose core would be much better choice (but I don't know anything about Qualcomm Kryo). Yet, even though it would be better choice, it still wouldn't actually close the gap, so don't get your hopes too high :-) As for not seeing vector instructions. Pmull[2] is about something completely different. As for vmull you have to recognize that it's limited by 32-bit inputs and there is no carry handling in vector instructions. This means that it would take more instructions to do same job, even though you perform pair of multiplications in one vector instruction. Well, it's more complicated than just amount of instructions, but nevertheless, scalar 64x64 multiplication with carry processing offered by ARMv8 ISA does deliver better result than 128-bit vector instructions would. From raja.ashok at huawei.com Tue Feb 7 15:12:50 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Tue, 7 Feb 2017 15:12:50 +0000 Subject: [openssl-users] Doubt regarding process of invalid [D]TLS record Message-ID: Hi All, In dtls1_get_record(), we are calling ssl3_read_n to get 13 bytes of DTLS record header from socket and then based on the length in record header, we again call ssl3_read_n to get record payload from socket. Here we are handling invalid record, like length less 13 bytes or invalid version in record header or invalid epoch etc. If such invalid record comes then we are dropping that record and going to read again from socket, by calling ssl3_read_n again. If a peer is continuously sending invalid DTLS record, then our execution will be just running inside dtls1_get_record function. It wont come out of that function. So if a malicious peer wants to block our DTLS connection thread, then it can do by simply sending invalid DTLS record continuously. This behaviour would be same for both synchronous and asynchronous UDP sockets. This will simply block the application for long time, for the API SSL_connect, SSL_accept or SSL_read. I feel here we should not block the application call for long time, we should have some mechanism to fail the connection and inform application if we get invalid DTLS record continuously. For example, if we receive around 100 invalid DTLS record continuously, then we should come out of this "goto" in dtls1_get_record and return failure to application. And also we can send alert to peer and close the DTLS connection. For similar issue in ssl3_get_record(), we are having a max limit(MAX_EMPTY_RECORDS) for the received empty record. I feel similar limit should be there for invalid DTLS record in dtls1_get_record. Similarly in ssl3_get_message and dtls1_get_message_fragment, if we receive Hello request message continuously, then we are just dropping and continuously going back to read on socket. This also may cause a long time block to application, for the API SSL_connect if malicious peer is continuously sending Hello request msg. I feel blocking of application call for a long time should be avoided. Please check this and clarify me, if my understanding is wrong. Note : I am referring openssl-1.0.2k and asking this doubt. Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: From appro at openssl.org Tue Feb 7 15:48:55 2017 From: appro at openssl.org (Andy Polyakov) Date: Tue, 7 Feb 2017 16:48:55 +0100 Subject: [openssl-users] FW: problem with missing STDINT.H file In-Reply-To: References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov> Message-ID: >> The attached text file is a snippet from attempting to install >> openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when >> could not be found. > > Do you have inttypes.h instead? > > As Jeff pointed out in another email this is for uint32_t and similar > types. These get included from e_os2.h as follows: > > # if defined(OPENSSL_SYS_UEFI) > typedef INT8 int8_t; > typedef UINT8 uint8_t; > typedef INT16 int16_t; > typedef UINT16 uint16_t; > typedef INT32 int32_t; > typedef UINT32 uint32_t; > typedef INT64 int64_t; > typedef UINT64 uint64_t; > # define PRIu64 "%Lu" > # elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \ > defined(__osf__) || defined(__sgi) || defined(__hpux) || \ > defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__) > # include It should probably be noted that this is quite counter-intuitive condition. Basically all those defined(__this-or-that__) refer to systems that are kind of stuck between standards and are "almost, but not quite, entirely unlike" 199901L. So that intuitively one would expect to see __STDC_VERSION__ < 199901L || defined(__this-or-that__). But then it was argued that inttypes.h >= 199901L includes stdint.h anyway, as well as defines other "goodies". So that this condition effectively produces two different outcomes: on >=199901L it results in *extended* equivalent of stdint.h, and on __this-n-that__ - in *pre-standard*, potentially limited equivalent of stdint.h. And remaining question in the context of original query is what is Solaris 8. It does have inttypes.h so that one can [and probably should] extend __this-or-that__ with defined(__sun). [And as Jeffrey already mentioned compiling OpenSSL is job for C compiler, not C++.] From Michael.Wojcik at microfocus.com Tue Feb 7 16:03:40 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 7 Feb 2017 16:03:40 +0000 Subject: [openssl-users] FW: problem with missing STDINT.H file In-Reply-To: References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Andy Polyakov > Sent: Tuesday, February 07, 2017 10:49 > > # elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) > || \ > > defined(__osf__) || defined(__sgi) || defined(__hpux) || \ > > defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__) > > It should probably be noted that this is quite counter-intuitive > condition. Also, that "defined(__STDC_VERSION__)" is redundant; if X is not defined in a #if test, then it has to be replaced with 0, which is not >= 199901L. Any implementation that doesn't do that isn't even compatible with C90, and you'll have bigger problems. And the "defined" operator is an operator, not a function. The parentheses are superfluous. # elif __STDC_VERSION__ >= 199901L || \ defined __osf__ || defined __sgi || defined __hpux || \ defined OPENSSL_SYS_VMS || defined __OpenBSD__ || defined __sun /* C99 implementations and some others have inttype.h */ Ah, that's almost readable. Michael Wojcik Distinguished Engineer, Micro Focus From vijay.chander at gmail.com Tue Feb 7 16:42:38 2017 From: vijay.chander at gmail.com (Vijay Chander) Date: Tue, 7 Feb 2017 08:42:38 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> Message-ID: Thanks Andy. A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully get down to -1:5. There is no L3 cache on the A72 eval board and performance counters do show 9x more DRAM accesses for ARM compared to x86. Will check out Mongoose and Kyro. Do you know of any good hardware crypto intellectual property like synopsis for example which can help in asymmetric crypto part of TLS handshake ? Thanks, Vijay On Feb 7, 2017 7:06 AM, "Andy Polyakov" wrote: > Is big number montogomery multiplication as optimized as it can be for > ARM64 as compared to X86-64 from the latest openssl github ? > We are not seeing vmull ( or pmull/pmull2) instructions in > armv8-mont.pl . > > On an ARM cortex-A72 (1GHz) and E5-2620 (2.1 Ghz) we are seeing an > order of 10 difference in RSA signing perf for 2048 bit keys. When it comes to performance correct question actually is not what is the result in absolute terms, but how far is it from possible maximum for specific processor [taking into consideration all the factors from ISA capabilities and specific hardware implementation]. So that implying that 10x difference between processors in question is result of insufficient optimization for one is somewhat unjustified. Well, to be completely honest there are some minor tricks one can pull on ARMv8, but it will only make the gap a *little* bit smaller. Or in other words suck it up, that's the way Cortex [currently?] is. If it's so critical *and* you're in position to choose processor, then Samsung Mongoose core would be much better choice (but I don't know anything about Qualcomm Kryo). Yet, even though it would be better choice, it still wouldn't actually close the gap, so don't get your hopes too high :-) As for not seeing vector instructions. Pmull[2] is about something completely different. As for vmull you have to recognize that it's limited by 32-bit inputs and there is no carry handling in vector instructions. This means that it would take more instructions to do same job, even though you perform pair of multiplications in one vector instruction. Well, it's more complicated than just amount of instructions, but nevertheless, scalar 64x64 multiplication with carry processing offered by ARMv8 ISA does deliver better result than 128-bit vector instructions would. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Feb 7 18:37:07 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 7 Feb 2017 19:37:07 +0100 Subject: [openssl-users] FW: problem with missing STDINT.H file In-Reply-To: References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov> Message-ID: <40c7a16e-7d2e-1a9b-cbaf-f844d6e9a484@wisemo.com> On 07/02/2017 17:03, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Andy Polyakov >> Sent: Tuesday, February 07, 2017 10:49 >>> # elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) >> || \ >>> defined(__osf__) || defined(__sgi) || defined(__hpux) || \ >>> defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__) >> It should probably be noted that this is quite counter-intuitive >> condition. > Also, that "defined(__STDC_VERSION__)" is redundant; if X is not defined in a #if test, then it has to be replaced with 0, which is not >= 199901L. Any implementation that doesn't do that isn't even compatible with C90, and you'll have bigger problems. > > And the "defined" operator is an operator, not a function. The parentheses are superfluous. Using parenthesis with the defined and sizeof operators is considered good for readability and thus proper style in most projects. What is a lot less readable in the if/ifelse/endif block that was posted is the somewhat counter intuitive order in which conditions are checked (and thus override each other). That kind of complex logic often would benefit from comments clarifying the reasoning. For example why is the workaround for UEFI located before tests for compiler support? And why are all compilers claiming compliance with recent STDC versions assumed NOT to have stdint.h, only inttypes.h? 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 Tue Feb 7 18:54:49 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Feb 2017 18:54:49 +0000 Subject: [openssl-users] How to disable the DTLS stuff in openssl 1.0.2k In-Reply-To: References: Message-ID: <2933f077-5f43-40d9-55ac-c46eba9bd14b@openssl.org> On 06/02/17 09:58, Devang Kubavat wrote: > Hi, > I am trying to configure the OpenSSL 1.0.2k for windows. > Can anyone help me How to disable the DTLS? I guess this email got stuck somewhere because I only just got this. See my answer to this on your stackoverflow question: https://stackoverflow.com/questions/42081976/how-to-disable-the-dtls-stuff-in-openssl-1-0-2k/ Matt From appro at openssl.org Tue Feb 7 19:07:37 2017 From: appro at openssl.org (Andy Polyakov) Date: Tue, 7 Feb 2017 20:07:37 +0100 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> Message-ID: <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully > get down to -1:5. And Mongoose will take you to ~1:2.5 (scaled to same frequency that is). Which I'd say is a fair result. Well, still could have been a bit better, but it's not unreasonable given ISA differences. Keep in mind that presented x86_64 result is for code utilizing Intel-specific code extensions. > There is no L3 cache on the A72 eval board and performance counters do > show 9x more DRAM accesses for ARM compared to x86. This is unexpected, because it takes *less* references to memory to perform it on ARMv8. Because it has larger register bank. And cache requirement is not that high for L3 to kick in... But at any case memory is not bottleneck here... From james.m.carter at nasa.gov Tue Feb 7 19:56:07 2017 From: james.m.carter at nasa.gov (Carter, James M. (MSFC-ES34)) Date: Tue, 7 Feb 2017 19:56:07 +0000 Subject: [openssl-users] FW: problem with missing STDINT.H file In-Reply-To: <40c7a16e-7d2e-1a9b-cbaf-f844d6e9a484@wisemo.com> References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov> <40c7a16e-7d2e-1a9b-cbaf-f844d6e9a484@wisemo.com> Message-ID: <5077833AAECE8A45871004A2ABC9F2C2178C96B5@NDMSMBX301.ndc.nasa.gov> Thanks to all persons who have provided the expertise with my problem of missing header file. One suggestion was to step down a version to 1.0.2k. This has worked configure, make, make test and make install all executed and installed. James Carter PhD ES34 Bldg 4487 Rm B117 Optics & Imaging Branch Space Systems Department Marshall Space Flight Center, AL 35812 P: 256-544-3469 C: 256-425-2068 F: 256-544-5629 -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm Sent: Tuesday, February 07, 2017 12:37 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] FW: problem with missing STDINT.H file On 07/02/2017 17:03, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >> Behalf Of Andy Polyakov >> Sent: Tuesday, February 07, 2017 10:49 >>> # elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) >> || \ >>> defined(__osf__) || defined(__sgi) || defined(__hpux) || \ >>> defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__) >> It should probably be noted that this is quite counter-intuitive >> condition. > Also, that "defined(__STDC_VERSION__)" is redundant; if X is not defined in a #if test, then it has to be replaced with 0, which is not >= 199901L. Any implementation that doesn't do that isn't even compatible with C90, and you'll have bigger problems. > > And the "defined" operator is an operator, not a function. The parentheses are superfluous. Using parenthesis with the defined and sizeof operators is considered good for readability and thus proper style in most projects. What is a lot less readable in the if/ifelse/endif block that was posted is the somewhat counter intuitive order in which conditions are checked (and thus override each other). That kind of complex logic often would benefit from comments clarifying the reasoning. For example why is the workaround for UEFI located before tests for compiler support? And why are all compilers claiming compliance with recent STDC versions assumed NOT to have stdint.h, only inttypes.h? 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Michael.Wojcik at microfocus.com Tue Feb 7 20:51:28 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 7 Feb 2017 20:51:28 +0000 Subject: [openssl-users] FW: problem with missing STDINT.H file In-Reply-To: <40c7a16e-7d2e-1a9b-cbaf-f844d6e9a484@wisemo.com> References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov> <40c7a16e-7d2e-1a9b-cbaf-f844d6e9a484@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jakob Bohm > Sent: Tuesday, February 07, 2017 13:37 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] FW: problem with missing STDINT.H file > > Using parenthesis with the defined and sizeof operators is > considered good for readability and thus proper style in > most projects. Rubbish. Cite a methodologically sound study that shows it improves readability, or that "most projects" define it as "proper style". (Good luck with the latter, since I'm willing to wager the vast majority of C source isn't associated with any explicit style document.) It's cargo-cult programming, most often by people who can't be bothered to learn the language they're using. Michael Wojcik Distinguished Engineer, Micro Focus From rsalz at akamai.com Tue Feb 7 21:01:05 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 7 Feb 2017 21:01:05 +0000 Subject: [openssl-users] FW: problem with missing STDINT.H file In-Reply-To: References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov> <40c7a16e-7d2e-1a9b-cbaf-f844d6e9a484@wisemo.com> Message-ID: <273799b156f24317afa341bc46b1ff72@usma1ex-dag1mb3.msg.corp.akamai.com> > It's cargo-cult programming, most often by people who can't be bothered to > learn the language they're using. There are also sometimes portability issues, vendors get things wrong. But at any rate, for this project, OpenSSL style says parens after sizeof and says nothing at all about pre-processor defined operator. It probably should, but clearly our existing style uses parens. Ok? You guys are both important contributors to the project. It hurts me to see you fight :) From vijay.chander at gmail.com Tue Feb 7 22:26:10 2017 From: vijay.chander at gmail.com (Vijay Chander) Date: Tue, 7 Feb 2017 14:26:10 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> Message-ID: Andy, 1:2.5 is pretty in my opinion for ARM ! We will check out Mongoose. Hmm - will try to get to the bottom of those cache misses (at a lower priority). Thanks, -vijay On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov wrote: > > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully > > get down to -1:5. > > And Mongoose will take you to ~1:2.5 (scaled to same frequency that is). > Which I'd say is a fair result. Well, still could have been a bit > better, but it's not unreasonable given ISA differences. Keep in mind > that presented x86_64 result is for code utilizing Intel-specific code > extensions. > > > There is no L3 cache on the A72 eval board and performance counters do > > show 9x more DRAM accesses for ARM compared to x86. > > This is unexpected, because it takes *less* references to memory to > perform it on ARMv8. Because it has larger register bank. And cache > requirement is not that high for L3 to kick in... But at any case memory > is not bottleneck here... > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akihana at gmail.com Tue Feb 7 23:31:59 2017 From: akihana at gmail.com (Mike Mohr) Date: Tue, 7 Feb 2017 15:31:59 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> Message-ID: Have you considered using GMP as a big integer backed for openssl? It has support for several arm variants using handwritten assembly code and the developers go to great lengths to find optimize runtime on all supported platforms. On Feb 7, 2017 2:26 PM, "Vijay Chander" wrote: Andy, 1:2.5 is pretty in my opinion for ARM ! We will check out Mongoose. Hmm - will try to get to the bottom of those cache misses (at a lower priority). Thanks, -vijay On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov wrote: > > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully > > get down to -1:5. > > And Mongoose will take you to ~1:2.5 (scaled to same frequency that is). > Which I'd say is a fair result. Well, still could have been a bit > better, but it's not unreasonable given ISA differences. Keep in mind > that presented x86_64 result is for code utilizing Intel-specific code > extensions. > > > There is no L3 cache on the A72 eval board and performance counters do > > show 9x more DRAM accesses for ARM compared to x86. > > This is unexpected, because it takes *less* references to memory to > perform it on ARMv8. Because it has larger register bank. And cache > requirement is not that high for L3 to kick in... But at any case memory > is not bottleneck here... > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From vijay.chander at gmail.com Wed Feb 8 00:32:59 2017 From: vijay.chander at gmail.com (Vijay Chander) Date: Tue, 7 Feb 2017 16:32:59 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> Message-ID: Mike, Tried with GMP. Same result for A72. Thanks, Vijay On Tue, Feb 7, 2017 at 3:31 PM, Mike Mohr wrote: > Have you considered using GMP as a big integer backed for openssl? It has > support for several arm variants using handwritten assembly code and the > developers go to great lengths to find optimize runtime on all supported > platforms. > > On Feb 7, 2017 2:26 PM, "Vijay Chander" wrote: > >> Have you considered using GMP as a big integer backed for openssl? It >> has support for several arm variants using handwritten assembly code and >> the developers go to great lengths to find optimize runtime on all >> supported platforms. >> >> On Feb 7, 2017 2:26 PM, "Vijay Chander" wrote: >> >> Andy, >> 1:2.5 is pretty in my opinion for ARM ! >> >> We will check out Mongoose. >> >> Hmm - will try to get to the bottom of those cache misses (at a lower >> priority). >> >> Thanks, >> -vijay >> >> >> >> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov wrote: >> >>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully >>> > get down to -1:5. >>> >>> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is). >>> Which I'd say is a fair result. Well, still could have been a bit >>> better, but it's not unreasonable given ISA differences. Keep in mind >>> that presented x86_64 result is for code utilizing Intel-specific code >>> extensions. >>> >>> > There is no L3 cache on the A72 eval board and performance counters do >>> > show 9x more DRAM accesses for ARM compared to x86. >>> >>> This is unexpected, because it takes *less* references to memory to >>> perform it on ARMv8. Because it has larger register bank. And cache >>> requirement is not that high for L3 to kick in... But at any case memory >>> is not bottleneck here... >>> >>> -- >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >>> >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Feb 8 00:42:36 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 8 Feb 2017 00:42:36 +0000 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> Message-ID: <9e22f4c421424e4aa71292cf2642a415@usma1ex-dag1mb3.msg.corp.akamai.com> > Have you considered using GMP as a big integer backed for openssl?? It has support for several arm variants using handwritten assembly code and the developers go to great lengths to find optimize runtime on all supported platforms. It might be interesting if we could figure out how to handle it as a dynamic library. License issues prevent anything else. From jb-openssl at wisemo.com Wed Feb 8 00:46:19 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 8 Feb 2017 01:46:19 +0100 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> Message-ID: <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> OpenSSL also has a lot of handwritten assembly language for ARM, x86 etc. Most of it written by Andy Polyakov. His response about what can and cannot be done on various ARM CPU models is most probably a result of this work. Also, OpenSSL has a more permissive license than the GMP, so using GMP in OpenSSL would cause problems for many OpenSSL using applications. On 08/02/2017 00:31, Mike Mohr wrote: > Have you considered using GMP as a big integer backed for openssl? It > has support for several arm variants using handwritten assembly code > and the developers go to great lengths to find optimize runtime on all > supported platforms. > > On Feb 7, 2017 2:26 PM, "Vijay Chander" > wrote: > > Andy, > 1:2.5 is pretty in my opinion for ARM ! > > We will check out Mongoose. > > Hmm - will try to get to the bottom of those cache misses (at a > lower priority). > > Thanks, > -vijay > > > On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > wrote: > > > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully > > get down to -1:5. > > And Mongoose will take you to ~1:2.5 (scaled to same frequency > that is). > Which I'd say is a fair result. Well, still could have been a bit > better, but it's not unreasonable given ISA differences. Keep > in mind > that presented x86_64 result is for code utilizing > Intel-specific code > extensions. > > > There is no L3 cache on the A72 eval board and performance > counters do > > show 9x more DRAM accesses for ARM compared to x86. > > This is unexpected, because it takes *less* references to > memory to > perform it on ARMv8. Because it has larger register bank. And > cache > requirement is not that high for L3 to kick in... But at any > case memory > is not bottleneck here... > -- Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded 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 vijay.chander at gmail.com Wed Feb 8 00:50:33 2017 From: vijay.chander at gmail.com (Vijay Chander) Date: Tue, 7 Feb 2017 16:50:33 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> Message-ID: Yes. Already took Andy's word from his previous replies for precisely this reason. GMP exercise was easy enough to get it out of the way. Thanks, Vijay On Feb 7, 2017 4:46 PM, "Jakob Bohm" wrote: > OpenSSL also has a lot of handwritten assembly language for ARM, > x86 etc. Most of it written by Andy Polyakov. > > His response about what can and cannot be done on various ARM CPU > models is most probably a result of this work. > > Also, OpenSSL has a more permissive license than the GMP, so using > GMP in OpenSSL would cause problems for many OpenSSL using > applications. > > On 08/02/2017 00:31, Mike Mohr wrote: > >> Have you considered using GMP as a big integer backed for openssl? It >> has support for several arm variants using handwritten assembly code >> and the developers go to great lengths to find optimize runtime on all >> supported platforms. >> >> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote: >> >> Andy, >> 1:2.5 is pretty in my opinion for ARM ! >> >> We will check out Mongoose. >> >> Hmm - will try to get to the bottom of those cache misses (at a >> lower priority). >> >> Thanks, >> -vijay >> >> >> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote: >> >> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should >> hopefully >> > get down to -1:5. >> >> And Mongoose will take you to ~1:2.5 (scaled to same frequency >> that is). >> Which I'd say is a fair result. Well, still could have been a bit >> better, but it's not unreasonable given ISA differences. Keep >> in mind >> that presented x86_64 result is for code utilizing >> Intel-specific code >> extensions. >> >> > There is no L3 cache on the A72 eval board and performance >> counters do >> > show 9x more DRAM accesses for ARM compared to x86. >> >> This is unexpected, because it takes *less* references to >> memory to >> perform it on ARMv8. Because it has larger register bank. And >> cache >> requirement is not that high for L3 to kick in... But at any >> case memory >> is not bottleneck here... >> >> > > -- > Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 +4531131610> > This message is only for its intended recipient, delete if misaddressed. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > 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 > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From akihana at gmail.com Wed Feb 8 03:21:13 2017 From: akihana at gmail.com (Mike Mohr) Date: Tue, 7 Feb 2017 19:21:13 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> Message-ID: Licensing issues are indeed thorny. Why can't openssl perform a dynamic link? The soversion should handle any ABI issues introduced in later versions of GMP. Are you cross compiling GMP for your use on a target device? If so, you'll need to ensure that the MPN_PATH is set appropriately. If you don't do so, you'll get the generic c code instead of optimized assembly routines. The performance difference can be dramatic, potentially several orders of magnitude. I had to deal with this myself when cross compiling GMP for Android. On Feb 7, 2017 4:51 PM, "Vijay Chander" wrote: Yes. Already took Andy's word from his previous replies for precisely this reason. GMP exercise was easy enough to get it out of the way. Thanks, Vijay On Feb 7, 2017 4:46 PM, "Jakob Bohm" wrote: > OpenSSL also has a lot of handwritten assembly language for ARM, > x86 etc. Most of it written by Andy Polyakov. > > His response about what can and cannot be done on various ARM CPU > models is most probably a result of this work. > > Also, OpenSSL has a more permissive license than the GMP, so using > GMP in OpenSSL would cause problems for many OpenSSL using > applications. > > On 08/02/2017 00:31, Mike Mohr wrote: > >> Have you considered using GMP as a big integer backed for openssl? It >> has support for several arm variants using handwritten assembly code >> and the developers go to great lengths to find optimize runtime on all >> supported platforms. >> >> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote: >> >> Andy, >> 1:2.5 is pretty in my opinion for ARM ! >> >> We will check out Mongoose. >> >> Hmm - will try to get to the bottom of those cache misses (at a >> lower priority). >> >> Thanks, >> -vijay >> >> >> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote: >> >> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should >> hopefully >> > get down to -1:5. >> >> And Mongoose will take you to ~1:2.5 (scaled to same frequency >> that is). >> Which I'd say is a fair result. Well, still could have been a bit >> better, but it's not unreasonable given ISA differences. Keep >> in mind >> that presented x86_64 result is for code utilizing >> Intel-specific code >> extensions. >> >> > There is no L3 cache on the A72 eval board and performance >> counters do >> > show 9x more DRAM accesses for ARM compared to x86. >> >> This is unexpected, because it takes *less* references to >> memory to >> perform it on ARMv8. Because it has larger register bank. And >> cache >> requirement is not that high for L3 to kick in... But at any >> case memory >> is not bottleneck here... >> >> > > -- > Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 +4531131610> > This message is only for its intended recipient, delete if misaddressed. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > 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 > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From akihana at gmail.com Wed Feb 8 11:26:17 2017 From: akihana at gmail.com (Mike Mohr) Date: Wed, 8 Feb 2017 03:26:17 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> Message-ID: Of course OpenSSL contains hand-optimized assembly routines. However, GMP has been around since at least 1993 and the library specifically targets heavily optimized multiple precision arithmetic. OpenSSL is a TLS/SSL toolkit, and necessarily focuses on implementing SSL/TLS correctly - I'd argue that the bigint subsystem is almost tangential to the other parts of any SSL library. A less optimized bigint subsystem should be reasonably expected. I would be surprised if the native bigint code could compete against GMP performance-wise, even when OpenSSL's optimized assembly code is used. I haven't benchmarked OpenSSL's bigint subsystem and would be interested in seeing a comparison against a correctly configured GMP. On Tue, Feb 7, 2017 at 4:46 PM, Jakob Bohm wrote: > OpenSSL also has a lot of handwritten assembly language for ARM, > x86 etc. Most of it written by Andy Polyakov. > > His response about what can and cannot be done on various ARM CPU > models is most probably a result of this work. > > Also, OpenSSL has a more permissive license than the GMP, so using > GMP in OpenSSL would cause problems for many OpenSSL using > applications. > > On 08/02/2017 00:31, Mike Mohr wrote: > >> Have you considered using GMP as a big integer backed for openssl? It >> has support for several arm variants using handwritten assembly code >> and the developers go to great lengths to find optimize runtime on all >> supported platforms. >> >> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote: >> >> Andy, >> 1:2.5 is pretty in my opinion for ARM ! >> >> We will check out Mongoose. >> >> Hmm - will try to get to the bottom of those cache misses (at a >> lower priority). >> >> Thanks, >> -vijay >> >> >> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote: >> >> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should >> hopefully >> > get down to -1:5. >> >> And Mongoose will take you to ~1:2.5 (scaled to same frequency >> that is). >> Which I'd say is a fair result. Well, still could have been a bit >> better, but it's not unreasonable given ISA differences. Keep >> in mind >> that presented x86_64 result is for code utilizing >> Intel-specific code >> extensions. >> >> > There is no L3 cache on the A72 eval board and performance >> counters do >> > show 9x more DRAM accesses for ARM compared to x86. >> >> This is unexpected, because it takes *less* references to >> memory to >> perform it on ARMv8. Because it has larger register bank. And >> cache >> requirement is not that high for L3 to kick in... But at any >> case memory >> is not bottleneck here... >> >> > > -- > Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 +4531131610> > This message is only for its intended recipient, delete if misaddressed. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > 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 > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Feb 8 12:51:47 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 8 Feb 2017 12:51:47 +0000 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> Message-ID: <5de69b86440a42f2bd223d154142f289@usma1ex-dag1mb3.msg.corp.akamai.com> > Licensing issues are indeed thorny. Why can't openssl perform a dynamic link? The soversion should handle any ABI issues introduced in later versions of GMP. Anything is possible; it is just code. I don't think this is a priority for the team. A pull request ... From Michael.Wojcik at microfocus.com Wed Feb 8 14:12:21 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 8 Feb 2017 14:12:21 +0000 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Mike Mohr > Sent: Tuesday, February 07, 2017 22:21 > Licensing issues are indeed thorny. Why can't openssl perform a dynamic link? The soversion should handle any ABI issues > introduced in later versions of GMP. Replace "thorny" with "completely unacceptable" for at least some commercial users of OpenSSL. And dynamic linking does not solve the problem, because customers would still have to get GMP. Some companies refuse to ship GPL code in any form, regardless of whether they've made modifications, and forcing customers to find and install GMP is hardly reasonable. Providing TLS support in commercial software is already difficult enough. Let's not make it harder in the hypothetical hope of eking out a bit more performance. Anyone who really wants GMP could implement it as an OpenSSL engine. That is, take the OpenSSL code for the algorithms you're using, copy them into an engine, and then replace the BN math operations with calls to GMP. Michael Wojcik Distinguished Engineer, Micro Focus From matt at openssl.org Wed Feb 8 14:28:37 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Feb 2017 14:28:37 +0000 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> Message-ID: <1ab121c5-42fe-2aeb-c878-461f9d51127a@openssl.org> On 08/02/17 14:12, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On >> Behalf Of Mike Mohr Sent: Tuesday, February 07, 2017 22:21 > >> Licensing issues are indeed thorny. Why can't openssl perform a >> dynamic link? The soversion should handle any ABI issues introduced >> in later versions of GMP. > > Replace "thorny" with "completely unacceptable" for at least some > commercial users of OpenSSL. And dynamic linking does not solve the > problem, because customers would still have to get GMP. Some > companies refuse to ship GPL code in any form, regardless of whether > they've made modifications, and forcing customers to find and install > GMP is hardly reasonable. > > Providing TLS support in commercial software is already difficult > enough. Let's not make it harder in the hypothetical hope of eking > out a bit more performance. > > Anyone who really wants GMP could implement it as an OpenSSL engine. > That is, take the OpenSSL code for the algorithms you're using, copy > them into an engine, and then replace the BN math operations with > calls to GMP. FYI, there already *is* a GMP engine in 1.0.2. It got removed from 1.1.0 due to lack of use. It is not compiled by default. You have to use "enable-gmp". Not tried it though. Matt From vijay.chander at gmail.com Wed Feb 8 15:06:29 2017 From: vijay.chander at gmail.com (Vijay Chander) Date: Wed, 8 Feb 2017 07:06:29 -0800 Subject: [openssl-users] BN_MUL_MONT for ARM64 v8 In-Reply-To: References: <3ff37fd9-9ffd-5f76-bad6-b204e7f9002b@openssl.org> <6d1a14d9-956f-ec0d-e013-24a8457bd54e@openssl.org> <128a70b2-0266-9a3d-6985-688ca6b83678@wisemo.com> Message-ID: Mike, I was native compiling on A72 (64 bit) using libgmp version 10.2. Thanks, -vijay On Feb 7, 2017 7:21 PM, "Mike Mohr" wrote: > Licensing issues are indeed thorny. Why can't openssl perform a dynamic > link? The soversion should handle any ABI issues introduced in later > versions of GMP. > > Are you cross compiling GMP for your use on a target device? If so, you'll > need to ensure that the MPN_PATH is set appropriately. If you don't do so, > you'll get the generic c code instead of optimized assembly routines. The > performance difference can be dramatic, potentially several orders of > magnitude. I had to deal with this myself when cross compiling GMP for > Android. > > On Feb 7, 2017 4:51 PM, "Vijay Chander" wrote: > > Yes. Already took Andy's word from his previous replies for precisely this > reason. > > GMP exercise was easy enough to get it out of the way. > > Thanks, > Vijay > > On Feb 7, 2017 4:46 PM, "Jakob Bohm" wrote: > >> OpenSSL also has a lot of handwritten assembly language for ARM, >> x86 etc. Most of it written by Andy Polyakov. >> >> His response about what can and cannot be done on various ARM CPU >> models is most probably a result of this work. >> >> Also, OpenSSL has a more permissive license than the GMP, so using >> GMP in OpenSSL would cause problems for many OpenSSL using >> applications. >> >> On 08/02/2017 00:31, Mike Mohr wrote: >> >>> Have you considered using GMP as a big integer backed for openssl? It >>> has support for several arm variants using handwritten assembly code >>> and the developers go to great lengths to find optimize runtime on all >>> supported platforms. >>> >>> On Feb 7, 2017 2:26 PM, "Vijay Chander" >> > wrote: >>> >>> Andy, >>> 1:2.5 is pretty in my opinion for ARM ! >>> >>> We will check out Mongoose. >>> >>> Hmm - will try to get to the bottom of those cache misses (at a >>> lower priority). >>> >>> Thanks, >>> -vijay >>> >>> >>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov >> > wrote: >>> >>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should >>> hopefully >>> > get down to -1:5. >>> >>> And Mongoose will take you to ~1:2.5 (scaled to same frequency >>> that is). >>> Which I'd say is a fair result. Well, still could have been a bit >>> better, but it's not unreasonable given ISA differences. Keep >>> in mind >>> that presented x86_64 result is for code utilizing >>> Intel-specific code >>> extensions. >>> >>> > There is no L3 cache on the A72 eval board and performance >>> counters do >>> > show 9x more DRAM accesses for ARM compared to x86. >>> >>> This is unexpected, because it takes *less* references to >>> memory to >>> perform it on ARMv8. Because it has larger register bank. And >>> cache >>> requirement is not that high for L3 to kick in... But at any >>> case memory >>> is not bottleneck here... >>> >>> >> >> -- >> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com >> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 > +4531131610> >> This message is only for its intended recipient, delete if misaddressed. >> WiseMo - Remote Service Management for PCs, Phones and Embedded >> >> >> 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 >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pm at jubeat.net Thu Feb 9 09:58:19 2017 From: pm at jubeat.net (=?gb18030?B?UE0gRXh0cmE=?=) Date: Thu, 9 Feb 2017 17:58:19 +0800 Subject: [openssl-users] Should I / How to remove expired certificates from CRL Message-ID: Should I remove expired certificates from CRL? If so, how to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Feb 9 13:16:50 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 9 Feb 2017 14:16:50 +0100 Subject: [openssl-users] Should I / How to remove expired certificates from CRL In-Reply-To: References: Message-ID: <72a91e15-d6e6-1802-1a76-00e0fee242e2@wisemo.com> On 09/02/2017 10:58, PM Extra wrote: > Should I remove expired certificates from CRL? > If so, how to do this? > Depends if any relying parties are checking old signatures "as of" some securely recorded date of receiving the signature. In that case, they will still need to be able to see, in the latest CRL, if and when a (now expired) certificate was revoked before it expired. This is also the reason it can be important to add a "backdated" revocation to a CRL, e.g. if a breach of a private key has been detected as happening around a specific time. As always there is the fundamental issue of deciding if the party reporting loss of a private key is lying to deny responsibility for something that was recently signed by that party. So I would not remove actual revocations from CRL lists, but would instead rotate issuing intermediary certificates such that a new intermediary (with its own CRL) is introduced a few times/year. Some time after all certificates issued by an old intermediary expire, but before the intermediary itself expires, it should sign a "final" CRL that doesn't expire. 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 Michael.Wojcik at microfocus.com Thu Feb 9 13:18:29 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 9 Feb 2017 13:18:29 +0000 Subject: [openssl-users] Should I / How to remove expired certificates from CRL In-Reply-To: References: Message-ID: If you remove expired certificates from the CRL, then CRL consumers have no way of knowing whether a certificate was revoked before it expired, and thus no way of knowing whether a timestamped signature made with the corresponding key is valid. This is a complex issue, because CRL bloat is a real problem. (That's why we have delta CRLs in the first place.) There's a CRL extension (expiredCertsOnCRL) that should be used if the CRL includes expired certificates. I've seen a number of discussions on this topic, in such places as the IETF PKIX list. See for example this thread: https://www.ietf.org/mail-archive/web/pkix/current/msg03776.html It seems to be difficult to find relevant material with simple web searches, though. The search terms are too common. I'm sure there are other people on the list who know more about current practices in this area than I do. Michael Wojcik Distinguished Engineer, Micro Focus From wouter.verhelst at fedict.be Thu Feb 9 11:40:49 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Thu, 9 Feb 2017 12:40:49 +0100 Subject: [openssl-users] Should I / How to remove expired certificates from CRL In-Reply-To: References: Message-ID: <0d5e70be-92ad-9c60-3448-fca21f10b40d@fedict.be> On 09-02-17 10:58, PM Extra wrote: > Should I remove expired certificates from CRL? No. The date of the revocation, which can be found in the CRL, is still relevant for checking when older certificates were revoked, in case you ever need to check signatures on older messages. -- Wouter Verhelst From michel.sales at free.fr Sat Feb 11 09:15:21 2017 From: michel.sales at free.fr (Michel) Date: Sat, 11 Feb 2017 10:15:21 +0100 Subject: [openssl-users] FW: problem with missing STDINT.H file In-Reply-To: <273799b156f24317afa341bc46b1ff72@usma1ex-dag1mb3.msg.corp.akamai.com> References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov> <40c7a16e-7d2e-1a9b-cbaf-f844d6e9a484@wisemo.com> <273799b156f24317afa341bc46b1ff72@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: <000001d28447$5f81c410$1e854c30$@sales@free.fr> > You guys are both important contributors to the project. +1 Personally I have learn a lot from your contributions. Thanks Jakob and Michael. From bhasker at unixindia.com Sat Feb 11 13:05:35 2017 From: bhasker at unixindia.com (Bhasker C V) Date: Sat, 11 Feb 2017 18:35:35 +0530 Subject: [openssl-users] Decrypt old openssl files Message-ID: Hi, I have two systems one with openssl 1.0.1e (debian wheezy) and the new one with openssl 1.1.0c (debian stretch) The files encrypted with 1.0.1e are not decryptable via 1.1.0c These are the investigations I have done on my system with 1.0.1e openssl $ echo some text > file $ cat file | openssl aes-256-cbc -pass pass:test > file.enc $ md5sum file.enc 5482ea53a6677865d1e559ac3057738c file.enc when I bring that file over to my system with 1.1.0c openssl $ md5sum file.enc 5482ea53a6677865d1e559ac3057738c file.enc $ cat file.enc | openssl aes-256-cbc -d -pass pass:test bad decrypt 4146981184:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto/evp/evp_enc.c:529: Please can someone tell me what other options I Am supposed to pass to get decryption done successfully. Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sat Feb 11 13:35:44 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 11 Feb 2017 08:35:44 -0500 Subject: [openssl-users] Decrypt old openssl files In-Reply-To: References: Message-ID: > I have two systems one with openssl 1.0.1e (debian wheezy) and the new one > with openssl 1.1.0c (debian stretch) > > The files encrypted with 1.0.1e are not decryptable via 1.1.0c > These are the investigations I have done > > on my system with 1.0.1e openssl > $ echo some text > file > $ cat file | openssl aes-256-cbc -pass pass:test > file.enc > $ md5sum file.enc > 5482ea53a6677865d1e559ac3057738c file.enc > > when I bring that file over to my system with 1.1.0c openssl > $ md5sum file.enc > 5482ea53a6677865d1e559ac3057738c file.enc > $ cat file.enc | openssl aes-256-cbc -d -pass pass:test > bad decrypt > 4146981184:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad > decrypt:crypto/evp/evp_enc.c:529: > > Please can someone tell me what other options I Am supposed to pass to get > decryption done successfully. >From the OpenSSL 1.1.0c-3 update notes. I don't believe its in the 'openssl enc' man page yet (https://www.openssl.org/docs/man1.0.1/apps/enc.html). The openssl enc command changed the default digest (used to create the key from passphrase) from MD5 to SHA256 since the version 1.1.0. The digest can be specified with the -md option. Jeff From bhasker at unixindia.com Sat Feb 11 14:30:27 2017 From: bhasker at unixindia.com (Bhasker C V) Date: Sat, 11 Feb 2017 20:00:27 +0530 Subject: [openssl-users] Decrypt old openssl files In-Reply-To: References: Message-ID: Wow ! thanks openssl -md md5 ... does the trick. All my docs are back now. That was a great help Double thanks to Jeff. On Sat, Feb 11, 2017 at 7:05 PM, Jeffrey Walton wrote: > > I have two systems one with openssl 1.0.1e (debian wheezy) and the new > one > > with openssl 1.1.0c (debian stretch) > > > > The files encrypted with 1.0.1e are not decryptable via 1.1.0c > > These are the investigations I have done > > > > on my system with 1.0.1e openssl > > $ echo some text > file > > $ cat file | openssl aes-256-cbc -pass pass:test > file.enc > > $ md5sum file.enc > > 5482ea53a6677865d1e559ac3057738c file.enc > > > > when I bring that file over to my system with 1.1.0c openssl > > $ md5sum file.enc > > 5482ea53a6677865d1e559ac3057738c file.enc > > $ cat file.enc | openssl aes-256-cbc -d -pass pass:test > > bad decrypt > > 4146981184:error:06065064:digital envelope routines:EVP_DecryptFinal_ex: > bad > > decrypt:crypto/evp/evp_enc.c:529: > > > > Please can someone tell me what other options I Am supposed to pass to > get > > decryption done successfully. > > From the OpenSSL 1.1.0c-3 update notes. I don't believe its in the > 'openssl enc' man page yet > (https://www.openssl.org/docs/man1.0.1/apps/enc.html). > > The openssl enc command changed the default digest (used to create the > key > from passphrase) from MD5 to SHA256 since the version 1.1.0. The digest > can > be specified with the -md option. > > Jeff > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajaygargnsit at gmail.com Sun Feb 12 13:13:15 2017 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Sun, 12 Feb 2017 18:43:15 +0530 Subject: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi In-Reply-To: References: Message-ID: Any ideas please? Is compiling openssl even possible on Raspberry-Pi? On Sat, Jan 28, 2017 at 10:50 AM, Ajay Garg wrote: > Hi Experts !!! > > Any help, please ?!!! > > On Sun, Jan 15, 2017 at 9:14 AM, Ajay Garg wrote: > >> Hi All. >> >> I am getting stuck on the first step of configuring OpenSSL. >> Following are some of the diagnostics :: >> >> >> OpenSSL-Version : *1.0.2d* >> >> >> ######################################################################### >> pi at raspberrypi:~/instamsg-c/third_party/openssl $ *uname -a* >> Linux raspberrypi 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l >> GNU/Linux >> ######################################################################### >> >> >> ######################################################################### >> pi at raspberrypi:~/instamsg-c/third_party/openssl $ *./Configure >> linux-armv4* >> Configuring for linux-armv4 >> no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 >> (skip dir) >> no-gmp [default] OPENSSL_NO_GMP (skip dir) >> no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) >> no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 >> no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) >> no-md2 [default] OPENSSL_NO_MD2 (skip dir) >> no-rc5 [default] OPENSSL_NO_RC5 (skip dir) >> no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) >> no-sctp [default] OPENSSL_NO_SCTP (skip dir) >> no-shared [default] >> no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) >> no-store [experimental] OPENSSL_NO_STORE (skip dir) >> no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) >> no-zlib [default] >> no-zlib-dynamic [default] >> IsMK1MF=0 >> CC =gcc >> CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H >> -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM >> -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM >> EX_LIBS =-ldl >> CPUID_OBJ =armcap.o armv4cpuid.o >> BN_ASM =bn_asm.o armv4-mont.o armv4-gf2m.o >> EC_ASM = >> DES_ENC =des_enc.o fcrypt_b.o >> AES_ENC =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o >> BF_ENC =bf_enc.o >> CAST_ENC =c_enc.o >> RC4_ENC =rc4_enc.o rc4_skey.o >> RC5_ENC =rc5_enc.o >> MD5_OBJ_ASM = >> SHA1_OBJ_ASM =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o >> RMD160_OBJ_ASM= >> CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o >> MODES_OBJ =ghash-armv4.o ghashv8-armx.o >> ENGINES_OBJ = >> PROCESSOR = >> RANLIB =/usr/bin/ranlib >> ARFLAGS = >> PERL =/usr/bin/perl >> THIRTY_TWO_BIT mode >> DES_UNROLL used >> DES_INT used >> BN_LLONG mode >> RC4 uses uchar >> RC4_CHUNK is unsigned long >> BF_PTR used >> e_os2.h => include/openssl/e_os2.h >> making links in crypto... >> make[1]: Entering directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto' >> crypto.h => ../include/openssl/crypto.h >> opensslv.h => ../include/openssl/opensslv.h >> opensslconf.h => ../include/openssl/opensslconf.h >> ebcdic.h => ../include/openssl/ebcdic.h >> symhacks.h => ../include/openssl/symhacks.h >> ossl_typ.h => ../include/openssl/ossl_typ.h >> constant_time_test.c => ../test/constant_time_test.c >> making links in crypto/objects... >> make[2]: Entering directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/objects' >> objects.h => ../../include/openssl/objects.h >> obj_mac.h => ../../include/openssl/obj_mac.h >> make[2]: Leaving directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/objects' >> making links in crypto/md4... >> make[2]: Entering directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/md4' >> md4.h => ../../include/openssl/md4.h >> md4test.c => ../../test/md4test.c >> md4.c => ../../apps/md4.c >> make[2]: Leaving directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/md4' >> making links in crypto/md5... >> make[2]: Entering directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/md5' >> md5.h => ../../include/openssl/md5.h >> md5test.c => ../../test/md5test.c >> make[2]: Leaving directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/md5' >> making links in crypto/sha... >> make[2]: Entering directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/sha' >> sha.h => ../../include/openssl/sha.h >> shatest.c => ../../test/shatest.c >> sha1test.c => ../../test/sha1test.c >> sha256t.c => ../../test/sha256t.c >> sha512t.c => ../../test/sha512t.c >> make[2]: Leaving directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/sha' >> making links in crypto/mdc2... >> make[2]: Entering directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/mdc2' >> mdc2.h => ../../include/openssl/mdc2.h >> mdc2test.c => ../../test/mdc2test.c >> make[2]: Leaving directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/mdc2' >> making links in crypto/hmac... >> make[2]: Entering directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/hmac' >> make[2]: *** No rule to make target 'links'. Stop. >> make[2]: Leaving directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto/hmac' >> Makefile:95: recipe for target 'links' failed >> make[1]: *** [links] Error 1 >> make[1]: Leaving directory '/home/pi/instamsg-c/third_par >> ty/openssl/crypto' >> Makefile:433: recipe for target 'links' failed >> make: *** [links] Error 1 >> ######################################################################### >> >> >> What am I missing? >> >> Will be grateful for pointers. >> >> >> >> Thanks and Regards, >> Ajay >> > > > > -- > Regards, > Ajay > -- Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Sun Feb 12 20:09:14 2017 From: kgoldman at us.ibm.com (Ken Goldman) Date: Sun, 12 Feb 2017 15:09:14 -0500 Subject: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi In-Reply-To: References: Message-ID: It is definitely possible, because we run openssl on the Pi. We did not, however, compile it ourselves. We install from a Pi repository. On 2/12/2017 8:13 AM, Ajay Garg wrote: > Any ideas please? > Is compiling openssl even possible on Raspberry-Pi? From noloader at gmail.com Mon Feb 13 00:56:44 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 12 Feb 2017 19:56:44 -0500 Subject: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi In-Reply-To: References: Message-ID: On Sun, Feb 12, 2017 at 8:13 AM, Ajay Garg wrote: > Any ideas please? > Is compiling openssl even possible on Raspberry-Pi? > Try 'config' rather than 'Configure'. It looks like it does the job. I'm not sure why the same triplet produces different results. Maybe you need to perform a 'make dclean' to clean former artifacts? $ git clone https://github.com/openssl/openssl ... $ cd openssl ... $ git checkout OpenSSL_1_0_2d Checking out files: 100% (14097/14097), done. Note: checking out 'OpenSSL_1_0_2d'. ... $ ./config Operating system: armv7l-whatever-linux2 Configuring for linux-armv4 Configuring for linux-armv4 no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [default] ... created directory `include/openssl' e_os2.h => include/openssl/e_os2.h making links in crypto... make[1]: Entering directory '/home/jwalton/openssl/crypto' crypto.h => ../include/openssl/crypto.h opensslv.h => ../include/openssl/opensslv.h opensslconf.h => ../include/openssl/opensslconf.h ebcdic.h => ../include/openssl/ebcdic.h symhacks.h => ../include/openssl/symhacks.h ossl_typ.h => ../include/openssl/ossl_typ.h constant_time_test.c => ../test/constant_time_test.c ... generating dummy tests (if needed)... make[1]: Entering directory '/home/jwalton/openssl/test' md2test.c => dummytest.c rc5test.c => dummytest.c jpaketest.c => dummytest.c make[1]: Leaving directory '/home/jwalton/openssl/test' Configured for linux-armv4. From devang.kubavat at in.abb.com Mon Feb 13 06:24:00 2017 From: devang.kubavat at in.abb.com (Devang Kubavat) Date: Mon, 13 Feb 2017 06:24:00 +0000 Subject: [openssl-users] Resume the session with new session keys Message-ID: Hi, There are two method to resume the session, 1.) Session ID, 2.) Session Ticket Out of these two methods, which method is useful to resume session with new session keys ? Is there any way to resume the session with new session keys ? Can anyone please help me ? Currently I am using the Ticket based session resumption and I can see that same master secret I get during SSL_get1_session even if session is resumed! Best Regards, Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Mon Feb 13 08:52:42 2017 From: openssl at openssl.org (OpenSSL) Date: Mon, 13 Feb 2017 08:52:42 +0000 (GMT) Subject: [openssl-users] Forthcoming OpenSSL release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL release =========================== The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.0e This release will be made available on 16th February 2017 between 1200-1600 UTC, and will include a fix for a security defect classified as severity "High". This issue does not affect OpenSSL versions prior to 1.1.0. Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJYoXCaAAoJEAEKUEB8TIy92GwH+gMIr6v8IQE04/aHWlp+ilep RIPM3x+NAQCkBTSZDhYPRIfJPnbEfGY1hi6Og28SQwHyfClL8Kyg0rkcgEJa9Q1A evhXesZD6xwWiPbqS4yu/iAnjapCPDuNQOeH8toRBs97N4bZ5/SLN6a5UUQg3lQ6 4t3zHJMK3RDRl6O39xmU84qpP7iumGW8Br/0XD2DfPvF0hAJVO+IfvTHK1WEFZg3 j1bYFUEP3lFWnXQDN7h4e9dOKRioSADdl/Tj+Ibh51OBYwaE2xjqqsOs4VAjbG8x V17okImTVhXhKSEOw3wsNirjW/+ui6fDIjszUGTcmNSp+MLXvUB21+8OXaVTDQs= =DVlI -----END PGP SIGNATURE----- From khurramashraf_786 at hotmail.com Mon Feb 13 10:57:27 2017 From: khurramashraf_786 at hotmail.com (khurram ashraf) Date: Mon, 13 Feb 2017 10:57:27 +0000 Subject: [openssl-users] RSA engine is not using the functions mentioned in struct Message-ID: I am new to making engines in openssl. Basically I want to implement an OpenSSL RSA engine that uses the functions I mentioned while encrypting and decrypting. My engine compiles and loads but it seems that it is not using the functions I want it to use for encryption and decryption. #include #include #include #include #include #include #include #include #include static int eng_rsa_pub_enc (int flen, const unsigned char *from, unsigned char *to, RSA * rsa, int padding) { printf ("Engine is encrypting using pub key \n"); RSA_public_encrypt (flen, from, to, rsa, RSA_PKCS1_PADDING); } static int eng_rsa_pub_dec (int flen, const unsigned char *from, unsigned char *to, RSA * rsa, int padding) { printf ("Engine is decrypting using pub key \n"); RSA_public_decrypt (flen, from, to, rsa, RSA_PKCS1_PADDING); } static int eng_rsa_priv_enc (int flen, const unsigned char *from, unsigned char *to, RSA * rsa, int padding __attribute__ ((unused))) { printf ("Engine is encrypting using priv key \n"); RSA_private_encrypt (flen, from, to, rsa, RSA_PKCS1_PADDING); } static int eng_rsa_priv_dec (int flen, const unsigned char *from, unsigned char *to, RSA * rsa, int padding __attribute__ ((unused))) { printf ("Engine is decrypting using priv key \n"); RSA_private_decrypt (flen, from, to, rsa, RSA_PKCS1_PADDING); } /* Constants used when creating the ENGINE */ static const char *engine_rsa_id = "rsa-engine 1"; static const char *engine_rsa_name = "engine for testing 1"; static RSA_METHOD struct_rsa = { "RSA engine for demo", eng_rsa_pub_enc, eng_rsa_pub_dec, eng_rsa_priv_enc, eng_rsa_priv_dec, NULL, NULL, NULL, NULL, RSA_FLAG_CACHE_PUBLIC | RSA_FLAG_CACHE_PRIVATE, NULL, NULL, NULL }; static int bind (ENGINE * e, const char *id) { printf ("%s\n", id); if (!ENGINE_set_id (e, engine_rsa_id) || !ENGINE_set_name (e, engine_rsa_name) || !ENGINE_set_RSA (e, &struct_rsa)) return 0; return 1; } IMPLEMENT_DYNAMIC_BIND_FN (bind) IMPLEMENT_DYNAMIC_CHECK_FN () I am compiling the code using following command. gcc -fPIC -c rsa-engine.c gcc -shared -o librsa_engine.so -lcrypto rsa-engine.o openssl engine -t -c rsa_engine Here the engine loads but when i try to encrypt a text file by using following command openssl pkeyutl -encrypt -in message.txt -pubin -inkey pubkey-B.pem -engine rsa_engine -out cipher.bin openssl pkeyutl -decrypt -in cipher.bin -inkey privkey-B.pem -engine rsa_engine -out rec.txt It seems that it is not using the functions which I defined in the struct_rsa. It is also not giving the output from the printf in the function. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Feb 13 11:15:29 2017 From: levitte at openssl.org (Richard Levitte) Date: Mon, 13 Feb 2017 12:15:29 +0100 (CET) Subject: [openssl-users] RSA engine is not using the functions mentioned in struct In-Reply-To: References: Message-ID: <20170213.121529.1947332410456236719.levitte@openssl.org> In message on Mon, 13 Feb 2017 10:57:27 +0000, khurram ashraf said: khurramashraf_786> Here the engine loads but when i try to encrypt a text file by using khurramashraf_786> following command khurramashraf_786> khurramashraf_786> openssl pkeyutl -encrypt -in message.txt -pubin -inkey pubkey-B.pem -engine rsa_engine -out cipher.bin khurramashraf_786> openssl pkeyutl -decrypt -in cipher.bin -inkey privkey-B.pem -engine rsa_engine -out rec.txt khurramashraf_786> khurramashraf_786> It seems that it is not using the functions which I defined in the khurramashraf_786> struct_rsa. It is also not giving the output from the printf in the khurramashraf_786> function. You need to tell it where to find the engine as well. libcrypto looks in the standard system places (typically /usr/lib or so) and the path given by the environment variable OPENSSL_ENGINES. Try these lines and see if that makes a difference: OPENSSL_ENGINES=. export OPENSSL_ENGINES openssl pkeyutl -encrypt -in message.txt -pubin -inkey pubkey-B.pem -engine rsa_engine -out cipher.bin openssl pkeyutl -decrypt -in cipher.bin -inkey privkey-B.pem -engine rsa_engine -out rec.txt Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From khurramashraf_786 at hotmail.com Mon Feb 13 11:56:13 2017 From: khurramashraf_786 at hotmail.com (khurram ashraf) Date: Mon, 13 Feb 2017 11:56:13 +0000 Subject: [openssl-users] RSA engine is not using the functions mentioned in struct In-Reply-To: <20170213.121529.1947332410456236719.levitte@openssl.org> References: , <20170213.121529.1947332410456236719.levitte@openssl.org> Message-ID: Respected Mr. Levitte, I have created the symlink to /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/librsa_engine.so. During encryption and decryption it mentions that "engine "rsa-engine 1" set", but it doesnot use the function in the struct and also doesnot output the printf. Furthermore, I also tried the method you recomended but still no result. Best Regards. Khurram ________________________________ From: openssl-users on behalf of Richard Levitte Sent: Monday, February 13, 2017 11:15 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] RSA engine is not using the functions mentioned in struct In message on Mon, 13 Feb 2017 10:57:27 +0000, khurram ashraf said: khurramashraf_786> Here the engine loads but when i try to encrypt a text file by using khurramashraf_786> following command khurramashraf_786> khurramashraf_786> openssl pkeyutl -encrypt -in message.txt -pubin -inkey pubkey-B.pem -engine rsa_engine -out cipher.bin khurramashraf_786> openssl pkeyutl -decrypt -in cipher.bin -inkey privkey-B.pem -engine rsa_engine -out rec.txt khurramashraf_786> khurramashraf_786> It seems that it is not using the functions which I defined in the khurramashraf_786> struct_rsa. It is also not giving the output from the printf in the khurramashraf_786> function. You need to tell it where to find the engine as well. libcrypto looks in the standard system places (typically /usr/lib or so) and the path given by the environment variable OPENSSL_ENGINES. Try these lines and see if that makes a difference: OPENSSL_ENGINES=. export OPENSSL_ENGINES openssl pkeyutl -encrypt -in message.txt -pubin -inkey pubkey-B.pem -engine rsa_engine -out cipher.bin openssl pkeyutl -decrypt -in cipher.bin -inkey privkey-B.pem -engine rsa_engine -out rec.txt Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users openssl-users Info Page mta.openssl.org This mailing list is for discussion among those using the OpenSSL software. To see the collection of prior postings to the list, visit the openssl-users Archives -------------- next part -------------- An HTML attachment was scrubbed... URL: From harakiri_23 at yahoo.com Mon Feb 13 12:40:20 2017 From: harakiri_23 at yahoo.com (Harakiri) Date: Mon, 13 Feb 2017 12:40:20 +0000 (UTC) Subject: [openssl-users] Using RSASSA-PSS in command line smime / cms utility References: <359345130.3282354.1486989620281.ref@mail.yahoo.com> Message-ID: <359345130.3282354.1486989620281@mail.yahoo.com> Can i set the padding?RSASSA-PSS or alg?ECDSA via command line when using openssl smime or openssl cms command? I can't find an option for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From murugesh.pitchaiah at gmail.com Mon Feb 13 13:58:12 2017 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Mon, 13 Feb 2017 19:28:12 +0530 Subject: [openssl-users] Fwd: Makefile.org in openSSL 1.1.0d In-Reply-To: References: Message-ID: Team, I downloaded the openSSL 1.1.0d now and was trying to use that. Previously I was using openSSL 1.0.2.h. I do not see the 'Makefile.org' in the new 1.1.0d. In my application I was using this file. Now as it is not present in 1.1.0d, could not complete the upgrade. Can someone explain why 'Makefile.org' is removed now and how to tackle it ? Thanks, Murugesh P. From rsalz at akamai.com Mon Feb 13 15:40:14 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Feb 2017 15:40:14 +0000 Subject: [openssl-users] Fwd: Makefile.org in openSSL 1.1.0d In-Reply-To: References: Message-ID: > Can someone explain why 'Makefile.org' is removed now and how to tackle it > ? The whole build system changed; there is no Makefile.org any more. What were you trying to do? From amajumdar at splunk.com Mon Feb 13 20:36:19 2017 From: amajumdar at splunk.com (Anamitra Dutta Majumdar) Date: Mon, 13 Feb 2017 20:36:19 +0000 Subject: [openssl-users] OpenSSL behavior for NULL characters Message-ID: I am trying to figure out what is the default OpenSSL server side behavior when we send the following command openssl s_client -connect localhost:8089 < /dev/zero 2>&1 What is the expected/default behavior of a TLS server. Should it close the connection , or continue to accept the NULL characters. Anamitra Dutta Majumdar Product Security Architect Office: 4152663903 Email: amajumdar at splunk.com Splunk Inc. San Francisco | Cupertino | London | Hong Kong | Washington D.C. | Seattle | Plano | Singapore | Munich | Tokyo | Shanghai -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Feb 13 20:53:05 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Feb 2017 20:53:05 +0000 Subject: [openssl-users] OpenSSL behavior for NULL characters In-Reply-To: References: Message-ID: What?s the serer on the other side? If it?s a web server, then \0 characters are generally illegal. If it?s s_server, then it, too, really wants ASCII lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amajumdar at splunk.com Mon Feb 13 21:09:10 2017 From: amajumdar at splunk.com (Anamitra Dutta Majumdar) Date: Mon, 13 Feb 2017 21:09:10 +0000 Subject: [openssl-users] OpenSSL behavior for NULL characters Message-ID: It is a home grown HTTPS server. Anamitra Dutta Majumdar Product Security Architect Office: 4152663903 Email: amajumdar at splunk.com Splunk Inc. San Francisco | Cupertino | London | Hong Kong | Washington D.C. | Seattle | Plano | Singapore | Munich | Tokyo | Shanghai From: openssl-users on behalf of "Salz, Rich" Reply-To: "openssl-users at openssl.org" Date: Monday, February 13, 2017 at 12:53 PM To: "openssl-users at openssl.org" Subject: Re: [openssl-users] OpenSSL behavior for NULL characters What?s the serer on the other side? If it?s a web server, then \0 characters are generally illegal. If it?s s_server, then it, too, really wants ASCII lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Feb 13 21:40:39 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Feb 2017 16:40:39 -0500 Subject: [openssl-users] OpenSSL behavior for NULL characters In-Reply-To: References: Message-ID: <2E0824BB-3D09-4024-8873-03F8A279538B@dukhovni.org> > On Feb 13, 2017, at 3:53 PM, Salz, Rich wrote: > > What?s the serer on the other side? If it?s a web server, then \0 characters are generally illegal. If it?s s_server, then it, too, really wants ASCII lines. For binary-clean input use the "-nocommads" option to s_client. The remaining behaviour is then up to the server, though on EBCDIC systems, the input is still assumed to be textual and ASCII conversion will be attempted. The s_client(1) command is not "stunnel", it is a diagnostic tool, not a proxy. -- Viktor. From rsalz at akamai.com Tue Feb 14 00:41:24 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Feb 2017 00:41:24 +0000 Subject: [openssl-users] OpenSSL behavior for NULL characters In-Reply-To: References: Message-ID: <8d0d983f0d2640ab9327910aeb266d9f@usma1ex-dag1mb3.msg.corp.akamai.com> > It is a home grown HTTPS server. Well, then what does your server do? To be very very clear: TLS is a *send the bytes* protocol. It knows nothing about EBCDIC, ASCII, text, etc. From karl at denninger.net Tue Feb 14 04:28:51 2017 From: karl at denninger.net (Karl Denninger) Date: Mon, 13 Feb 2017 22:28:51 -0600 Subject: [openssl-users] OpenSSL behavior for NULL characters In-Reply-To: <8d0d983f0d2640ab9327910aeb266d9f@usma1ex-dag1mb3.msg.corp.akamai.com> References: <8d0d983f0d2640ab9327910aeb266d9f@usma1ex-dag1mb3.msg.corp.akamai.com> Message-ID: On 2/13/2017 18:41, Salz, Rich wrote: >> It is a home grown HTTPS server. > Well, then what does your server do? > > To be very very clear: TLS is a *send the bytes* protocol. It knows nothing about EBCDIC, ASCII, text, etc. To back up what Rich has said I pass a LOT of data, including HTTPS and binary protocols between different machines (which may contain any particular set of bytes in a packet format) using OpenSSL as the encryption method for said transport and I've had no issues whatsoever with whatever I stuff in the pipe coming out the other end unmolested. Do be aware of the semantics and exceptions (which you must handle -- or else) described in the documentation however -- especially for non-blocking sockets. Due to the potential for renegotiations and similar failing to pay attention to those can result in some pretty interesting "surprises". -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2993 bytes Desc: S/MIME Cryptographic Signature URL: From murugesh.pitchaiah at gmail.com Tue Feb 14 06:51:05 2017 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Tue, 14 Feb 2017 12:21:05 +0530 Subject: [openssl-users] Fwd: Makefile.org in openSSL 1.1.0d In-Reply-To: References: Message-ID: Thank you Rich. I was using 1.0.2.h earlier. It was using Makefile.org and then Configure script was run to generate the Makefile. The template available in Makefile.org was used to prepare the Makefile. Can you please share if any thread, details on new build system, how to use that? Thanks, Murugesh P. On 2/13/17, Salz, Rich wrote: > >> Can someone explain why 'Makefile.org' is removed now and how to tackle >> it >> ? > > The whole build system changed; there is no Makefile.org any more. What > were you trying to do? > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From matt at openssl.org Tue Feb 14 09:30:31 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 14 Feb 2017 09:30:31 +0000 Subject: [openssl-users] OpenSSL Project Bylaws Message-ID: <6a9d61ca-923a-e4ce-f91b-421a77f83f97@openssl.org> I am pleased to be able to announce the publication of our new Project Bylaws. I have written a short blog post about what we are hoping to achieve and some of the thinking that went into these here: https://www.openssl.org/blog/blog/2017/02/13/bylaws/ The bylaws themselves are available here: https://www.openssl.org/policies/bylaws.html The Project Bylaws describe how the OpenSSL Project operates, what the different project roles are and how decisions are made. Incidentally these project bylaws should not be confused with the OpenSSL Software Foundation (OSF) Bylaws which were also recently published and describe how that legal entity operates. Matt From rsalz at akamai.com Tue Feb 14 12:47:20 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 14 Feb 2017 12:47:20 +0000 Subject: [openssl-users] Fwd: Makefile.org in openSSL 1.1.0d In-Reply-To: References: Message-ID: > Can you please share if any thread, details on new build system, how to use > that? Look at the README file. From openssl at openssl.org Thu Feb 16 12:18:56 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 16 Feb 2017 12:18:56 +0000 Subject: [openssl-users] OpenSSL version 1.1.0e published Message-ID: <20170216121856.GA3824@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.0e 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 1.1.0e of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0e is available for download via HTTP 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-1.1.0e.tar.gz Size: 5202247 SHA1 checksum: 8bbbaf36feffadd3cb9110912a8192e665ebca4b SHA256 checksum: 57be8618979d80c910728cfc99369bf97b2a1abd8f366ab6ebdee8975ad3874c The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0e.tar.gz openssl sha256 openssl-1.1.0e.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpZPjAAoJENnE0m0OYESRxHwIAIk2mWe90coHwxhyMNsGswJH sVhGvvLMza+TZWOg5PIu0KGuFQhrGaKFtRUfWCiXApkNhTN5yiUq550sz4wP/+Uv KwE/R2ra5JPdGUmGxHZ14N/E54BursW5EhWpmraqlNyKw0IOOj2amvAjvNiMikuj +2Xc+59rMFInba6w9D5S45jtVY7uSk75RX9P5wtxH/ZG5cYALiqS+V5cpZBWMif4 lvZyc6sTZ77xb6yBNVMpeNmm5vkZrqOvSFnCuk/SwPVyfyWfh3alzx2ryzu6JZj2 57IY1gKK8kFx2o/FAC2kq9Vs9EkJv4ApVqIc90jtMcYHgAtek3yi+GIJ5O6xlak= =mbOM -----END PGP SIGNATURE----- From openssl at openssl.org Thu Feb 16 12:21:24 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 16 Feb 2017 12:21:24 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20170216122124.GA4307@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [16 Feb 2017] ======================================== Encrypt-Then-Mac renegotiation crash (CVE-2017-3733) ==================================================== Severity: High During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake (or vice-versa) then this can cause OpenSSL to crash (dependent on ciphersuite). Both clients and servers are affected. OpenSSL 1.1.0 users should upgrade to 1.1.0e This issue does not affect OpenSSL version 1.0.2. This issue was reported to OpenSSL on 31st January 2017 by Joe Orton (Red Hat). The fix was developed by Matt Caswell of the OpenSSL development team. Note ==== Support for version 1.0.1 ended on 31st December 2016. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20170216.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpZMiAAoJENnE0m0OYESRMUgH/0UN9sxxgyDewSCMeTOYPauK cSPqyw1pndQI6Lu+d3OCdWd01rdLcm+HxlbW5FOUjGZ4G9YefE0+JcvKkIuLGIpQ 1EE0g/ZuBzWDh7/MkFWcmjHceYVXi5sKewtWcQvO9uePzlPhlSZoNIL1G66n1HAo of3ZlSL5BmibaTiz1WmpDG//0W1pgYP5OdvQ8/AVrJJf8pUnU9Oyubm1yCyK2RHi jfJWLbMx0ENgW4G1sW4s8bPaj4GwLjIrZl8ocqoyAHhghkBv/UXUhv6i62bKHmxW vfYwwiU0GlRVwPXzFKbbE3qqCRyDsq+XLAe/09NZZWA+BtscWuUhUpyEODBqzeY= =zqNG -----END PGP SIGNATURE----- From levitte at openssl.org Thu Feb 16 12:29:16 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 16 Feb 2017 13:29:16 +0100 (CET) Subject: [openssl-users] Fwd: Makefile.org in openSSL 1.1.0d In-Reply-To: References: Message-ID: <20170216.132916.2268632556946347021.levitte@openssl.org> With 1.1.0 and on, the build system is of the "configure first" model, unconditionally. You will get a working Makefile as a result, and will find more information in README and INSTALL. Cheers, Richard In message on Tue, 14 Feb 2017 12:21:05 +0530, murugesh pitchaiah said: murugesh.pitchaiah> Thank you Rich. murugesh.pitchaiah> murugesh.pitchaiah> I was using 1.0.2.h earlier. It was using Makefile.org and then murugesh.pitchaiah> Configure script was run to generate the Makefile. The template murugesh.pitchaiah> available in Makefile.org was used to prepare the Makefile. murugesh.pitchaiah> murugesh.pitchaiah> Can you please share if any thread, details on new build system, how murugesh.pitchaiah> to use that? murugesh.pitchaiah> murugesh.pitchaiah> Thanks, murugesh.pitchaiah> Murugesh P. murugesh.pitchaiah> murugesh.pitchaiah> On 2/13/17, Salz, Rich wrote: murugesh.pitchaiah> > murugesh.pitchaiah> >> Can someone explain why 'Makefile.org' is removed now and how to tackle murugesh.pitchaiah> >> it murugesh.pitchaiah> >> ? murugesh.pitchaiah> > murugesh.pitchaiah> > The whole build system changed; there is no Makefile.org any more. What murugesh.pitchaiah> > were you trying to do? murugesh.pitchaiah> > -- murugesh.pitchaiah> > openssl-users mailing list murugesh.pitchaiah> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users murugesh.pitchaiah> > murugesh.pitchaiah> From nounou.dadoun at avigilon.com Thu Feb 16 19:54:34 2017 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Thu, 16 Feb 2017 19:54:34 +0000 Subject: [openssl-users] Forthcoming OpenSSL release In-Reply-To: References: Message-ID: <8149AB08BCB1F54F92680ED6104891A0ECEEBB@mbx027-w1-ca-4.exch027.domain.local> Sorry I haven't been following the discussion on this vulnerability if there is one. The advisory says that " this can cause OpenSSL to crash (dependent on ciphersuite) "; is there any indication about which cipher suites are affected? So that we know whether we should upgrade now or catch the next one, thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of OpenSSL Sent: Monday, February 13, 2017 12:53 AM To: openssl-announce at openssl.org; openssl-users at openssl.org; openssl-dev at openssl.org Subject: [openssl-users] Forthcoming OpenSSL release -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL release =========================== The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.0e This release will be made available on 16th February 2017 between 1200-1600 UTC, and will include a fix for a security defect classified as severity "High". This issue does not affect OpenSSL versions prior to 1.1.0. Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJYoXCaAAoJEAEKUEB8TIy92GwH+gMIr6v8IQE04/aHWlp+ilep RIPM3x+NAQCkBTSZDhYPRIfJPnbEfGY1hi6Og28SQwHyfClL8Kyg0rkcgEJa9Q1A evhXesZD6xwWiPbqS4yu/iAnjapCPDuNQOeH8toRBs97N4bZ5/SLN6a5UUQg3lQ6 4t3zHJMK3RDRl6O39xmU84qpP7iumGW8Br/0XD2DfPvF0hAJVO+IfvTHK1WEFZg3 j1bYFUEP3lFWnXQDN7h4e9dOKRioSADdl/Tj+Ibh51OBYwaE2xjqqsOs4VAjbG8x V17okImTVhXhKSEOw3wsNirjW/+ui6fDIjszUGTcmNSp+MLXvUB21+8OXaVTDQs= =DVlI -----END PGP SIGNATURE----- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Thu Feb 16 23:11:02 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Feb 2017 23:11:02 +0000 Subject: [openssl-users] Forthcoming OpenSSL release In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0ECEEBB@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0ECEEBB@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <25722552-fae8-2a05-1db1-b61c4984acd0@openssl.org> On 16/02/17 19:54, Nounou Dadoun wrote: > Sorry I haven't been following the discussion on this vulnerability > if there is one. The advisory says that " this can cause OpenSSL to > crash (dependent on ciphersuite) "; is there any indication about > which cipher suites are affected? So that we know whether we should > upgrade now or catch the next one, thanks ... N A malicious client (say) could cause a server to crash if it has been configured to support at least one AEAD ciphersuite and at least one non-AEAD ciphersuite. Matt From philipp_subx at redfish-solutions.com Fri Feb 17 06:43:17 2017 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 16 Feb 2017 23:43:17 -0700 Subject: [openssl-users] Updating (re-issuing) self-signed cert with keyid, issuer, serial AKI Message-ID: <62DF940A-489E-4EA0-8092-379757590DBB@redfish-solutions.com> Hi. I have the following certificate (below) and I?m trying to generate a new self-signed cert from it, but when I do so the issuer+serial get dropped from it. Looking at the CSR that gets generated as an intermediate step, I?m not seeing that information there. What do I need to do to "copy through" the AKI into the request with -x509toreq? Also attaching the script I?m using. And yes, it?s a 1024-bit key? It?s probably worth scrapping the old key and generating a new one, but before I do that I want to solve the AKI issue... Thanks, -Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: example.crt Type: application/x-x509-ca-cert Size: 1017 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: renew-dummy-cert Type: application/octet-stream Size: 912 bytes Desc: not available URL: From guru at unixarea.de Fri Feb 17 07:46:42 2017 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 17 Feb 2017 08:46:42 +0100 Subject: [openssl-users] openssl client v1.1.0 can not connect: handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40 Message-ID: <20170217074642.GA2174@c720-r292778-amd64> Hello, We run a SSL client/server application, where the server is written in Java using jdk1.8.0_31 and the client is written in C. We prepare the update to OpenSSL 1.1.0 for the C client and are facing the problem, that not even the OpenSSL s_client can now connect to our server. It says: 4146546432:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40 More details below. server: written in Java, using jdk1.8.0_31 client: $ openssl version OpenSSL 1.0.2e-freebsd 3 Dec 2015 $ nohup openssl s_client -tls1_2 -connect 10.23.33.55:58076 quit $ cat nohup.out depth=0 C = de, ST = Germany, L = Munich, O = unixarea.de, OU = gTech, CN = Matthias Apitz verify error:num=18:self signed certificate verify return:1 depth=0 C = de, ST = Germany, L = Munich, O = unixarea.de, OU = gTech, CN = Matthias Apitz verify return:1 CONNECTED(00000004) --- Certificate chain 0 s:/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz i:/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz --- Server certificate -----BEGIN CERTIFICATE----- MIIDPDCCAvmgAwIBAgIEcrMKAzALBgcqhkjOOAQDBQAwbzELMAkGA1UEBhMCZGUx ... -----END CERTIFICATE----- subject=/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz issuer=/C=de/ST=Germany/L=Munich/O=unixarea.de/OU=gTech/CN=Matthias Apitz --- No client certificate CA names sent Peer signing digest: SHA1 Server Temp Key: DH, 1024 bits --- SSL handshake has read 1427 bytes and written 507 bytes --- New, TLSv1/SSLv3, Cipher is DHE-DSS-AES128-GCM-SHA256 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : DHE-DSS-AES128-GCM-SHA256 Session-ID: 58A69B4328BCDD246B3C2B1D7B600273AF8ACC16DE91EBB94980B1909D1D17C8 Session-ID-ctx: Master-Key: 78F0BA616EE9DBFF8BDF4A294DA70494979CBE9761185228A056C07DEC9EEBC8D126D14A27F1FDA55D4AA42DFB29E684 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1487313732 Timeout : 7200 (sec) Verify return code: 18 (self signed certificate) --- OK - message received closed client: $ /usr/local/sisis-pap/bin/openssl version OpenSSL 1.1.0d 26 Jan 2017 $ /usr/local/sisis-pap/bin/openssl s_client -connect 10.23.33.55:58076 CONNECTED(00000003) 4146546432:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1487313886 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 From matt at openssl.org Fri Feb 17 09:57:39 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 17 Feb 2017 09:57:39 +0000 Subject: [openssl-users] openssl client v1.1.0 can not connect: handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40 In-Reply-To: <20170217074642.GA2174@c720-r292778-amd64> References: <20170217074642.GA2174@c720-r292778-amd64> Message-ID: On 17/02/17 07:46, Matthias Apitz wrote: > New, TLSv1/SSLv3, Cipher is DHE-DSS-AES128-GCM-SHA256 Your server appears to be configured with a DSA certificate. OpenSSL 1.1.0 made changes to the default ciphersuites that get sent. See this CHANGES entry: *) Changes to the DEFAULT cipherlist: - Prefer (EC)DHE handshakes over plain RSA. - Prefer AEAD ciphers over legacy ciphers. - Prefer ECDSA over RSA when both certificates are available. - Prefer TLSv1.2 ciphers/PRF. - Remove DSS, SEED, IDEA, CAMELLIA, and AES-CCM from the default cipherlist. [Emilia K?sper] So OpenSSL 1.1.0 does not offer any DSS based ciphersuites by default any more. If your server only has a DSA certificate then this is going to fail. Matt From stm at pdflib.com Fri Feb 17 14:25:55 2017 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Fri, 17 Feb 2017 15:25:55 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? Message-ID: Hi, we use OpenSSL 1.0.2 together with PKCS#11 tokens by plugging methods into the RSA_METHOD structure that interface with the PKCS#11 token, and this works fine so far. However, for creating RSA signatures with PSS padding this strategy doesn't work anymore, because OpenSSL wants to directly encrypt with the private key in this case, which is not possible in PKCS#11. Therefore my idea is to override the function pkey_rsa_sign() and plug a wrapper around it into the EVP_PKEY_METHOD structure that is associated with the EVP_PKEY_CTX to handle this special situation. The header evp.h declares the following functions among others: EVP_PKEY_METHOD* EVP_PKEY_meth_new(int id, int flags); void EVP_PKEY_meth_copy(EVP_PKEY_METHOD *dst, const EVP_PKEY_METHOD *src); void EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *pmeth, int (*sign_init)(EVP_PKEY_CTX *ctx), int (*sign)(EVP_PKEY_CTX *ctx, unsigned char *sig, size_t *siglen, const unsigned char *tbs, size_t tbslen)); But I can't figure out how to use these functions to achieve what I want, because the following pieces seem to be missing: - Retrieve the EVP_PKEY_METHOD pointer from a EVP_PKEY_CTX pointer - Set the EVP_PKEY_METHOD pointer for a EVP_PKEY_CTX pointer - Retrieve the existing "sign_init" and "sign" function pointers from an initialized EVP_PKEY_METHOD pointer for being able to wrap them Is it possible to override methods in an EVP_PKEY_METHOD structure, or would it be necessary to implement a whole OpenSSL engine to do what I want? Thanks. -- Stephan From jb-openssl at wisemo.com Fri Feb 17 15:09:17 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 17 Feb 2017 16:09:17 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: References: Message-ID: <687ec6bc-0e04-9fa5-8e21-557ae0e56fc0@wisemo.com> On 17/02/2017 15:25, Stephan M?hlstrasser wrote: > Hi, > > we use OpenSSL 1.0.2 together with PKCS#11 tokens by plugging methods > into the RSA_METHOD structure that interface with the PKCS#11 token, > and this works fine so far. However, for creating RSA signatures with > PSS padding this strategy doesn't work anymore, because OpenSSL wants > to directly encrypt with the private key in this case, which is not > possible in PKCS#11. > I believe some PKCS#11 tokens can do this by using CKM_RSA_X_509 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 stm at pdflib.com Fri Feb 17 15:21:21 2017 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Fri, 17 Feb 2017 16:21:21 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: <687ec6bc-0e04-9fa5-8e21-557ae0e56fc0@wisemo.com> References: <687ec6bc-0e04-9fa5-8e21-557ae0e56fc0@wisemo.com> Message-ID: <70e6f260-6727-1029-74f4-36803940cce3@pdflib.com> Am 17.02.17 um 16:09 schrieb Jakob Bohm: > On 17/02/2017 15:25, Stephan M?hlstrasser wrote: >> Hi, >> >> we use OpenSSL 1.0.2 together with PKCS#11 tokens by plugging methods >> into the RSA_METHOD structure that interface with the PKCS#11 token, >> and this works fine so far. However, for creating RSA signatures with >> PSS padding this strategy doesn't work anymore, because OpenSSL wants >> to directly encrypt with the private key in this case, which is not >> possible in PKCS#11. >> > I believe some PKCS#11 tokens can do this by using CKM_RSA_X_509 How could that work? If I understand the PKCS#11 specification correctly it is not possible in principle to use private keys for encryption via the C_EncryptInit() and C_Encrypt() functions, for the following reasons: 1) Private keys are not allowed to have the CKA_ENCRYPT attribute (see "Table 30, Common Private Key Attributes" in the PKCS#11 specification, which does not list the CKA_ENCRYPT attribute). 2) For the C_EncryptInit() to succeed the key must have the attribute CKA_ENCRYPT=true. From the PKCS#11 documentation of C_EncryptInit(): "The CKA_ENCRYPT attribute of the encryption key, which indicates whether the key supports encryption, must be CK_TRUE." -- Stephan From guru at unixarea.de Fri Feb 17 16:29:46 2017 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 17 Feb 2017 17:29:46 +0100 Subject: [openssl-users] openssl client v1.1.0 can not connect: handshake failure:ssl/record/rec_layer_s3.c:1385:SSL alert number 40 In-Reply-To: References: <20170217074642.GA2174@c720-r292778-amd64> Message-ID: <20170217162946.GA3321@c720-r292778-amd64.oa.oclc.org> El d?a Friday, February 17, 2017 a las 09:57:39AM +0000, Matt Caswell escribi?: > > > On 17/02/17 07:46, Matthias Apitz wrote: > > New, TLSv1/SSLv3, Cipher is DHE-DSS-AES128-GCM-SHA256 > > Your server appears to be configured with a DSA certificate. > > OpenSSL 1.1.0 made changes to the default ciphersuites that get sent. > See this CHANGES entry: > > *) Changes to the DEFAULT cipherlist: > - Prefer (EC)DHE handshakes over plain RSA. > - Prefer AEAD ciphers over legacy ciphers. > - Prefer ECDSA over RSA when both certificates are available. > - Prefer TLSv1.2 ciphers/PRF. > - Remove DSS, SEED, IDEA, CAMELLIA, and AES-CCM from the > default cipherlist. > [Emilia K?sper] > > So OpenSSL 1.1.0 does not offer any DSS based ciphersuites by default > any more. If your server only has a DSA certificate then this is going > to fail. Thanks. I have aadded more ciphers using SSL_set_cipher_list(3) and all is fine now. matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 From russellbell at gmail.com Fri Feb 17 16:51:52 2017 From: russellbell at gmail.com (russellbell at gmail.com) Date: Fri, 17 Feb 2017 09:51:52 -0700 Subject: [openssl-users] (no subject) Message-ID: <201702171651.v1HGpqZp006690@randytool.net> >From russellbell at gmail.com Fri Feb 17 09:50:52 MST 2017 to: openssl-users-request at openssl.org subject: set digest set digest From jb-openssl at wisemo.com Fri Feb 17 17:43:19 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 17 Feb 2017 18:43:19 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: <70e6f260-6727-1029-74f4-36803940cce3@pdflib.com> References: <687ec6bc-0e04-9fa5-8e21-557ae0e56fc0@wisemo.com> <70e6f260-6727-1029-74f4-36803940cce3@pdflib.com> Message-ID: <1bda9342-34c7-1536-accb-84c6ae5f658b@wisemo.com> On 17/02/2017 16:21, Stephan M?hlstrasser wrote: > Am 17.02.17 um 16:09 schrieb Jakob Bohm: >> On 17/02/2017 15:25, Stephan M?hlstrasser wrote: >>> Hi, >>> >>> we use OpenSSL 1.0.2 together with PKCS#11 tokens by plugging methods >>> into the RSA_METHOD structure that interface with the PKCS#11 token, >>> and this works fine so far. However, for creating RSA signatures with >>> PSS padding this strategy doesn't work anymore, because OpenSSL wants >>> to directly encrypt with the private key in this case, which is not >>> possible in PKCS#11. >>> >> I believe some PKCS#11 tokens can do this by using CKM_RSA_X_509 > > How could that work? If I understand the PKCS#11 specification > correctly it is not possible in principle to use private keys for > encryption via the C_EncryptInit() and C_Encrypt() functions, for the > following reasons: > > 1) Private keys are not allowed to have the CKA_ENCRYPT attribute (see > "Table 30, Common Private Key Attributes" in the PKCS#11 > specification, which does not list the CKA_ENCRYPT attribute). > > 2) For the C_EncryptInit() to succeed the key must have the attribute > CKA_ENCRYPT=true. > > From the PKCS#11 documentation of C_EncryptInit(): > > "The CKA_ENCRYPT attribute of the encryption key, which indicates > whether the key supports encryption, must be CK_TRUE." > Some token keys on some tokens (think e-mail decryption private keys or TLS server private keys) intentionally support decryption of a wrapped symmetric key via PKCS#11 mechanisms such as the one from PKCS1v1.5 or OAEP. The precise set of such public key operations available is given by the set of "mechanisms" enumerated by the pkcs11 driver for the individual token. One of the defined mechanisms (the one confusingly named "X509") appears to actually be the raw RSA operation, thus allowing it to be repurposed to implement any RSA scheme (such as PSS, or SHA-256 signatures) that might be missing on the token iteself. But this obviously only works for those tokens that allow this, which varies by token model, token configuration and PKCS11-driver version. This obviously isn't possible for all tokens, and thus in general doesn't solve your original problem for those tokens that support PSS signatures natively, but not the raw RSA operation. But it can be helpful for those tokens that do support the raw RSA operation and expose this ability through their PKCS#11 drivers. 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 bsmith at progress.com Fri Feb 17 18:51:48 2017 From: bsmith at progress.com (Bill Smith) Date: Fri, 17 Feb 2017 18:51:48 +0000 Subject: [openssl-users] undefined symbol fabs in file test/ct_test.o in openssl 1.1.0e on solaris Message-ID: I pulled down 1.1.0e and tried to build it on Solaris 64. I ran into the following error: /tools/solaris/SunStudio12.2/bin/cc -xarch=v9 -mt -o test/ct_test test/ct_test.o test/testutil.o -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs Undefined first referenced symbol in file fabs test/ct_test.o ld: fatal: Symbol referencing errors. No output written to test/ct_test These diffs appear to fix the issue. Added -lm to ex_libs for Solaris. solaris64:117$ diff -c /scratch/bsmith/openssl/openssl-1.1.0e/Configurations/10-main.conf Configurations/10-main.conf *** /scratch/bsmith/openssl/openssl-1.1.0e/Configurations/10-main.conf Thu Feb 16 06:58:20 2017 --- Configurations/10-main.conf Fri Feb 17 11:06:45 2017 *************** *** 179,185 **** inherit_from => [ "BASE_unix" ], template => 1, cflags => "-DFILIO_H", ! ex_libs => add("-lresolv -lsocket -lnsl -ldl"), dso_scheme => "dlfcn", thread_scheme => "pthreads", shared_target => "solaris-shared", --- 179,185 ---- inherit_from => [ "BASE_unix" ], template => 1, cflags => "-DFILIO_H", ! ex_libs => add("-lresolv -lsocket -lnsl -ldl -lm"), dso_scheme => "dlfcn", thread_scheme => "pthreads", shared_target => "solaris-shared", solaris64:117$ From openssl-users at dukhovni.org Fri Feb 17 19:15:10 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 17 Feb 2017 14:15:10 -0500 Subject: [openssl-users] undefined symbol fabs in file test/ct_test.o in openssl 1.1.0e on solaris In-Reply-To: References: Message-ID: <1481BC8A-3E0C-4598-9556-0A83F78AC763@dukhovni.org> > On Feb 17, 2017, at 1:51 PM, Bill Smith wrote: > > I pulled down 1.1.0e and tried to build it on Solaris 64. I ran into the following error: > > > /tools/solaris/SunStudio12.2/bin/cc -xarch=v9 -mt -o test/ct_test test/ct_test.o test/testutil.o -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread > cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs > Undefined first referenced > symbol in file > fabs test/ct_test.o > ld: fatal: Symbol referencing errors. No output written to test/ct_test > > These diffs appear to fix the issue. Added -lm to ex_libs for Solaris. > > solaris64:117$ diff -c /scratch/bsmith/openssl/openssl-1.1.0e/Configurations/10-main.conf Configurations/10-main.conf > *** /scratch/bsmith/openssl/openssl-1.1.0e/Configurations/10-main.conf Thu Feb 16 06:58:20 2017 > --- Configurations/10-main.conf Fri Feb 17 11:06:45 2017 > *************** > *** 179,185 **** > inherit_from => [ "BASE_unix" ], > template => 1, > cflags => "-DFILIO_H", > ! ex_libs => add("-lresolv -lsocket -lnsl -ldl"), > dso_scheme => "dlfcn", > thread_scheme => "pthreads", > shared_target => "solaris-shared", > --- 179,185 ---- > inherit_from => [ "BASE_unix" ], > template => 1, > cflags => "-DFILIO_H", > ! ex_libs => add("-lresolv -lsocket -lnsl -ldl -lm"), > dso_scheme => "dlfcn", > thread_scheme => "pthreads", > shared_target => "solaris-shared", > solaris64:117$ I would avoid adding that library dependency to all the code just because a test program uses fabs(). It is better to just avoid fabs() in the test code, or add "-lm" for just that program (or perhaps just all the test programs). -- Viktor. From levitte at openssl.org Fri Feb 17 19:57:00 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 17 Feb 2017 20:57:00 +0100 (CET) Subject: [openssl-users] undefined symbol fabs in file test/ct_test.o in openssl 1.1.0e on solaris In-Reply-To: <1481BC8A-3E0C-4598-9556-0A83F78AC763@dukhovni.org> References: <1481BC8A-3E0C-4598-9556-0A83F78AC763@dukhovni.org> Message-ID: <20170217.205700.2212918361585080843.levitte@openssl.org> In message <1481BC8A-3E0C-4598-9556-0A83F78AC763 at dukhovni.org> on Fri, 17 Feb 2017 14:15:10 -0500, Viktor Dukhovni said: openssl-users> openssl-users> > On Feb 17, 2017, at 1:51 PM, Bill Smith wrote: openssl-users> > openssl-users> > I pulled down 1.1.0e and tried to build it on Solaris 64. I ran into the following error: openssl-users> > openssl-users> > openssl-users> > /tools/solaris/SunStudio12.2/bin/cc -xarch=v9 -mt -o test/ct_test test/ct_test.o test/testutil.o -L. -lcrypto -lresolv -lsocket -lnsl -ldl -lpthread openssl-users> > cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs openssl-users> > Undefined first referenced openssl-users> > symbol in file openssl-users> > fabs test/ct_test.o openssl-users> > ld: fatal: Symbol referencing errors. No output written to test/ct_test openssl-users> > openssl-users> > These diffs appear to fix the issue. Added -lm to ex_libs for Solaris. openssl-users> > openssl-users> > solaris64:117$ diff -c /scratch/bsmith/openssl/openssl-1.1.0e/Configurations/10-main.conf Configurations/10-main.conf openssl-users> > *** /scratch/bsmith/openssl/openssl-1.1.0e/Configurations/10-main.conf Thu Feb 16 06:58:20 2017 openssl-users> > --- Configurations/10-main.conf Fri Feb 17 11:06:45 2017 openssl-users> > *************** openssl-users> > *** 179,185 **** openssl-users> > inherit_from => [ "BASE_unix" ], openssl-users> > template => 1, openssl-users> > cflags => "-DFILIO_H", openssl-users> > ! ex_libs => add("-lresolv -lsocket -lnsl -ldl"), openssl-users> > dso_scheme => "dlfcn", openssl-users> > thread_scheme => "pthreads", openssl-users> > shared_target => "solaris-shared", openssl-users> > --- 179,185 ---- openssl-users> > inherit_from => [ "BASE_unix" ], openssl-users> > template => 1, openssl-users> > cflags => "-DFILIO_H", openssl-users> > ! ex_libs => add("-lresolv -lsocket -lnsl -ldl -lm"), openssl-users> > dso_scheme => "dlfcn", openssl-users> > thread_scheme => "pthreads", openssl-users> > shared_target => "solaris-shared", openssl-users> > solaris64:117$ openssl-users> openssl-users> I would avoid adding that library dependency to all the code just because openssl-users> a test program uses fabs(). It is better to just avoid fabs() in the test openssl-users> code, or add "-lm" for just that program (or perhaps just all the test openssl-users> programs). This would mean adding that in test/build.info. Unfortunately, libm is Unix and the build.info are meant to be platform agnostic, so it's kind of a no can do. I'll have a thought on this kind of thing. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From Michael.Wojcik at microfocus.com Fri Feb 17 22:03:58 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 17 Feb 2017 22:03:58 +0000 Subject: [openssl-users] undefined symbol fabs in file test/ct_test.o in openssl 1.1.0e on solaris In-Reply-To: <20170217.205700.2212918361585080843.levitte@openssl.org> References: <1481BC8A-3E0C-4598-9556-0A83F78AC763@dukhovni.org> <20170217.205700.2212918361585080843.levitte@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Richard Levitte > Sent: Friday, February 17, 2017 14:57 > > In message <1481BC8A-3E0C-4598-9556-0A83F78AC763 at dukhovni.org> on > Fri, 17 Feb 2017 14:15:10 -0500, Viktor Dukhovni users at dukhovni.org> said: > > openssl-users> I would avoid adding that library dependency to all the code just because > openssl-users> a test program uses fabs(). It is better to just avoid fabs() in the test > openssl-users> code, or add "-lm" for just that program (or perhaps just all the test > openssl-users> programs). > > This would mean adding that in test/build.info. Unfortunately, libm > is Unix and the build.info are meant to be platform agnostic, so it's > kind of a no can do. I'll have a thought on this kind of thing. For the record, we've always just changed the Solaris configuration we use in Configure to add -lm. While I understand Viktor's reservations about adding a library just for a test program, pretty much all other UNIX platforms long ago simply put all the libm functionality into libc and made libm a vestigial empty library. Adding -lm for Solaris just makes Solaris behave like other UNIX platforms. The separation of the math routines such as fabs(3m) into libm is a historical accident anyway; it was done in (relatively) early UNIX implementations because they didn't have dynamic linking, and disk and memory were constrained resources. In any event, programs that don't actually use any of the 3m routines won't resolve any symbols from libm, and so shouldn't end up loading it even if -lm is specified on the command line. But I have no strong opinion on the matter. If the team decide it'd be better not to use -lm when linking all the Solaris executables, that's not an issue for me. We customize Configure on most platforms for various reasons; one customization more or less doesn't make much difference. I admit I'm a bit curious what other people do when building on Solaris, though. Michael Wojcik Distinguished Engineer, Micro Focus From ajaygargnsit at gmail.com Sun Feb 19 14:08:39 2017 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Sun, 19 Feb 2017 19:38:39 +0530 Subject: [openssl-users] Issues while "configuring before compiling" OpenSSL on Raspberry-Pi In-Reply-To: References: Message-ID: Thanks guys.. that worked. Seems I screwed up something while copying the 1.0.2_d version into our framework. Cloning again from scratch worked in first attempt. Thanks a ton again for your valuable time !! Thanks and Regards, Ajay On Mon, Feb 13, 2017 at 6:26 AM, Jeffrey Walton wrote: > On Sun, Feb 12, 2017 at 8:13 AM, Ajay Garg wrote: > > Any ideas please? > > Is compiling openssl even possible on Raspberry-Pi? > > > > Try 'config' rather than 'Configure'. It looks like it does the job. > I'm not sure why the same triplet produces different results. Maybe > you need to perform a 'make dclean' to clean former artifacts? > > $ git clone https://github.com/openssl/openssl > ... > $ cd openssl > ... > > $ git checkout OpenSSL_1_0_2d > Checking out files: 100% (14097/14097), done. > Note: checking out 'OpenSSL_1_0_2d'. > ... > > $ ./config > Operating system: armv7l-whatever-linux2 > Configuring for linux-armv4 > Configuring for linux-armv4 > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip > dir) > no-gmp [default] OPENSSL_NO_GMP (skip dir) > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > no-shared [default] > no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) > no-store [experimental] OPENSSL_NO_STORE (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > ... > > created directory `include/openssl' > e_os2.h => include/openssl/e_os2.h > making links in crypto... > make[1]: Entering directory '/home/jwalton/openssl/crypto' > crypto.h => ../include/openssl/crypto.h > opensslv.h => ../include/openssl/opensslv.h > opensslconf.h => ../include/openssl/opensslconf.h > ebcdic.h => ../include/openssl/ebcdic.h > symhacks.h => ../include/openssl/symhacks.h > ossl_typ.h => ../include/openssl/ossl_typ.h > constant_time_test.c => ../test/constant_time_test.c > ... > > generating dummy tests (if needed)... > make[1]: Entering directory '/home/jwalton/openssl/test' > md2test.c => dummytest.c > rc5test.c => dummytest.c > jpaketest.c => dummytest.c > make[1]: Leaving directory '/home/jwalton/openssl/test' > > Configured for linux-armv4. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From stm at pdflib.com Mon Feb 20 07:40:22 2017 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Mon, 20 Feb 2017 08:40:22 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: <1bda9342-34c7-1536-accb-84c6ae5f658b@wisemo.com> References: <687ec6bc-0e04-9fa5-8e21-557ae0e56fc0@wisemo.com> <70e6f260-6727-1029-74f4-36803940cce3@pdflib.com> <1bda9342-34c7-1536-accb-84c6ae5f658b@wisemo.com> Message-ID: <23079783-ce67-a60c-8061-87179dafc214@pdflib.com> Jakob, Am 17.02.17 um 18:43 schrieb Jakob Bohm: >> ... > Some token keys on some tokens (think e-mail decryption private keys or > TLS server private keys) intentionally support decryption of a wrapped > symmetric key via PKCS#11 mechanisms such as the one from PKCS1v1.5 or > OAEP. > > The precise set of such public key operations available is given by the set > of "mechanisms" enumerated by the pkcs11 driver for the individual token. > > One of the defined mechanisms (the one confusingly named "X509") appears to > actually be the raw RSA operation, thus allowing it to be repurposed to > implement any RSA scheme (such as PSS, or SHA-256 signatures) that might > be missing on the token iteself. But this obviously only works for those > tokens that allow this, which varies by token model, token configuration > and PKCS11-driver version. > > This obviously isn't possible for all tokens, and thus in general doesn't > solve your original problem for those tokens that support PSS signatures > natively, but not the raw RSA operation. But it can be helpful for those > tokens that do support the raw RSA operation and expose this ability > through > their PKCS#11 drivers. thank you for the explanation about the CKM_RSA_X_509 mechanism. I was not aware of its meaning, and I will study it in more detail. The tokens that I have access to do provide this mechanism, so I can experiment with it. Regarding my original question, does anybody have comments whether and if so how it is possible to override methods in a EVP_PKEY_METHOD structure? Thank you. -- Stephan From rschm2 at unh.newhaven.edu Tue Feb 21 05:38:49 2017 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Tue, 21 Feb 2017 05:38:49 +0000 Subject: [openssl-users] Integrate EVP Cipher into OpenSSL Speed Sest Message-ID: Hello, I successfully managed to integrate an encryption cipher into the EVP and has been tested to work and now I'd like to get some speed tests of the cipher using openssl's integrated speed test via the command line with the "-evp" flag. What I've done so far to try and integrate it into openssl's speed test.... 1) Confirmed EVP_mycipher() works 2) Noticed ./apps/speed.c was calling: case OPT_EVP: evp_cipher = EVP_get_cipherbyname(opt_arg()); 3) Then modified ./crypto/objects/objects.txt to include the necessary defines # Mycipher !Alias myc 1 !Cname myc myc 1 : MYCIPHER : mycipher 4) Ran a make update then make and saw all necessary defines were generated However, the speed test cannot find my cipher because EVP_get_cipherbyname() returns NULL. But... in a separate test.c file when I use EVP_get_cipherbynid() using mycipher's NID value it finds it. Any idea why the EVP is able to find my cipher via NID but not by name? Any help is much appreciated! Rob Schmicker -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Tue Feb 21 08:53:39 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 21 Feb 2017 14:23:39 +0530 Subject: [openssl-users] DTLS for SCTP connections Message-ID: Hi, We have a client, server applications that is using SCTP as a transport protocol. We have to secure the connections using DTLS. I am using openssl version 1.0.2 which supports DTLS. But the problem i am facing is usage of DTLS SCTP related API's. Openssl documentation does not clearly explain all the SCTP related API's and usage sequence. I have tried going though internet and found most of the sites redirect to one link for SCTP DTLS sample code. But this link is not working. http://sctp.fh-muenster.de/dtls-samples.html If any of you has an sample code of DTLS adaptation for SCTP. It would immensely help me for my work. Looking forward to your valuable inputs. Thanks, Mahesh G S -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Tuexen at lurchi.franken.de Tue Feb 21 08:58:32 2017 From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen) Date: Tue, 21 Feb 2017 09:58:32 +0100 Subject: [openssl-users] DTLS for SCTP connections In-Reply-To: References: Message-ID: > On 21 Feb 2017, at 09:53, mahesh gs wrote: > > Hi, > > We have a client, server applications that is using SCTP as a transport protocol. We have to secure the connections using DTLS. I am using openssl version 1.0.2 which supports DTLS. But the problem i am facing is usage of DTLS SCTP related API's. Openssl documentation does not clearly explain all the SCTP related API's and usage sequence. > > I have tried going though internet and found most of the sites redirect to one link for SCTP DTLS sample code. But this link is not working. > > http://sctp.fh-muenster.de/dtls-samples.html Try http://web.archive.org/web/20150617012520/http://sctp.fh-muenster.de/dtls-samples.html and yes, we need to bring the machine up again. Best regards Michael > > If any of you has an sample code of DTLS adaptation for SCTP. It would immensely help me for my work. > > Looking forward to your valuable inputs. > > Thanks, > Mahesh G S > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From j.curdes at overspeed.de Tue Feb 21 11:16:53 2017 From: j.curdes at overspeed.de (Jakob Curdes) Date: Tue, 21 Feb 2017 12:16:53 +0100 Subject: [openssl-users] Question RE certificate chain verification Message-ID: <5cca4d2c-3e93-0076-afab-e96c029d571b@overspeed.de> Hi, I am new to the list and have a question where it seems I cannot find the answer in archives here or in other sources. We want to verify the certificate chain of an "official" certificate, but including the revocation status of the intermediate certs, via CRL or OCSP. (The chain verification itself is easy and solved, our problems lie just with getting the revocation status of an arbitrary certificate). It seems to turn out that a) this is seldom done completely (otherwise I think there would be more "working recipes") and it is not easy to do it in a generic way as we keep getting various errors at different steps. Wtihout making it too long, we want to do the following: a) retrieve and save certificate from server via URL b)retrieve and save certificate chain from server c) determine OCSP URL or CRL list URL d1) verify cert against OCSP source OR d2) download CRL; then verify cert against CRL Up to c), everything is straightforward. We use openssl 1.0.1e-60.el7 from current CentOS 7. When using OCSP, we keep getting spurious error messages from the OCSP servers like "unauthorized" or "Bad request" when issuing an openssl command like openssl ocsp -no_nonce -issuer certificate1_chain.pem -cert certificate1.pem -url http://ocsp2.globalsign.com/gsalphasha2g2 -header "HOST" "ocsp2.globalsign.com/gsalphasha2g2" -resp_text /Error querying OCSP responsder (SIC!!)////140058021447584:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:250:Code=400,Reason=Bad Request/ openssl ocsp -no_nonce -issuer certificate2_chain.pem -cert certificate2.pem -url http://ocsp.comodoca.com -header "HOST" "ocsp.comodoca.com" -resp_text /Responder Error: unauthorized (6)/ (Note that this does not seem to be related to nonce requests or missing host headers - thanks to Ivan Ristic and others these are well-known problems...) Needless to say that using a browser you get a 200 response! When going the CRL way, we keep getting /usr/bin/openssl verify -crl_check_all -CAfile certificate1_chain_crl.pem certificate1.pem /certificate1.pem: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority////error 2 at 2 depth lookup:unable to get issuer certificate////error 20 at 0 depth lookup:unable to get local issuer certificate/ although the chain seems to be complete and we downloaded the CRL from the CRL URL specified in the certificate. The depth 0 error can probably be ignored as this is the root cert!? But the depth 2 cert is the final cert and all intermediates are given, so why can the issuer certificate not be found? => We are obviously doing things wrong or omitting something. Has anybody out there a working recipe how to do this for typical certificate chains? Thank you for any hints, Jakob Curdes -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at tuta.io Tue Feb 21 17:39:56 2017 From: openssl at tuta.io (openssl at tuta.io) Date: Tue, 21 Feb 2017 18:39:56 +0100 (CET) Subject: [openssl-users] Specify padding scheme with EVP_VerifyFinal Message-ID: Hello, I am facing a problem regarding an application which uses EVP_VerifyInit_ex, EVP_VerifyUpdate and EVP_VerifyFinal to verify RSA signatures with EVP_get_digestbyname("RSA-SHA256"). Is it correct that ECP_VerifyFinal defaults to PKCS#1 v1.5 padding? We would like to be able to switch to other padding algorithms without having to change a lot of code of the application itself. Is it possible to specify a different padding scheme (e.g. RSA_PKCS1_PSS_PADDING) using this API? If not, what is the easiest way to work around this "limitation"? Thank you in advance, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Wed Feb 22 06:47:29 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Wed, 22 Feb 2017 12:17:29 +0530 Subject: [openssl-users] DTLS for SCTP connections In-Reply-To: References: Message-ID: Hi, Thank you for sharing the sample code. I tried running SCTP DTLS Echo server and client. I am facing strange problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs on the server side. Client side back trace (gdb) bt #0 0x0000003db4c0ea10 in __recvmsg_nocancel () from /lib64/libpthread.so.0 #1 0x00007ffff7a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 "\026\376\377", outl=17741) at bss_dgram.c:1178 #2 0x00007ffff7a597a9 in BIO_read (b=0x6223f0, out=0x629073, outl=17741) at bio_lib.c:210 #3 0x00007ffff7db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, extend=) at s3_pkt.c:258 #4 0x00007ffff7dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676 #5 0x00007ffff7dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, buf=0x7ffffffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938 #6 0x00007ffff7dcdda5 in dtls1_get_message_fragment (s=0x622c70, st1=, stn=4449, max=30, ok=0x7ffffffee09c) at d1_both.c:908 #7 0x00007ffff7dce414 in dtls1_get_message (s=0x622c70, st1=4448, stn=4449, mt=14, max=30, ok=0x7ffffffee09c) at d1_both.c:512 #8 0x00007ffff7dacaf9 in ssl3_get_server_done (s=0x622c70) at s3_clnt.c:2458 #9 0x00007ffff7dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466 #10 0x0000000000402f75 in start_client(char*, char*, int, int, int) () #11 0x0000000000403573 in main () Server side back trace (gdb) info threads 2 Thread 0x7ffff793c700 (LWP 20161) 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 * 1 Thread 0x7ffff793e720 (LWP 20155) 0x0000003db4c0e84d in accept () from /lib64/libpthread.so.0 (gdb) t 2 [Switching to thread 2 (Thread 0x7ffff793c700 (LWP 20161))]#0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 (gdb) bt #0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 #1 0x00007ffff7a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x7ffff0001930) at bss_dgram.c:1803 #2 0x00007ffff7dc7830 in dtls1_accept (s=0x7ffff00008c0) at d1_srvr.c:403 #3 0x00000000004021ee in connection_handle(void*) () #4 0x0000003db4c07851 in start_thread () from /lib64/libpthread.so.0 #5 0x0000003db48e890d in clone () from /lib64/libc.so.6 (gdb) I am also attaching the wireshark trace (port 4443) and a server key for decoding wireshark. Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443 Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 -l 50 -n 5 16.181.38.161 Thanks in advance for your valuable input Regards, Mahesh G S On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen < Michael.Tuexen at lurchi.franken.de> wrote: > > On 21 Feb 2017, at 09:53, mahesh gs wrote: > > > > Hi, > > > > We have a client, server applications that is using SCTP as a transport > protocol. We have to secure the connections using DTLS. I am using openssl > version 1.0.2 which supports DTLS. But the problem i am facing is usage of > DTLS SCTP related API's. Openssl documentation does not clearly explain all > the SCTP related API's and usage sequence. > > > > I have tried going though internet and found most of the sites redirect > to one link for SCTP DTLS sample code. But this link is not working. > > > > http://sctp.fh-muenster.de/dtls-samples.html > Try > http://web.archive.org/web/20150617012520/http://sctp.fh- > muenster.de/dtls-samples.html > and yes, we need to bring the machine up again. > > Best regards > Michael > > > > If any of you has an sample code of DTLS adaptation for SCTP. It would > immensely help me for my work. > > > > Looking forward to your valuable inputs. > > > > Thanks, > > Mahesh G S > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: log.pcap Type: application/octet-stream Size: 31278 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: server.key.pem Type: application/octet-stream Size: 3899 bytes Desc: not available URL: From david.oberhollenzer at sigma-star.at Wed Feb 22 09:11:02 2017 From: david.oberhollenzer at sigma-star.at (David Oberhollenzer) Date: Wed, 22 Feb 2017 10:11:02 +0100 Subject: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine Message-ID: <0e5b7690-efdd-5266-b0b7-2129ac1c68ef@sigma-star.at> Hi, I'm trying to compile OpenSSL 1.1.0e with the afalg engine on a recent CentOS 7. I removed the kernel version check for the afalg engine from the Configure script since AFAIK the CentOS kernel should have all of that back ported. I ran the following configure command: $ ./Configure linux-x86_64 shared enable-engine enable-dso \ enable-afalgeng --prefix=/opt/openssl --openssldir=/opt/openssl After make, I get an afalg.so in the output, but after installing it and running openssl speed I get complaints about bind_engine not being exported: $ /opt/openssl/bin/openssl speed -evp aes-128-cbc -engine afalg invalid engine "afalg" 140034190133056:error:2506406A:DSO support routines:dlfcn_bind_func:could not bind to the requested symbol name:crypto/dso/dso_dlfcn.c:178:symname(bind_engine): /opt/openssl/lib/engines-1.1/afalg.so: undefined symbol: bind_engine 140034190133056:error:2506C06A:DSO support routines:DSO_bind_func:could not bind to the requested symbol name:crypto/dso/dso_lib.c:185: 140034190133056:error:260B6068:engine routines:dynamic_load:DSO failure:crypto/engine/eng_dyn.c:427: 140034190133056:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:339:id=afalg 140034190133056:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:113:filename(libafalg.so): libafalg.so: cannot open shared object file: No such file or directory 140034190133056:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:161: 140034190133056:error:260B6084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:414: ... Running readelf on afalg.so confirms that the symbol is indeed not in the binary. Am I missing some magic configure options or is there some other problem? Thanks, David From matt at openssl.org Wed Feb 22 12:50:59 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Feb 2017 12:50:59 +0000 Subject: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine In-Reply-To: <0e5b7690-efdd-5266-b0b7-2129ac1c68ef@sigma-star.at> References: <0e5b7690-efdd-5266-b0b7-2129ac1c68ef@sigma-star.at> Message-ID: <9582194c-8b77-f0bb-eaf4-ecdd251f486d@openssl.org> On 22/02/17 09:11, David Oberhollenzer wrote: > Running readelf on afalg.so confirms that the symbol is indeed not > in the binary. Am I missing some magic configure options or is there > some other problem? I just tried the exact same Configure line as you on 1.1.0e and it all works fine: $ readelf afalg.so -s | grep bind_engine 66: 0000000000002840 319 FUNC GLOBAL DEFAULT 12 bind_engine 95: 0000000000002840 319 FUNC GLOBAL DEFAULT 12 bind_engine You said you: > removed the kernel version check for the > afalg engine from the Configure script since AFAIK the CentOS > kernel should have all of that back ported. There is a similar check in engines/afalg/e_afalg.c which checks the version of the kernel headers. Did you also amend that: #if LINUX_VERSION_CODE <= KERNEL_VERSION(K_MAJ, K_MIN1, K_MIN2) || \ !defined(AF_ALG) # ifndef PEDANTIC # warning "AFALG ENGINE requires Kernel Headers >= 4.1.0" # warning "Skipping Compilation of AFALG engine" # endif void engine_load_afalg_int(void); void engine_load_afalg_int(void) { } #else Matt From Michael.Tuexen at lurchi.franken.de Wed Feb 22 15:03:00 2017 From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen) Date: Wed, 22 Feb 2017 16:03:00 +0100 Subject: [openssl-users] DTLS for SCTP connections In-Reply-To: References: Message-ID: > On 22 Feb 2017, at 07:47, mahesh gs wrote: > > Hi, > > Thank you for sharing the sample code. > > I tried running SCTP DTLS Echo server and client. I am facing strange problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs on the server side. > > Client side back trace > > (gdb) bt > #0 0x0000003db4c0ea10 in __recvmsg_nocancel () from /lib64/libpthread.so.0 > #1 0x00007ffff7a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 "\026\376\377", outl=17741) at bss_dgram.c:1178 > #2 0x00007ffff7a597a9 in BIO_read (b=0x6223f0, out=0x629073, outl=17741) at bio_lib.c:210 > #3 0x00007ffff7db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, extend=) at s3_pkt.c:258 > #4 0x00007ffff7dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676 > #5 0x00007ffff7dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, buf=0x7ffffffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938 > #6 0x00007ffff7dcdda5 in dtls1_get_message_fragment (s=0x622c70, st1=, stn=4449, max=30, ok=0x7ffffffee09c) > at d1_both.c:908 > #7 0x00007ffff7dce414 in dtls1_get_message (s=0x622c70, st1=4448, stn=4449, mt=14, max=30, ok=0x7ffffffee09c) at d1_both.c:512 > #8 0x00007ffff7dacaf9 in ssl3_get_server_done (s=0x622c70) at s3_clnt.c:2458 > #9 0x00007ffff7dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466 > #10 0x0000000000402f75 in start_client(char*, char*, int, int, int) () > #11 0x0000000000403573 in main () > > > Server side back trace > > (gdb) info threads > 2 Thread 0x7ffff793c700 (LWP 20161) 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > * 1 Thread 0x7ffff793e720 (LWP 20155) 0x0000003db4c0e84d in accept () from /lib64/libpthread.so.0 > (gdb) t 2 > [Switching to thread 2 (Thread 0x7ffff793c700 (LWP 20161))]#0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > (gdb) bt > #0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > #1 0x00007ffff7a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x7ffff0001930) at bss_dgram.c:1803 > #2 0x00007ffff7dc7830 in dtls1_accept (s=0x7ffff00008c0) at d1_srvr.c:403 > #3 0x00000000004021ee in connection_handle(void*) () > #4 0x0000003db4c07851 in start_thread () from /lib64/libpthread.so.0 > #5 0x0000003db48e890d in clone () from /lib64/libc.so.6 > (gdb) > > > I am also attaching the wireshark trace (port 4443) and a server key for decoding wireshark. > > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443 > > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 -l 50 -n 5 16.181.38.161 > > Thanks in advance for your valuable input I've CCed Irene, who did some testing recently on FreeBSD, where the implementation works. The server is waiting for a sender dry event which it should get. Which version of OpenSSL are you using and which OS are you using? Best regards Michael > > Regards, > Mahesh G S > > > > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen wrote: > > On 21 Feb 2017, at 09:53, mahesh gs wrote: > > > > Hi, > > > > We have a client, server applications that is using SCTP as a transport protocol. We have to secure the connections using DTLS. I am using openssl version 1.0.2 which supports DTLS. But the problem i am facing is usage of DTLS SCTP related API's. Openssl documentation does not clearly explain all the SCTP related API's and usage sequence. > > > > I have tried going though internet and found most of the sites redirect to one link for SCTP DTLS sample code. But this link is not working. > > > > http://sctp.fh-muenster.de/dtls-samples.html > Try > http://web.archive.org/web/20150617012520/http://sctp.fh-muenster.de/dtls-samples.html > and yes, we need to bring the machine up again. > > Best regards > Michael > > > > If any of you has an sample code of DTLS adaptation for SCTP. It would immensely help me for my work. > > > > Looking forward to your valuable inputs. > > > > Thanks, > > Mahesh G S > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From vsraja at gmail.com Wed Feb 22 19:01:53 2017 From: vsraja at gmail.com (Senthil Raja Velu) Date: Thu, 23 Feb 2017 00:31:53 +0530 Subject: [openssl-users] OpenSSL handshake failure with RSA bad signature error Message-ID: Hi, I have recently updated my openssl server version from 1.0.1m to 1.0.2j. After updating the handshake fails with the client. The client still use openssl version 1.0.1e-fips. Note: With older openssl server version (1.0.1m) the handshake works with the same set of certificates. Here is the complete handshake message sequence from the server side with all debugs: TlsInfoCB HANDSHAKE_START(time:4849) sCount(0) cCount(1) undefined:before/accept initialization TlsInfoCB SSL_accept:before/accept initialization TlsMsgCB TLS-MSG: <<< ??? len=5 TlsHexDumpCB 0000 - 16 03 01 00 94 ..... TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=148 ClientHello TlsHexDumpCB 0000 - 01 00 00 90 03 03 58 ad-d7 b5 64 af 9e d2 38 c4 ......X...d...8. 0010 - 4a 8b fc 7c 3b 2f 12 64-68 70 c4 57 73 54 54 ce J..|;/.dhp.WsTT. 0020 - 82 dd f2 58 c7 85 00 00-24 00 0a 00 2f 00 32 00 ...X....$.../.2. 0030 - 33 00 35 c0 14 c0 03 c0-04 c0 05 c0 08 c0 09 c0 3.5............. 0040 - 0a c0 0d c0 0e c0 0f c0-12 c0 13 00 ff 01 00 00 ................ 0050 - 43 00 0b 00 04 03 00 01-02 00 0a 00 08 00 06 00 C............... 0060 - 19 00 18 00 17 00 23 00-00 00 0d 00 22 00 20 06 ......#.....". . 0070 - 01 06 02 06 03 05 01 05-02 05 03 04 01 04 02 04 ................ 0080 - 03 03 01 03 02 03 03 02-01 02 02 02 03 01 01 00 ................ 0090 - 0f 00 01 01 .... TlsExtCB TLS-EXT: client "EC point formats" (id=11) len=4 TlsHexDumpCB 0000 - 03 00 01 02 .... TlsExtCB TLS-EXT: client "elliptic curves" (id=10) len=8 TlsHexDumpCB 0000 - 00 06 00 19 00 18 00 17- ........ TlsExtCB TLS-EXT: client "session ticket" (id=35) len=0 TlsExtCB TLS-EXT: client "signature algorithms" (id=13) len=34 TlsHexDumpCB 0000 - 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01 . .............. 0010 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03 ................ 0020 - 01 01 .. TlsExtCB TLS-EXT: client "heartbeat" (id=15) len=1 TlsHexDumpCB 0000 - 01 . TlsInfoCB SSL_accept:SSLv3 read client hello A TlsMsgCB TLS-MSG: >>> ??? len=5 TlsHexDumpCB 0000 - 16 03 03 00 3a ....: TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=58 ServerHello TlsHexDumpCB 0000 - 02 00 00 36 03 03 b6 97-ce 9a 96 74 98 52 c0 4a ...6.......t.R.J 0010 - c4 2e f4 20 1f 47 c0 b3-2e e4 8c ed 79 9e 22 e1 ... .G......y.". 0020 - 57 f9 1f 56 c4 b5 00 00-0a 00 00 0e ff 01 00 01 W..V............ 0030 - 00 00 23 00 00 00 0f 00-01 01 ..#....... TlsInfoCB SSL_accept:SSLv3 write server hello A TlsMsgCB TLS-MSG: >>> ??? len=5 TlsHexDumpCB 0000 - 16 03 03 04 f1 ..... TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=1265 Certificate TlsHexDumpCB 0000 - 0b 00 04 ed 00 04 ea 00-02 15 30 82 02 11 30 82 ..........0...0. 0010 - 01 7a 02 09 00 aa f8 6d-8b 4d d8 0f f0 30 0d 06 .z.....m.M...0.. 0020 - 09 2a 86 48 86 f7 0d 01-01 05 05 00 30 4e 31 0b .*.H........0N1. 0030 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...U....US1.0.. 0040 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .U....California 0050 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...U....SanJo 0060 - 73 65 31 18 30 16 06 03-55 04 03 13 0f 77 77 77 se1.0...U....www 0070 - 2e 6e 75 61 67 65 43 41-2e 63 6f 6d 30 1e 17 0d .nuageCA.com0... 0080 - 31 34 30 39 30 34 30 39-35 37 35 30 5a 17 0d 32 140904095750Z..2 0090 - 34 30 39 30 31 30 39 35-37 35 30 5a 30 4c 31 0b 40901095750Z0L1. 00a0 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...U....US1.0.. 00b0 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .U....California 00c0 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...U....SanJo 00d0 - 73 65 31 16 30 14 06 03-55 04 03 13 0d 77 77 77 se1.0...U....www 00e0 - 2e 6e 75 61 67 65 2e 63-6f 6d 30 81 9f 30 0d 06 .nuage.com0..0.. 00f0 - 09 2a 86 48 86 f7 0d 01-01 01 05 00 03 81 8d 00 .*.H............ 0100 - 30 81 89 02 81 81 00 d1-2f 3b 18 80 af 87 aa f3 0......./;...... 0110 - dd 62 5f 96 d6 69 ba 28-cf f6 56 7f c8 56 62 de .b_..i.(..V..Vb. 0120 - 7a 9d fc 6d 26 17 df 0d-5f 09 15 5e 24 68 04 37 z..m&..._..^$h.7 0130 - e0 02 47 e3 18 64 5c 2e-0a 2e 89 57 f9 54 b0 97 ..G..d\....W.T.. 0140 - 93 24 06 8b 22 55 54 68-89 ea 8d 1d 97 b0 d2 8b .$.."UTh........ 0150 - 5b 34 19 ba 41 c0 da ca-49 82 d4 76 a3 de 5f fc [4..A...I..v.._. 0160 - cf fa 6b 22 6c 8c c9 af-c2 e4 2b 08 75 cf 3d 5a ..k"l.....+.u.=Z 0170 - eb 32 9c 23 ac 6a 09 a7-7a 7b 67 36 08 17 e0 76 .2.#.j..z{g6...v 0180 - a0 9c f5 5b dc 0a a1 02-03 01 00 01 30 0d 06 09 ...[........0... 0190 - 2a 86 48 86 f7 0d 01 01-05 05 00 03 81 81 00 09 *.H............. 01a0 - ef 65 ee e8 3d b9 5f 11-5c 8a 8b 97 f7 3f 75 78 .e..=._.\....?ux 01b0 - f3 11 5f 09 0e b8 fe a0-6b 70 53 1e 34 1b 66 55 .._.....kpS.4.fU 01c0 - c5 7c d6 00 e4 ef 2f 56-7e 0b 0e fe d1 2b f9 42 .|..../V~....+.B 01d0 - d5 b7 3d 54 52 05 72 52-0b c2 89 3f 0a 5b ad e9 ..=TR.rR...?.[.. 01e0 - 04 98 c8 c2 0a b7 ec 7c-15 5d 4e 9f 45 70 a5 92 .......|.]N.Ep.. 01f0 - 3c 7e 1f 59 3b 03 97 c6-8a 45 a7 02 81 f8 4a 35 <~.Y;....E....J5 0200 - 24 ed 97 f2 89 0a 23 d2-ea b8 2e ff 12 ec e4 20 $.....#........ 0210 - 3d ab b4 ae e2 a6 ee a2-92 2b fb 9e b6 f6 3a 00 =........+....:. 0220 - 02 cf 30 82 02 cb 30 82-02 34 a0 03 02 01 02 02 ..0...0..4...... 0230 - 09 00 e4 51 8c 52 e2 ce-56 6f 30 0d 06 09 2a 86 ...Q.R..Vo0...*. 0240 - 48 86 f7 0d 01 01 05 05-00 30 4e 31 0b 30 09 06 H........0N1.0.. 0250 - 03 55 04 06 13 02 55 53-31 13 30 11 06 03 55 04 .U....US1.0...U. 0260 - 08 13 0a 43 61 6c 69 66-6f 72 6e 69 61 31 10 30 ...California1.0 0270 - 0e 06 03 55 04 07 13 07-53 61 6e 4a 6f 73 65 31 ...U....SanJose1 0280 - 18 30 16 06 03 55 04 03-13 0f 77 77 77 2e 6e 75 .0...U....www.nu 0290 - 61 67 65 43 41 2e 63 6f-6d 30 1e 17 0d 31 34 30 ageCA.com0...140 02a0 - 39 30 34 30 39 35 36 32-36 5a 17 0d 32 34 30 39 904095626Z..2409 02b0 - 30 31 30 39 35 36 32 36-5a 30 4e 31 0b 30 09 06 01095626Z0N1.0.. 02c0 - 03 55 04 06 13 02 55 53-31 13 30 11 06 03 55 04 .U....US1.0...U. 02d0 - 08 13 0a 43 61 6c 69 66-6f 72 6e 69 61 31 10 30 ...California1.0 02e0 - 0e 06 03 55 04 07 13 07-53 61 6e 4a 6f 73 65 31 ...U....SanJose1 02f0 - 18 30 16 06 03 55 04 03-13 0f 77 77 77 2e 6e 75 .0...U....www.nu 0300 - 61 67 65 43 41 2e 63 6f-6d 30 81 9f 30 0d 06 09 ageCA.com0..0... 0310 - 2a 86 48 86 f7 0d 01 01-01 05 00 03 81 8d 00 30 *.H............0 0320 - 81 89 02 81 81 00 ac 55-1b d9 c1 d6 17 da 27 fd .......U......'. 0330 - e8 fb f6 54 88 f0 6a b7-26 60 b3 81 c2 51 57 be ...T..j.&`...QW. 0340 - 3d 2c 80 1c d2 94 02 90-f2 10 31 af a7 4e 5a c1 =,........1..NZ. 0350 - fe e7 10 62 f2 2a 52 2f-d1 03 2a 8a 1a 33 8a 11 ...b.*R/..*..3.. 0360 - e1 c4 96 bd 15 51 a2 f6-23 0f fb 66 3f 3e d9 4e .....Q..#..f?>.N 0370 - 5d 7b f4 df 77 c6 8b 58-3e bf 09 f9 61 2e 33 40 ]{..w..X>...a.3@ 0380 - e5 28 6a 42 87 59 02 c0-be 89 7f 9b bc 8b 06 ea .(jB.Y.......... 0390 - 40 60 1a 44 80 cd 15 e1-9d e7 2b e6 a8 de d7 11 @`.D......+..... 03a0 - 09 9c 17 b8 7b 07 02 03-01 00 01 a3 81 b0 30 81 ....{.........0. 03b0 - ad 30 1d 06 03 55 1d 0e-04 16 04 14 7a 59 61 56 .0...U......zYaV 03c0 - b4 cd 2c 8b b4 b1 03 cf-5b 84 d8 3a 14 76 d8 38 ..,.....[..:.v.8 03d0 - 30 7e 06 03 55 1d 23 04-77 30 75 80 14 7a 59 61 0~..U.#.w0u..zYa 03e0 - 56 b4 cd 2c 8b b4 b1 03-cf 5b 84 d8 3a 14 76 d8 V..,.....[..:.v. 03f0 - 38 a1 52 a4 50 30 4e 31-0b 30 09 06 03 55 04 06 8.R.P0N1.0...U.. 0400 - 13 02 55 53 31 13 30 11-06 03 55 04 08 13 0a 43 ..US1.0...U....C 0410 - 61 6c 69 66 6f 72 6e 69-61 31 10 30 0e 06 03 55 alifornia1.0...U 0420 - 04 07 13 07 53 61 6e 4a-6f 73 65 31 18 30 16 06 ....SanJose1.0.. 0430 - 03 55 04 03 13 0f 77 77-77 2e 6e 75 61 67 65 43 .U....www.nuageC 0440 - 41 2e 63 6f 6d 82 09 00-e4 51 8c 52 e2 ce 56 6f A.com....Q.R..Vo 0450 - 30 0c 06 03 55 1d 13 04-05 30 03 01 01 ff 30 0d 0...U....0....0. 0460 - 06 09 2a 86 48 86 f7 0d-01 01 05 05 00 03 81 81 ..*.H........... 0470 - 00 09 2b 89 da 1c 40 72-c6 17 1b 71 f0 53 bd d8 ..+... at r...q.S.. 0480 - cc fb c3 fd 50 ae 92 f1-38 3d 8f 83 15 b3 bf 82 ....P...8=...... 0490 - 1d cf d5 29 91 31 95 a5-13 80 a0 c8 41 35 fc 51 ...).1......A5.Q 04a0 - 8c 89 eb 42 64 c6 a9 d5-bf 1e b2 1f 99 ce 5c 56 ...Bd.........\V 04b0 - 12 2d 53 da 7c d5 06 2b-89 cf 59 a4 4b 15 89 ea .-S.|..+..Y.K... 04c0 - 02 fc 75 c4 92 08 15 ae-79 89 f6 1b b4 98 fe 36 ..u.....y......6 04d0 - 5b 74 51 26 46 c7 e0 0b-25 18 8a 55 8b d8 07 78 [tQ&F...%..U...x 04e0 - 95 9c fa 9e 5c 2c 4c cc-1e c3 ba 99 78 7e 08 36 ....\,L.....x~.6 04f0 - 46 F TlsInfoCB SSL_accept:SSLv3 write certificate A TlsMsgCB TLS-MSG: >>> ??? len=5 TlsHexDumpCB 0000 - 16 03 03 00 2e ..... TlsMsgCB TLS-MSG: >>> TLSv1.2 Handshake len=46 CertificateRequest TlsHexDumpCB 0000 - 0d 00 00 26 03 01 02 40-00 1e 06 01 06 02 06 03 ...&... at ........ 0010 - 05 01 05 02 05 03 04 01-04 02 04 03 03 01 03 02 ................ 0020 - 03 03 02 01 02 02 02 03-00 00 0e ........... 002e - TlsInfoCB SSL_accept:SSLv3 write certificate request A TlsInfoCB SSL_accept:SSLv3 flush data TlsInfoCB SSL_accept:error in SSLv3 read client certificate A TlsInfoCB SSL_accept:error in SSLv3 read client certificate A TlsConnAccept SSL state after: SSLv3 read client certificate A TlsMsgCB TLS-MSG: <<< ??? len=5 TlsHexDumpCB 0000 - 16 03 03 04 f1 ..... TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=1265 Certificate TlsHexDumpCB 0000 - 0b 00 04 ed 00 04 ea 00-02 15 30 82 02 11 30 82 ..........0...0. 0010 - 01 7a 02 09 00 aa f8 6d-8b 4d d8 0f f1 30 0d 06 .z.....m.M...0.. 0020 - 09 2a 86 48 86 f7 0d 01-01 05 05 00 30 4e 31 0b .*.H........0N1. 0030 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...U....US1.0.. 0040 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .U....California 0050 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...U....SanJo 0060 - 73 65 31 18 30 16 06 03-55 04 03 13 0f 77 77 77 se1.0...U....www 0070 - 2e 6e 75 61 67 65 43 41-2e 63 6f 6d 30 1e 17 0d .nuageCA.com0... 0080 - 31 34 30 39 30 34 30 39-35 37 35 30 5a 17 0d 32 140904095750Z..2 0090 - 34 30 39 30 31 30 39 35-37 35 30 5a 30 4c 31 0b 40901095750Z0L1. 00a0 - 30 09 06 03 55 04 06 13-02 55 53 31 13 30 11 06 0...U....US1.0.. 00b0 - 03 55 04 08 13 0a 43 61-6c 69 66 6f 72 6e 69 61 .U....California 00c0 - 31 10 30 0e 06 03 55 04-07 13 07 53 61 6e 4a 6f 1.0...U....SanJo 00d0 - 73 65 31 16 30 14 06 03-55 04 03 13 0d 77 77 77 se1.0...U....www 00e0 - 2e 6e 75 61 67 65 2e 63-6f 6d 30 81 9f 30 0d 06 .nuage.com0..0.. 00f0 - 09 2a 86 48 86 f7 0d 01-01 01 05 00 03 81 8d 00 .*.H............ 0100 - 30 81 89 02 81 81 00 a8-76 3f f4 6d d1 08 fe 7c 0.......v?.m...| 0110 - 2a 58 f1 36 68 61 ea 63-c0 7b 05 ba da 76 27 e5 *X.6ha.c.{...v'. 0120 - ef 6f f2 c4 e2 f4 ee bc-eb 48 21 f0 94 7e 9e 48 .o.......H!..~.H 0130 - 63 a7 a7 e2 58 d8 41 af-eb ad d4 97 e6 50 af c1 c...X.A......P.. 0140 - 63 2a 05 19 08 82 cf 79-13 c0 78 4f 0b d7 39 64 c*.....y..xO..9d 0150 - d8 e0 1e f1 4e 69 8f 41-a9 3a 63 77 2c 9a 8b d5 ....Ni.A.:cw,... 0160 - 21 65 df f1 30 97 6f 57-93 0e 2b 8d 05 1d 74 d1 !e..0.oW..+...t. 0170 - 66 61 e7 d4 a4 d4 e1 be-8c d5 67 a8 36 82 63 11 fa........g.6.c. 0180 - 50 4f fa 7d ad 28 ff 02-03 01 00 01 30 0d 06 09 PO.}.(......0... 0190 - 2a 86 48 86 f7 0d 01 01-05 05 00 03 81 81 00 4f *.H............O 01a0 - 33 50 c1 e0 97 48 d3 ad-e0 13 0f 82 62 75 bf 3b 3P...H......bu.; 01b0 - b9 69 42 f7 5d 60 5f 8a-52 38 80 32 13 b9 81 de .iB.]`_.R8.2.... 01c0 - 1f 8e e3 6e 35 85 e6 92-51 8d 68 4b aa c0 d9 86 ...n5...Q.hK.... 01d0 - b8 5a 82 3a 5e 7f 15 56-69 94 33 52 81 0e 59 c9 .Z.:^..Vi.3R..Y. 01e0 - ea c2 b4 e0 7c c2 74 3d-5b a7 53 d7 63 98 f5 60 ....|.t=[.S.c..` 01f0 - c2 19 83 f5 b7 54 9e 1d-c8 c4 05 89 80 4f cc a5 .....T.......O.. 0200 - 02 99 76 5f 67 e8 56 13-76 03 7c cc 85 d1 a3 26 ..v_g.V.v.|....& 0210 - 3d 7b 67 10 04 d1 54 76-ef 63 7c 4b e0 a3 e3 00 ={g...Tv.c|K.... 0220 - 02 cf 30 82 02 cb 30 82-02 34 a0 03 02 01 02 02 ..0...0..4...... 0230 - 09 00 e4 51 8c 52 e2 ce-56 6f 30 0d 06 09 2a 86 ...Q.R..Vo0...*. 0240 - 48 86 f7 0d 01 01 05 05-00 30 4e 31 0b 30 09 06 H........0N1.0.. 0250 - 03 55 04 06 13 02 55 53-31 13 30 11 06 03 55 04 .U....US1.0...U. 0260 - 08 13 0a 43 61 6c 69 66-6f 72 6e 69 61 31 10 30 ...California1.0 0270 - 0e 06 03 55 04 07 13 07-53 61 6e 4a 6f 73 65 31 ...U....SanJose1 0280 - 18 30 16 06 03 55 04 03-13 0f 77 77 77 2e 6e 75 .0...U....www.nu 0290 - 61 67 65 43 41 2e 63 6f-6d 30 1e 17 0d 31 34 30 ageCA.com0...140 02a0 - 39 30 34 30 39 35 36 32-36 5a 17 0d 32 34 30 39 904095626Z..2409 02b0 - 30 31 30 39 35 36 32 36-5a 30 4e 31 0b 30 09 06 01095626Z0N1.0.. 02c0 - 03 55 04 06 13 02 55 53-31 13 30 11 06 03 55 04 .U....US1.0...U. 02d0 - 08 13 0a 43 61 6c 69 66-6f 72 6e 69 61 31 10 30 ...California1.0 02e0 - 0e 06 03 55 04 07 13 07-53 61 6e 4a 6f 73 65 31 ...U....SanJose1 02f0 - 18 30 16 06 03 55 04 03-13 0f 77 77 77 2e 6e 75 .0...U....www.nu 0300 - 61 67 65 43 41 2e 63 6f-6d 30 81 9f 30 0d 06 09 ageCA.com0..0... 0310 - 2a 86 48 86 f7 0d 01 01-01 05 00 03 81 8d 00 30 *.H............0 0320 - 81 89 02 81 81 00 ac 55-1b d9 c1 d6 17 da 27 fd .......U......'. 0330 - e8 fb f6 54 88 f0 6a b7-26 60 b3 81 c2 51 57 be ...T..j.&`...QW. 0340 - 3d 2c 80 1c d2 94 02 90-f2 10 31 af a7 4e 5a c1 =,........1..NZ. 0350 - fe e7 10 62 f2 2a 52 2f-d1 03 2a 8a 1a 33 8a 11 ...b.*R/..*..3.. 0360 - e1 c4 96 bd 15 51 a2 f6-23 0f fb 66 3f 3e d9 4e .....Q..#..f?>.N 0370 - 5d 7b f4 df 77 c6 8b 58-3e bf 09 f9 61 2e 33 40 ]{..w..X>...a.3@ 0380 - e5 28 6a 42 87 59 02 c0-be 89 7f 9b bc 8b 06 ea .(jB.Y.......... 0390 - 40 60 1a 44 80 cd 15 e1-9d e7 2b e6 a8 de d7 11 @`.D......+..... 03a0 - 09 9c 17 b8 7b 07 02 03-01 00 01 a3 81 b0 30 81 ....{.........0. 03b0 - ad 30 1d 06 03 55 1d 0e-04 16 04 14 7a 59 61 56 .0...U......zYaV 03c0 - b4 cd 2c 8b b4 b1 03 cf-5b 84 d8 3a 14 76 d8 38 ..,.....[..:.v.8 03d0 - 30 7e 06 03 55 1d 23 04-77 30 75 80 14 7a 59 61 0~..U.#.w0u..zYa 03e0 - 56 b4 cd 2c 8b b4 b1 03-cf 5b 84 d8 3a 14 76 d8 V..,.....[..:.v. 03f0 - 38 a1 52 a4 50 30 4e 31-0b 30 09 06 03 55 04 06 8.R.P0N1.0...U.. 0400 - 13 02 55 53 31 13 30 11-06 03 55 04 08 13 0a 43 ..US1.0...U....C 0410 - 61 6c 69 66 6f 72 6e 69-61 31 10 30 0e 06 03 55 alifornia1.0...U 0420 - 04 07 13 07 53 61 6e 4a-6f 73 65 31 18 30 16 06 ....SanJose1.0.. 0430 - 03 55 04 03 13 0f 77 77-77 2e 6e 75 61 67 65 43 .U....www.nuageC 0440 - 41 2e 63 6f 6d 82 09 00-e4 51 8c 52 e2 ce 56 6f A.com....Q.R..Vo 0450 - 30 0c 06 03 55 1d 13 04-05 30 03 01 01 ff 30 0d 0...U....0....0. 0460 - 06 09 2a 86 48 86 f7 0d-01 01 05 05 00 03 81 81 ..*.H........... 0470 - 00 09 2b 89 da 1c 40 72-c6 17 1b 71 f0 53 bd d8 ..+... at r...q.S.. 0480 - cc fb c3 fd 50 ae 92 f1-38 3d 8f 83 15 b3 bf 82 ....P...8=...... 0490 - 1d cf d5 29 91 31 95 a5-13 80 a0 c8 41 35 fc 51 ...).1......A5.Q 04a0 - 8c 89 eb 42 64 c6 a9 d5-bf 1e b2 1f 99 ce 5c 56 ...Bd.........\V 04b0 - 12 2d 53 da 7c d5 06 2b-89 cf 59 a4 4b 15 89 ea .-S.|..+..Y.K... 04c0 - 02 fc 75 c4 92 08 15 ae-79 89 f6 1b b4 98 fe 36 ..u.....y......6 04d0 - 5b 74 51 26 46 c7 e0 0b-25 18 8a 55 8b d8 07 78 [tQ&F...%..U...x 04e0 - 95 9c fa 9e 5c 2c 4c cc-1e c3 ba 99 78 7e 08 36 ....\,L.....x~.6 04f0 - 46 F TlsInfoCB SSL_accept:SSLv3 read client certificate A TlsMsgCB TLS-MSG: <<< ??? len=5 TlsHexDumpCB 0000 - 16 03 03 00 86 ..... TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=134 ClientKeyExchange TlsHexDumpCB 0000 - 10 00 00 82 00 80 62 63-f6 b8 00 19 3d 68 8c cd ......bc....=h.. 0010 - f7 e0 ca b8 d7 d8 f0 15-45 48 fd ca e9 53 27 45 ........EH...S'E 0020 - b5 ae a0 af 43 05 ec b4-88 12 5d 9b e9 3d 94 c9 ....C.....]..=.. 0030 - 72 cb 63 47 af e7 a5 a9-de 91 ba 52 fc b4 fc 17 r.cG.......R.... 0040 - 5c 51 59 4d 43 b3 2e 23-4d 75 fa 4f a9 5b bb 5b \QYMC..#Mu.O.[.[ 0050 - 20 10 87 9f a8 2e c7 5c-ed 51 30 b2 61 60 c7 ca ......\.Q0.a`.. 0060 - 7c 2b df ae dd ce 37 d3-55 b2 ec e3 af 10 f3 ce |+....7.U....... 0070 - 85 c7 5c 46 61 6c b3 33-cb a8 fb 93 22 db 5e 25 ..\Fal.3....".^% 0080 - 47 11 0d 6b 9c 53 G..k.S TlsInfoCB SSL_accept:SSLv3 read client key exchange A TlsMsgCB TLS-MSG: <<< ??? len=5 TlsHexDumpCB 0000 - 16 03 03 00 88 ..... TlsMsgCB TLS-MSG: <<< TLSv1.2 Handshake len=136 CertificateVerify TlsHexDumpCB 0000 - 0f 00 00 84 06 01 00 80-26 20 60 8a 42 c3 b0 98 ........& `.B... 0010 - b6 28 04 ab 76 39 0b 9d-41 47 32 d3 29 65 3e c3 .(..v9..AG2.)e>. 0020 - f6 78 89 b1 09 df a4 fe-9f 6a 4a d0 99 11 27 88 .x.......jJ...'. 0030 - 76 db 95 ba d1 77 4a 35-7f ae 67 6a cb a6 a7 b7 v....wJ5..gj.... 0040 - 79 c2 78 63 14 49 e2 2b-68 72 8c 08 02 fa 51 35 y.xc.I.+hr....Q5 0050 - 98 4e 70 3b 7a ab 4d e4-c0 3e 49 0d a8 33 58 11 .Np;z.M..>I..3X. 0060 - 31 23 cd bc 4b 77 55 b6-d3 f5 f1 e3 5c da a6 96 1#..KwU.....\... 0070 - b8 41 d2 ac df b8 36 43-62 b4 df b4 e6 86 42 5e .A....6Cb.....B^ 0080 - eb 5c 89 18 51 64 9a 31- .\..Qd.1 TlsMsgCB TLS-MSG: >>> ??? len=5 TlsHexDumpCB 0000 - 15 03 03 00 02 ..... TlsMsgCB TLS-MSG: >>> TLSv1.2 Alert len=2 fatal decrypt_error TlsHexDumpCB 0000 - 02 33 .3 TlsInfoCB SSL3 alert write:fatal:decrypt error TlsPrintCB 058880:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:/workspace/openssl/crypto/rsa/rsa_sign.c:300: TlsInfoCB SSL_accept:failed in error TlsPrintCB 058880:error:1408807B:SSL routines:ssl3_get_cert_verify:bad signature:/workspace/openssl/ssl/s3_srvr.c:3100: Appreciate any pointers on addressing this issue. Thanks, Senthil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at sigma-star.at Wed Feb 22 20:20:02 2017 From: richard at sigma-star.at (Richard Weinberger) Date: Wed, 22 Feb 2017 21:20:02 +0100 Subject: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine In-Reply-To: <86759315-b073-0c78-6dfb-e8ec838b92f2@sigma-star.at> References: <0e5b7690-efdd-5266-b0b7-2129ac1c68ef@sigma-star.at> <86759315-b073-0c78-6dfb-e8ec838b92f2@sigma-star.at> Message-ID: <80c98eac-2fc3-a239-4939-3c39ee959f1b@sigma-star.at> Am 22.02.2017 um 12:24 schrieb David Oberhollenzer: > Sorry, never mind. After taking a closer look at the source code I saw > that there are further compile time and run-time kernel version > checks in e_afalg.c. I adjusted the version number and got that to > work now. Well, why does the afalg engine depend on Linux 4.1? AF_ALG is part of Linux since 2.6.38. Furthermore it is not clear to me why the Kernel version is being checked during the build. What if I build on an older kernel? Does your build system offer a config option for that? Thanks, //richard -- sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria ATU66964118 - FN 374287y From matt at openssl.org Wed Feb 22 23:04:20 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Feb 2017 23:04:20 +0000 Subject: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine In-Reply-To: <80c98eac-2fc3-a239-4939-3c39ee959f1b@sigma-star.at> References: <0e5b7690-efdd-5266-b0b7-2129ac1c68ef@sigma-star.at> <86759315-b073-0c78-6dfb-e8ec838b92f2@sigma-star.at> <80c98eac-2fc3-a239-4939-3c39ee959f1b@sigma-star.at> Message-ID: <77eefaa4-90b3-1a78-ed25-2b7afe93a6e1@openssl.org> On 22/02/17 20:20, Richard Weinberger wrote: > Am 22.02.2017 um 12:24 schrieb David Oberhollenzer: >> Sorry, never mind. After taking a closer look at the source code I saw >> that there are further compile time and run-time kernel version >> checks in e_afalg.c. I adjusted the version number and got that to >> work now. > > Well, why does the afalg engine depend on Linux 4.1? > AF_ALG is part of Linux since 2.6.38. I think its the dependence on the AIO stuff. The AFALG engine is an async aware engine. If your application is also async aware (i.e. uses the new async APIs in 1.1.0) then you can offload crypto work onto the kernel while you application gets on with something else. At the moment though the crypto support in that engine is quite limited. It only supports offloading of AES128-CBC. > > Furthermore it is not clear to me why the Kernel version is being > checked during the build. > What if I build on an older kernel? > Does your build system offer a config option for that? No - I guess the assumption is that it is more normal to do it the other way around (i.e. build on a newer kernel but target an older one). Matt From noloader at gmail.com Thu Feb 23 04:43:46 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 22 Feb 2017 23:43:46 -0500 Subject: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine In-Reply-To: <80c98eac-2fc3-a239-4939-3c39ee959f1b@sigma-star.at> References: <0e5b7690-efdd-5266-b0b7-2129ac1c68ef@sigma-star.at> <86759315-b073-0c78-6dfb-e8ec838b92f2@sigma-star.at> <80c98eac-2fc3-a239-4939-3c39ee959f1b@sigma-star.at> Message-ID: >> Sorry, never mind. After taking a closer look at the source code I saw >> that there are further compile time and run-time kernel version >> checks in e_afalg.c. I adjusted the version number and got that to >> work now. > > Well, why does the afalg engine depend on Linux 4.1? > AF_ALG is part of Linux since 2.6.38. > > Furthermore it is not clear to me why the Kernel version is being > checked during the build. > What if I build on an older kernel? > Does your build system offer a config option for that? Also see https://mta.openssl.org/pipermail/openssl-dev/2016-March/006171.html Its been my experience that most AFALG issues are due to the kernel and problems with its implementation, and not OpenSSL. Kernel test vectors are virtually non-existent, so things randomly move in and out of a state of "it works as expected" to other various states. For example, here are the AFALG test vectors: https://github.com/tstruk/afalg_async_test. They are not in the kernel proper, they are incomplete, and its hits or miss whether they will work as expected. You can learn if an async driver is available with: cat /proc/crypto | egrep '^(name|driver|async|$)' Jeff From mahesh116 at gmail.com Thu Feb 23 05:13:14 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Thu, 23 Feb 2017 10:43:14 +0530 Subject: [openssl-users] DTLS for SCTP connections In-Reply-To: References: Message-ID: Hi Michael, I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and openssl version is 1.1.0. SCTP version : [root at localhost DIAMETER]# rpm -qa | grep -i "sctp" *lksctp-tools-1.0.10-5.el6.x86_64* [root at localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64 Name : lksctp-tools Relocations: (not relocatable) Version : 1.0.10 Vendor: Red Hat, Inc. Release : 5.el6 *Build Date: Mon 22 Feb 2010 12:24:33 PM CET* Install Date: Wed 08 Feb 2017 10:08:12 AM CET Build Host: hs20-bc1-2.build.redhat.com Group : System Environment/Libraries Source RPM: lksctp-tools-1.0.10-5.el6.src.rpm Size : 203688 License: GPLv2 and GPLv2+ and LGPLv2 and BSD Signature : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID 199e2f91fd431d51 Packager : Red Hat, Inc. URL : http://lksctp.sourceforge.net Summary : User-space access to Linux Kernel SCTP Description : This is the lksctp-tools package for Linux Kernel SCTP (Stream Control Transmission Protocol) Reference Implementation. Thanks, Mahesh G S On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen < Michael.Tuexen at lurchi.franken.de> wrote: > > On 22 Feb 2017, at 07:47, mahesh gs wrote: > > > > Hi, > > > > Thank you for sharing the sample code. > > > > I tried running SCTP DTLS Echo server and client. I am facing strange > problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs > on the server side. > > > > Client side back trace > > > > (gdb) bt > > #0 0x0000003db4c0ea10 in __recvmsg_nocancel () from > /lib64/libpthread.so.0 > > #1 0x00007ffff7a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 > "\026\376\377", outl=17741) at bss_dgram.c:1178 > > #2 0x00007ffff7a597a9 in BIO_read (b=0x6223f0, out=0x629073, > outl=17741) at bio_lib.c:210 > > #3 0x00007ffff7db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, > extend=) at s3_pkt.c:258 > > #4 0x00007ffff7dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676 > > #5 0x00007ffff7dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, > buf=0x7ffffffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938 > > #6 0x00007ffff7dcdda5 in dtls1_get_message_fragment (s=0x622c70, > st1=, stn=4449, max=30, ok=0x7ffffffee09c) > > at d1_both.c:908 > > #7 0x00007ffff7dce414 in dtls1_get_message (s=0x622c70, st1=4448, > stn=4449, mt=14, max=30, ok=0x7ffffffee09c) at d1_both.c:512 > > #8 0x00007ffff7dacaf9 in ssl3_get_server_done (s=0x622c70) at > s3_clnt.c:2458 > > #9 0x00007ffff7dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466 > > #10 0x0000000000402f75 in start_client(char*, char*, int, int, int) () > > #11 0x0000000000403573 in main () > > > > > > Server side back trace > > > > (gdb) info threads > > 2 Thread 0x7ffff793c700 (LWP 20161) 0x0000003db4c0ea2d in recvmsg () > from /lib64/libpthread.so.0 > > * 1 Thread 0x7ffff793e720 (LWP 20155) 0x0000003db4c0e84d in accept () > from /lib64/libpthread.so.0 > > (gdb) t 2 > > [Switching to thread 2 (Thread 0x7ffff793c700 (LWP 20161))]#0 > 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > > (gdb) bt > > #0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > > #1 0x00007ffff7a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x7ffff0001930) > at bss_dgram.c:1803 > > #2 0x00007ffff7dc7830 in dtls1_accept (s=0x7ffff00008c0) at > d1_srvr.c:403 > > #3 0x00000000004021ee in connection_handle(void*) () > > #4 0x0000003db4c07851 in start_thread () from /lib64/libpthread.so.0 > > #5 0x0000003db48e890d in clone () from /lib64/libc.so.6 > > (gdb) > > > > > > I am also attaching the wireshark trace (port 4443) and a server key for > decoding wireshark. > > > > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443 > > > > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 > -l 50 -n 5 16.181.38.161 > > > > Thanks in advance for your valuable input > I've CCed Irene, who did some testing recently on FreeBSD, where the > implementation works. > The server is waiting for a sender dry event which it should get. > > Which version of OpenSSL are you using and which OS are you using? > > Best regards > Michael > > > > Regards, > > Mahesh G S > > > > > > > > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen franken.de> wrote: > > > On 21 Feb 2017, at 09:53, mahesh gs wrote: > > > > > > Hi, > > > > > > We have a client, server applications that is using SCTP as a > transport protocol. We have to secure the connections using DTLS. I am > using openssl version 1.0.2 which supports DTLS. But the problem i am > facing is usage of DTLS SCTP related API's. Openssl documentation does not > clearly explain all the SCTP related API's and usage sequence. > > > > > > I have tried going though internet and found most of the sites > redirect to one link for SCTP DTLS sample code. But this link is not > working. > > > > > > http://sctp.fh-muenster.de/dtls-samples.html > > Try > > http://web.archive.org/web/20150617012520/http://sctp.fh- > muenster.de/dtls-samples.html > > and yes, we need to bring the machine up again. > > > > Best regards > > Michael > > > > > > If any of you has an sample code of DTLS adaptation for SCTP. It would > immensely help me for my work. > > > > > > Looking forward to your valuable inputs. > > > > > > Thanks, > > > Mahesh G S > > > -- > > > openssl-users mailing list > > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From walter.h at mathemainzel.info Thu Feb 23 06:09:10 2017 From: walter.h at mathemainzel.info (Walter H.) Date: Thu, 23 Feb 2017 07:09:10 +0100 Subject: [openssl-users] Question RE certificate chain verification In-Reply-To: <5cca4d2c-3e93-0076-afab-e96c029d571b@overspeed.de> References: <5cca4d2c-3e93-0076-afab-e96c029d571b@overspeed.de> Message-ID: On Tue, February 21, 2017 12:16, Jakob Curdes wrote: > Hi, I am new to the list and have a question where it seems I cannot find > the answer in archives here or in other sources. > > We want to verify the certificate chain of an "official" certificate, but > including the revocation status of the intermediate certs, via CRL or > OCSP. > (The chain verification itself is easy and solved, our problems lie just > with getting the revocation status of an arbitrary certificate). > > It seems to turn out that a) this is seldom done completely (otherwise I > think there would be more "working recipes") and it is not easy to do it > in a generic way as we keep getting various errors at different steps. > > Wtihout making it too long, we want to do the following: > a) retrieve and save certificate from server via URL > b)retrieve and save certificate chain from server > c) determine OCSP URL or CRL list URL > d1) verify cert against OCSP source OR > d2) download CRL; then verify cert against CRL > > Up to c), everything is straightforward. We use openssl 1.0.1e-60.el7 from > current CentOS 7. try this: CAFILE=/etc/pki/certs/ca-bundle.trust.crt CERT=/tmp/cert.crt <-- cert to validate ISSUER=/tmp/issuer.crt <-- issuing ca cert OCSPURL=$(openssl x509 -in $CERT -noout -ocsp_uri) OCSPHOST=$(echo "$OCSPURL" |gawk --field-separator=\/ '{ print $3 }' -) OCSPRESULT=$(openssl ocsp -CAfile $CAFILE -no_nonce -noverify -issuer $ISSUER -cert $CERT -url "$OCSPURL" -header Host $OCSPHOST |grep "$CERT") From j.curdes at overspeed.de Thu Feb 23 16:20:29 2017 From: j.curdes at overspeed.de (Jakob Curdes) Date: Thu, 23 Feb 2017 17:20:29 +0100 Subject: [openssl-users] Question RE certificate chain verification In-Reply-To: References: Message-ID: <287d00d0-33bb-7762-8072-1ff55a465b1c@overspeed.de> > Hi, I am new to the list and have a question where it seems I cannot find > the answer in archives here or in other sources. > > We want to verify the certificate chain of an "official" certificate, but > including the revocation status of the intermediate certs, via CRL or > OCSP. > (The chain verification itself is easy and solved, our problems lie just > with getting the revocation status of an arbitrary certificate). > > It seems to turn out that a) this is seldom done completely (otherwise I > think there would be more "working recipes") and it is not easy to do it > in a generic way as we keep getting various errors at different steps. > > Wtihout making it too long, we want to do the following: > a) retrieve and save certificate from server via URL > b)retrieve and save certificate chain from server > c) determine OCSP URL or CRL list URL > d1) verify cert against OCSP source OR > d2) download CRL; then verify cert against CRL > > Up to c), everything is straightforward. We use openssl 1.0.1e-60.el7 from > current CentOS 7. try this: CAFILE=/etc/pki/certs/ca-bundle.trust.crt CERT=/tmp/cert.crt <-- cert to validate ISSUER=/tmp/issuer.crt <-- issuing ca cert OCSPURL=$(openssl x509 -in $CERT -noout -ocsp_uri) OCSPHOST=$(echo "$OCSPURL" |gawk --field-separator=\/ '{ print $3 }' -) OCSPRESULT=$(openssl ocsp -CAfile $CAFILE -no_nonce -noverify -issuer $ISSUER -cert $CERT -url "$OCSPURL" -header Host $OCSPHOST |grep "$CERT") Thank you, we will try this, will probably take a couple of days. Regards, Jakob Curdes -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.sales at free.fr Thu Feb 23 17:54:48 2017 From: michel.sales at free.fr (Michel) Date: Thu, 23 Feb 2017 18:54:48 +0100 Subject: [openssl-users] Specify padding scheme with EVP_VerifyFinal In-Reply-To: References: Message-ID: <002b01d28dfd$ef230e20$cd692a60$@sales@free.fr> Hi, > Is it possible to specify a different padding scheme (e.g. RSA_PKCS1_PSS_PADDING) using this API ? > If not, what is the easiest way to work around this "limitation" ? Isn?t it what you are looking for : EVP_PKEY_CTX_set_rsa_padding() ? https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_CTX_set_rsa_padding.html and : https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying (OpenSSL version >= 1.0) Hope it helps, Michel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vkaliape at gmail.com Thu Feb 23 18:02:16 2017 From: vkaliape at gmail.com (Vijayakumar Kaliaperumal) Date: Thu, 23 Feb 2017 23:32:16 +0530 Subject: [openssl-users] DTLS Handshake fails with DTLSv1_listen Message-ID: Hi, While writing a DTLS server using DTLSv1_listen(), I found that when I receive a fragmented clienthello from the client, DTLS handshake fails. DTLSv1_listen stuck in the while loop (in the app). When I checked the man page of DTLSv1_listen(), it clearly says that API does not handle a fragmented clienthello. as it operates entirely statelessly ( Safeguard against DOS attacks ? ) However DTLS RFC clearly states that implementation must handle fragmented handshake messages RFC 4347 Datagram Transport Layer Security: ?When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.? Avoiding the fragmented clienthello is the only way out for this problem ? or any other alternatives exist ? Regards, Vijay -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at tuta.io Thu Feb 23 18:37:46 2017 From: openssl at tuta.io (openssl at tuta.io) Date: Thu, 23 Feb 2017 19:37:46 +0100 (CET) Subject: [openssl-users] Specify padding scheme with EVP_VerifyFinal In-Reply-To: <002b01d28dfd$ef230e20$cd692a60$@sales@free.fr> References: <> <002b01d28dfd$ef230e20$cd692a60$@sales@free.fr> Message-ID: Hi Michel, it looks like what I am looking for, but the software uses EVP_VerifyInit_ex which is a typedef for EVP_DigestInit_ex. How are those functions related to EVP_DigestVerifyInit? Can I use EVP_DigestVerify* functions along with EVP_Verify* functions? I must not break compatibility with the old implementation which needs to support arbitrary MD algorithms. Thank you for your response! Tom > > Hi, > > ? > > > > Is it possible to specify a different padding scheme (e.g. > RSA_PKCS1_PSS_PADDING) using this API> > ? > > > > If not, what is the easiest way to work around this "limitation" ? > > > > Isn?t it what you are looking for?: EVP_PKEY_CTX_set_rsa_padding() ? > > https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_CTX_set_rsa_padding.html > > and : > > https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying > > (OpenSSL version >= 1.0) > > ? > > Hope it helps, > > ? > > Michel. > > ? > > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Feb 23 21:35:33 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Feb 2017 21:35:33 +0000 Subject: [openssl-users] DTLS Handshake fails with DTLSv1_listen In-Reply-To: References: Message-ID: On 23/02/17 18:02, Vijayakumar Kaliaperumal wrote: > Hi, > > While writing a DTLS server using DTLSv1_listen(), I found that > when I receive a fragmented clienthello from the client, DTLS handshake > fails. DTLSv1_listen stuck in the while loop (in the app). > When I checked the man page of DTLSv1_listen(), it clearly says that > API does not handle a fragmented clienthello. as it operates entirely > statelessly ( Safeguard against DOS attacks ? ) Yes, DTLS is particularly susceptible to DoS attacks so the whole point of DTLSv1_listen() is to avoid that. > > However DTLS RFC clearly states that implementation must handle > fragmented handshake messages > > RFC 4347 Datagram Transport Layer Security: > ?When a DTLS implementation receives a handshake message fragment, it > MUST buffer it until it has the entire handshake message.? > Yes this issue was the subject of some discussion when we rewrote the DTLSv1_listen() implementation for version 1.1.0. Actually the documentation is slightly out-of-date. It was true at the time we did the initial rewrite, but we later made some amendments to relax that requirement a little. We now allow fragmented ClientHellos as long as the cookie is fully contained within the first fragment. We should probably fix the docs to say that. Fragmenting a ClientHello so much that that property isn't true would be a fairly mad thing to do IMO. You don't say which OpenSSL version you are using - 1.0.2 or 1.1.0. If 1.0.2 I would highly recommend that you upgrade to 1.1.0. The 1.0.2 implementation has all sorts of problems that are just unfixable (which is why we rewrote it). If you're already using 1.1.0, are you encountering ClientHello's that are fragmented to the point that the cookie isn't in the first fragment?? If so I'd be interested to know what client is doing that! > Avoiding the fragmented clienthello is the only way out for this problem > ? or any other alternatives exist ? There are 3 ways of doing this with OpenSSL: 1) Fully stateless. This is the preferred way - using DTLSv1_listen() 2) Stateful with cookie. With this way of doing things you don't use DTLSv1_listen() at all. You just use SSL_accept() like you would for a TLS connection. The underlying BIO is expected to be in a "connected" state. You need to set the SSL_OP_COOKIE_EXCHANGE option. This gives you "some" protection from DoS. It still allocates state on the server but some of the more expensive operations are deferred until after the cookie exchange loop has been completed. 3) Stateful without cookie. Like (2) but don't set SSL_OP_COOKIE_EXCHANGE. No protection at all from DoS. Approaches 2 + 3 can handle fully fragmented ClientHellos at the expense of reduced/no protection from DoS. Matt From mahesh116 at gmail.com Fri Feb 24 09:31:36 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Fri, 24 Feb 2017 15:01:36 +0530 Subject: [openssl-users] DTLS for SCTP connections In-Reply-To: References: Message-ID: Hi, I did some more search regarding this problem and found that its a defect in kernel SCTP. OS was built with linux kernel version 2.6 which is quite old. Defect Link : https://sourceforge.net/p/lksctp/mailman/message/27729264/ I upgraded to RHEL 7.1 and the problem resolved. Thanks for your support. On Thu, Feb 23, 2017 at 10:43 AM, mahesh gs wrote: > Hi Michael, > > I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and > openssl version is 1.1.0. > > SCTP version : > > [root at localhost DIAMETER]# rpm -qa | grep -i "sctp" > *lksctp-tools-1.0.10-5.el6.x86_64* > [root at localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64 > Name : lksctp-tools Relocations: (not relocatable) > Version : 1.0.10 Vendor: Red Hat, Inc. > Release : 5.el6 *Build Date: Mon 22 Feb 2010 > 12:24:33 PM CET* > Install Date: Wed 08 Feb 2017 10:08:12 AM CET Build Host: > hs20-bc1-2.build.redhat.com > Group : System Environment/Libraries Source RPM: > lksctp-tools-1.0.10-5.el6.src.rpm > Size : 203688 License: GPLv2 and GPLv2+ > and LGPLv2 and BSD > Signature : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID > 199e2f91fd431d51 > Packager : Red Hat, Inc. > URL : http://lksctp.sourceforge.net > Summary : User-space access to Linux Kernel SCTP > Description : > This is the lksctp-tools package for Linux Kernel SCTP (Stream Control > Transmission Protocol) Reference Implementation. > > > > Thanks, > Mahesh G S > > On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen franken.de> wrote: > >> > On 22 Feb 2017, at 07:47, mahesh gs wrote: >> > >> > Hi, >> > >> > Thank you for sharing the sample code. >> > >> > I tried running SCTP DTLS Echo server and client. I am facing strange >> problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs >> on the server side. >> > >> > Client side back trace >> > >> > (gdb) bt >> > #0 0x0000003db4c0ea10 in __recvmsg_nocancel () from >> /lib64/libpthread.so.0 >> > #1 0x00007ffff7a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 >> "\026\376\377", outl=17741) at bss_dgram.c:1178 >> > #2 0x00007ffff7a597a9 in BIO_read (b=0x6223f0, out=0x629073, >> outl=17741) at bio_lib.c:210 >> > #3 0x00007ffff7db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, >> extend=) at s3_pkt.c:258 >> > #4 0x00007ffff7dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676 >> > #5 0x00007ffff7dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, >> buf=0x7ffffffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938 >> > #6 0x00007ffff7dcdda5 in dtls1_get_message_fragment (s=0x622c70, >> st1=, stn=4449, max=30, ok=0x7ffffffee09c) >> > at d1_both.c:908 >> > #7 0x00007ffff7dce414 in dtls1_get_message (s=0x622c70, st1=4448, >> stn=4449, mt=14, max=30, ok=0x7ffffffee09c) at d1_both.c:512 >> > #8 0x00007ffff7dacaf9 in ssl3_get_server_done (s=0x622c70) at >> s3_clnt.c:2458 >> > #9 0x00007ffff7dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466 >> > #10 0x0000000000402f75 in start_client(char*, char*, int, int, int) () >> > #11 0x0000000000403573 in main () >> > >> > >> > Server side back trace >> > >> > (gdb) info threads >> > 2 Thread 0x7ffff793c700 (LWP 20161) 0x0000003db4c0ea2d in recvmsg () >> from /lib64/libpthread.so.0 >> > * 1 Thread 0x7ffff793e720 (LWP 20155) 0x0000003db4c0e84d in accept () >> from /lib64/libpthread.so.0 >> > (gdb) t 2 >> > [Switching to thread 2 (Thread 0x7ffff793c700 (LWP 20161))]#0 >> 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 >> > (gdb) bt >> > #0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 >> > #1 0x00007ffff7a633a6 in BIO_dgram_sctp_wait_for_dry >> (b=0x7ffff0001930) at bss_dgram.c:1803 >> > #2 0x00007ffff7dc7830 in dtls1_accept (s=0x7ffff00008c0) at >> d1_srvr.c:403 >> > #3 0x00000000004021ee in connection_handle(void*) () >> > #4 0x0000003db4c07851 in start_thread () from /lib64/libpthread.so.0 >> > #5 0x0000003db48e890d in clone () from /lib64/libc.so.6 >> > (gdb) >> > >> > >> > I am also attaching the wireshark trace (port 4443) and a server key >> for decoding wireshark. >> > >> > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443 >> > >> > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 >> -l 50 -n 5 16.181.38.161 >> > >> > Thanks in advance for your valuable input >> I've CCed Irene, who did some testing recently on FreeBSD, where the >> implementation works. >> The server is waiting for a sender dry event which it should get. >> >> Which version of OpenSSL are you using and which OS are you using? >> >> Best regards >> Michael >> > >> > Regards, >> > Mahesh G S >> > >> > >> > >> > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen < >> Michael.Tuexen at lurchi.franken.de> wrote: >> > > On 21 Feb 2017, at 09:53, mahesh gs wrote: >> > > >> > > Hi, >> > > >> > > We have a client, server applications that is using SCTP as a >> transport protocol. We have to secure the connections using DTLS. I am >> using openssl version 1.0.2 which supports DTLS. But the problem i am >> facing is usage of DTLS SCTP related API's. Openssl documentation does not >> clearly explain all the SCTP related API's and usage sequence. >> > > >> > > I have tried going though internet and found most of the sites >> redirect to one link for SCTP DTLS sample code. But this link is not >> working. >> > > >> > > http://sctp.fh-muenster.de/dtls-samples.html >> > Try >> > http://web.archive.org/web/20150617012520/http://sctp.fh-mue >> nster.de/dtls-samples.html >> > and yes, we need to bring the machine up again. >> > >> > Best regards >> > Michael >> > > >> > > If any of you has an sample code of DTLS adaptation for SCTP. It >> would immensely help me for my work. >> > > >> > > Looking forward to your valuable inputs. >> > > >> > > Thanks, >> > > Mahesh G S >> > > -- >> > > openssl-users mailing list >> > > To unsubscribe: https://mta.openssl.org/mailma >> n/listinfo/openssl-users >> > >> > -- >> > openssl-users mailing list >> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > >> > -- >> > openssl-users mailing list >> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Tuexen at lurchi.franken.de Fri Feb 24 11:59:19 2017 From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen) Date: Fri, 24 Feb 2017 12:59:19 +0100 Subject: [openssl-users] DTLS for SCTP connections In-Reply-To: References: Message-ID: <2173E563-2881-41CE-AD0D-AD5DC36EC29D@lurchi.franken.de> > On 24 Feb 2017, at 10:31, mahesh gs wrote: > > Hi, > > I did some more search regarding this problem and found that its a defect in kernel SCTP. OS was built with linux kernel version 2.6 which is quite old. > > Defect Link : https://sourceforge.net/p/lksctp/mailman/message/27729264/ > > I upgraded to RHEL 7.1 and the problem resolved. > Great. Thanks for letting us know. Best regards Michael > Thanks for your support. > > On Thu, Feb 23, 2017 at 10:43 AM, mahesh gs wrote: > Hi Michael, > > I am using "Red Hat Enterprise Linux Server release 6.4 (Santiago)" and openssl version is 1.1.0. > > SCTP version : > > [root at localhost DIAMETER]# rpm -qa | grep -i "sctp" > lksctp-tools-1.0.10-5.el6.x86_64 > [root at localhost DIAMETER]# rpm -qi lksctp-tools-1.0.10-5.el6.x86_64 > Name : lksctp-tools Relocations: (not relocatable) > Version : 1.0.10 Vendor: Red Hat, Inc. > Release : 5.el6 Build Date: Mon 22 Feb 2010 12:24:33 PM CET > Install Date: Wed 08 Feb 2017 10:08:12 AM CET Build Host: hs20-bc1-2.build.redhat.com > Group : System Environment/Libraries Source RPM: lksctp-tools-1.0.10-5.el6.src.rpm > Size : 203688 License: GPLv2 and GPLv2+ and LGPLv2 and BSD > Signature : RSA/8, Mon 16 Aug 2010 08:17:01 PM CEST, Key ID 199e2f91fd431d51 > Packager : Red Hat, Inc. > URL : http://lksctp.sourceforge.net > Summary : User-space access to Linux Kernel SCTP > Description : > This is the lksctp-tools package for Linux Kernel SCTP (Stream Control > Transmission Protocol) Reference Implementation. > > > > Thanks, > Mahesh G S > > On Wed, Feb 22, 2017 at 8:33 PM, Michael Tuexen wrote: > > On 22 Feb 2017, at 07:47, mahesh gs wrote: > > > > Hi, > > > > Thank you for sharing the sample code. > > > > I tried running SCTP DTLS Echo server and client. I am facing strange problem "ssl_connect" hangs on the client side, even the "ssl_accept" hangs on the server side. > > > > Client side back trace > > > > (gdb) bt > > #0 0x0000003db4c0ea10 in __recvmsg_nocancel () from /lib64/libpthread.so.0 > > #1 0x00007ffff7a64dc5 in dgram_sctp_read (b=0x6223f0, out=0x629073 "\026\376\377", outl=17741) at bss_dgram.c:1178 > > #2 0x00007ffff7a597a9 in BIO_read (b=0x6223f0, out=0x629073, outl=17741) at bio_lib.c:210 > > #3 0x00007ffff7db80e4 in ssl3_read_n (s=0x622c70, n=13, max=17741, extend=) at s3_pkt.c:258 > > #4 0x00007ffff7dcaf75 in dtls1_get_record (s=0x622c70) at d1_pkt.c:676 > > #5 0x00007ffff7dcb6b8 in dtls1_read_bytes (s=0x622c70, type=22, buf=0x7ffffffedfd0 "\006", len=12, peek=0) at d1_pkt.c:938 > > #6 0x00007ffff7dcdda5 in dtls1_get_message_fragment (s=0x622c70, st1=, stn=4449, max=30, ok=0x7ffffffee09c) > > at d1_both.c:908 > > #7 0x00007ffff7dce414 in dtls1_get_message (s=0x622c70, st1=4448, stn=4449, mt=14, max=30, ok=0x7ffffffee09c) at d1_both.c:512 > > #8 0x00007ffff7dacaf9 in ssl3_get_server_done (s=0x622c70) at s3_clnt.c:2458 > > #9 0x00007ffff7dc8467 in dtls1_connect (s=0x622c70) at d1_clnt.c:466 > > #10 0x0000000000402f75 in start_client(char*, char*, int, int, int) () > > #11 0x0000000000403573 in main () > > > > > > Server side back trace > > > > (gdb) info threads > > 2 Thread 0x7ffff793c700 (LWP 20161) 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > > * 1 Thread 0x7ffff793e720 (LWP 20155) 0x0000003db4c0e84d in accept () from /lib64/libpthread.so.0 > > (gdb) t 2 > > [Switching to thread 2 (Thread 0x7ffff793c700 (LWP 20161))]#0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > > (gdb) bt > > #0 0x0000003db4c0ea2d in recvmsg () from /lib64/libpthread.so.0 > > #1 0x00007ffff7a633a6 in BIO_dgram_sctp_wait_for_dry (b=0x7ffff0001930) at bss_dgram.c:1803 > > #2 0x00007ffff7dc7830 in dtls1_accept (s=0x7ffff00008c0) at d1_srvr.c:403 > > #3 0x00000000004021ee in connection_handle(void*) () > > #4 0x0000003db4c07851 in start_thread () from /lib64/libpthread.so.0 > > #5 0x0000003db48e890d in clone () from /lib64/libc.so.6 > > (gdb) > > > > > > I am also attaching the wireshark trace (port 4443) and a server key for decoding wireshark. > > > > Command used on server side: ./dtls_sctp_echo -L 16.181.38.161 -p 4443 > > > > Command used on client side : ./dtls_sctp_echo -L 16.181.38.161 -p 4443 -l 50 -n 5 16.181.38.161 > > > > Thanks in advance for your valuable input > I've CCed Irene, who did some testing recently on FreeBSD, where the implementation works. > The server is waiting for a sender dry event which it should get. > > Which version of OpenSSL are you using and which OS are you using? > > Best regards > Michael > > > > Regards, > > Mahesh G S > > > > > > > > On Tue, Feb 21, 2017 at 2:28 PM, Michael Tuexen wrote: > > > On 21 Feb 2017, at 09:53, mahesh gs wrote: > > > > > > Hi, > > > > > > We have a client, server applications that is using SCTP as a transport protocol. We have to secure the connections using DTLS. I am using openssl version 1.0.2 which supports DTLS. But the problem i am facing is usage of DTLS SCTP related API's. Openssl documentation does not clearly explain all the SCTP related API's and usage sequence. > > > > > > I have tried going though internet and found most of the sites redirect to one link for SCTP DTLS sample code. But this link is not working. > > > > > > http://sctp.fh-muenster.de/dtls-samples.html > > Try > > http://web.archive.org/web/20150617012520/http://sctp.fh-muenster.de/dtls-samples.html > > and yes, we need to bring the machine up again. > > > > Best regards > > Michael > > > > > > If any of you has an sample code of DTLS adaptation for SCTP. It would immensely help me for my work. > > > > > > Looking forward to your valuable inputs. > > > > > > Thanks, > > > Mahesh G S > > > -- > > > openssl-users mailing list > > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jsouthwell at serengeti.com Fri Feb 24 16:15:43 2017 From: jsouthwell at serengeti.com (Joseph Southwell) Date: Fri, 24 Feb 2017 11:15:43 -0500 Subject: [openssl-users] Help with "tlsv1 alert insufficient security" Message-ID: <12B418D6-FDCD-4AEB-A41A-24E31D74F31D@serengeti.com> We upgraded from 0.9.8 to 1.0.2 and now we are seeing that message when we try connecting to a server that previously worked. What does it mean and how can I figure out how to work around it? I can?t get the server to change anything and I need to be able to continue connecting to it. openssl s_client -connect xxxxxxx.com :#### -starttls ftp CONNECTED(00000170) 4960:error:1407742F:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert insufficient security:.\ssl\s23_clnt.c:770: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 88 bytes and written 317 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.1 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1487578706 Timeout : 300 (sec) Verify return code: 0 (ok) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Feb 24 20:57:30 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Feb 2017 20:57:30 +0000 Subject: [openssl-users] Help with "tlsv1 alert insufficient security" In-Reply-To: <12B418D6-FDCD-4AEB-A41A-24E31D74F31D@serengeti.com> References: <12B418D6-FDCD-4AEB-A41A-24E31D74F31D@serengeti.com> Message-ID: Later versions ratched up the security. Try -ciphers DEFAULT at SECLEVEL=0 From matt at openssl.org Fri Feb 24 21:11:09 2017 From: matt at openssl.org (Matt Caswell) Date: Fri, 24 Feb 2017 21:11:09 +0000 Subject: [openssl-users] Help with "tlsv1 alert insufficient security" In-Reply-To: <12B418D6-FDCD-4AEB-A41A-24E31D74F31D@serengeti.com> References: <12B418D6-FDCD-4AEB-A41A-24E31D74F31D@serengeti.com> Message-ID: <658d191b-567c-ed8d-6a5d-7ae7690b0cc1@openssl.org> On 24/02/17 16:15, Joseph Southwell wrote: > We upgraded from 0.9.8 to 1.0.2 and now we are seeing that message when > we try connecting to a server that previously worked. What does it mean > and how can I figure out how to work around it? I can?t get the server > to change anything and I need to be able to continue connecting to it. > > openssl s_client -connect xxxxxxx.com :#### > -starttls ftp > > CONNECTED(00000170) > 4960:error:1407742F:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert > insufficient security:.\ssl\s23_clnt.c:770: That is actually quite strange. This is the server sending the OpenSSL client an alert to say that you have insufficient security in your ClientHello. Without access to the server it is quite difficult to tell why. What is strange is the default security has been increased significantly between 0.9.8 and 1.0.2. Possibly some ciphers/parameters that were previously offered are no longer offered by default in 1.0.2 - and therefore the server can't find one it likes. Rich's suggestion is a good one, but unfortunately only applies to version 1.1.0 - it won't work in 1.0.2. You might want to try compiling with the "enable-weak-ssl-ciphers" config option to see if that makes a difference. Alternatively, try and find out what connection params are used when connecting from 0.9.8. That might give you a clue as to what settings are acceptable to the server. Matt From steve at openssl.org Sat Feb 25 03:32:37 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 25 Feb 2017 03:32:37 +0000 Subject: [openssl-users] Specify padding scheme with EVP_VerifyFinal In-Reply-To: References: <002b01d28dfd$ef230e20$cd692a60$@sales@free.fr> Message-ID: <20170225033237.GA7268@openssl.org> On Thu, Feb 23, 2017, openssl at tuta.io wrote: > Hi Michel, > > it looks like what I am looking for, but the software uses EVP_VerifyInit_ex which is a typedef for EVP_DigestInit_ex. How are those functions related to EVP_DigestVerifyInit? Can I use EVP_DigestVerify* functions along with EVP_Verify* functions? I must not break compatibility with the old implementation which needs to support arbitrary MD algorithms. > You have to use the EVP_Digest* functions if you want to change the RSA padding mode (or other parameters). This is not supported in the older EVP_Verify* API. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Sat Feb 25 03:35:43 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 25 Feb 2017 03:35:43 +0000 Subject: [openssl-users] Using RSASSA-PSS in command line smime / cms utility In-Reply-To: <359345130.3282354.1486989620281@mail.yahoo.com> References: <359345130.3282354.1486989620281.ref@mail.yahoo.com> <359345130.3282354.1486989620281@mail.yahoo.com> Message-ID: <20170225033543.GB7268@openssl.org> On Mon, Feb 13, 2017, Harakiri via openssl-users wrote: > Can i set the padding?RSASSA-PSS or alg?ECDSA via command line when using openssl smime or openssl cms command? > I can't find an option for it. You have to use the cms command and -keyopt rsa_padding_mode:pss check out the documentation of pkeutil for other PSS options such as setting the salt length. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Sat Feb 25 04:18:01 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 25 Feb 2017 04:18:01 +0000 Subject: [openssl-users] RSA_method_set_sign In-Reply-To: <4525401.EbsysoPbcS@devstation> References: <4525401.EbsysoPbcS@devstation> Message-ID: <20170225041801.GA7919@openssl.org> On Sat, Jan 14, 2017, Melvyn Sopacua wrote: > Hello all, > > Some background: I'd like to have a workstation that uses OpenSSL 1.1 > instead of a lower version. For that I'm porting various pieces of > software and quickly discovered that I was repeating myself. In addition > this teaches me more about the OpenSSL library, which I consider a great > benefit. > This resulted in me working on a forwards-compatibility library, using > the OpenSSL Wiki as a guide and the KDE QCA library as a testbed. Work > in progress can be seen at [1] and [2]. > > However, I believe I've now hit a brick wall: > Various functions in the realm RSA_method_set_* allow us to set > callbacks for RSA operations. However, I see no way to implement these, > since various (all?) X509 structures are now opaque. In addition, the > default RSA_sign implementation calls the rsa_sign callback in the > provided RSA structure, so we'll create an infinite loop if we wrap it > like this: > > RSA_method_set_sign(meth, my_rsa_sign); > int my_rsa_sign(...) { > RSA_sign(...); > store_state_on_our_object(); > } > > This is caused by the code in [3]. > That file also shows the problem: OpenSSL itself has access to X509_SIG > (and friends) internals as demonstrated in encode_pkcs1(). But, I don't > see any way to setup the same context(s) from outside OpenSSL. There's > no X509_*_set_ to setup the algorithm and parameters. > > Am I missing something or is it simply no longer possible to implement > these callbacks properly? > Can you give a pointer to the part that is causing problems? The rsa_sign interface is used where the only interface available is passed the digest algorithm and the raw digest and it performs its own formatting using DigestInfo etc. If you don't want to do that then the rsa_priv_enc method is more appropriate: it gets passed the block to encrypt (sign) and all the DigestInfo formatting is handled by OpenSSL itself. If you really need to it should be possible to set up or examine an X509_SIG structure using the available APIs. For example to retieve its fields you use X509_SIG_get0 and to set them X509_SIG_getm. The contained X509_ALGOR can be set up using X509_ALGOR_set0 and examined with X509_ALGOR_get0. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Sat Feb 25 04:53:10 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 25 Feb 2017 04:53:10 +0000 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: References: Message-ID: <20170225045310.GA8597@openssl.org> On Fri, Feb 17, 2017, Stephan M?hlstrasser wrote: > Hi, > > we use OpenSSL 1.0.2 together with PKCS#11 tokens by plugging > methods into the RSA_METHOD structure that interface with the > PKCS#11 token, and this works fine so far. However, for creating RSA > signatures with PSS padding this strategy doesn't work anymore, > because OpenSSL wants to directly encrypt with the private key in > this case, which is not possible in PKCS#11. > > Therefore my idea is to override the function pkey_rsa_sign() and > plug a wrapper around it into the EVP_PKEY_METHOD structure that is > associated with the EVP_PKEY_CTX to handle this special situation. > > The header evp.h declares the following functions among others: > > EVP_PKEY_METHOD* EVP_PKEY_meth_new(int id, int flags); > void EVP_PKEY_meth_copy(EVP_PKEY_METHOD *dst, const EVP_PKEY_METHOD *src); > > void EVP_PKEY_meth_set_sign(EVP_PKEY_METHOD *pmeth, > int (*sign_init)(EVP_PKEY_CTX *ctx), > int (*sign)(EVP_PKEY_CTX *ctx, unsigned char *sig, > size_t *siglen, const unsigned char *tbs, size_t tbslen)); > > But I can't figure out how to use these functions to achieve what I > want, because the following pieces seem to be missing: > > - Retrieve the EVP_PKEY_METHOD pointer from a EVP_PKEY_CTX pointer > - Set the EVP_PKEY_METHOD pointer for a EVP_PKEY_CTX pointer > - Retrieve the existing "sign_init" and "sign" function pointers > from an initialized EVP_PKEY_METHOD pointer for being able to wrap > them > > Is it possible to override methods in an EVP_PKEY_METHOD structure, > or would it be necessary to implement a whole OpenSSL engine to do > what I want? > It should be possible yes, though AFAIK no one has yet tried to do this so there may be some pieces missing. In outline you'd retrieve the appropriate EVP_PKEY_METHOD for the algorithm of interest, make a copy of it and then set the operation you wish to override, you can also retrieve the original operation in case you sometimes wish to call that. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From m.r.sopacua at gmail.com Sat Feb 25 09:06:55 2017 From: m.r.sopacua at gmail.com (Melvyn Sopacua) Date: Sat, 25 Feb 2017 10:06:55 +0100 Subject: [openssl-users] RSA_method_set_sign In-Reply-To: <20170225041801.GA7919@openssl.org> References: <4525401.EbsysoPbcS@devstation> <20170225041801.GA7919@openssl.org> Message-ID: <4983604.DQnrgpcOQS@devstation> Hi Stephen, thank you for taking the time to answer. On Saturday 25 February 2017 04:18:01 Dr. Stephen Henson wrote: > On Sat, Jan 14, 2017, Melvyn Sopacua wrote: > > This is caused by the code in [3]. > > That file also shows the problem: OpenSSL itself has access to > > X509_SIG (and friends) internals as demonstrated in encode_pkcs1(). > > But, I don't see any way to setup the same context(s) from outside > > OpenSSL. There's no X509_*_set_ to setup the algorithm > > and parameters. > > > > Am I missing something or is it simply no longer possible to > > implement these callbacks properly? > > Can you give a pointer to the part that is causing problems? The method I'm trying to port is this: https://github.com/melvyn-sopacua/qca/blob/openssl11-compat/plugins/qca-ossl/qca-ossl.cpp#L2745 > The rsa_sign interface is used where the only interface available is > passed the digest algorithm and the raw digest and it performs its > own formatting using DigestInfo etc. > > If you don't want to do that then the rsa_priv_enc method is more > appropriate: it gets passed the block to encrypt (sign) and all the > DigestInfo formatting is handled by OpenSSL itself. This may be a better approach in the long run. Thank you. > If you really need to it should be possible to set up or examine an > X509_SIG structure using the available APIs. For example to retieve > its fields you use X509_SIG_get0 and to set them X509_SIG_getm. Well, that explains why I couldn't find it. I was looking for something X509_SIG_*set* and never thought X509_SIG_getm() would be what I needed. So: sig.algor= &algor; sig.digest = &digest; becomes X509_SIG_getm(sig, palg, pdigest); *palg = algor; *pdigest = digest; And I'm guessing I have to free the structures retrieved by getm() if they're not NULL. I may just wrap this in a X509_SIG_setup() function so the freeing isn't forgotten. -- Melvyn Sopacua From steve at openssl.org Sat Feb 25 12:22:09 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 25 Feb 2017 12:22:09 +0000 Subject: [openssl-users] RSA_method_set_sign In-Reply-To: <4983604.DQnrgpcOQS@devstation> References: <4525401.EbsysoPbcS@devstation> <20170225041801.GA7919@openssl.org> <4983604.DQnrgpcOQS@devstation> Message-ID: <20170225122209.GA15470@openssl.org> On Sat, Feb 25, 2017, Melvyn Sopacua wrote: > Hi Stephen, > > thank you for taking the time to answer. > > On Saturday 25 February 2017 04:18:01 Dr. Stephen Henson wrote: > > On Sat, Jan 14, 2017, Melvyn Sopacua wrote: > > > This is caused by the code in [3]. > > > That file also shows the problem: OpenSSL itself has access to > > > X509_SIG (and friends) internals as demonstrated in encode_pkcs1(). > > > But, I don't see any way to setup the same context(s) from outside > > > OpenSSL. There's no X509_*_set_ to setup the algorithm > > > and parameters. > > > > > > Am I missing something or is it simply no longer possible to > > > implement these callbacks properly? > > > > Can you give a pointer to the part that is causing problems? > > The method I'm trying to port is this: > https://github.com/melvyn-sopacua/qca/blob/openssl11-compat/plugins/qca-ossl/qca-ossl.cpp#L2745 > > > The rsa_sign interface is used where the only interface available is > > passed the digest algorithm and the raw digest and it performs its > > own formatting using DigestInfo etc. > > > > If you don't want to do that then the rsa_priv_enc method is more > > appropriate: it gets passed the block to encrypt (sign) and all the > > DigestInfo formatting is handled by OpenSSL itself. > > This may be a better approach in the long run. Thank you. > Yes it looks like if you implement rsa_priv_enc instead the function becomes much simpler and you just need the last part at around line 2814. You also have to check the padding mode, all the X509_SIG stuff is then handle by OpenSSL itself. > > If you really need to it should be possible to set up or examine an > > X509_SIG structure using the available APIs. For example to retieve > > its fields you use X509_SIG_get0 and to set them X509_SIG_getm. > > Well, that explains why I couldn't find it. I was looking for something > X509_SIG_*set* and never thought X509_SIG_getm() would be what I needed. > > So: > sig.algor= &algor; > sig.digest = &digest; > becomes > X509_SIG_getm(sig, palg, pdigest); > *palg = algor; > *pdigest = digest; > > And I'm guessing I have to free the structures retrieved by getm() if > they're not NULL. I may just wrap this in a X509_SIG_setup() function so > the freeing isn't forgotten. > You can set the values in place using something like this: unsigned char *tmps = NULL; int tmpslen; X509_SIG *sig = X509_SIG_new(); X509_ALGOR *alg; ASN1_OCTET_STRING *digest; X509_SIG_getm(sig, &alg, &digest); X509_ALGOR_set0(alg, OBJ_nid2obj(type), V_ASN1_NULL, NULL); ASN1_STRING_set(digest, m, m_len); /* Allocate and encode */ tmpslen = i2d_X509_SIG(&sig, &tmps); X509_SIG_free(sig); Then the encoded structure is "tmpslen" bytes in the buffer "tmps" which you have to free up after use with OPENSSL_free(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From stm at pdflib.com Mon Feb 27 09:15:41 2017 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Mon, 27 Feb 2017 10:15:41 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: <20170225045310.GA8597@openssl.org> References: <20170225045310.GA8597@openssl.org> Message-ID: Steve, Am 25.02.17 um 05:53 schrieb Dr. Stephen Henson: > On Fri, Feb 17, 2017, Stephan M?hlstrasser wrote: > ... >> Is it possible to override methods in an EVP_PKEY_METHOD structure, >> or would it be necessary to implement a whole OpenSSL engine to do >> what I want? >> > > It should be possible yes, though AFAIK no one has yet tried to do this so > there may be some pieces missing. > > In outline you'd retrieve the appropriate EVP_PKEY_METHOD for the algorithm of > interest, make a copy of it and then set the operation you wish to override, > you can also retrieve the original operation in case you sometimes wish to > call that. thanks for confirming that this should be possible in principle. I guess my problem was that I thought one must retrieve the EVP_PKEY_METHOD from the EVP_PKEY_CTX pointer. As you are saying it must be retrieved for the algorithm, I think I understood now that it must be fetched via EVP_PKEY_meth_find(). Is the following sketch roughly appropriate? int my_sign_init_function(EVP_PKEY_CTX *ctx); int my_sign_function(EVP_PKEY_CTX *ctx, unsigned char *sig, size_t *siglen, const unsigned char *tbs, size_t tbslen); const EVP_PKEY_METHOD *rsa_meth = EVP_PKEY_meth_find(EVP_PKEY_RSA); EVP_PKEY_METHOD *new_rsa_meth = EVP_PKEY_meth_new(EVP_PKEY_RSA, 0); EVP_PKEY_meth_copy(new_rsa_meth, rsa_meth); EVP_PKEY_meth_set_sign(new_rsa_meth, my_sign_init_function, my_sign_function); EVP_PKEY_meth_add0(new_rsa_meth); What is still unclear to me is how to retrieve the original function pointers from the EVP_PKEY_METHOD. EVP_PKEY_METHOD is an opaque structure, and I could not find a getter counterpart for EVP_PKEY_meth_set_sign(). How is it supposed to be possible to retrieve the original operations from an EVP_PKEY_METHOD pointer? Thanks. -- Stephan From akshar.kanak1 at gmail.com Mon Feb 27 12:03:20 2017 From: akshar.kanak1 at gmail.com (Akshar Kanak) Date: Mon, 27 Feb 2017 17:33:20 +0530 Subject: [openssl-users] POODLE attack on TLS1.2 Message-ID: Dear Team In https://en.wikipedia.org/wiki/POODLE , It is mentioned that POODLE attack is possible aganist *TLS *also . has this issue been alredy addressed in openssl . Thanks and regards Akshar -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Feb 27 12:14:48 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Feb 2017 12:14:48 +0000 Subject: [openssl-users] POODLE attack on TLS1.2 In-Reply-To: References: Message-ID: <006bfe66-d8cb-ac30-cf49-b5e49ca10adc@openssl.org> On 27/02/17 12:03, Akshar Kanak wrote: > Dear Team > In https://en.wikipedia.org/wiki/POODLE , It is mentioned that > POODLE attack is possible aganist *TLS *also . has this issue been > alredy addressed in openssl . This was never an issue in OpenSSL - so there is nothing to address. This issue only affected certain implementations that did not correctly handle TLS padding (notably F5 and A10 devices). See: https://www.imperialviolet.org/2014/12/08/poodleagain.html Matt From Richard.Koenning at ts.fujitsu.com Mon Feb 27 12:16:28 2017 From: Richard.Koenning at ts.fujitsu.com (=?ISO-8859-1?Q?Richard_K=F6nning?=) Date: Mon, 27 Feb 2017 13:16:28 +0100 Subject: [openssl-users] POODLE attack on TLS1.2 In-Reply-To: References: Message-ID: <58B4189C.4060308@ts.fujitsu.com> On 27.02.2017 13:03, Akshar Kanak wrote: > Dear Team > In https://en.wikipedia.org/wiki/POODLE , It is mentioned that > POODLE attack is possible aganist *TLS *also . has this issue been > alredy addressed in openssl . > > Thanks and regards > Akshar As the corresponding section in the Wikipedia article says that is not a flaw in the TLS protocol but a flaw in it's implementations, more exactly in the implementation of CBC encryption mode. For being on the safe side take cipher suites not using CBC mode. Best regards, Richard From steve at openssl.org Mon Feb 27 14:34:12 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 27 Feb 2017 14:34:12 +0000 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: References: <20170225045310.GA8597@openssl.org> Message-ID: <20170227143412.GA7705@openssl.org> On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote: > Steve, > > Am 25.02.17 um 05:53 schrieb Dr. Stephen Henson: > >On Fri, Feb 17, 2017, Stephan M?hlstrasser wrote: > >... > >>Is it possible to override methods in an EVP_PKEY_METHOD structure, > >>or would it be necessary to implement a whole OpenSSL engine to do > >>what I want? > >> > > > >It should be possible yes, though AFAIK no one has yet tried to do this so > >there may be some pieces missing. > > > >In outline you'd retrieve the appropriate EVP_PKEY_METHOD for the algorithm of > >interest, make a copy of it and then set the operation you wish to override, > >you can also retrieve the original operation in case you sometimes wish to > >call that. > > thanks for confirming that this should be possible in principle. > > I guess my problem was that I thought one must retrieve the > EVP_PKEY_METHOD from the EVP_PKEY_CTX pointer. As you are saying it > must be retrieved for the algorithm, I think I understood now that > it must be fetched via EVP_PKEY_meth_find(). > > Is the following sketch roughly appropriate? > > int my_sign_init_function(EVP_PKEY_CTX *ctx); > int my_sign_function(EVP_PKEY_CTX *ctx, unsigned char *sig, size_t > *siglen, const unsigned char *tbs, size_t tbslen); > > const EVP_PKEY_METHOD *rsa_meth = EVP_PKEY_meth_find(EVP_PKEY_RSA); > EVP_PKEY_METHOD *new_rsa_meth = EVP_PKEY_meth_new(EVP_PKEY_RSA, 0); > EVP_PKEY_meth_copy(new_rsa_meth, rsa_meth); > EVP_PKEY_meth_set_sign(new_rsa_meth, my_sign_init_function, > my_sign_function); > EVP_PKEY_meth_add0(new_rsa_meth); > > What is still unclear to me is how to retrieve the original function > pointers from the EVP_PKEY_METHOD. EVP_PKEY_METHOD is an opaque > structure, and I could not find a getter counterpart for > EVP_PKEY_meth_set_sign(). > > How is it supposed to be possible to retrieve the original > operations from an EVP_PKEY_METHOD pointer? > Ah I see you're using OpenSSL 1.0.2. There isn't a way to get the existing function pointers in 1.0.2, the "getter" functions are only in 1.1.0. There shouldn't be any need to add the method to the list: it should be possible to associate an EVP_PKEY with a non-default method (e.g. explicitly or implemented in an ENGINE). I say *should* because there doesn't seem to be currently a way to do that without changing EVP_PKEY internal fields (which isn't possible in 1.1.0 anyway). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From stm at pdflib.com Mon Feb 27 14:55:29 2017 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Mon, 27 Feb 2017 15:55:29 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: <20170227143412.GA7705@openssl.org> References: <20170225045310.GA8597@openssl.org> <20170227143412.GA7705@openssl.org> Message-ID: <84ddd9a6-f018-2bdb-2750-ae5f35d7a120@pdflib.com> Am 27.02.17 um 15:34 schrieb Dr. Stephen Henson: > On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote: >> How is it supposed to be possible to retrieve the original >> operations from an EVP_PKEY_METHOD pointer? >> > > Ah I see you're using OpenSSL 1.0.2. There isn't a way to get the existing > function pointers in 1.0.2, the "getter" functions are only in 1.1.0. Ok, I looked at the evp.h header in the 1.1.0 branch, and there I can see the getter functions. So I understand that I would have to backport those getter functions to the 1.0.2 branch in my repository if I wanted to use them with 1.0.2. > There shouldn't be any need to add the method to the list: it should be > possible to associate an EVP_PKEY with a non-default method (e.g. explicitly > or implemented in an ENGINE). I say *should* because there doesn't seem to be > currently a way to do that without changing EVP_PKEY internal fields (which > isn't possible in 1.1.0 anyway). I'm sorry, I don't get what you are trying to tell me in the above paragraph. Are you talking about an alternative way to set up the methods in the EVP_PKEY_METHOD structure? -- Stephan From steve at openssl.org Mon Feb 27 15:33:02 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 27 Feb 2017 15:33:02 +0000 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: <84ddd9a6-f018-2bdb-2750-ae5f35d7a120@pdflib.com> References: <20170225045310.GA8597@openssl.org> <20170227143412.GA7705@openssl.org> <84ddd9a6-f018-2bdb-2750-ae5f35d7a120@pdflib.com> Message-ID: <20170227153302.GA9611@openssl.org> On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote: > Am 27.02.17 um 15:34 schrieb Dr. Stephen Henson: > > >There shouldn't be any need to add the method to the list: it should be > >possible to associate an EVP_PKEY with a non-default method (e.g. explicitly > >or implemented in an ENGINE). I say *should* because there doesn't seem to be > >currently a way to do that without changing EVP_PKEY internal fields (which > >isn't possible in 1.1.0 anyway). > > I'm sorry, I don't get what you are trying to tell me in the above > paragraph. Are you talking about an alternative way to set up the > methods in the EVP_PKEY_METHOD structure? > Well this is by analogy with how the other algorithm specific methods work. With RSA_METHOD et al there are two ways to provide your own mechanisms for operations. If it's a general purpose mechanism (e.g. a crypto accelerator) which should perform all RSA operations you can provide the default method. If you want to only affect certain keys (e.g. those tied to a specific HSM) you *can* do this via the default method and just check each key as it goes through (e.g. some ex_data attached to it) and only handle those of interest passing the rest to the default operation. There is an alternative way. You create a custom method and set that as the key's internal method. Then any existing keys use the default method as usual but the keys you care about go through the custom method. For EVP_PKEY_METHOD you can provide the default implementation for an algorithm but unfortunately there is no way to provide a key specific method which is transparently used. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From stm at pdflib.com Mon Feb 27 15:50:54 2017 From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=) Date: Mon, 27 Feb 2017 16:50:54 +0100 Subject: [openssl-users] How to override methods in EVP_PKEY_METHOD structure that is attached to a EVP_PKEY_CTX? In-Reply-To: <20170227153302.GA9611@openssl.org> References: <20170225045310.GA8597@openssl.org> <20170227143412.GA7705@openssl.org> <84ddd9a6-f018-2bdb-2750-ae5f35d7a120@pdflib.com> <20170227153302.GA9611@openssl.org> Message-ID: <10e0976c-69b3-61a6-a1c2-e42897c6a97c@pdflib.com> Am 27.02.17 um 16:33 schrieb Dr. Stephen Henson: > On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote: > >> Am 27.02.17 um 15:34 schrieb Dr. Stephen Henson: >> >>> There shouldn't be any need to add the method to the list: it should be >>> possible to associate an EVP_PKEY with a non-default method (e.g. explicitly >>> or implemented in an ENGINE). I say *should* because there doesn't seem to be >>> currently a way to do that without changing EVP_PKEY internal fields (which >>> isn't possible in 1.1.0 anyway). >> >> I'm sorry, I don't get what you are trying to tell me in the above >> paragraph. Are you talking about an alternative way to set up the >> methods in the EVP_PKEY_METHOD structure? >> > > Well this is by analogy with how the other algorithm specific methods work. > > With RSA_METHOD et al there are two ways to provide your own mechanisms for > operations. > > If it's a general purpose mechanism (e.g. a crypto accelerator) which should > perform all RSA operations you can provide the default method. > > If you want to only affect certain keys (e.g. those tied to a specific HSM) > you *can* do this via the default method and just check each key as it goes > through (e.g. some ex_data attached to it) and only handle those of interest > passing the rest to the default operation. > > There is an alternative way. You create a custom method and set that as the > key's internal method. Then any existing keys use the default method as usual > but the keys you care about go through the custom method. > > For EVP_PKEY_METHOD you can provide the default implementation for an > algorithm but unfortunately there is no way to provide a key specific method > which is transparently used. Ok, thank you for this explanation! I will try to make sense of this and I will see whether I am able to map this to the corresponding API calls and data structures... -- Stephan From m.r.sopacua at gmail.com Mon Feb 27 17:36:21 2017 From: m.r.sopacua at gmail.com (Melvyn Sopacua) Date: Mon, 27 Feb 2017 18:36:21 +0100 Subject: [openssl-users] RSA_method_set_sign In-Reply-To: <20170225122209.GA15470@openssl.org> References: <4525401.EbsysoPbcS@devstation> <4983604.DQnrgpcOQS@devstation> <20170225122209.GA15470@openssl.org> Message-ID: <3556409.gSozNeUfQe@devstation> On Saturday 25 February 2017 12:22:09 Dr. Stephen Henson wrote: > You can set the values in place using something like this: > > unsigned char *tmps = NULL; > int tmpslen; > X509_SIG *sig = X509_SIG_new(); > X509_ALGOR *alg; > ASN1_OCTET_STRING *digest; > X509_SIG_getm(sig, &alg, &digest); > X509_ALGOR_set0(alg, OBJ_nid2obj(type), V_ASN1_NULL, NULL); > ASN1_STRING_set(digest, m, m_len); > /* Allocate and encode */ > tmpslen = i2d_X509_SIG(&sig, &tmps); > X509_SIG_free(sig); Thanks. Totally clear now. But, I have to say, this method is badly named. It walks and talks like a set0() but is called getm(). This is why I assumed, the pointers may have been filled by X509_SIG_new() and I'd be responsible for them. -- Melvyn Sopacua -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshi.sanjaya at gmail.com Tue Feb 28 09:59:13 2017 From: joshi.sanjaya at gmail.com (Sanjaya Joshi) Date: Tue, 28 Feb 2017 15:29:13 +0530 Subject: [openssl-users] Reg, TLS over SCTP (SOCK_SEQPACKET) Message-ID: Hello, I understand that when implementing TLS over SCTP, if socket is opened with SOCK_STREAM (one-to-one connection), then normal openssl calls (SSL_accept, SSL_connect) can be used for TLS handshakes in a client/server program. But these calls don't work when SOCK_SEQPACKET (one-to-many connections) is used. Does openssl provide any alternatives for these calls ? Or an application need to perform the TLS handshakes manually ? Also, whether openssl has any sample program for TLS over SCTP with SOCK_SEQPACKET ? Would appreciate a quick reply. Thanks in advance. Regards, Sanjaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From tniessen at tnie.de Tue Feb 28 11:01:44 2017 From: tniessen at tnie.de (=?UTF-8?Q?Tobias_Nie=c3=9fen?=) Date: Tue, 28 Feb 2017 12:01:44 +0100 Subject: [openssl-users] Migrating from EVP_Verify*/EVP_Sign* to EVP_Digest* Message-ID: <3c5b57d2-aa37-1f2d-7e10-8bb154cf31f3@tnie.de> Hello, we are currently discussing support for RSASSA-PSS padding in the node.js built-in crypto module: https://github.com/nodejs/node/issues/1127 So far, the crypto module uses the older EVP_Sign/EVP_Verify APIs, which do not support specifying the padding (and salt length). We considered switching to the newer EVP_Digest* functions, but we cannot provide the public key during initialization of the signature / verification process as this would require unacceptable changes to the public API of the crypto module. Is there any way to use the new API without specifying the key during initialization? Considering that the old API just computes a message digest until EVP_SignFinal/EVP_VerifyFinal is called, shouldn't it be possible to do merely the same thing using the new API? If it is impossible, is there any workaround? Thank you in advance, Tobias From steve at openssl.org Tue Feb 28 11:49:16 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 28 Feb 2017 11:49:16 +0000 Subject: [openssl-users] Migrating from EVP_Verify*/EVP_Sign* to EVP_Digest* In-Reply-To: <3c5b57d2-aa37-1f2d-7e10-8bb154cf31f3@tnie.de> References: <3c5b57d2-aa37-1f2d-7e10-8bb154cf31f3@tnie.de> Message-ID: <20170228114916.GA31921@openssl.org> On Tue, Feb 28, 2017, Tobias Nie?en wrote: > Hello, > > we are currently discussing support for RSASSA-PSS padding in the > node.js built-in crypto module: > https://github.com/nodejs/node/issues/1127 > > So far, the crypto module uses the older EVP_Sign/EVP_Verify APIs, > which do not support specifying > the padding (and salt length). We considered switching to the newer > EVP_Digest* functions, but we > cannot provide the public key during initialization of the signature > / verification process as this would > require unacceptable changes to the public API of the crypto module. > Is there any way to use the > new API without specifying the key during initialization? > Considering that the old API just computes > a message digest until EVP_SignFinal/EVP_VerifyFinal is called, > shouldn't it be possible to do merely > the same thing using the new API? > No there isn't with the new API. The reason for that is that some operations performed (for example which digests can be used, or which salt lengths are permissible for PSS) depend on the public key. For example in the master branch RSA-PSS keys can restrict the digest which can be use with the key. The way the new API is structured you get the error as soon as you attempt the operation. > If it is impossible, is there any workaround? > There is an alternative which may help. Instead of using EVP_Sign* which computes the digest and signs with it you can instead call EVP_DigestInit_ex, EVP_DigestUpdate and EVP_DigestFinal_ex() to compute the raw digest. Then you can use the EVP_PKEY APIs to sign the raw digest with EVP_PKEY_sign() using RSA-PSS or verify it with EVP_PKEY_verify(). If that isn't clear let me know and I'll explain further. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Tue Feb 28 13:33:17 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 28 Feb 2017 13:33:17 +0000 Subject: [openssl-users] Reg, TLS over SCTP (SOCK_SEQPACKET) In-Reply-To: References: Message-ID: <0cd2f7cd66794e7193596f9788981521@usma1ex-dag1mb1.msg.corp.akamai.com> > But these calls don't work when?SOCK_SEQPACKET (one-to-many connections) is used. Does openssl provide any alternatives for these calls ? Or an application need to perform the TLS handshakes manually ? This is not supported, and there are no demo's available.