From alexhultman at gmail.com Wed Aug 1 06:27:38 2018 From: alexhultman at gmail.com (Alex H) Date: Wed, 1 Aug 2018 08:27:38 +0200 Subject: [openssl-users] Shutdown details Message-ID: Hi, I have trouble understanding the details of TLS shutdown. I get the basics but, Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry. That is, after sending a close_notify, can I receive data before getting my client_notify response? The sources of SSL_write checks for SSL_SENT_SHUTDOWN state and returns with error if set, but does not check for SSL_RECEIVED_SHUTDOWN. This indicates somehow I'm allowed to still send data after received a close_notify? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bin.ichiki.he at hitachi-solutions.com Wed Aug 1 08:14:58 2018 From: bin.ichiki.he at hitachi-solutions.com (=?iso-2022-jp?B?GyRCO1RQVElSGyhCIC8gSUNISUtJGyRCISQbKEJCSU4=?=) Date: Wed, 1 Aug 2018 08:14:58 +0000 Subject: [openssl-users] openssl-1.1.1 make test error on Red Hat Enterprise Linux 6.1. Message-ID: Hello, everyone. My name is Bin Ichiki. I'm trying to install openssl-1.1.1-pre8 on Red Hat Enterprise Linux 6.1(RHEL6.1). But when I ran ?make test?, test failed as following log: Test Summary Report ------------------- ../test/recipes/04-test_err.t (Wstat: 256 Tests: 1 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=148, Tests=1340, 270 wallclock secs ( 1.70 usr 0.17 sys + 239.19 cusr 20.62 csys = 261.68 CPU) Result: FAIL I think, if an errno is changed other than EINVAL after the function ERR_get_error was executed, this test will fail. Therefore I investigated the place where an errno is changed. The follows are back trace from the processes that changed the errno. (gdb) bt #0 0x0081b505 in __xpg_strerror_r () from /lib/libc.so.6 #1 0x002e2ec0 in openssl_strerror_r (errnum=11, buf=0x3d4d00 "", buflen=32) at crypto/o_str.c:234 #2 0x002b0460 in build_SYS_str_reasons () at crypto/err/err.c:217 #3 0x002b07a5 in ERR_load_ERR_strings () at crypto/err/err.c:327 #4 0x002b1ba3 in err_load_crypto_strings_int () at crypto/err/err_all.c:46 #5 0x002d2fcc in ossl_init_load_crypto_strings () at crypto/init.c:182 #6 0x002d2fa2 in ossl_init_load_crypto_strings_ossl_ () at crypto/init.c:170 #7 0x003e3920 in pthread_once () from /lib/libpthread.so.0 #8 0x0033597b in CRYPTO_THREAD_run_once (once=0x3d5cc4, init=0x2d2f8b ) at crypto/threads_pthread.c:113 #9 0x002d36b6 in OPENSSL_init_crypto (opts=2, settings=0x0) at crypto/init.c:584 #10 0x002b156b in ERR_get_state () at crypto/err/err.c:702 #11 0x002b0d95 in get_error_values (inc=1, top=0, file=0x0, line=0x0, data=0x0, flags=0x0) at crypto/err/err.c:483 #12 0x002b0ba7 in ERR_get_error () at crypto/err/err.c:429 A version of glibc in RHEL6 is 2.12. The strerror_r function (XSI-compliant) in glibc 2.12 changes errno. When errnum parameter is 11, the error description string is "Resource temporarily unavailable". The area size for this string is 33. but buflen parameter is 32. The buffer area is insufficient. So errno is set to ERANGE and 04-test_err.t fails. Will be this problem fixed until OpenSSL 1.1.1 is released? Thank you. From tim.fortinbras at gmail.com Wed Aug 1 08:19:29 2018 From: tim.fortinbras at gmail.com (timmy pony) Date: Wed, 1 Aug 2018 09:19:29 +0100 Subject: [openssl-users] (no subject) Message-ID: Hi, Trying to get the Openssl command line version of the following snippet. I have tried this openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 codeTosign.txt But the the results do not match ? ``` From: "tim.fortinbras" To: openssl-users at openssl.org Cc: Bcc: Date: Tue, 31 Jul 2018 06:48:59 -0700 (MST) Subject: Looking for exact openssl commands to do the following from command line ? import java.security.KeyFactory; import java.security.Signature; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class SHA256RSA { public static void main(String[] args) throws Exception { String input = "sample input"; // Not a real private key! Replace with your private key! String strPk = "-----BEGIN PRIVATE KEY-----\nMIIEvwIBADANBgkqhkiG9" + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG" + "........................................................" + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n" + "-----END PRIVATE KEY-----\n"; String base64Signature = signSHA256RSA(input,strPk); System.out.println("Signature="+base64Signature); } // Create base64 encoded signature using SHA256/RSA. private static String signSHA256RSA(String input, String strPk) throws Exception { // Remove markers and new line characters in private key String realPK = strPk.replaceAll("-----END PRIVATE KEY-----", "") .replaceAll("-----BEGIN PRIVATE KEY-----", "") .replaceAll("\n", ""); byte[] b1 = Base64.getDecoder().decode(realPK); PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(b1); KeyFactory kf = KeyFactory.getInstance("RSA"); Signature privateSignature = Signature.getInstance("SHA256withRSA"); privateSignature.initSign(kf.generatePrivate(spec)); privateSignature.update(input.getBytes("UTF-8")); byte[] s = privateSignature.sign(); return Base64.getEncoder().encodeToString(s); } } ``` -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.fortinbras at gmail.com Wed Aug 1 08:24:38 2018 From: tim.fortinbras at gmail.com (timmy pony) Date: Wed, 1 Aug 2018 09:24:38 +0100 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? Message-ID: Hi, Could some openssl expert please advise ? Trying to get the equivalent Openssl command-line version of the following java snippet. I have tried this openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 codeTosign.txt But the the results do not match ? ``` From: "tim.fortinbras" To: openssl-users at openssl.org Cc: Bcc: Date: Tue, 31 Jul 2018 06:48:59 -0700 (MST) Subject: Looking for exact openssl commands to do the following from command line ? import java.security.KeyFactory; import java.security.Signature; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class SHA256RSA { public static void main(String[] args) throws Exception { String input = "sample input"; // Not a real private key! Replace with your private key! String strPk = "-----BEGIN PRIVATE KEY-----\nMIIEvwIBADANBgkqhkiG9" + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG" + "........................................................" + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n" + "-----END PRIVATE KEY-----\n"; String base64Signature = signSHA256RSA(input,strPk); System.out.println("Signature="+base64Signature); } // Create base64 encoded signature using SHA256/RSA. private static String signSHA256RSA(String input, String strPk) throws Exception { // Remove markers and new line characters in private key String realPK = strPk.replaceAll("-----END PRIVATE KEY-----", "") .replaceAll("-----BEGIN PRIVATE KEY-----", "") .replaceAll("\n", ""); byte[] b1 = Base64.getDecoder().decode(realPK); PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(b1); KeyFactory kf = KeyFactory.getInstance("RSA"); Signature privateSignature = Signature.getInstance("SHA256withRSA"); privateSignature.initSign(kf.generatePrivate(spec)); privateSignature.update(input.getBytes("UTF-8")); byte[] s = privateSignature.sign(); return Base64.getEncoder().encodeToString(s); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Aug 1 08:42:47 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 1 Aug 2018 09:42:47 +0100 Subject: [openssl-users] openssl-1.1.1 make test error on Red Hat Enterprise Linux 6.1. In-Reply-To: References: Message-ID: Please can you submit this problem as a github issue: https://github.com/openssl/openssl/issues Thanks Matt On 01/08/18 09:14, ??? / ICHIKI?BIN wrote: > Hello, everyone. My name is Bin Ichiki. > > I'm trying to install openssl-1.1.1-pre8 on Red Hat Enterprise Linux 6.1(RHEL6.1). > > But when I ran ?make test?, test failed as following log: > > Test Summary Report > ------------------- > ../test/recipes/04-test_err.t (Wstat: 256 Tests: 1 Failed: 1) > Failed test: 1 > Non-zero exit status: 1 > Files=148, Tests=1340, 270 wallclock secs ( 1.70 usr 0.17 sys + 239.19 cusr 20.62 csys = 261.68 CPU) > Result: FAIL > > > I think, if an errno is changed other than EINVAL after the function ERR_get_error was executed, this test will fail. > > Therefore I investigated the place where an errno is changed. > > The follows are back trace from the processes that changed the errno. > > > (gdb) bt > #0 0x0081b505 in __xpg_strerror_r () from /lib/libc.so.6 > #1 0x002e2ec0 in openssl_strerror_r (errnum=11, buf=0x3d4d00 "", buflen=32) at crypto/o_str.c:234 > #2 0x002b0460 in build_SYS_str_reasons () at crypto/err/err.c:217 > #3 0x002b07a5 in ERR_load_ERR_strings () at crypto/err/err.c:327 > #4 0x002b1ba3 in err_load_crypto_strings_int () at crypto/err/err_all.c:46 > #5 0x002d2fcc in ossl_init_load_crypto_strings () at crypto/init.c:182 > #6 0x002d2fa2 in ossl_init_load_crypto_strings_ossl_ () at crypto/init.c:170 > #7 0x003e3920 in pthread_once () from /lib/libpthread.so.0 > #8 0x0033597b in CRYPTO_THREAD_run_once (once=0x3d5cc4, init=0x2d2f8b ) at crypto/threads_pthread.c:113 > #9 0x002d36b6 in OPENSSL_init_crypto (opts=2, settings=0x0) at crypto/init.c:584 > #10 0x002b156b in ERR_get_state () at crypto/err/err.c:702 > #11 0x002b0d95 in get_error_values (inc=1, top=0, file=0x0, line=0x0, data=0x0, flags=0x0) at crypto/err/err.c:483 > #12 0x002b0ba7 in ERR_get_error () at crypto/err/err.c:429 > > > A version of glibc in RHEL6 is 2.12. > > The strerror_r function (XSI-compliant) in glibc 2.12 changes errno. > > When errnum parameter is 11, the error description string is "Resource temporarily unavailable". > > The area size for this string is 33. but buflen parameter is 32. The buffer area is insufficient. > > So errno is set to ERANGE and 04-test_err.t fails. > > Will be this problem fixed until OpenSSL 1.1.1 is released? > > > Thank you. > From thulasi.goriparthi at gmail.com Wed Aug 1 09:32:28 2018 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 1 Aug 2018 15:02:28 +0530 Subject: [openssl-users] Chinese remainder algorithm In-Reply-To: References: Message-ID: Hello Jan, Decide on what your public exponent(e) should be, and either use RSA_X931_derive_ex() if you are using an older openssl which supports this function or follow rsa_builtin_keygen() from crypto/rsa/rsa_gen.c on how to derive private exponent(d) and modulus(n). By the way, technically, you do not need private exponent(d) for signing, as you already have CRT components. What is the function that complained about missing d? Thanks, Thulasi. On 31 July 2018 at 16:19, Jan Bilek wrote: > Hi all, > > I need to reconstruct public and private keys for data signing operation > from p, q, dmp1, dmq1 and iqmp. When I fill values in as per below then > OpenSSL complains about missing d. > > RSA* pkey = RSA_new(); > pkey->n = NULL; > pkey->e = NULL; > pkey->d = NULL; > > pkey->p = BN_bin2bn(secureP.data(), secureP.size(), NULL); > pkey->q = BN_bin2bn(secureQ.data(), secureQ.size(), NULL); > pkey->dmp1 = BN_bin2bn(secureDmp1.data(), secureDmp1.size(), NULL); > pkey->dmq1 = BN_bin2bn(secureDmq1.data(), secureDmq1.size(), NULL); > pkey->iqmp = BN_bin2bn(secureIqmp.data(), secureIqmp.size(), NULL); > > I did my homework on Google/Stackoverflow/OpenSSL docu, but I haven't been > able to find out any good way to do this, while it is obvious that openssl > needs to know this by deafult for its internals. > Would you have any hint on where next with this? > > Thank you, > Jan > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From vc.chakrapani at gmail.com Wed Aug 1 10:13:09 2018 From: vc.chakrapani at gmail.com (Chakrapani Reddy) Date: Wed, 1 Aug 2018 15:43:09 +0530 Subject: [openssl-users] Help : TLS 1.3 Server is not listening on the default port Message-ID: Hello, Wanted to try to capture the TLS1.3 message flow using openssl-1.1.1-pre7 and used the below command to run the server. [root at vm bin]# pwd /opt/build/openssl-1.1.1-pre7/bin *[root at vm bin]# ./openssl s_server -cert server.crt -key server1.key* But it is throwing the below error : Using default temp DH parameters *47306412798048:error:02004061:system library:socket:unknown:crypto/bio/b_sock2.c:49:47306412798048:error:2008C076:BIO routines:BIO_socket:unable to create socket:crypto/bio/b_sock2.c:50:* 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 0 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 0 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) ldd ./openssl linux-vdso.so.1 => (0x00007fff6c9fd000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003fc2200000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003fc2a00000) libc.so.6 => /lib64/libc.so.6 (0x0000003fc1e00000) /lib64/ld-linux-x86-64.so.2 (0x0000003fc1600000) Shall we know how to make it working? Best Regards, Chakrapani -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed Aug 1 12:49:34 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 1 Aug 2018 12:49:34 +0000 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <65b27675-3029-18a2-fa57-becb807b59c4@cloudandheat.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <65b27675-3029-18a2-fa57-becb807b59c4@cloudandheat.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Christian B?hme > Sent: Tuesday, July 31, 2018 10:16 > > On 30.07.2018 20:12, Michael Wojcik wrote: > > > FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap, but RLIMIT_DATA as > > applying only to malloc. (That is, mmap'd pages do not count against the data limit.) > > mmap() , by defninition, populates the process' virtual address space, and if that > is limited in size, artificially or not, then the call is going to fail, eventually. That's irrelevant to the statement you quoted, which was about the SUS process-limit mechanism (setrusage et al.), not the process address space. > > Agreed. And I'm not endorsing the mmap approach for this problem anyway - I'd use a streaming > > approach, so I'm not limited by address space. > > This structure, if held in a regular file, can be processed quite non-linearly, > and without mmap()'ing its entire contents. Indeed. I still don't see any compelling reason to mmap it at all. > The pure streaming approach may be appropriate for file descriptors that are not > seekable like sockets, pipes, tty ends etcpp., whereas with egular files, random > access schemes using either pread(v)(2) or lseek(2) in combination with > read(v)(2) can be employed. Or regular files could also be processed sequentially. What's the advantage of making seekable sources a special case? In any case, the OpenSSL apps are a convenience and a set of samples. You can always write your own version of the cms app. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Wed Aug 1 12:56:06 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 08:56:06 -0400 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <33ac87a7-95c0-4b90-9426-b4c72da54ac1@wisemo.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <76DDA20E-6704-4913-B045-238561DD80AA@dukhovni.org> <33ac87a7-95c0-4b90-9426-b4c72da54ac1@wisemo.com> Message-ID: <20180801125606.GA47858@straasha.imrryr.org> On Tue, Jul 31, 2018 at 06:14:18PM +0200, Jakob Bohm wrote: > > CMS works fine for small messages, and could even be used to construct > > the integrity-protected chunks in a higher-level protocol. CMS is > > not appropriate for multi-gigabyte or terabyte, ... datasets. > > Actually, the CMS format itself is clearly designed for streamed decoding. It is not, because there is no integrity protection until you reach the end of the message. In a packetized format designed for streaming, each chunk and their sequencing is integrity protected, streaming extractors are only exposed to (tamper-evident) truncation attacks. -- Viktor. From Michael.Wojcik at microfocus.com Wed Aug 1 13:31:26 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 1 Aug 2018 13:31:26 +0000 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <20180801125606.GA47858@straasha.imrryr.org> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <76DDA20E-6704-4913-B045-238561DD80AA@dukhovni.org> <33ac87a7-95c0-4b90-9426-b4c72da54ac1@wisemo.com> <20180801125606.GA47858@straasha.imrryr.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Wednesday, August 01, 2018 06:56 > > On Tue, Jul 31, 2018 at 06:14:18PM +0200, Jakob Bohm wrote: > > > Actually, the CMS format itself is clearly designed for streamed decoding. > > It is not, because there is no integrity protection until you reach > the end of the message. In a packetized format designed for > streaming, each chunk and their sequencing is integrity protected, > streaming extractors are only exposed to (tamper-evident) truncation > attacks. And thus falling foul of Moxie Marlinspike's Cryptographic Doom Principle: If you don't verify integrity first, sooner or later you'll be in trouble. While CMS has been updated, its roots are long - PKCS#7 is 20 years old, after all, and RFC 5652 is nearing the end of its first decade. Back then, deferring the integrity check to the end wasn't seen as a problem. Today we know better - which is why many people prefer AEAD modes. CMS with an AEAD mode (such as AES128-GCM) ought to avoid the integrity-protection issue for the encrypted content, but not for the other parts of the message, I assume. (I'm no CMS expert so I may be missing something there.) And, of course, both sender and recipient would have to support that algorithm. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Wed Aug 1 13:37:11 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 09:37:11 -0400 Subject: [openssl-users] openssl-1.1.1 make test error on Red Hat Enterprise Linux 6.1. In-Reply-To: References: Message-ID: > On Aug 1, 2018, at 4:42 AM, Matt Caswell wrote: > > Please can you submit this problem as a github issue: > > https://github.com/openssl/openssl/issues We certainly need to raise the buffer size, for example on MacOS/X and FreeBSD errno 47 has a (coincidentally) 47-byte long error message: $ perl -le ' for ($i = 0; $i < 256; ++$i) { $! = $i; $l = length("$!"); if ($l > $m) { $m = $l; $n = $i; } last if ($i eq "$!"); } $! = $n; print "$i: $n: $m: $!"; ' 97[*]: 47: 47: Address family not supported by protocol family This will also be affected by the locale. I'd set the limit generously at 128 bytes. -- -- Viktor. [*] FreeBSD has 96 error strings, while running the same Perl script on MacOS/X demonstrates 106 error strings. From openssl-users at dukhovni.org Wed Aug 1 13:42:44 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 09:42:44 -0400 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <76DDA20E-6704-4913-B045-238561DD80AA@dukhovni.org> <33ac87a7-95c0-4b90-9426-b4c72da54ac1@wisemo.com> <20180801125606.GA47858@straasha.imrryr.org> Message-ID: <2DF0C0C1-A0CC-45D3-AB7B-B8360417B2B7@dukhovni.org> > On Aug 1, 2018, at 9:31 AM, Michael Wojcik wrote: > > CMS with an AEAD mode (such as AES128-GCM) ought to avoid the integrity-protection issue for the encrypted content, but not for the other parts of the message, I assume. (I'm no CMS expert so I may be missing something there.) And, of course, both sender and recipient would have to support that algorithm. Not if you make it streaming. A streaming implementing will emit almost the entirety of the decrypted message before checking integrity at the end and finding out that some part of it (already output) was wrong. -- Viktor. From openssl-users at dukhovni.org Wed Aug 1 14:00:01 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 10:00:01 -0400 Subject: [openssl-users] Initialising OpenSSL more than once - how do we handle this? In-Reply-To: <78dfbb09-7bfc-d1fe-7d0a-ddf5ae4a3737@openssl.org> References: <01EC6E16-FAD9-436E-9053-86A9127AE417@sharp.fm> <04999B37-294B-44BA-A98E-A5716E434C76@sharp.fm> <6F1F3A11-D7A9-4883-A295-12FC72D7D3A4@dukhovni.org> <6EEE7BD9-414B-4223-A372-20F7D83D059D@dukhovni.org> <35b5e9e9-3100-677b-b274-8c02da717089@jordan.maileater.net> <95ab3b6e-8e94-00e8-ee83-d7e38e1cf169@gmail.com> <2E3F9F82-7E06-4175-A715-25B5D5CD69F2@akamai.com> <8afb3b55-f403-75bd-1096-31e5276f4d38@gmail.com> <78dfbb09-7bfc-d1fe-7d0a-ddf5ae4a3737@openssl.org> Message-ID: <8C8C4B3B-6C7B-4314-8CF9-51D4837B4B6B@dukhovni.org> > On Jul 31, 2018, at 4:59 AM, Matt Caswell wrote: > > To be clear I can only think of one leak that we have at process exit > (well technically its two instances of the same thing). And that leak is > not the result of a *mistake*. It is a deliberate design decision to > workaround around a problem on some platforms (i.e. anything that isn't > Windows, Linux or Solaris, IIRC). There's at least one more, we don't call X509_PURPOSE_cleanup(), without which we leak memory allocated via X509_PURPOSE_add(). There may be other static allocations that the test suite does not exercise. -- Viktor. From ronydm9890 at gmail.com Wed Aug 1 14:36:33 2018 From: ronydm9890 at gmail.com (Rony DM) Date: Wed, 1 Aug 2018 10:36:33 -0400 Subject: [openssl-users] Support for EC key generation in engine interface Message-ID: Hello, Does the OpenSSL engine interface allow EC key generation to be offloaded to the engine? We are able to find bindings for ECDSA and ECDH, but for not for generating the key. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Aug 1 15:17:42 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 11:17:42 -0400 Subject: [openssl-users] unknown cipher? In-Reply-To: References: Message-ID: <081D19FB-FD71-4705-9613-8995B8FC1F92@dukhovni.org> > On Jul 31, 2018, at 5:08 PM, Henderson, Karl wrote: > > When I type: > > openssl ciphers -tls1_3 -stdname -V > > I see this as one of the results: > > 0x13,0x02 - TLS_AES_256_GCM_SHA384 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD This is a TLS cipher-suite. > However, when I try to do a speed test on this algorithm > > openssl speed -evp TLS_AES_256_GCM_SHA384 This command tests the performance of basic cryptographic algorithms supported by the libcrypto EVP layer, such as AES, SHA256, RSA, ... > speed: TLS_AES_256_GCM_SHA384 is an unknown cipher or digest > > What am I missing? TLS cipher-suites are from libssl, and are not EVP-layer cryptographic algorithms. -- Viktor. From openssl-users at dukhovni.org Wed Aug 1 15:28:11 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 11:28:11 -0400 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? In-Reply-To: References: Message-ID: <20180801152811.GB47858@straasha.imrryr.org> On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote: > I have tried this > > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 codeTosign.txt This produces raw binary output, no base64 encoding. What is the content of the file "codeToSign.txt"? Post the output of: od -tx1 < /tmp/codeToSign.txt > public class SHA256RSA { > > public static void main(String[] args) throws Exception { > String input = "sample input"; This input has no newline ending, perhaps the disk file does. > // Not a real private key! Replace with your private key! > String strPk = "-----BEGIN PRIVATE KEY-----\nMIIEvwIBADANBgkqhkiG9" > + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG" > + "........................................................" > + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n" > + "-----END PRIVATE KEY-----\n"; I sure hope your production code will *NOT* have the private key embedded in the executable. > String base64Signature = signSHA256RSA(input,strPk); > System.out.println("Signature="+base64Signature); This outputs a signature encoded in base64. -- Viktor. From tim.fortinbras at gmail.com Wed Aug 1 16:14:42 2018 From: tim.fortinbras at gmail.com (timmy pony) Date: Wed, 1 Aug 2018 17:14:42 +0100 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? In-Reply-To: <20180801152811.GB47858@straasha.imrryr.org> References: <20180801152811.GB47858@straasha.imrryr.org> Message-ID: Thanks Viktor, for assistance ..... The embedded private key "skeleton" is only for visualisation purposes; No it will not. the openssl command returns binary. so i can do .But they are still coming out different. openssl base64 -in /tmp/sign.sha256 -out On Wed, Aug 1, 2018 at 4:28 PM Viktor Dukhovni wrote: > On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote: > > > I have tried this > > > > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 > codeTosign.txt > > This produces raw binary output, no base64 encoding. What is the > content of the file "codeToSign.txt"? Post the output of: > > od -tx1 < /tmp/codeToSign.txt > > > public class SHA256RSA { > > > > public static void main(String[] args) throws Exception { > > String input = "sample input"; > > This input has no newline ending, perhaps the disk file does. > > > // Not a real private key! Replace with your private key! > > String strPk = "-----BEGIN PRIVATE > KEY-----\nMIIEvwIBADANBgkqhkiG9" > > + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG" > > + > "........................................................" > > + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n" > > + "-----END PRIVATE KEY-----\n"; > > I sure hope your production code will *NOT* have the private key > embedded in the executable. > > > String base64Signature = signSHA256RSA(input,strPk); > > System.out.println("Signature="+base64Signature); > > This outputs a signature encoded in base64. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Aug 1 16:16:37 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 12:16:37 -0400 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? In-Reply-To: References: <20180801152811.GB47858@straasha.imrryr.org> Message-ID: > On Aug 1, 2018, at 12:14 PM, timmy pony wrote: > > Thanks Viktor, > for assistance ..... > The embedded private key "skeleton" is only for visualisation purposes; No it will not. > > > the openssl command returns binary. > so i can do .But they are still coming out different. > > openssl base64 -in /tmp/sign.sha256 -out Please re-read my previous post and respond to *all* the points. -- Viktor. From tim.fortinbras at gmail.com Wed Aug 1 16:47:20 2018 From: tim.fortinbras at gmail.com (timmy pony) Date: Wed, 1 Aug 2018 17:47:20 +0100 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? In-Reply-To: <20180801152811.GB47858@straasha.imrryr.org> References: <20180801152811.GB47858@straasha.imrryr.org> Message-ID: Hi Vicktor, Speed read the previous mail. On Wed, Aug 1, 2018 at 4:28 PM Viktor Dukhovni wrote: > On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote: > > > I have tried this > > > > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 > codeTosign.txt > > This produces raw binary output, no base64 encoding. What is the > content of the file "codeToSign.txt"? Post the output of: > > od -tx1 < /tmp/codeToSign.txt > od -tx1 < codeToSign.txt 0000000 73 61 6d 70 6c 65 20 69 6e 70 75 74 0a 0000015 > > > public class SHA256RSA { > > > > public static void main(String[] args) throws Exception { > > String input = "sample input"; > > This input has no newline ending, perhaps the disk file does. > > > // Not a real private key! Replace with your private key! > > String strPk = "-----BEGIN PRIVATE > KEY-----\nMIIEvwIBADANBgkqhkiG9" > > + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG" > > + > "........................................................" > > + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n" > > + "-----END PRIVATE KEY-----\n"; > > I sure hope your production code will *NOT* have the private key > embedded in the executable. > > > String base64Signature = signSHA256RSA(input,strPk); > > System.out.println("Signature="+base64Signature); > > This outputs a signature encoded in base64. > > -- > Viktor. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.fortinbras at gmail.com Wed Aug 1 16:51:03 2018 From: tim.fortinbras at gmail.com (timmy pony) Date: Wed, 1 Aug 2018 17:51:03 +0100 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? In-Reply-To: References: <20180801152811.GB47858@straasha.imrryr.org> Message-ID: Hi Vicktor - I put a '\n' at end of java snippet Both are now equal Thank you for your help. On Wed, Aug 1, 2018 at 5:47 PM timmy pony wrote: > Hi Vicktor, Speed read the previous mail. > > > > On Wed, Aug 1, 2018 at 4:28 PM Viktor Dukhovni > wrote: > >> On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote: >> >> > I have tried this >> > >> > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 >> codeTosign.txt >> >> This produces raw binary output, no base64 encoding. What is the >> content of the file "codeToSign.txt"? Post the output of: >> >> od -tx1 < /tmp/codeToSign.txt >> > > od -tx1 < codeToSign.txt > > 0000000 73 61 6d 70 6c 65 20 69 6e 70 75 74 0a > > 0000015 > > >> >> > public class SHA256RSA { >> > >> > public static void main(String[] args) throws Exception { >> > String input = "sample input"; >> >> This input has no newline ending, perhaps the disk file does. >> >> > // Not a real private key! Replace with your private key! >> > String strPk = "-----BEGIN PRIVATE >> KEY-----\nMIIEvwIBADANBgkqhkiG9" >> > + "w0BAQEFAASCBKkwggSlAgEAAoIBAQDJUGqaRB11KjxQ\nKHDeG" >> > + >> "........................................................" >> > + "Ldt0hAPNl4QKYWCfJm\nNf7Afqaa/RZq0+y/36v83NGENQ==\n" >> > + "-----END PRIVATE KEY-----\n"; >> >> I sure hope your production code will *NOT* have the private key >> embedded in the executable. >> >> > String base64Signature = signSHA256RSA(input,strPk); >> > System.out.println("Signature="+base64Signature); >> >> This outputs a signature encoded in base64. >> >> -- >> Viktor. >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Aug 1 16:51:31 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 12:51:31 -0400 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? In-Reply-To: References: <20180801152811.GB47858@straasha.imrryr.org> Message-ID: > On Aug 1, 2018, at 12:47 PM, timmy pony wrote: > > On Wed, Aug 1, 2018 at 4:28 PM Viktor Dukhovni wrote: > On Wed, Aug 01, 2018 at 09:24:38AM +0100, timmy pony wrote: > > > I have tried this > > > > openssl dgst -sha256 -sign my_private.key -out /tmp/sign.sha256 codeTosign.txt > > This produces raw binary output, no base64 encoding. What is the > content of the file "codeToSign.txt"? Post the output of: > > od -tx1 < /tmp/codeToSign.txt > > od -tx1 < codeToSign.txt > 0000000 73 61 6d 70 6c 65 20 69 6e 70 75 74 0a > 0000015 As expected, the disk file has a newline ending (0x0a) after the input string. > > public class SHA256RSA { > > > > public static void main(String[] args) throws Exception { > > String input = "sample input"; > > This input has no newline ending, perhaps the disk file does. The input string signed by the Java code does not. The signatures are therefore *expected* to be different. Either include a newline in the Java string, or create an input file with no newline ending. -- Viktor. From uri at ll.mit.edu Wed Aug 1 16:46:20 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 1 Aug 2018 16:46:20 +0000 Subject: [openssl-users] Java Snippet output is not equal to command line openssl command output , Why ? In-Reply-To: References: <20180801152811.GB47858@straasha.imrryr.org> Message-ID: <75E2B58D-C7D3-472D-9257-08C4461EAE61@ll.mit.edu> Actually, it all works just fine. Viktor's point about adding terminating "\n" to the input text helped. -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDGlXflMDDD8kOP TP5y06tSXe1g8G3uJAoGHT8NewYANIONuJEZveXnfL8+bJRIu8FDzeCc4SWsCISK WMmX/VY+IzZxLvUlOzRaKmO3Su7A9ABSc/AtcEVcrXhr9qV3axZDMXRXsWTxFnhO /lRK8RpfGoGIhgCKkuNswy/DUjka0x03HymD7HwWhaNgsuvon+zWlSNTIV3t/WU4 093DlykKgDwEPym3UXHIgAecEAsYvm/YeYtM8NsHF2tzr40dKxA460lO/P8Vr7rL df+AF9sNyfNFR81KBtPp2aqvZVXabHQrIZEpoZLrkz6uCObmyPiFx2m59Y3nXQV2 Fac8DuATAgEDAoIBAQCEY6VDdXXX9te03f73N8eMPp5AoElJbVwEE39eUgQAIwJe ewtmfplE/dTUSGLbJ9YtM+sTQMPIBa2xkIZlU47UF3mgyfjDfM2RcZfPh0nV+AA2 9/VzoC49yPrypG5PnLmCIPg6dkNLZFA0qY2HS2bqEauwWVWxt0JIgh/XjCYR4OYZ y7unFj5XnW93cAfL9U8CZPonO6iHCB14unk/UyiIHNrR41at0+qwVJYXdTFx+m0C 3KiWAwleRdVy2LBj3Fq1R3/pW3tnYTadgOInRYF4hQuF+ttIzEiuimhd6blUdMlR WWbw8xp2A8buS4DQUKz0u1OAAhDvsqfEDsWLIAq7AoGBAPHwbdW8aLN85Y3W1pYf 2ELIlV1422sH+MrKv/jqQFf9LVmiXzq2+EZiYQcSxUFp5/1OvnRIHfY2hiBtq4Ww VBq9/0u/D8Rv9bKPOvpLxYZP9FIOo8/BaLp5VV3Vz4pxVort0xHr+DfWFWH7t0cC m/3LtfC1Y7j0TKyL/soyDWzXAoGBANIf/7pM4msWM+5WtEoW17OKaE6fbHYbeG44 /C76WhRBJ5onCuz7m0tdoB9mGv+D3s8FcBojzlbDKIrZvv7XDG1rAL2x5AGKqDZP +bH5ahKJDg/tq7Sba6xqtLBMtzVqZrtDSGTUPLNkeDJM4F6rs/dK+HvEjruLhF1E ALS5UWMlAoGBAKFK8+PS8HeomQk55GQVOtcwY5Ol55yv+zHcf/tG1Y/+HjvBlNHP UC7sQK9h2NZGmqjfKaLavqQkWWrzx651jWcpVN0qCoL1TncKJ1GH2QQ1TYwJwoqA 8HxQ45Pj37Gg5FyejLadUCU5Y5anz4SsZ/6HzqB47SX4Mx2yqdwhXkiPAoGBAIwV VSbd7EdkIp7keDFkj80G8DRqSE68+vQl/XSm5rgrb7waB0invNzpFWpEEf+tPzSu SrwX3uSCGwc71KnksvOcqykhQquxxXmKpnamRrcGCV/zx8288nLxzcrdz3jxmdIs 2u3i0yJC+swzQD8dIqTcpafYXyeyWD4tVc3Q4OzDAoGBAML1gJ2slF0egQmxKSJK YktcRX4IP1rWlYClgcJ9OLAxZBFWPwW8+hsTfCDoa5WEk4+CFHZ37PyibzjGuASC UQmOZj6tVnaRkB62ExArgjzyyIMEUAbfFw4vKHe8cyF8MFC6JbTYj0EDlQtkhK65 HE0xeJjwo/swhpkBItsH0cYJ -----END PRIVATE KEY----- -----BEGIN PUBLIC KEY----- MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAxpV35TAww/JDj0z+ctOr Ul3tYPBt7iQKBh0/DXsGADSDjbiRGb3l53y/PmyUSLvBQ83gnOElrAiEiljJl/1W PiM2cS71JTs0Wipjt0ruwPQAUnPwLXBFXK14a/ald2sWQzF0V7Fk8RZ4Tv5USvEa XxqBiIYAipLjbMMvw1I5GtMdNx8pg+x8FoWjYLLr6J/s1pUjUyFd7f1lONPdw5cp CoA8BD8pt1FxyIAHnBALGL5v2HmLTPDbBxdrc6+NHSsQOOtJTvz/Fa+6y3X/gBfb DcnzRUfNSgbT6dmqr2VV2mx0KyGRKaGS65M+rgjm5sj4hcdpufWN510FdhWnPA7g EwIBAw== -----END PUBLIC KEY----- $ cat rsa_tst1.java import java.security.KeyFactory; import java.security.Signature; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class rsa_tst1 { public static void main(String[] args) throws Exception { String input = "sample input\n"; final String strPk = "-----BEGIN PRIVATE KEY-----\n" + "MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDGlXflMDDD8kOP\n" + "TP5y06tSXe1g8G3uJAoGHT8NewYANIONuJEZveXnfL8+bJRIu8FDzeCc4SWsCISK\n" + "WMmX/VY+IzZxLvUlOzRaKmO3Su7A9ABSc/AtcEVcrXhr9qV3axZDMXRXsWTxFnhO\n" + "/lRK8RpfGoGIhgCKkuNswy/DUjka0x03HymD7HwWhaNgsuvon+zWlSNTIV3t/WU4\n" + "093DlykKgDwEPym3UXHIgAecEAsYvm/YeYtM8NsHF2tzr40dKxA460lO/P8Vr7rL\n" + "df+AF9sNyfNFR81KBtPp2aqvZVXabHQrIZEpoZLrkz6uCObmyPiFx2m59Y3nXQV2\n" + "Fac8DuATAgEDAoIBAQCEY6VDdXXX9te03f73N8eMPp5AoElJbVwEE39eUgQAIwJe\n" + "ewtmfplE/dTUSGLbJ9YtM+sTQMPIBa2xkIZlU47UF3mgyfjDfM2RcZfPh0nV+AA2\n" + "9/VzoC49yPrypG5PnLmCIPg6dkNLZFA0qY2HS2bqEauwWVWxt0JIgh/XjCYR4OYZ\n" + "y7unFj5XnW93cAfL9U8CZPonO6iHCB14unk/UyiIHNrR41at0+qwVJYXdTFx+m0C\n" + "3KiWAwleRdVy2LBj3Fq1R3/pW3tnYTadgOInRYF4hQuF+ttIzEiuimhd6blUdMlR\n" + "WWbw8xp2A8buS4DQUKz0u1OAAhDvsqfEDsWLIAq7AoGBAPHwbdW8aLN85Y3W1pYf\n" + "2ELIlV1422sH+MrKv/jqQFf9LVmiXzq2+EZiYQcSxUFp5/1OvnRIHfY2hiBtq4Ww\n" + "VBq9/0u/D8Rv9bKPOvpLxYZP9FIOo8/BaLp5VV3Vz4pxVort0xHr+DfWFWH7t0cC\n" + "m/3LtfC1Y7j0TKyL/soyDWzXAoGBANIf/7pM4msWM+5WtEoW17OKaE6fbHYbeG44\n" + "/C76WhRBJ5onCuz7m0tdoB9mGv+D3s8FcBojzlbDKIrZvv7XDG1rAL2x5AGKqDZP\n" + "+bH5ahKJDg/tq7Sba6xqtLBMtzVqZrtDSGTUPLNkeDJM4F6rs/dK+HvEjruLhF1E\n" + "ALS5UWMlAoGBAKFK8+PS8HeomQk55GQVOtcwY5Ol55yv+zHcf/tG1Y/+HjvBlNHP\n" + "UC7sQK9h2NZGmqjfKaLavqQkWWrzx651jWcpVN0qCoL1TncKJ1GH2QQ1TYwJwoqA\n" + "8HxQ45Pj37Gg5FyejLadUCU5Y5anz4SsZ/6HzqB47SX4Mx2yqdwhXkiPAoGBAIwV\n" + "VSbd7EdkIp7keDFkj80G8DRqSE68+vQl/XSm5rgrb7waB0invNzpFWpEEf+tPzSu\n" + "SrwX3uSCGwc71KnksvOcqykhQquxxXmKpnamRrcGCV/zx8288nLxzcrdz3jxmdIs\n" + "2u3i0yJC+swzQD8dIqTcpafYXyeyWD4tVc3Q4OzDAoGBAML1gJ2slF0egQmxKSJK\n" + "YktcRX4IP1rWlYClgcJ9OLAxZBFWPwW8+hsTfCDoa5WEk4+CFHZ37PyibzjGuASC\n" + "UQmOZj6tVnaRkB62ExArgjzyyIMEUAbfFw4vKHe8cyF8MFC6JbTYj0EDlQtkhK65\n" + "HE0xeJjwo/swhpkBItsH0cYJ\n" + "-----END PRIVATE KEY-----\n"; String base64Signature = signSHA256RSA(input,strPk); System.out.println("Signature:\n"+base64Signature); } // Create base64 encoded signature using SHA256/RSA. private static String signSHA256RSA(String input, String strPk) throws Exception { // Remove markers and new line characters in private key String realPK = strPk.replaceAll("-----END PRIVATE KEY-----", "") .replaceAll("-----BEGIN PRIVATE KEY-----", "") .replaceAll("\n", ""); byte[] b1 = Base64.getDecoder().decode(realPK); PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(b1); KeyFactory kf = KeyFactory.getInstance("RSA"); Signature privateSignature = Signature.getInstance("SHA256withRSA"); privateSignature.initSign(kf.generatePrivate(spec)); privateSignature.update(input.getBytes("UTF-8")); byte[] s = privateSignature.sign(); return Base64.getEncoder().encodeToString(s); } } $ java rsa_tst1 Signature: aM9GLnfy+yZ7g6PSpQ0+BEgQvNq0KwrKVeVUNtCNPnC7zOVd3wTp69xxcQfVCWY3MDGw0xVSs6P/Ud+do/NbFbw9ShdTfBi81hKe5rV8US//oF1RWa0uDdz6Pr5JCa+6E35oVZeoRC7i0UjJDLGx0PPpMshGQWtau8r7/Oaw2BywiIwvKWRp9zBMgQJRiO1rrCHqOEIegTGUCsRuzzk4XoFdDQEHJ8fydFV5/feIUQJCrC4HIIrwr8XPtEJrsJyssC6xmU5hkFKJhuovd/+9pfNEIVQnBFd03VCEdJWhuTf2IKabDGg8MGKMGsEkgFZpUQJijXMD7ifzLcQXzp7q7w== Stored it in tsig.b64 file. $ echo "sample input" > tt.txt $ openssl base64 -in tsig.b64 -d -a -out tsig.sig $ openssl dgst -sha256 -verify rsa2048-pub.pem -signature tsig.sig tt.txt Verified OK ?On 8/1/18, 12:17, "openssl-users on behalf of Viktor Dukhovni" wrote: > On Aug 1, 2018, at 12:14 PM, timmy pony wrote: > > Thanks Viktor, > for assistance ..... > The embedded private key "skeleton" is only for visualisation purposes; No it will not. > > > the openssl command returns binary. > so i can do .But they are still coming out different. > > openssl base64 -in /tmp/sign.sha256 -out Please re-read my previous post and respond to *all* the points. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From roberto at spadim.com.br Wed Aug 1 17:51:35 2018 From: roberto at spadim.com.br (Roberto Spadim) Date: Wed, 1 Aug 2018 14:51:35 -0300 Subject: [openssl-users] porting socket ssl python to c++ Message-ID: hi guys, i'm with a newbie question i have this piece of code, but i'm not finding something similar with c++, could anyone help? thanks: import socket import ssl import sys if len(sys.argv) == 3: HOST = sys.argv[1] # IP PORT = int(sys.argv[2]) # Port else: print "USAGE: $python client_ssl.py " exit(1) print 'Connecting...' s = socket.create_connection((HOST, PORT)) s = ssl.wrap_socket(s) print "Connected!\n" while True: query = raw_input("Query: ") if ( query == "quit" ): break s.send(query) data = s.recv(16384) print 'Reply:', data s.close() -- Roberto Spadim -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexhultman at gmail.com Wed Aug 1 18:15:37 2018 From: alexhultman at gmail.com (Alex H) Date: Wed, 1 Aug 2018 20:15:37 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: References: Message-ID: I would appreciate an answer to this question, it's holding me back and should be a simple yes/no. And yes, "client_notify" is a typo and should be "close_notify". Thanks Den ons 1 aug. 2018 kl 08:27 skrev Alex H : > Hi, > > I have trouble understanding the details of TLS shutdown. I get the basics > but, > > Is it possible to receive data after calling SSL_shutdown? Reading the > specs and docs leaves this rather blurry. > > That is, after sending a close_notify, can I receive data before getting > my client_notify response? > > The sources of SSL_write checks for SSL_SENT_SHUTDOWN state and returns > with error if set, but does not check for SSL_RECEIVED_SHUTDOWN. This > indicates somehow I'm allowed to still send data after received a > close_notify? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Aug 1 19:15:47 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Aug 2018 15:15:47 -0400 Subject: [openssl-users] Shutdown details In-Reply-To: References: Message-ID: <0059B4A9-E9D1-47D1-A707-03EF94E754E6@dukhovni.org> > On Aug 1, 2018, at 2:27 AM, Alex H wrote: > > Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry. TLS *does not* support half-closed connections (RFC5246): close_notify This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice. Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection. The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection. If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation must receive the responding close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying transport connection, then the implementation MAY choose to close the transport without waiting for the responding close_notify. No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed. Note: It is assumed that closing a connection reliably delivers pending data before destroying the transport. If your question is whether you can still read any data that may have been in flight when you send your close_notify, I believe the answer is no. Further data received from the peer is discarded after a close_notify is sent. -- Viktor. From alexhultman at gmail.com Wed Aug 1 19:46:37 2018 From: alexhultman at gmail.com (Alex H) Date: Wed, 1 Aug 2018 21:46:37 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: <0059B4A9-E9D1-47D1-A707-03EF94E754E6@dukhovni.org> References: <0059B4A9-E9D1-47D1-A707-03EF94E754E6@dukhovni.org> Message-ID: [...] The other party MUST respond with a close_notify alert of its own and close down the connection immediately, *discarding any pending writes*. I've read this before, but I've also checked the sources of SSL_write and they seem contradictory: SSL_write does not return with error when SSL_RECEIVED_SHUTDOWN is set, but does so when SSL_SENT_SHUTDOWN is set. Why is this? A minor bug? If the RFC states the end who receives a close_notify should *discard any pending writes* then it surely seems a bug to allow SSL_write for a connection where SSL_RECEIVED_SHUTDOWN is set? .... > If your question is whether you can still read any data that may have been in flight when you send your close_notify, I believe the answer is no. Further data received from the peer is discarded after a close_notify is sent. I also believe so, especially since SSL_shutdown docs seem to hint that once SSL_shutdown is called, it should be called again until fully done (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown becomes the only function called until the SSL connection is fully closed, no more SSL_read is called and thus it cannot report any received data. SSL_shutdown does not return with any data. Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug? Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni < openssl-users at dukhovni.org>: > > > > On Aug 1, 2018, at 2:27 AM, Alex H wrote: > > > > Is it possible to receive data after calling SSL_shutdown? Reading the > specs and docs leaves this rather blurry. > > TLS *does not* support half-closed connections (RFC5246): > > close_notify > This message notifies the recipient that the sender will not send > any more messages on this connection. Note that as of TLS 1.1, > failure to properly close a connection no longer requires that a > session not be resumed. This is a change from TLS 1.0 to conform > with widespread implementation practice. > > Either party may initiate a close by sending a close_notify alert. > Any data received after a closure alert is ignored. > > Unless some other fatal alert has been transmitted, each party is > required to send a close_notify alert before closing the write side > of the connection. The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. It is not required for the initiator > of the close to wait for the responding close_notify alert before > closing the read side of the connection. > > If the application protocol using TLS provides that any data may be > carried over the underlying transport after the TLS connection is > closed, the TLS implementation must receive the responding > close_notify alert before indicating to the application layer that > the TLS connection has ended. If the application protocol will not > transfer any additional data, but will only close the underlying > transport connection, then the implementation MAY choose to close the > transport without waiting for the responding close_notify. No part > of this standard should be taken to dictate the manner in which a > usage profile for TLS manages its data transport, including when > connections are opened or closed. > > Note: It is assumed that closing a connection reliably delivers > pending data before destroying the transport. > > If your question is whether you can still read any data that may have > been in flight when you send your close_notify, I believe the answer > is no. Further data received from the peer is discarded after a > close_notify is sent. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wiml at omnigroup.com Wed Aug 1 19:59:13 2018 From: wiml at omnigroup.com (Wim Lewis) Date: Wed, 1 Aug 2018 12:59:13 -0700 Subject: [openssl-users] porting socket ssl python to c++ In-Reply-To: References: Message-ID: This pair of articles is quite old, so some of the API details have changed, but it has an overall description of how to use OpenSSL: https://www.linuxjournal.com/article/4822 https://www.linuxjournal.com/article/5487 The link to the example code is broken, but you can find it here: https://github.com/Andersbakken/openssl-examples/ One thing to be aware of is that the check_cert() function is just a sketch of what a real check_cert() function would need to do (which depends on your application, to some extent). There are some functions that have been added to OpenSSL since then that, AIUI, can replace having to do those checks in your own check_cert(): https://www.openssl.org/docs/man1.1.0/crypto/X509_check_host.html From jb-openssl at wisemo.com Wed Aug 1 23:36:03 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 2 Aug 2018 01:36:03 +0200 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <2DF0C0C1-A0CC-45D3-AB7B-B8360417B2B7@dukhovni.org> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <76DDA20E-6704-4913-B045-238561DD80AA@dukhovni.org> <33ac87a7-95c0-4b90-9426-b4c72da54ac1@wisemo.com> <20180801125606.GA47858@straasha.imrryr.org> <2DF0C0C1-A0CC-45D3-AB7B-B8360417B2B7@dukhovni.org> Message-ID: <4bf77485-6303-3449-cc48-cd0c2a5f43b8@wisemo.com> On 01/08/2018 15:42, Viktor Dukhovni wrote: > >> On Aug 1, 2018, at 9:31 AM, Michael Wojcik wrote: >> >> CMS with an AEAD mode (such as AES128-GCM) ought to avoid the integrity-protection issue for the encrypted content, but not for the other parts of the message, I assume. (I'm no CMS expert so I may be missing something there.) And, of course, both sender and recipient would have to support that algorithm. > Not if you make it streaming. A streaming implementing will emit almost > the entirety of the decrypted message before checking integrity at the > end and finding out that some part of it (already output) was wrong. > Which is entirely fine if all you do with the stream output before integrity checking is to store it somewhere larger than process RAM, such as in a (temporary) disk file (Or perform some other operation which is safe with garbage input). Consider the (logically equivalent) fact that most algorithms inside OpenSSL stream their output to memory because it is rarely possible to hold an entire message in CPU registers. But I agree that blindly switching to AEAD modes does nothing to help the "problem" of allowing a different level of the software stack to see decrypted output before the integrity check has been completed. OpenSSL should be an open toolkit, not a bondage-and-discipline programming environment like NaCl. 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 vc.chakrapani at gmail.com Thu Aug 2 11:12:28 2018 From: vc.chakrapani at gmail.com (Chakrapani Reddy) Date: Thu, 2 Aug 2018 16:42:28 +0530 Subject: [openssl-users] Help : TLS 1.3 Server is not listening on the default port In-Reply-To: References: Message-ID: Below command helped Thanks. *[root at vm bin]# ./openssl s_server -cert server.crt -key server1.key -4 -accept 44330 -www -tls1_3* On Wed, Aug 1, 2018 at 3:43 PM, Chakrapani Reddy wrote: > Hello, > > Wanted to try to capture the TLS1.3 message flow using openssl-1.1.1-pre7 > and used the below command to run the server. > [root at vm bin]# pwd > /opt/build/openssl-1.1.1-pre7/bin > > *[root at vm bin]# ./openssl s_server -cert server.crt -key server1.key* > > But it is throwing the below error : > > Using default temp DH parameters > > *47306412798048:error:02004061:system > library:socket:unknown:crypto/bio/b_sock2.c:49:47306412798048:error:2008C076:BIO > routines:BIO_socket:unable to create socket:crypto/bio/b_sock2.c:50:* > 0 items in the session cache > 0 client connects (SSL_connect()) > 0 client renegotiates (SSL_connect()) > 0 client connects that finished > 0 server accepts (SSL_accept()) > 0 server renegotiates (SSL_accept()) > 0 server accepts that finished > 0 session cache hits > 0 session cache misses > 0 session cache timeouts > 0 callback cache hits > 0 cache full overflows (128 allowed) > > > ldd ./openssl > linux-vdso.so.1 => (0x00007fff6c9fd000) > libdl.so.2 => /lib64/libdl.so.2 (0x0000003fc2200000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003fc2a00000) > libc.so.6 => /lib64/libc.so.6 (0x0000003fc1e00000) > /lib64/ld-linux-x86-64.so.2 (0x0000003fc1600000) > > Shall we know how to make it working? > > Best Regards, > Chakrapani > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neomeisterhax at gmail.com Thu Aug 2 11:38:35 2018 From: neomeisterhax at gmail.com (Neo meister) Date: Thu, 2 Aug 2018 12:38:35 +0100 Subject: [openssl-users] Need help with creating a server certificate Message-ID: I started the process of creating a chain of certificates from the root CA down to a leaf certificate using openssl running on a debian vm. I successfully created and verified the root cert, intermediate cert and chain file. The issue I am having now is that when I go to create a leaf cert to be used by the server it will not work for me. After generating the key and and the CSR i use this command " *openssl* ca -config path/to/config/folder/openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in path/to/CSR/folder/www.testcert.com.csr.pem -out path/to/output/cert/folder/www.testcert.com.cert.pem". After running this command I get the output "using configuration from path/to/config/folder/openssl.cnf". When I check the folder i told openssl to place the newly created cert in it is not there. I have tried changing to a different output folder for the new cert but I get the same result. Any idea what is going on? The guide I have been using up until this point is at: https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Thu Aug 2 11:30:15 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 2 Aug 2018 05:30:15 -0600 Subject: [openssl-users] openssl-1.1.0-stable-SNAP-20180802 issue Message-ID: <20180802113015.GA16031@doctor.nl2k.ab.ca> While compiling today's openssl 1.1.0 snap on FreeBSD 11.2 I got /usr/bin/cc -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -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\"" -DL_ENDIAN -Wall -O3 -pthread -D_THREAD_SAFE -D_REENTRANT -rdynamic -fPIC -MMD -MF crypto/asn1/tasn_utl.d.tmp -MT crypto/asn1/tasn_utl.o -c -o crypto/asn1/tasn_utl.o crypto/asn1/tasn_utl.c cc: warning: argument unused during compilation: '-rdynamic' [-Wunused-command-line-argument] crypto/asn1/tasn_utl.c:60:5: error: use of undeclared identifier 'CRYPTO_REF_COUNT' CRYPTO_REF_COUNT *lck; ^ crypto/asn1/tasn_utl.c:60:23: error: use of undeclared identifier 'lck' CRYPTO_REF_COUNT *lck; ^ crypto/asn1/tasn_utl.c:70:5: error: use of undeclared identifier 'lck'; did you mean 'lock'? lck = offset2ptr(*pval, aux->ref_offset); ^~~ lock crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here CRYPTO_RWLOCK **lock; ^ crypto/asn1/tasn_utl.c:75:10: error: use of undeclared identifier 'lck'; did you mean 'lock'? *lck = ret = 1; ^~~ lock crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here CRYPTO_RWLOCK **lock; ^ crypto/asn1/tasn_utl.c:75:14: warning: incompatible integer to pointer conversion assigning to 'CRYPTO_RWLOCK *' (aka 'void *') from 'int' [-Wint-conversion] *lck = ret = 1; ^ ~~~~~~~ crypto/asn1/tasn_utl.c:83:14: warning: implicit declaration of function 'CRYPTO_UP_REF' is invalid in C99 [-Wimplicit-function-declaration] if (!CRYPTO_UP_REF(lck, &ret, *lock)) ^ crypto/asn1/tasn_utl.c:83:28: error: use of undeclared identifier 'lck'; did you mean 'lock'? if (!CRYPTO_UP_REF(lck, &ret, *lock)) ^~~ lock crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here CRYPTO_RWLOCK **lock; ^ crypto/asn1/tasn_utl.c:87:14: warning: implicit declaration of function 'CRYPTO_DOWN_REF' is invalid in C99 [-Wimplicit-function-declaration] if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) ^ crypto/asn1/tasn_utl.c:87:30: error: use of undeclared identifier 'lck'; did you mean 'lock'? if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) ^~~ lock crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here CRYPTO_RWLOCK **lock; ^ 3 warnings and 6 errors generated. *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism A problem is a chance for you to do your best. -Duke Ellington From christian.boehme at cloudandheat.com Thu Aug 2 11:53:42 2018 From: christian.boehme at cloudandheat.com (=?UTF-8?Q?Christian_B=c3=b6hme?=) Date: Thu, 2 Aug 2018 13:53:42 +0200 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <65b27675-3029-18a2-fa57-becb807b59c4@cloudandheat.com> Message-ID: <8c8eb116-ee0c-529b-20f7-c22ca9c62621@cloudandheat.com> Hello, On 01.08.2018 14:49, Michael Wojcik wrote: >> On 30.07.2018 20:12, Michael Wojcik wrote: >> >>> FWIW, SUS Issue 5 defines RLIMIT_AS as applying to both malloc and mmap, but RLIMIT_DATA as >>> applying only to malloc. (That is, mmap'd pages do not count against the data limit.) >> >> mmap() , by defninition, populates the process' virtual address space, and if that >> is limited in size, artificially or not, then the call is going to fail, eventually. > > That's irrelevant to the statement you quoted, which was about the SUS process-limit mechanism > (setrusage et al.), not the process address space. I may have skipped a few steps and made too broad a statement, so here are the details and corrections. malloc(3) is a pure C library call, whereas mmap(2) is a proper system call on those, POSIX-conforming systems I have seen, anyway. To a userland process, there is nothing more fundamental than the system call interface. If it requires resources to do its work, it needs to go through this interface and ask "the system" first. The kernel as an implementation of "the system", where process-level resource control actually happens, does not care about what userland code such as the C library does unless that actually decides to call the system. Except for SAS OSes, processes generally live in their own virtual address space, and that is where "the process's data segment" is located that RLIMIT_DATA refers to. s/brk(2) are system calls to manage the end of the process's data segment AKA program break, while mmap() , as much broader a concept, does not have this limited view on the process's address space and is therefore also more powerful. Now, with Linux since 4.7 for example, RLIMIT_DATA also controls mmap() . What's more, glibc malloc() on Linux is actually implemented in terms of mmap() these days, although usage of s/brk() isn't phased out completely (apparently, the runtime linker still likes those). Since s/brk() and mmap() are the only means available to a Linux userland process to manage those parts of its address space that it is designed to manage, controlling a process's RLIMIT_DATA value ultimately controls all of its ability to manage its address space, data segment or otherwise. >> The pure streaming approach may be appropriate for file descriptors that are not >> seekable like sockets, pipes, tty ends etcpp., whereas with egular files, random >> access schemes using either pread(v)(2) or lseek(2) in combination with >> read(v)(2) can be employed. > > Or regular files could also be processed sequentially. What's the advantage of making > seekable sources a special case? Making sure that the message under investigation is consistent w.r.t. the standards according to which it was supposedly constructed, without having to consume resources that aren't strictly necessary to make such a decision. In other words, it's about system performance /and/ making sure to get the logic right at the same time. There is simply no need to slurp in the whole file just to get at its end (if so required), when mechanisms for random access are readily available. Please remember our messages can get fairly large. System performance and tight integration are equally important to us as the security aspects. > In any case, the OpenSSL apps are a convenience and a set of samples. My original impression was that those tools represented some kind of reference implementation of the libraries. Clearly, I was wrong ;-) Thanks, Christian -- *Christian B?hme* Developer System Integration CLOUD&HEAT *CLOUD & HEAT Technologies GmbH* K?nigsbr?cker Str. 96 (Halle 15) | 01099 Dresden Tel: +49 351 479 3670 - 100 Fax: +49 351 479 3670 - 110 E-Mail: christian.boehme at cloudandheat.com Web: https://www.cloudandheat.com Handelsregister: Amtsgericht Dresden Registernummer: HRB 30549 USt.-Ident.-Nr.: DE281093504 Gesch?ftsf?hrer: Nicolas R?hrs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 533 bytes Desc: OpenPGP digital signature URL: From uri at ll.mit.edu Thu Aug 2 12:28:29 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 2 Aug 2018 12:28:29 +0000 Subject: [openssl-users] openssl-1.1.0-stable-SNAP-20180802 issue In-Reply-To: <20180802113015.GA16031@doctor.nl2k.ab.ca> References: <20180802113015.GA16031@doctor.nl2k.ab.ca> Message-ID: Same problem on Linux. Regards, Uri Sent from my iPhone > On Aug 2, 2018, at 07:47, The Doctor wrote: > > While compiling today's openssl 1.1.0 snap on FreeBSD 11.2 > > I got > > /usr/bin/cc -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -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\"" -DL_ENDIAN -Wall -O3 -pthread -D_THREAD_SAFE -D_REENTRANT -rdynamic -fPIC -MMD -MF crypto/asn1/tasn_utl.d.tmp -MT crypto/asn1/tasn_utl.o -c -o crypto/asn1/tasn_utl.o crypto/asn1/tasn_utl.c > cc: warning: argument unused during compilation: '-rdynamic' [-Wunused-command-line-argument] > crypto/asn1/tasn_utl.c:60:5: error: use of undeclared identifier > 'CRYPTO_REF_COUNT' > CRYPTO_REF_COUNT *lck; > ^ > crypto/asn1/tasn_utl.c:60:23: error: use of undeclared identifier 'lck' > CRYPTO_REF_COUNT *lck; > ^ > crypto/asn1/tasn_utl.c:70:5: error: use of undeclared identifier 'lck'; did you > mean 'lock'? > lck = offset2ptr(*pval, aux->ref_offset); > ^~~ > lock > crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > CRYPTO_RWLOCK **lock; > ^ > crypto/asn1/tasn_utl.c:75:10: error: use of undeclared identifier 'lck'; did you > mean 'lock'? > *lck = ret = 1; > ^~~ > lock > crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > CRYPTO_RWLOCK **lock; > ^ > crypto/asn1/tasn_utl.c:75:14: warning: incompatible integer to pointer > conversion assigning to 'CRYPTO_RWLOCK *' (aka 'void *') from 'int' > [-Wint-conversion] > *lck = ret = 1; > ^ ~~~~~~~ > crypto/asn1/tasn_utl.c:83:14: warning: implicit declaration of function > 'CRYPTO_UP_REF' is invalid in C99 [-Wimplicit-function-declaration] > if (!CRYPTO_UP_REF(lck, &ret, *lock)) > ^ > crypto/asn1/tasn_utl.c:83:28: error: use of undeclared identifier 'lck'; did you > mean 'lock'? > if (!CRYPTO_UP_REF(lck, &ret, *lock)) > ^~~ > lock > crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > CRYPTO_RWLOCK **lock; > ^ > crypto/asn1/tasn_utl.c:87:14: warning: implicit declaration of function > 'CRYPTO_DOWN_REF' is invalid in C99 [-Wimplicit-function-declaration] > if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) > ^ > crypto/asn1/tasn_utl.c:87:30: error: use of undeclared identifier 'lck'; did you > mean 'lock'? > if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) > ^~~ > lock > crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > CRYPTO_RWLOCK **lock; > ^ > 3 warnings and 6 errors generated. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 > *** Error code 1 > > Stop. > make: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 > > > Please fix. > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! > https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism > A problem is a chance for you to do your best. -Duke Ellington > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From matt at openssl.org Thu Aug 2 12:58:19 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 2 Aug 2018 13:58:19 +0100 Subject: [openssl-users] openssl-1.1.0-stable-SNAP-20180802 issue In-Reply-To: References: <20180802113015.GA16031@doctor.nl2k.ab.ca> Message-ID: The fix is already pending: https://github.com/openssl/openssl/pull/6843 Just waiting on it being pushed. Matt On 02/08/18 13:28, Blumenthal, Uri - 0553 - MITLL wrote: > Same problem on Linux. > > Regards, > Uri > > Sent from my iPhone > >> On Aug 2, 2018, at 07:47, The Doctor wrote: >> >> While compiling today's openssl 1.1.0 snap on FreeBSD 11.2 >> >> I got >> >> /usr/bin/cc -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -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\"" -DL_ENDIAN -Wall -O3 -pthread -D_THREAD_SAFE -D_REENTRANT -rdynamic -fPIC -MMD -MF crypto/asn1/tasn_utl.d.tmp -MT crypto/asn1/tasn_utl.o -c -o crypto/asn1/tasn_utl.o crypto/asn1/tasn_utl.c >> cc: warning: argument unused during compilation: '-rdynamic' [-Wunused-command-line-argument] >> crypto/asn1/tasn_utl.c:60:5: error: use of undeclared identifier >> 'CRYPTO_REF_COUNT' >> CRYPTO_REF_COUNT *lck; >> ^ >> crypto/asn1/tasn_utl.c:60:23: error: use of undeclared identifier 'lck' >> CRYPTO_REF_COUNT *lck; >> ^ >> crypto/asn1/tasn_utl.c:70:5: error: use of undeclared identifier 'lck'; did you >> mean 'lock'? >> lck = offset2ptr(*pval, aux->ref_offset); >> ^~~ >> lock >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here >> CRYPTO_RWLOCK **lock; >> ^ >> crypto/asn1/tasn_utl.c:75:10: error: use of undeclared identifier 'lck'; did you >> mean 'lock'? >> *lck = ret = 1; >> ^~~ >> lock >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here >> CRYPTO_RWLOCK **lock; >> ^ >> crypto/asn1/tasn_utl.c:75:14: warning: incompatible integer to pointer >> conversion assigning to 'CRYPTO_RWLOCK *' (aka 'void *') from 'int' >> [-Wint-conversion] >> *lck = ret = 1; >> ^ ~~~~~~~ >> crypto/asn1/tasn_utl.c:83:14: warning: implicit declaration of function >> 'CRYPTO_UP_REF' is invalid in C99 [-Wimplicit-function-declaration] >> if (!CRYPTO_UP_REF(lck, &ret, *lock)) >> ^ >> crypto/asn1/tasn_utl.c:83:28: error: use of undeclared identifier 'lck'; did you >> mean 'lock'? >> if (!CRYPTO_UP_REF(lck, &ret, *lock)) >> ^~~ >> lock >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here >> CRYPTO_RWLOCK **lock; >> ^ >> crypto/asn1/tasn_utl.c:87:14: warning: implicit declaration of function >> 'CRYPTO_DOWN_REF' is invalid in C99 [-Wimplicit-function-declaration] >> if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) >> ^ >> crypto/asn1/tasn_utl.c:87:30: error: use of undeclared identifier 'lck'; did you >> mean 'lock'? >> if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) >> ^~~ >> lock >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here >> CRYPTO_RWLOCK **lock; >> ^ >> 3 warnings and 6 errors generated. >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 >> >> >> Please fix. >> >> -- >> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca >> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! >> https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism >> A problem is a chance for you to do your best. -Duke Ellington >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> From openssl-users at dukhovni.org Thu Aug 2 15:13:22 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 2 Aug 2018 11:13:22 -0400 Subject: [openssl-users] openssl cms -decrypt failing due to malloc(3) failure In-Reply-To: <8c8eb116-ee0c-529b-20f7-c22ca9c62621@cloudandheat.com> References: <0e9259df-df53-0756-4669-c5e3b2909c8a@cloudandheat.com> <617BBA26-8F5B-4B71-A782-EC65E799417D@akamai.com> <611e2deb-2513-97da-98b2-6bbf8a8f90fd@cloudandheat.com> <1d573b51-d889-0980-4758-871fda162361@jordan.maileater.net> <65b27675-3029-18a2-fa57-becb807b59c4@cloudandheat.com> <8c8eb116-ee0c-529b-20f7-c22ca9c62621@cloudandheat.com> Message-ID: <20180802151322.GA14409@straasha.imrryr.org> On Thu, Aug 02, 2018 at 01:53:42PM +0200, Christian B?hme wrote: > > In any case, the OpenSSL apps are a convenience and a set of samples. > > My original impression was that those tools represented some kind of reference > implementation of the libraries. Clearly, I was wrong ;-) Well, OpenSSL's cms(1) is not a reference implementation of the CMS standard. It is an implementation of CMS via the OpenSSL APIs, and its source code is a useful resource in understanding how to use those APIs. IIRC the requirement to extract the complete CMS message into memory is not just an artefact of the CLI design. Rather, I seem to recall that presently the CMS library needs the whole message in memory in order to process it. If so, a streaming implementation would need to extend the CMS implementation in libcrypto to support that mode of operation. -- Viktor. From murugesh.pitchaiah at gmail.com Fri Aug 3 05:32:18 2018 From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah) Date: Fri, 3 Aug 2018 11:02:18 +0530 Subject: [openssl-users] Need help with creating a server certificate In-Reply-To: References: Message-ID: Hi, The command you used is the correct one to generate a cert from CSR. Still certificate not generated means there may be some config issue. You did not see any errors after the following line ? using configuration from > path/to/config/folder/openssl.cnf". Also check if the file/path permissions are ok. Thanks, Murugesh P. On 8/2/18, Neo meister wrote: > I started the process of creating a chain of certificates from the root CA > down to a leaf certificate using openssl running on a debian vm. I > successfully created and verified the root cert, intermediate cert and > chain file. The issue I am having now is that when I go to create a leaf > cert to be used by the server it will not work for me. After generating the > key and and the CSR i use this command " *openssl* ca -config > path/to/config/folder/openssl.cnf -extensions server_cert -days 375 -notext > -md sha256 -in path/to/CSR/folder/www.testcert.com.csr.pem -out > path/to/output/cert/folder/www.testcert.com.cert.pem". > > After running this command I get the output "using configuration from > path/to/config/folder/openssl.cnf". > > When I check the folder i told openssl to place the newly created cert in > it is not there. I have tried changing to a different output folder for the > new cert but I get the same result. Any idea what is going on? > > > The guide I have been using up until this point is at: > https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html > From doctor at doctor.nl2k.ab.ca Fri Aug 3 12:17:36 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 3 Aug 2018 06:17:36 -0600 Subject: [openssl-users] openssl-1.1.0-stable-SNAP-20180802 issue In-Reply-To: References: <20180802113015.GA16031@doctor.nl2k.ab.ca> Message-ID: <20180803121736.GB38324@doctor.nl2k.ab.ca> On Thu, Aug 02, 2018 at 01:58:19PM +0100, Matt Caswell wrote: > The fix is already pending: > https://github.com/openssl/openssl/pull/6843 > > Just waiting on it being pushed. > > Matt > Still waiting! 20180803 is also affected!! > > On 02/08/18 13:28, Blumenthal, Uri - 0553 - MITLL wrote: > > Same problem on Linux. > > > > Regards, > > Uri > > > > Sent from my iPhone > > > >> On Aug 2, 2018, at 07:47, The Doctor wrote: > >> > >> While compiling today's openssl 1.1.0 snap on FreeBSD 11.2 > >> > >> I got > >> > >> /usr/bin/cc -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -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\"" -DL_ENDIAN -Wall -O3 -pthread -D_THREAD_SAFE -D_REENTRANT -rdynamic -fPIC -MMD -MF crypto/asn1/tasn_utl.d.tmp -MT crypto/asn1/tasn_utl.o -c -o crypto/asn1/tasn_utl.o crypto/asn1/tasn_utl.c > >> cc: warning: argument unused during compilation: '-rdynamic' [-Wunused-command-line-argument] > >> crypto/asn1/tasn_utl.c:60:5: error: use of undeclared identifier > >> 'CRYPTO_REF_COUNT' > >> CRYPTO_REF_COUNT *lck; > >> ^ > >> crypto/asn1/tasn_utl.c:60:23: error: use of undeclared identifier 'lck' > >> CRYPTO_REF_COUNT *lck; > >> ^ > >> crypto/asn1/tasn_utl.c:70:5: error: use of undeclared identifier 'lck'; did you > >> mean 'lock'? > >> lck = offset2ptr(*pval, aux->ref_offset); > >> ^~~ > >> lock > >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > >> CRYPTO_RWLOCK **lock; > >> ^ > >> crypto/asn1/tasn_utl.c:75:10: error: use of undeclared identifier 'lck'; did you > >> mean 'lock'? > >> *lck = ret = 1; > >> ^~~ > >> lock > >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > >> CRYPTO_RWLOCK **lock; > >> ^ > >> crypto/asn1/tasn_utl.c:75:14: warning: incompatible integer to pointer > >> conversion assigning to 'CRYPTO_RWLOCK *' (aka 'void *') from 'int' > >> [-Wint-conversion] > >> *lck = ret = 1; > >> ^ ~~~~~~~ > >> crypto/asn1/tasn_utl.c:83:14: warning: implicit declaration of function > >> 'CRYPTO_UP_REF' is invalid in C99 [-Wimplicit-function-declaration] > >> if (!CRYPTO_UP_REF(lck, &ret, *lock)) > >> ^ > >> crypto/asn1/tasn_utl.c:83:28: error: use of undeclared identifier 'lck'; did you > >> mean 'lock'? > >> if (!CRYPTO_UP_REF(lck, &ret, *lock)) > >> ^~~ > >> lock > >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > >> CRYPTO_RWLOCK **lock; > >> ^ > >> crypto/asn1/tasn_utl.c:87:14: warning: implicit declaration of function > >> 'CRYPTO_DOWN_REF' is invalid in C99 [-Wimplicit-function-declaration] > >> if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) > >> ^ > >> crypto/asn1/tasn_utl.c:87:30: error: use of undeclared identifier 'lck'; did you > >> mean 'lock'? > >> if (!CRYPTO_DOWN_REF(lck, &ret, *lock)) > >> ^~~ > >> lock > >> crypto/asn1/tasn_utl.c:61:21: note: 'lock' declared here > >> CRYPTO_RWLOCK **lock; > >> ^ > >> 3 warnings and 6 errors generated. > >> *** Error code 1 > >> > >> Stop. > >> make[1]: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 > >> *** Error code 1 > >> > >> Stop. > >> make: stopped in /usr/source/openssl-1.1.0-stable-SNAP-20180802 > >> > >> > >> Please fix. > >> > >> -- > >> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > >> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! > >> https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism > >> A problem is a chance for you to do your best. -Duke Ellington > >> -- > >> 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 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism A problem is a chance for you to do your best. -Duke Ellington From hkario at redhat.com Fri Aug 3 13:51:16 2018 From: hkario at redhat.com (Hubert Kario) Date: Fri, 03 Aug 2018 15:51:16 +0200 Subject: [openssl-users] Appropriate use of SSL_CTX_set_cipher_list() In-Reply-To: References: <20180717223647.GA13977@archenemy.localdomain> <20180718202431.GA26188@archenemy.localdomain> Message-ID: <7568211.NKHoubeDlF@pintsize.usersys.redhat.com> On Thursday, 19 July 2018 00:12:55 CEST Michael Wojcik wrote: > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > > Of Ryan Beethe > > Sent: Wednesday, July 18, 2018 14:25 > > > > For a safe client application, should you explicitly set the cipher list > > explicitly, rather than trust the default cipher list that comes from > > the package manager's libssl? > > I don't think there's a definitive answer. It will depend on how well that > OpenSSL package is maintained and how often the system administrator (who > may just be Joe End User) updates it, the criteria used by the developer to > set the cipher list, and so on. > > That said, I'll always prefer software that has a configurable cipher list > with a decent default. If the software uses an OpenSSL provided by the OS > manufacturer or some third party, and that OpenSSL comes with its own > default cipher suite list, as in the Fedora case, then making the > application's default "use the OpenSSL package's default" might well be > acceptable. But as I user and system administrator, I always want the > freedom to override it. and the idea of providing that was exactly to allow this, as not all applications provide necessary configuration options, so without the system policy you have no way of overriding openssl defaults at all yes, it's system-wide, but applications are explicitly allowed to override the policy, and if you really need to communicate with old software or hardware, there is LEGACY policy provided for this > The OpenSSL-consuming software I work on all uses our own OpenSSL builds - > we don't use the OS-supplied one, if there is one - so this isn't an issue > I have to deal with professionally. But we do make the cipher-suite list > configurable, with a default that tries to strike a reasonable compromise > between strength and compatibility. yes, for people that manage this stuff themselves, and spend a lot of time thinking and making decisions about their TLS settings, regularly updating it, this may feel intrusive but please remember, this is not the typical user behaviour -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From wangqun at alumni.nus.edu.sg Sun Aug 5 09:48:20 2018 From: wangqun at alumni.nus.edu.sg (Wang) Date: Sun, 5 Aug 2018 02:48:20 -0700 (MST) Subject: [openssl-users] FIPS 2.0.11 build with Visual Studio 2010 fails self-tests Message-ID: <1533462500515-0.post@n7.nabble.com> Hello, I hit the exactly the same issue as the one reported here - http://openssl.6102.n7.nabble.com/FIPS-Module-1-2-build-with-Visual-Studio-2010-fails-self-tests-tt36372.html#a36391 Anybody knows if a solution is available now? Thanks so much in advance, Wang -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From angus at magsys.co.uk Sun Aug 5 10:03:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Sun, 5 Aug 2018 11:03 +0100 (BST) Subject: [openssl-users] FIPS 2.0.11 build with Visual Studio 2010 fails self-tests In-Reply-To: <1533462500515-0.post@n7.nabble.com> Message-ID: > I hit the exactly the same issue as the one reported here - > http://openssl.6102.n7.nabble.com/FIPS-Module-1-2-build-with-Visua > l-Studio-2010-fails-self-tests-tt36372.html#a36391 > > Anybody knows if a solution is available now? That is an eight year old message for an obsolete OpenSSL version. There is a more current version OpenSSL v1.0.2m-fips binary for Win32 built with Visual Studio Community 2015, at: http://wiki.overbyte.eu/wiki/index.php/ICS_Download That does pass the self test. Angus From jjain at vmware.com Sun Aug 5 20:27:42 2018 From: jjain at vmware.com (Jayant Jain) Date: Sun, 5 Aug 2018 20:27:42 +0000 Subject: [openssl-users] ssl save/restore/migrate functionality In-Reply-To: References: Message-ID: Is there a way to save the SSL Context / Session and then restore the session on a new instance to support session migration. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Aug 5 20:55:34 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 5 Aug 2018 16:55:34 -0400 Subject: [openssl-users] ssl save/restore/migrate functionality In-Reply-To: References: Message-ID: > On Aug 5, 2018, at 4:27 PM, Jayant Jain wrote: > > Is there a way to save the SSL Context / Session and then restore the session on a new instance to support session migration. TLS session resumption is supported. Migration of the SSL state of a live connection is not. That is, while the operating system may let you pass the connection file descriptor between processes, OpenSSL does not presently support serializing and de-serializing the connection state to allow the to the other process continue the existing SSL session. -- Viktor. From jjain at vmware.com Mon Aug 6 00:07:58 2018 From: jjain at vmware.com (Jayant Jain) Date: Mon, 6 Aug 2018 00:07:58 +0000 Subject: [openssl-users] ssl save/restore/migrate functionality In-Reply-To: References: , Message-ID: Do you see it being of enough value to consider bringing the feature into your roadmap. Thanks ________________________________ From: openssl-users on behalf of Viktor Dukhovni Sent: Sunday, August 5, 2018 1:55:34 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] ssl save/restore/migrate functionality > On Aug 5, 2018, at 4:27 PM, Jayant Jain wrote: > > Is there a way to save the SSL Context / Session and then restore the session on a new instance to support session migration. TLS session resumption is supported. Migration of the SSL state of a live connection is not. That is, while the operating system may let you pass the connection file descriptor between processes, OpenSSL does not presently support serializing and de-serializing the connection state to allow the to the other process continue the existing SSL session. -- Viktor. -- openssl-users mailing list To unsubscribe: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-users&data=02%7C01%7Cjjain%40vmware.com%7C5076c6bbe8c84eaa9cf608d5fb15da69%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636690993642698931&sdata=VydLsoqa78HwK%2FvOl8ahwgYyjJ3qCxiZd98PnxKBHZY%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Aug 6 00:27:24 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 5 Aug 2018 20:27:24 -0400 Subject: [openssl-users] ssl save/restore/migrate functionality In-Reply-To: References: Message-ID: <58F2731B-4CE1-4331-AAD7-C67F3104E69D@dukhovni.org> > On Aug 5, 2018, at 8:07 PM, Jayant Jain wrote: > > Do you see it being of enough value to consider bringing the feature into your roadmap. Can you be specific about which "it" you're looking for? There are no present plans to make it possible to move live connections across process boundaries. There are considerable obstacles to making that possible. If that's what you're looking for, it is not likely to happen soon. -- Viktor. From rsalz at akamai.com Mon Aug 6 00:29:09 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 6 Aug 2018 00:29:09 +0000 Subject: [openssl-users] ssl save/restore/migrate functionality In-Reply-To: <58F2731B-4CE1-4331-AAD7-C67F3104E69D@dukhovni.org> References: <58F2731B-4CE1-4331-AAD7-C67F3104E69D@dukhovni.org> Message-ID: <1FA06BB6-D622-44F9-9245-468DED4DC8B5@akamai.com> > Do you see it being of enough value to consider bringing the feature into your roadmap. No. At least not in my opinion. Migrating "live" TLS connections does not seem a common situation, and is bound to be non-portable. From hareesh.sai at gmail.com Mon Aug 6 13:00:14 2018 From: hareesh.sai at gmail.com (Hareesh D) Date: Mon, 6 Aug 2018 18:30:14 +0530 Subject: [openssl-users] About 1.0.2p version release !! Message-ID: Hi, Anyone know when is the official release of 1.0.2p version? Is it possible to get such info about openssl version plan ? Thanks !! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Aug 6 14:30:54 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 6 Aug 2018 16:30:54 +0200 Subject: [openssl-users] The new BN_num_bits_word in 1.0.2o triggers bug in MS C 14.00.60131 for ARM Message-ID: The new constant-time implementation of BN_num_bits_word in OpenSSL 1.0.2o triggers a compiler bug in Microsoft C 14.00.60131 for ARM (part of Visual Studio 2005 SP1).? The bug happens at all optimizations levels except completely disabled. Unfortunately, that version of Microsoft C is the official system compiler for some popular versions of Windows CE. I have not seen this bug in the MS compilers in Visual Studio 2012 (CL 17.00.60610.1) and Embedded Visual C++ 4.0 (CLARM.exe 12.20.9409), but those are system compilers for different CE versions and the system headers are not compatible across compilers. Here is an example of what the function is miscompiled to: BN_num_bits_word: ? 00000000: E3500000 cmp???????? r0, #0 ? 00000004: 0A000007 beq???????? |$LN3| ? 00000008: E1A030A0 mov???????? r3, r0, lsr #1 ? 0000000C: E2633000 rsb???????? r3, r3, #0 ? 00000010: E1A03FA3 mov???????? r3, r3, lsr #31 ? 00000014: E2633000 rsb???????? r3, r3, #0 ? 00000018: E2033001 and???????? r3, r3, #1 ? 0000001C: E3A02001 mov???????? r2, #1 ? 00000020: E0830002 add???????? r0, r3, r2 ? 00000024: E1A0F00E mov???????? pc, lr $LN3: ? 00000028: E1A030A0 mov???????? r3, r0, lsr #1 ? 0000002C: E2633000 rsb???????? r3, r3, #0 ? 00000030: E1A03FA3 mov???????? r3, r3, lsr #31 ? 00000034: E2633000 rsb???????? r3, r3, #0 ? 00000038: E2033001 and???????? r3, r3, #1 ? 0000003C: E3A02000 mov???????? r2, #0 ? 00000040: E0830002 add???????? r0, r3, r2 ? 00000044: E1A0F00E mov???????? pc, lr The patch below works around this, porting this to OpenSSL 1.1.x is left as an exercise for the reader: Work around a serious compiler bug in the system compiler for CE 5.00 ?? (Including Windows Mobile 5.x and 6.x). Author: WiseMo A/S, licensed under the Openssl license diff -Naur openssl-1.0.2o.orig/crypto/bn/bn_lib.c openssl-1.0.2o/crypto/bn/bn_lib.c --- openssl-1.0.2o.orig/crypto/bn/bn_lib.c??? 2018-03-27 13:54:46.000000000 +0000 +++ openssl-1.0.2o/crypto/bn/bn_lib.c??? 2018-05-11 10:17:55.000000000 +0000 @@ -142,6 +142,27 @@ ???? return (&const_one); ?} +#if _MSC_VER >= 1400 && _MSC_VER < 1500 && \ +??? (defined(__arm__)??????????? || \ +???? defined(__arm)????????????? || \ +???? defined(_M_ARM)???????????? || \ +???? defined(_ARM_)????????????? || \ +???? defined(ARM)??????????????? || \ +???? defined(__ARMEL__)????????? || \ +???? defined(__ARM_BIG_ENDIAN)?? || \ +???? defined(__MARM__)?????????? || \ +???? defined(__ARM_ARCH)???????? || \ +???? defined(__thumb__)????????? || \ +???? defined(_M_THUMB)?????????? || \ +???? defined(_THUMB_)??????????? || \ +???? defined(THUMB)) +// This compiler (The Visual Studio 2005 ARM Compiler), at least with SP1 +// completely miscompiles BN_num_bits_word() ! +#define MS_BROKEN_BN_num_bits_word? 1 + +#pragma optimize("", off) +#endif + ?int BN_num_bits_word(BN_ULONG l) ?{ ???? BN_ULONG x, mask; @@ -197,6 +218,10 @@ ???? return ((i * BN_BITS2) + BN_num_bits_word(a->d[i])); ?} +#ifdef MS_BROKEN_BN_num_bits_word +#pragma optimize("", on) +#endif + ?void BN_clear_free(BIGNUM *a) ?{ ???? int i; 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 Aug 7 14:09:19 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 7 Aug 2018 15:09:19 +0100 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: <06bd7b43-d84b-d844-e2a5-511dd671c5af@openssl.org> Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.0i and 1.0.2p. These releases will be made available on 14th August 2018 between approximately 1200-1600 UTC. These are bug-fix releases. They also contain the fixes for two LOW severity security issues (CVE-2018-0732 and CVE-2018-0737) which were previously announced here: https://www.openssl.org/news/secadv/20180612.txt https://www.openssl.org/news/secadv/20180416.txt Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jisoza at gmail.com Wed Aug 8 03:31:53 2018 From: jisoza at gmail.com (Juan Isoza) Date: Wed, 8 Aug 2018 05:31:53 +0200 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: References: Message-ID: and final 1.1.1 1.0.2p is for 14 august Le lun. 6 ao?t 2018 ? 15:00, Hareesh D a ?crit : > Hi, > > Anyone know when is the official release of 1.0.2p version? Is it possible > to get such info about openssl version plan ? > > Thanks !! > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Aug 8 08:27:43 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Aug 2018 09:27:43 +0100 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: References: Message-ID: On 08/08/18 04:31, Juan Isoza wrote: > and final 1.1.1 There is no date yet. We are still waiting on the official publication of the TLSv1.3 RFC which we anticipate happening any day now. Once that happens there will be another 1.1.1 beta release cycle soon after. Assuming no major issues are identified in that beta the final release should happen soon after that. Matt > > 1.0.2p is for 14 august > > Le?lun. 6 ao?t 2018 ??15:00, Hareesh D > a ?crit?: > > Hi, > > Anyone know when is the official release of 1.0.2p version? Is it > possible to get such info about openssl version plan ? > > Thanks !! > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > From doctor at doctor.nl2k.ab.ca Wed Aug 8 12:39:50 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 8 Aug 2018 06:39:50 -0600 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: References: Message-ID: <20180808123950.GA92017@doctor.nl2k.ab.ca> On Wed, Aug 08, 2018 at 09:27:43AM +0100, Matt Caswell wrote: > > > On 08/08/18 04:31, Juan Isoza wrote: > > and final 1.1.1 > > There is no date yet. We are still waiting on the official publication > of the TLSv1.3 RFC which we anticipate happening any day now. Once that > happens there will be another 1.1.1 beta release cycle soon after. > Assuming no major issues are identified in that beta the final release > should happen soon after that. > > Matt > MAtt how compatible is 1.1.1 to 1.1.0 brach? Will applicaions like NAmed, Exim, clamav, INND, proftpd, pure-ftpd, and apache et al work? > > > > > 1.0.2p is for 14 august > > > > Le??lun. 6 ao??t 2018 ????15:00, Hareesh D > > a ??crit??: > > > > Hi, > > > > Anyone know when is the official release of 1.0.2p version? Is it > > possible to get such info about openssl version plan ? > > > > Thanks !! > > -- > > 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 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism The heart has its reasons which reason knows nothing of. -Blaise Pascal From matt at openssl.org Wed Aug 8 12:46:54 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Aug 2018 13:46:54 +0100 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: <20180808123950.GA92017@doctor.nl2k.ab.ca> References: <20180808123950.GA92017@doctor.nl2k.ab.ca> Message-ID: On 08/08/18 13:39, The Doctor wrote: > On Wed, Aug 08, 2018 at 09:27:43AM +0100, Matt Caswell wrote: >> >> >> On 08/08/18 04:31, Juan Isoza wrote: >>> and final 1.1.1 >> >> There is no date yet. We are still waiting on the official publication >> of the TLSv1.3 RFC which we anticipate happening any day now. Once that >> happens there will be another 1.1.1 beta release cycle soon after. >> Assuming no major issues are identified in that beta the final release >> should happen soon after that. >> >> Matt >> > > MAtt how compatible is 1.1.1 to 1.1.0 brach? > > Will applicaions like NAmed, Exim, clamav, INND, proftpd, pure-ftpd, > and apache et al work? Well, I've not tested those applications but the intention is that it should be a drop in replacement and fully API/ABI compatible. However there are some potential "gotcha's" with TLSv1.3 which could cause some problems for some applications. This is primarily because the TLSv1.3 protocol is significantly different to TLSv1.2 and below. See: https://wiki.openssl.org/index.php/TLS1.3 Matt > >> >>> >>> 1.0.2p is for 14 august >>> >>> Le??lun. 6 ao??t 2018 ????15:00, Hareesh D >> > a ??crit??: >>> >>> Hi, >>> >>> Anyone know when is the official release of 1.0.2p version? Is it >>> possible to get such info about openssl version plan ? >>> >>> Thanks !! >>> -- >>> 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 stephane at codingwizard.nl Wed Aug 8 16:01:16 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Wed, 8 Aug 2018 18:01:16 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate Message-ID: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> Hello all, By default, if I create an X 509 certificate with a public key in it, the object identifier is rsaEncyption (1.2.840.113549.1.1.1). Is it possible to specify a different object identifier, e.g. rsaOAEP (1.2.840.113549.1.1.7)? I looked into the various EVP_PKEY and EVP_PKEY_CTX functions, and other places in code, but the only place this object ID is specified is in obj_dat.h, and not used anywhere else (as far as I can see...) Regards, Stephane van Hardeveld From kgoldman at us.ibm.com Wed Aug 8 17:20:50 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 8 Aug 2018 13:20:50 -0400 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> Message-ID: 1 - If you are trying to extract the public key, X509_get_pubkey() won't work. I have sample code to do it. Let me know if you want the complete function. Basically: X509_get_X509_PUBKEY X509_PUBKEY_get0_param d2i_RSAPublicKey 2 - If you are trying to verify a certificate chain, it does not work with openssl 1.1. You have to stay at 1.0 until someone (perhaps me) submits a fix. ~~~~~~~~~~~~~ BTW, the only time I ever saw rsaAOEP was for TPM 1.2 EK certificates. If you're working with the TPM, I can supply a lot of sample code. On 8/8/2018 12:01 PM, Stephane van Hardeveld wrote: > Hello all, > > By default, if I create an X 509 certificate with a public key in it, the > object identifier is rsaEncyption (1.2.840.113549.1.1.1). Is it possible to > specify a different object identifier, e.g. rsaOAEP (1.2.840.113549.1.1.7)? > I looked into the various EVP_PKEY and EVP_PKEY_CTX functions, and other > places in code, but the only place this object ID is specified is in > obj_dat.h, and not used anywhere else (as far as I can see...) > > Regards, > Stephane van Hardeveld > From rgm at htt-consult.com Wed Aug 8 19:49:48 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 8 Aug 2018 15:49:48 -0400 Subject: [openssl-users] EDDSA crl creation woes Message-ID: <5c6864da-870d-52ff-5689-e43c72eaee7f@htt-consult.com> Finally back on working on my EDDSA pki. Working on beta Fedora29 which now ships with: OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018 To recap, there are challenges on hash specification.? In creating certs, I cannot have default_md line in my .cnf file, or at least for it to = sha256.? And in those commands where I had to have -md sha256 with ecdsa, I have to have -md null.? This is compared to those commands that took -sha256 and now require nothing in the command line about the hash. So one to crl: ?? openssl ca -config $dir/openssl-$intermediate.cnf \ ???????? -gencrl -out $dir/crl/$crl Using configuration from /root/ca/intermediate/openssl-intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem: variable lookup failed for CA_default::default_md 3069739024:error:0E06D06C:configuration file routines:NCONF_get_string:no value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md In this .cnf file, there is no default_md line. So I added -md to the command line: ?? openssl ca -config $dir/openssl-$intermediate.cnf -md null\ ???????? -gencrl -out $dir/crl/$crl And that worked. Very confusing.? It would be preferable if EDDSA related generation just ignores md values? From doctor at doctor.nl2k.ab.ca Wed Aug 8 20:15:31 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 8 Aug 2018 14:15:31 -0600 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: References: <20180808123950.GA92017@doctor.nl2k.ab.ca> Message-ID: <20180808201531.GA87719@doctor.nl2k.ab.ca> On Wed, Aug 08, 2018 at 01:46:54PM +0100, Matt Caswell wrote: > > > On 08/08/18 13:39, The Doctor wrote: > > On Wed, Aug 08, 2018 at 09:27:43AM +0100, Matt Caswell wrote: > >> > >> > >> On 08/08/18 04:31, Juan Isoza wrote: > >>> and final 1.1.1 > >> > >> There is no date yet. We are still waiting on the official publication > >> of the TLSv1.3 RFC which we anticipate happening any day now. Once that > >> happens there will be another 1.1.1 beta release cycle soon after. > >> Assuming no major issues are identified in that beta the final release > >> should happen soon after that. > >> > >> Matt > >> > > > > MAtt how compatible is 1.1.1 to 1.1.0 brach? > > > > Will applicaions like NAmed, Exim, clamav, INND, proftpd, pure-ftpd, > > and apache et al work? > > Well, I've not tested those applications but the intention is that it > should be a drop in replacement and fully API/ABI compatible. However > there are some potential "gotcha's" with TLSv1.3 which could cause some > problems for some applications. This is primarily because the TLSv1.3 > protocol is significantly different to TLSv1.2 and below. See: > > https://wiki.openssl.org/index.php/TLS1.3 > > Matt > Right when will TLSv1.3 be officially recognised? > > > > >> > >>> > >>> 1.0.2p is for 14 august > >>> > >>> Le??lun. 6 ao??t 2018 ????15:00, Hareesh D >>> > a ??crit??: > >>> > >>> Hi, > >>> > >>> Anyone know when is the official release of 1.0.2p version? Is it > >>> possible to get such info about openssl version plan ? > >>> > >>> Thanks !! > >>> -- > >>> 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 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism The heart has its reasons which reason knows nothing of. -Blaise Pascal From matt at openssl.org Wed Aug 8 20:21:37 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 8 Aug 2018 21:21:37 +0100 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: <20180808201531.GA87719@doctor.nl2k.ab.ca> References: <20180808123950.GA92017@doctor.nl2k.ab.ca> <20180808201531.GA87719@doctor.nl2k.ab.ca> Message-ID: On 08/08/18 21:15, The Doctor wrote: > On Wed, Aug 08, 2018 at 01:46:54PM +0100, Matt Caswell wrote: >> >> >> On 08/08/18 13:39, The Doctor wrote: >>> On Wed, Aug 08, 2018 at 09:27:43AM +0100, Matt Caswell wrote: >>>> >>>> >>>> On 08/08/18 04:31, Juan Isoza wrote: >>>>> and final 1.1.1 >>>> >>>> There is no date yet. We are still waiting on the official publication >>>> of the TLSv1.3 RFC which we anticipate happening any day now. Once that >>>> happens there will be another 1.1.1 beta release cycle soon after. >>>> Assuming no major issues are identified in that beta the final release >>>> should happen soon after that. >>>> >>>> Matt >>>> >>> >>> MAtt how compatible is 1.1.1 to 1.1.0 brach? >>> >>> Will applicaions like NAmed, Exim, clamav, INND, proftpd, pure-ftpd, >>> and apache et al work? >> >> Well, I've not tested those applications but the intention is that it >> should be a drop in replacement and fully API/ABI compatible. However >> there are some potential "gotcha's" with TLSv1.3 which could cause some >> problems for some applications. This is primarily because the TLSv1.3 >> protocol is significantly different to TLSv1.2 and below. See: >> >> https://wiki.openssl.org/index.php/TLS1.3 >> >> Matt >> > > Right when will TLSv1.3 be officially recognised? Like I said above we anticipate the RFC publication happening any day now. I am hopeful it could happen this week. Matt > >> >>> >>>> >>>>> >>>>> 1.0.2p is for 14 august >>>>> >>>>> Le??lun. 6 ao??t 2018 ????15:00, Hareesh D >>>> > a ??crit??: >>>>> >>>>> Hi, >>>>> >>>>> Anyone know when is the official release of 1.0.2p version? Is it >>>>> possible to get such info about openssl version plan ? >>>>> >>>>> Thanks !! >>>>> -- >>>>> 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 jisoza at gmail.com Thu Aug 9 07:22:15 2018 From: jisoza at gmail.com (Juan Isoza) Date: Thu, 9 Aug 2018 09:22:15 +0200 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: References: <20180808123950.GA92017@doctor.nl2k.ab.ca> <20180808201531.GA87719@doctor.nl2k.ab.ca> Message-ID: > On 08/08/18 21:15, The Doctor wrote: > > On Wed, Aug 08, 2018 at 01:46:54PM +0100, Matt Caswell wrote: > > >>>> On 08/08/18 04:31, Juan Isoza wrote: > >>>>> and final 1.1.1 > >>>> > >>>> There is no date yet. We are still waiting on the official publication > >>>> of the TLSv1.3 RFC which we anticipate happening any day now. Once > that > >>>> happens there will be another 1.1.1 beta release cycle soon after. > >>>> Assuming no major issues are identified in that beta the final release > >>>> should happen soon after that. > > So we can (saying 75% of chance) IETF RFC then openssl pre9 before 24 august, and if no major bug, a release of openssl before october... Next step will help users with recent Linux (and other) distribution packaged with openssl 1.1.0 switch without risk to openssl 1.1.1 to offer TLS 1.3 (for server by example). But this is another thing.. regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane at codingwizard.nl Thu Aug 9 08:14:30 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Thu, 9 Aug 2018 10:14:30 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> Message-ID: <01c601d42fb8$ff4ea8a0$fdebf9e0$@codingwizard.nl> Hi Ken, I am trying to do two thing: 1: Generate X 509 certificates, with RSA-PSS signing, with different Hashing and Masking (SHA1 and SHA256), including an RSA Public key as content. This RSA 'content key' should specify it will be used for RSA-OAEP decryption. 2: Verify X 509 certificates, produced by other tools, which have the same format Currently, I am able to: - create a X 509 certificate with the different hashing and masking algorithms, but only with standard RSA Encryption OID. Verification of these certificates succeeds, and X509_get_pubkey() works as expected - Verify a X 509 certificate which is generated by a different tool, with SHA256 hashing and masking and RSA OAEP OID. Verification succeeds, but indeed, X509_get_pubkey fails (unknown algorithm I believe). I am able to retrieve the public key via ASN1_BIT_STRING *asnPubKey = X509_get0_pubkey_bitstr(x); unsigned char* pblob = asnPubKey->data; And then parsing the ASN myself. Will test your solution as well, seems a bit more robust ;-) One other thing I encountered: if wincrypt is used as certificate generator, it creates a valid certificate when using SHA1 as hashing and masking algorithm, but the signing seems to go wrong: openssl X509_verify reports 'first octet invalid'. Any idea if this is an issue with wincrypt? If using SHA256 as hashing and masking, the resulting ASN is invalid (sizes are not correct), openssl still can read it, and still reports the same 'first octet invalid' error. Verification of the signing itself is than already ok, right? Regards, Stephane > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Ken Goldman > Sent: woensdag 8 augustus 2018 19:21 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] rsaOAEP OID in X509 certificate > > 1 - If you are trying to extract the public key, X509_get_pubkey() won't > work. I have sample code to do it. Let me know if you want the > complete function. > > Basically: > > X509_get_X509_PUBKEY > X509_PUBKEY_get0_param > d2i_RSAPublicKey > > 2 - If you are trying to verify a certificate chain, it does not work > with openssl 1.1. You have to stay at 1.0 until someone (perhaps me) > submits a fix. > > ~~~~~~~~~~~~~ > > BTW, the only time I ever saw rsaAOEP was for TPM 1.2 EK certificates. > If you're working with the TPM, I can supply a lot of sample code. > > On 8/8/2018 12:01 PM, Stephane van Hardeveld wrote: > > Hello all, > > > > By default, if I create an X 509 certificate with a public key in it, the > > object identifier is rsaEncyption (1.2.840.113549.1.1.1). Is it possible to > > specify a different object identifier, e.g. rsaOAEP (1.2.840.113549.1.1.7)? > > I looked into the various EVP_PKEY and EVP_PKEY_CTX functions, and > other > > places in code, but the only place this object ID is specified is in > > obj_dat.h, and not used anywhere else (as far as I can see...) > > > > Regards, > > Stephane van Hardeveld > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From kgoldman at us.ibm.com Thu Aug 9 12:56:01 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 9 Aug 2018 08:56:01 -0400 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <01c601d42fb8$ff4ea8a0$fdebf9e0$@codingwizard.nl> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <01c601d42fb8$ff4ea8a0$fdebf9e0$@codingwizard.nl> Message-ID: On 8/9/2018 4:14 AM, Stephane van Hardeveld wrote: > Hi Ken, > > I am trying to do two thing: > 1: Generate X 509 certificates, with RSA-PSS signing, with different Hashing > and Masking (SHA1 and SHA256), including an RSA Public key as content. This > RSA 'content key' should specify it will be used for RSA-OAEP decryption. > 2: Verify X 509 certificates, produced by other tools, which have the same > format Do you really have to use a non-standard OID for the public key? If you do, you will be creating a certificate that cannot be parsed by openssl, Java's crypto library, and perhaps others. Your users will have to write custom code to validate the certificate and to extract the public key. In addition, you'll need custom CA code to create the certificates. I worry that custom crypto code can open attack surfaces compared to using well tested standards. Parsing DER securely is known to be hard. From matt at openssl.org Thu Aug 9 13:34:42 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 9 Aug 2018 14:34:42 +0100 Subject: [openssl-users] EDDSA crl creation woes In-Reply-To: <5c6864da-870d-52ff-5689-e43c72eaee7f@htt-consult.com> References: <5c6864da-870d-52ff-5689-e43c72eaee7f@htt-consult.com> Message-ID: <83ce493d-da10-3eb3-fa1e-48bbe8ab6680@openssl.org> On 08/08/18 20:49, Robert Moskowitz wrote: > Finally back on working on my EDDSA pki. > > Working on beta Fedora29 which now ships with: > > OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018 > > > To recap, there are challenges on hash specification.? In creating > certs, I cannot have default_md line in my .cnf file, or at least for it > to = sha256.? And in those commands where I had to have -md sha256 with > ecdsa, I have to have -md null.? This is compared to those commands that > took -sha256 and now require nothing in the command line about the hash. > > So one to crl: > > ?? openssl ca -config $dir/openssl-$intermediate.cnf \ > ???????? -gencrl -out $dir/crl/$crl > > Using configuration from /root/ca/intermediate/openssl-intermediate.cnf > Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem: > variable lookup failed for CA_default::default_md > 3069739024:error:0E06D06C:configuration file > routines:NCONF_get_string:no > value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md > > In this .cnf file, there is no default_md line. > > So I added -md to the command line: > > ?? openssl ca -config $dir/openssl-$intermediate.cnf -md null\ > ???????? -gencrl -out $dir/crl/$crl > > And that worked. > > Very confusing.? It would be preferable if EDDSA related generation just > ignores md values? > > I've just created PR 6901 that will hopefully improve things. This basically ignores any -md or default_md setting if EdDSA is in use. https://github.com/openssl/openssl/pull/6901 Matt From rgm at htt-consult.com Thu Aug 9 13:57:39 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 9 Aug 2018 09:57:39 -0400 Subject: [openssl-users] EDDSA crl creation woes In-Reply-To: <83ce493d-da10-3eb3-fa1e-48bbe8ab6680@openssl.org> References: <5c6864da-870d-52ff-5689-e43c72eaee7f@htt-consult.com> <83ce493d-da10-3eb3-fa1e-48bbe8ab6680@openssl.org> Message-ID: <20903fcd-8872-ed54-e0c6-9a4d325f90a0@htt-consult.com> On 08/09/2018 09:34 AM, Matt Caswell wrote: > > On 08/08/18 20:49, Robert Moskowitz wrote: >> Finally back on working on my EDDSA pki. >> >> Working on beta Fedora29 which now ships with: >> >> OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018 >> >> >> To recap, there are challenges on hash specification.? In creating >> certs, I cannot have default_md line in my .cnf file, or at least for it >> to = sha256.? And in those commands where I had to have -md sha256 with >> ecdsa, I have to have -md null.? This is compared to those commands that >> took -sha256 and now require nothing in the command line about the hash. >> >> So one to crl: >> >> ?? openssl ca -config $dir/openssl-$intermediate.cnf \ >> ???????? -gencrl -out $dir/crl/$crl >> >> Using configuration from /root/ca/intermediate/openssl-intermediate.cnf >> Enter pass phrase for /root/ca/intermediate/private/intermediate.key.pem: >> variable lookup failed for CA_default::default_md >> 3069739024:error:0E06D06C:configuration file >> routines:NCONF_get_string:no >> value:crypto/conf/conf_lib.c:275:group=CA_default name=default_md >> >> In this .cnf file, there is no default_md line. >> >> So I added -md to the command line: >> >> ?? openssl ca -config $dir/openssl-$intermediate.cnf -md null\ >> ???????? -gencrl -out $dir/crl/$crl >> >> And that worked. >> >> Very confusing.? It would be preferable if EDDSA related generation just >> ignores md values? >> >> > I've just created PR 6901 that will hopefully improve things. This > basically ignores any -md or default_md setting if EdDSA is in use. > > https://github.com/openssl/openssl/pull/6901 Matt, Thanks for addressing this.? It will keep a lot of questions off the user list once use of EDDSA becomes 'mainline'. Please let me know when a beta is out with this change so I can ask the Fedora team to grab it so I can test it. It pulls a big caveat section from the eddsa-pki draft I am writing. From stephane at codingwizard.nl Thu Aug 9 14:51:46 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Thu, 9 Aug 2018 16:51:46 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <01c601d42fb8$ff4ea8a0$fdebf9e0$@codingwizard.nl> Message-ID: <002501d42ff0$7eebb4e0$7cc31ea0$@codingwizard.nl> > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Ken Goldman > Sent: donderdag 9 augustus 2018 14:56 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] rsaOAEP OID in X509 certificate > > On 8/9/2018 4:14 AM, Stephane van Hardeveld wrote: > > Hi Ken, > > > > I am trying to do two thing: > > 1: Generate X 509 certificates, with RSA-PSS signing, with different Hashing > > and Masking (SHA1 and SHA256), including an RSA Public key as content. > This > > RSA 'content key' should specify it will be used for RSA-OAEP decryption. > > 2: Verify X 509 certificates, produced by other tools, which have the same > > format > > Do you really have to use a non-standard OID for the public key? > > If you do, you will be creating a certificate that cannot be parsed by > openssl, Java's crypto library, and perhaps others. Your users will > have to write custom code to validate the certificate and to extract the > public key. > > In addition, you'll need custom CA code to create the certificates. > > I worry that custom crypto code can open attack surfaces compared > to using well tested standards. Parsing DER securely is known to be > hard. > > Hi Ken, I will discuss this, but as far as I understand, these OID are allowed by the X 509 standard: 4.1.2.7. Subject Public Key Info This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in Section 4.1.1.2. The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in [RFC3279], [RFC4055], and [RFC4491]. And in rfc4055, 4.1 Openssl is capable of parsing it, only retrieving it gives an error on unknown algorithm (which is correct, since only rsaEncryption OID is recognized). Java I did not try yet, but the online ASN.1 parsers were also capable of decoding it, see enclosed png. Regards, Stephane -------------- next part -------------- A non-text attachment was scrubbed... Name: certificate_asndecoded.png Type: image/png Size: 58716 bytes Desc: not available URL: From kgoldman at us.ibm.com Thu Aug 9 16:52:12 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 9 Aug 2018 12:52:12 -0400 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <002501d42ff0$7eebb4e0$7cc31ea0$@codingwizard.nl> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <01c601d42fb8$ff4ea8a0$fdebf9e0$@codingwizard.nl> <002501d42ff0$7eebb4e0$7cc31ea0$@codingwizard.nl> Message-ID: On 8/9/2018 10:51 AM, Stephane van Hardeveld wrote: > > I will discuss this, but as far as I understand, these OID are allowed by > the X 509 standard: > 4.1.2.7. Subject Public Key Info > > [snip] > > And in rfc4055, 4.1 > > Openssl is capable of parsing it, only retrieving it gives an error on > unknown algorithm (which is correct, since only rsaEncryption OID is > recognized). Java I did not try yet, but the online ASN.1 parsers were also > capable of decoding it, see enclosed png. I understand that the X509 standard permits it. However, I'm looking at the practical side - crypto libraries. If openssl, Java, etc. can't use the results, and a typical CA can't create the certificate, then you require custom code. The drawback is that custom code, especially DER parsing code, is a security risk. It's hard to get correct when facing an attacker sending malformed certificates. You have to decide whether the benefit to this "meets the X509 standard but isn't supported" OID is worth the potential for an exploitable bug. From stephane at codingwizard.nl Thu Aug 9 18:43:16 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Thu, 9 Aug 2018 20:43:16 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <01c601d42fb8$ff4ea8a0$fdebf9e0$@codingwizard.nl> <002501d42ff0$7eebb4e0$7cc31ea0$@codingwizard.nl> Message-ID: <006001d43010$d5f43b70$81dcb250$@codingwizard.nl> > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Ken Goldman > Sent: donderdag 9 augustus 2018 18:52 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] rsaOAEP OID in X509 certificate > > On 8/9/2018 10:51 AM, Stephane van Hardeveld wrote: > > > > I will discuss this, but as far as I understand, these OID are allowed by > > the X 509 standard: > > 4.1.2.7. Subject Public Key Info > > > > [snip] > > > > And in rfc4055, 4.1 > > > > Openssl is capable of parsing it, only retrieving it gives an error on > > unknown algorithm (which is correct, since only rsaEncryption OID is > > recognized). Java I did not try yet, but the online ASN.1 parsers were also > > capable of decoding it, see enclosed png. > > I understand that the X509 standard permits it. > > However, I'm looking at the practical side - crypto libraries. > > If openssl, Java, etc. can't use the results, and a typical CA can't > create the certificate, then you require custom code. > > The drawback is that custom code, especially DER parsing code, is a > security risk. It's hard to get correct when facing an attacker sending > malformed certificates. > > You have to decide whether the benefit to this "meets the X509 standard > but isn't supported" OID is worth the potential for an exploitable bug. > Ah, yes. The practical world. Always a bummer. But good point anyways. Thanks for shedding some light on this issue Regards, Stephane From openssl-users at dukhovni.org Thu Aug 9 19:05:23 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Aug 2018 15:05:23 -0400 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> Message-ID: > On Aug 8, 2018, at 12:01 PM, Stephane van Hardeveld wrote: > > By default, if I create an X 509 certificate with a public key in it, the > object identifier is rsaEncyption (1.2.840.113549.1.1.1). Is it possible to > specify a different object identifier, e.g. rsaOAEP (1.2.840.113549.1.1.7)? > I looked into the various EVP_PKEY and EVP_PKEY_CTX functions, and other > places in code, but the only place this object ID is specified is in > obj_dat.h, and not used anywhere else (as far as I can see...) This request is a bit puzzling, since OAEP is a padding mode for RSA *encryption*, not RSA signatures. For the latter, once typically goes with PSS if one wants a more modern signature scheme. OpenSSL supports OAEP for RSA encryption (e.g. in CMS), but in X.509, where the task at hand is signing... So it is not clear that what you're looking for makes sense. -- Viktor. From stephane at codingwizard.nl Thu Aug 9 19:21:58 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Thu, 9 Aug 2018 21:21:58 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> Message-ID: <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Viktor Dukhovni > Sent: donderdag 9 augustus 2018 21:05 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] rsaOAEP OID in X509 certificate > > > > > On Aug 8, 2018, at 12:01 PM, Stephane van Hardeveld > wrote: > > > > By default, if I create an X 509 certificate with a public key in it, the > > object identifier is rsaEncyption (1.2.840.113549.1.1.1). Is it possible to > > specify a different object identifier, e.g. rsaOAEP (1.2.840.113549.1.1.7)? > > I looked into the various EVP_PKEY and EVP_PKEY_CTX functions, and > other > > places in code, but the only place this object ID is specified is in > > obj_dat.h, and not used anywhere else (as far as I can see...) > > This request is a bit puzzling, since OAEP is a padding mode for RSA > *encryption*, not RSA signatures. For the latter, once typically > goes with PSS if one wants a more modern signature scheme. > > OpenSSL supports OAEP for RSA encryption (e.g. in CMS), but in X.509, > where the task at hand is signing... So it is not clear that what > you're looking for makes sense. > > -- > Viktor. > Hi Victor, The certificate is signed with PSS. However, I try to indicate that the public key enclosed IN the certificate should be used with the OAEP padding mode while decrypting a separate message Regards, Stephane From openssl-users at dukhovni.org Thu Aug 9 20:01:25 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 9 Aug 2018 16:01:25 -0400 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> Message-ID: <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> > On Aug 9, 2018, at 3:21 PM, Stephane van Hardeveld wrote: > > The certificate is signed with PSS. However, I try to indicate that the > public key enclosed IN the certificate should be used with the OAEP padding > mode while decrypting a separate message Keys in X.509 certiificates are mostly used for signing (e.g. TLS with DHE or ECDHE key agreement). But I guess you could mint an encryption-only certificate that is not useful for signing, and use it exclusively for key wrapping. I don't know whether marking the key as an RSA-OAEP key would then have the effect of restricting its usage by various libraries to OAEP. In the case of OpenSSL such an SPKI would simply not work at all. :-( If someone contributed a quality implementation of this key type, it would probably be a good candidate for inclusion in libcrypto. More typically (e.g. IN CMS), the fact that OAEP was used to encrypt the message is part of the message metadata, and so decryption will automatically use OAEP when it is was explicitly selected at the time the message was created. Thus OAEP is baked into the message, rather than the certificate. OpenSSL supports "oaep" in cms(1), pkeyutl(1) and rsautl(1) which can create RSA encrypted objects, but does not presently support X.509 certificates with RFC4055/RFC5756 OAEP SPKI. https://tools.ietf.org/html/rfc4055#section-4.1 https://tools.ietf.org/html/rfc5756#section-4 -- Viktor. From stephane at codingwizard.nl Thu Aug 9 20:15:51 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Thu, 9 Aug 2018 22:15:51 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> Message-ID: <007601d4301d$c4cb4e30$4e61ea90$@codingwizard.nl> > > Keys in X.509 certiificates are mostly used for signing (e.g. TLS with > DHE or ECDHE key agreement). But I guess you could mint an encryption- > only > certificate that is not useful for signing, and use it exclusively for > key wrapping. That is exactly the use case ;-) I don't know whether marking the key as an RSA-OAEP key > would then have the effect of restricting its usage by various libraries > to OAEP. In the case of OpenSSL such an SPKI would simply not work at > all. :-( If someone contributed a quality implementation of this key > type, it would probably be a good candidate for inclusion in libcrypto. > > More typically (e.g. IN CMS), the fact that OAEP was used to encrypt > the message is part of the message metadata, and so decryption will > automatically use OAEP when it is was explicitly selected at the time > the message was created. Thus OAEP is baked into the message, rather > than the certificate. That is a perfect reason to use rsaEncryption as PKI OID then. > > OpenSSL supports "oaep" in cms(1), pkeyutl(1) and rsautl(1) which > can create RSA encrypted objects, but does not presently support > X.509 certificates with RFC4055/RFC5756 OAEP SPKI. Thanks for clearing that up. Ken Goldman mentioned it as well. Only broader used implementation until now (besides some proprietary implementations) I have seen supporting this kind of certificates is wincrypt. But not without flaws, especially in the masking function. Regards, Stephane From kurt at roeckx.be Thu Aug 9 21:23:13 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 9 Aug 2018 23:23:13 +0200 Subject: [openssl-users] The new BN_num_bits_word in 1.0.2o triggers bug in MS C 14.00.60131 for ARM In-Reply-To: References: Message-ID: <20180809212313.GA6279@roeckx.be> On Mon, Aug 06, 2018 at 04:30:54PM +0200, Jakob Bohm wrote: > The patch below works around this, porting this to OpenSSL 1.1.x > is left as an exercise for the reader: Can you please open a pull request on github for that? Kurt From rgm at htt-consult.com Fri Aug 10 20:44:26 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 10 Aug 2018 16:44:26 -0400 Subject: [openssl-users] EDDSA test results Message-ID: I have followed the procedure I made for ECDSA certs in: draft-moskowitz-ecdsa-pki (an update is pending on typos I encountered in this run through) But making ED25519 certs instead. Other than obvious changes (e.g. -algorithm ed25519) and hash specification, I was successful. My testing was done on a Fedora-armhfp-28-beta system providing openssl: OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018 I am going to assume that PR6901 will go into the next beta and I can drop the '-md null' from some command lines and do not have to make special .cnf files without md_default lines. I will test this on the next beta to be sure (trust, but verify!) Remaining to do: Using the tree command, here are some certificate size comparisons ? ?? ?????? ECDSA???? ED25519 Root cert??? 826???????? 737 Intermedicate CA cert?? 806 ????? 721 Client cert?????? 944 ?????? 834 Server cert??????????? 1086???????? 971 thank you for making ED25519 available! From rgm at htt-consult.com Fri Aug 10 20:50:04 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 10 Aug 2018 16:50:04 -0400 Subject: [openssl-users] EDDSA test results In-Reply-To: References: Message-ID: Oops.? That is the Fedora 29 beta... On 08/10/2018 04:44 PM, Robert Moskowitz wrote: > I have followed the procedure I made for ECDSA certs in: > > draft-moskowitz-ecdsa-pki (an update is pending on typos I encountered > in this run through) > > But making ED25519 certs instead. > > Other than obvious changes (e.g. -algorithm ed25519) and hash > specification, I was successful. > > My testing was done on a Fedora-armhfp-28-beta system providing openssl: > > OpenSSL 1.1.1-pre8 (beta) FIPS 20 Jun 2018 > > I am going to assume that PR6901 will go into the next beta and I can > drop the '-md null' from some command lines and do not have to make > special .cnf files without md_default lines. > > I will test this on the next beta to be sure (trust, but verify!) > > Remaining to do: > > Using the tree command, here are some certificate size comparisons > > ? ???????????? ?????? ECDSA???? ED25519 > > Root cert?????????????? 826???????? 737 > > Intermedicate CA cert?? 806?? ????? 721 > > Client cert???????????? 944? ?????? 834 > > Server cert??????????? 1086???????? 971 > > > > thank you for making ED25519 available! > From felipe at felipegasper.com Fri Aug 10 22:43:52 2018 From: felipe at felipegasper.com (Felipe Gasper) Date: Fri, 10 Aug 2018 18:43:52 -0400 Subject: [openssl-users] EDDSA key format Message-ID: Hi all, Do EDDSA keys serialize to any format other than SPKI (public) and PKCS8 (private)? I ask because RSA and ECC both have ?native? formats as well as SPKI and PKCS8. Thanks! -FG From tshort at akamai.com Sat Aug 11 00:27:14 2018 From: tshort at akamai.com (Short, Todd) Date: Sat, 11 Aug 2018 00:27:14 +0000 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: References: <20180808123950.GA92017@doctor.nl2k.ab.ca> <20180808201531.GA87719@doctor.nl2k.ab.ca>, Message-ID: <1D47E3BA-2DB2-4EA9-92E8-E965003F7BBF@akamai.com> RFC 8446 (TLS 1.3) was just published about ~30 minutes ago. -- -Todd Short // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On Aug 8, 2018, at 4:22 PM, Matt Caswell wrote: > > > >> On 08/08/18 21:15, The Doctor wrote: >>> On Wed, Aug 08, 2018 at 01:46:54PM +0100, Matt Caswell wrote: >>> >>> >>>> On 08/08/18 13:39, The Doctor wrote: >>>>> On Wed, Aug 08, 2018 at 09:27:43AM +0100, Matt Caswell wrote: >>>>> >>>>> >>>>>> On 08/08/18 04:31, Juan Isoza wrote: >>>>>> and final 1.1.1 >>>>> >>>>> There is no date yet. We are still waiting on the official publication >>>>> of the TLSv1.3 RFC which we anticipate happening any day now. Once that >>>>> happens there will be another 1.1.1 beta release cycle soon after. >>>>> Assuming no major issues are identified in that beta the final release >>>>> should happen soon after that. >>>>> >>>>> Matt >>>>> >>>> >>>> MAtt how compatible is 1.1.1 to 1.1.0 brach? >>>> >>>> Will applicaions like NAmed, Exim, clamav, INND, proftpd, pure-ftpd, >>>> and apache et al work? >>> >>> Well, I've not tested those applications but the intention is that it >>> should be a drop in replacement and fully API/ABI compatible. However >>> there are some potential "gotcha's" with TLSv1.3 which could cause some >>> problems for some applications. This is primarily because the TLSv1.3 >>> protocol is significantly different to TLSv1.2 and below. See: >>> >>> https://wiki.openssl.org/index.php/TLS1.3 >>> >>> Matt >>> >> >> Right when will TLSv1.3 be officially recognised? > > Like I said above we anticipate the RFC publication happening any day > now. I am hopeful it could happen this week. > > Matt > >> >>> >>>> >>>>> >>>>>> >>>>>> 1.0.2p is for 14 august >>>>>> >>>>>> Le??lun. 6 ao??t 2018 ????15:00, Hareesh D >>>>> > a ??crit??: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Anyone know when is the official release of 1.0.2p version? Is it >>>>>> possible to get such info about openssl version plan ? >>>>>> >>>>>> Thanks !! >>>>>> -- >>>>>> 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 philipp_subx at redfish-solutions.com Sat Aug 11 00:23:45 2018 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 10 Aug 2018 18:23:45 -0600 Subject: [openssl-users] Shutdown details In-Reply-To: References: <0059B4A9-E9D1-47D1-A707-03EF94E754E6@dukhovni.org> Message-ID: <31F1B9EE-9B5D-4281-9CAE-A2A2B4F76389@redfish-solutions.com> Hi. This is something that I?m also interested, as a contributor to Libevent, which provides SSL-socket support. I?ve opened an OpenSSL issue: https://github.com/openssl/openssl/issues/6911 to collect the details on how a graceful shutdown can be implemented in Libevent. Thanks, -Philip > On Aug 1, 2018, at 1:46 PM, Alex H wrote: > > [...] The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. > > I've read this before, but I've also checked the sources of SSL_write and they seem contradictory: > > SSL_write does not return with error when SSL_RECEIVED_SHUTDOWN is set, but does so when SSL_SENT_SHUTDOWN is set. Why is this? A minor bug? If the RFC states the end who receives a close_notify should discard any pending writes then it surely seems a bug to allow SSL_write for a connection where SSL_RECEIVED_SHUTDOWN is set? > > .... > > > If your question is whether you can still read any data that may have > been in flight when you send your close_notify, I believe the answer > is no. Further data received from the peer is discarded after a > close_notify is sent. > > I also believe so, especially since SSL_shutdown docs seem to hint that once SSL_shutdown is called, it should be called again until fully done (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown becomes the only function called until the SSL connection is fully closed, no more SSL_read is called and thus it cannot report any received data. SSL_shutdown does not return with any data. > > Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug? > > Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni >: > > > > On Aug 1, 2018, at 2:27 AM, Alex H > wrote: > > > > Is it possible to receive data after calling SSL_shutdown? Reading the specs and docs leaves this rather blurry. > > TLS *does not* support half-closed connections (RFC5246): > > close_notify > This message notifies the recipient that the sender will not send > any more messages on this connection. Note that as of TLS 1.1, > failure to properly close a connection no longer requires that a > session not be resumed. This is a change from TLS 1.0 to conform > with widespread implementation practice. > > Either party may initiate a close by sending a close_notify alert. > Any data received after a closure alert is ignored. > > Unless some other fatal alert has been transmitted, each party is > required to send a close_notify alert before closing the write side > of the connection. The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. It is not required for the initiator > of the close to wait for the responding close_notify alert before > closing the read side of the connection. > > If the application protocol using TLS provides that any data may be > carried over the underlying transport after the TLS connection is > closed, the TLS implementation must receive the responding > close_notify alert before indicating to the application layer that > the TLS connection has ended. If the application protocol will not > transfer any additional data, but will only close the underlying > transport connection, then the implementation MAY choose to close the > transport without waiting for the responding close_notify. No part > of this standard should be taken to dictate the manner in which a > usage profile for TLS manages its data transport, including when > connections are opened or closed. > > Note: It is assumed that closing a connection reliably delivers > pending data before destroying the transport. > > If your question is whether you can still read any data that may have > been in flight when you send your close_notify, I believe the answer > is no. Further data received from the peer is discarded after a > close_notify is sent. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexhultman at gmail.com Fri Aug 10 23:15:32 2018 From: alexhultman at gmail.com (Alex H) Date: Sat, 11 Aug 2018 01:15:32 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: <31F1B9EE-9B5D-4281-9CAE-A2A2B4F76389@redfish-solutions.com> References: <0059B4A9-E9D1-47D1-A707-03EF94E754E6@dukhovni.org> <31F1B9EE-9B5D-4281-9CAE-A2A2B4F76389@redfish-solutions.com> Message-ID: I ended up just treating those details as "unknown" and making my interface more low-level than I first aimed for. I wanted to make the shutdown procedure more automated with a simpler API that wrapped things at a higher level but ended up with pretty much BSD-sockets, but SSL. It is pretty easy to implement when you allow a little bit of uncertainty - it's not required to know 100% of how the internals work to implement shutdown. Den l?r 11 aug. 2018 kl 02:41 skrev Philip Prindeville < philipp_subx at redfish-solutions.com>: > Hi. > > This is something that I?m also interested, as a contributor to Libevent, > which provides SSL-socket support. > > I?ve opened an OpenSSL issue: > > https://github.com/openssl/openssl/issues/6911 > > to collect the details on how a graceful shutdown can be implemented in > Libevent. > > Thanks, > > -Philip > > > On Aug 1, 2018, at 1:46 PM, Alex H wrote: > > [...] The other party MUST respond with a close_notify alert of its own > and close down the connection immediately, *discarding any pending writes* > . > > I've read this before, but I've also checked the sources of SSL_write and > they seem contradictory: > > SSL_write does not return with error when SSL_RECEIVED_SHUTDOWN is set, > but does so when SSL_SENT_SHUTDOWN is set. Why is this? A minor bug? If the > RFC states the end who receives a close_notify should *discard any > pending writes* then it surely seems a bug to allow SSL_write for a > connection where SSL_RECEIVED_SHUTDOWN is set? > > .... > > > If your question is whether you can still read any data that may have > been in flight when you send your close_notify, I believe the answer > is no. Further data received from the peer is discarded after a > close_notify is sent. > > I also believe so, especially since SSL_shutdown docs seem to hint that > once SSL_shutdown is called, it should be called again until fully done > (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown > becomes the only function called until the SSL connection is fully closed, > no more SSL_read is called and thus it cannot report any received data. > SSL_shutdown does not return with any data. > > Regarding the SSL_RECEIVED_SHUTDOWN - do you think this is a minor bug? > > Den ons 1 aug. 2018 kl 21:16 skrev Viktor Dukhovni < > openssl-users at dukhovni.org>: > >> >> >> > On Aug 1, 2018, at 2:27 AM, Alex H wrote: >> > >> > Is it possible to receive data after calling SSL_shutdown? Reading the >> specs and docs leaves this rather blurry. >> >> TLS *does not* support half-closed connections (RFC5246): >> >> close_notify >> This message notifies the recipient that the sender will not send >> any more messages on this connection. Note that as of TLS 1.1, >> failure to properly close a connection no longer requires that a >> session not be resumed. This is a change from TLS 1.0 to conform >> with widespread implementation practice. >> >> Either party may initiate a close by sending a close_notify alert. >> Any data received after a closure alert is ignored. >> >> Unless some other fatal alert has been transmitted, each party is >> required to send a close_notify alert before closing the write side >> of the connection. The other party MUST respond with a close_notify >> alert of its own and close down the connection immediately, >> discarding any pending writes. It is not required for the initiator >> of the close to wait for the responding close_notify alert before >> closing the read side of the connection. >> >> If the application protocol using TLS provides that any data may be >> carried over the underlying transport after the TLS connection is >> closed, the TLS implementation must receive the responding >> close_notify alert before indicating to the application layer that >> the TLS connection has ended. If the application protocol will not >> transfer any additional data, but will only close the underlying >> transport connection, then the implementation MAY choose to close the >> transport without waiting for the responding close_notify. No part >> of this standard should be taken to dictate the manner in which a >> usage profile for TLS manages its data transport, including when >> connections are opened or closed. >> >> Note: It is assumed that closing a connection reliably delivers >> pending data before destroying the transport. >> >> If your question is whether you can still read any data that may have >> been in flight when you send your close_notify, I believe the answer >> is no. Further data received from the peer is discarded after a >> close_notify is sent. >> >> -- >> Viktor. >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Sat Aug 11 03:31:53 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Fri, 10 Aug 2018 23:31:53 -0400 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: <1D47E3BA-2DB2-4EA9-92E8-E965003F7BBF@akamai.com> References: <20180808123950.GA92017@doctor.nl2k.ab.ca> <20180808201531.GA87719@doctor.nl2k.ab.ca> <1D47E3BA-2DB2-4EA9-92E8-E965003F7BBF@akamai.com> Message-ID: <11f43cf9-b343-9d48-e854-dd9577eaa3a6@blastwave.org> On 08/10/2018 08:27 PM, Short, Todd via openssl-users wrote: > RFC 8446 (TLS 1.3) was just published about ~30 minutes ago. > Wonderful ! Todd are you okay[1] with your name being here : https://www.tls13.net/ Given that your name is in the maillist I figured .. sure, most likely .. but it is best to ask. Dennis From rsalz at akamai.com Sat Aug 11 13:37:07 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 11 Aug 2018 13:37:07 +0000 Subject: [openssl-users] TLS 1.3 and the release Message-ID: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> You probably know by now that TLS 1.3 was just released as RFC 8446; https://www.rfc-editor.org/info/rfc8446 This note is just trying to forestall a number of question threads. Our release plan called for one final beta (there were various draft-interop things to take out and some other little nits) and then the official release. We have had no discussion of changing that plan. Matt has already prepared a PR (the number escapes me), and there are a couple of open issues we still have to resolve. If all goes well, however, the final beta should begin very soon. Thanks to everyone in the OpenSSL community for your help and support! -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Aug 11 13:42:22 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 11 Aug 2018 15:42:22 +0200 (CEST) Subject: [openssl-users] [openssl-project] TLS 1.3 and the release In-Reply-To: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> References: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> Message-ID: <20180811.154222.2141826982723565227.levitte@openssl.org> In message <641FEB77-064E-4A49-A30B-41EDF127999F at akamai.com> on Sat, 11 Aug 2018 13:37:07 +0000, "Salz, Rich" said: rsalz> Matt has already prepared a PR (the number escapes me) https://github.com/openssl/openssl/pull/6741 -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From richard at nod.at Sat Aug 11 15:22:48 2018 From: richard at nod.at (Richard Weinberger) Date: Sat, 11 Aug 2018 17:22:48 +0200 Subject: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken? Message-ID: <15661103.eW4U5Sr9IO@blindfold> Hi! I have a hard time figuring how to write a DTLS UDP server that supports multiple clients. My dummy single user server works fine. To support multiple clients I tried two approaches: 1. singled threaded async IO, preferred since I have to deal with many clients 2. multi threaded, one thread per client Both approaches seem to be doomed for the very same reason, namely that DTLSv1_listen() does peek into the kernel queue and does not consume the client hello from the UDP socket. Both loop around DTLSv1_listen() and as soon the function returns > 0 a new socket for the client is created using bind/connect and the client address as returned by DTLSv1_listen(). This client socket is then passed to a new thread or feed into the event loop. In both cases the client hello is still in the queue of the server socket and the program will over and over create new client sockets. After searching the web for examples I've found this thread[0], where the approaches I tried are advertised. In [1] the demo server at [3] is suggested as good example. dtls_udp_echo.c from [3] does exactly what I did in my 2nd approach, and it fails in the same way. As soon one client connects, it creates over and over new sockets until it dies due to too many open files. After digging a bit into the source it looks to me like since commit [3], DTLSv1_listen() assumes that you re-use the same socket for the new client. Which makes supporting multiple clients impossible. Given that I'm not an OpenSSL DTLS expert I still hope I miss something. Can you please help me to figure what the correct approach for multiple clients is? Thanks, //richard P.s: I'm on Linux, OpenSSL 1.1.0h, but tried as OpenSSL git as of today. [0] https://mta.openssl.org/pipermail/openssl-users/2018-April/007861.html [1] https://mta.openssl.org/pipermail/openssl-users/2018-April/007864.html [2] https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c [3] https://github.com/openssl/openssl/commit/e3d0dae7cf8363ca462ac425b72c7bb31c3b4b7a From mcr at sandelman.ca Sun Aug 12 18:12:48 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 12 Aug 2018 14:12:48 -0400 Subject: [openssl-users] TLS 1.3 and the release In-Reply-To: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> References: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> Message-ID: <14581.1534097568@localhost> Salz, Rich via openssl-users wrote: > You probably know by now that TLS 1.3 was just released as RFC 8446; > https://www.rfc-editor.org/info/rfc8446 This note is just trying to > forestall a number of question threads. > Our release plan called for one final beta (there were various > draft-interop things to take out and some other little nits) and then > the official release. We have had no discussion of changing that plan. SUPER DUPER !!!! There are a bunch of non-openssl-project issues that are gonna need some coordination if we are gonna get TLS 1.3 out there better. I'm just dealing with trying to get openssl 1.1.0 to get installed on Ubuntu bionic. Yes, there is a package, but all the other packages depend upon 1.0.x.... and many things are linking against 1.0.x rather than 1.1, when both are installed... I don't know why they build stuff against 1.0.x rather than 1.1.0: I think it's a packaging oops. The story is worse for Xenial, on which many containers are presently based. Debian jessie/stretch and Devuan jessie/ascii might be in better situation, or maybe my observations of them are tainted by having installed from source. I realize that this is "not your problem", but I want to suggest that we open an Issue now in order to attract google hits so that it can be coordinated. In particular there are dozens of ubuntu PPAs that have rebuilds of openssl + XYZ, but 3/4 of them are stale... it would be nice to nominate a non-lame "winner" I can open such an Issue if you like. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From kurt at roeckx.be Sun Aug 12 18:49:35 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 12 Aug 2018 20:49:35 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: References: Message-ID: <20180812184935.GA11729@roeckx.be> On Wed, Aug 01, 2018 at 08:27:38AM +0200, Alex H wrote: > Hi, > > I have trouble understanding the details of TLS shutdown. I get the basics > but, > > Is it possible to receive data after calling SSL_shutdown? Reading the > specs and docs leaves this rather blurry. > > That is, after sending a close_notify, can I receive data before getting my > client_notify response? > > The sources of SSL_write checks for SSL_SENT_SHUTDOWN state and returns > with error if set, but does not check for SSL_RECEIVED_SHUTDOWN. This > indicates somehow I'm allowed to still send data after received a > close_notify? TLS 1.3 makes it explicit that after you've send a close_notify, the peer is still allowed to send data, so you can still read data. It only closes the connection in one direction. As far as I know, OpenSSL has always supported this, even when the RFC said that the other side needs to send the close_notify back on receiving it. In -pre8 we even have tests covering this behaviour, and the manpages have been update to say that it's possible. See https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html Kurt From kurt at roeckx.be Sun Aug 12 18:53:05 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 12 Aug 2018 20:53:05 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: References: <0059B4A9-E9D1-47D1-A707-03EF94E754E6@dukhovni.org> Message-ID: <20180812185304.GB11729@roeckx.be> On Wed, Aug 01, 2018 at 09:46:37PM +0200, Alex H wrote: > > > If your question is whether you can still read any data that may have > been in flight when you send your close_notify, I believe the answer > is no. Further data received from the peer is discarded after a > close_notify is sent. > > I also believe so, especially since SSL_shutdown docs seem to hint that > once SSL_shutdown is called, it should be called again until fully done > (serving SSL_WANT_READ/WRITE as needed). In other words, SSL_shutdown > becomes the only function called until the SSL connection is fully closed, > no more SSL_read is called and thus it cannot report any received data. > SSL_shutdown does not return with any data. You are probably reading old documentation. The documentation has been updated say that it's adviced to call SSL_read() until you get SSL_ERROR_ZERO_RETURN. Kurt From kurt at roeckx.be Sun Aug 12 19:05:19 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 12 Aug 2018 21:05:19 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: <20180812184935.GA11729@roeckx.be> References: <20180812184935.GA11729@roeckx.be> Message-ID: <20180812190519.GA13542@roeckx.be> On Sun, Aug 12, 2018 at 08:49:35PM +0200, Kurt Roeckx wrote: > In -pre8 we even have tests covering this behaviour, and the > manpages have been update to say that it's possible. See > https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html I think this was actually commited after pre8. Kurt From openssl-users at dukhovni.org Sun Aug 12 19:59:39 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 12 Aug 2018 15:59:39 -0400 Subject: [openssl-users] Shutdown details In-Reply-To: <20180812184935.GA11729@roeckx.be> References: <20180812184935.GA11729@roeckx.be> Message-ID: <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> > On Aug 12, 2018, at 2:49 PM, Kurt Roeckx wrote: > > TLS 1.3 makes it explicit that after you've send a close_notify, > the peer is still allowed to send data, so you can still read > data. It only closes the connection in one direction. Which is a change from previously required behaviour: https://tools.ietf.org/html/rfc8446#section-6.1 Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation. > As far as I know, OpenSSL has always supported this, even when the > RFC said that the other side needs to send the close_notify back > on receiving it. We might want to double-check that, I would have expected RFC-compliance here... Matt Caswell should know the definitive answer... -- Viktor. From alexhultman at gmail.com Sun Aug 12 19:59:41 2018 From: alexhultman at gmail.com (Alex H) Date: Sun, 12 Aug 2018 21:59:41 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: <20180812190519.GA13542@roeckx.be> References: <20180812184935.GA11729@roeckx.be> <20180812190519.GA13542@roeckx.be> Message-ID: Oh wow! That's perfect! Now the docs are very clear on this and essentially SSL _does_ support half-closed sockets. Thanks for clarifying this, TLS 1.3 seems like a big step forward. Den s?n 12 aug. 2018 kl 21:05 skrev Kurt Roeckx : > On Sun, Aug 12, 2018 at 08:49:35PM +0200, Kurt Roeckx wrote: > > In -pre8 we even have tests covering this behaviour, and the > > manpages have been update to say that it's possible. See > > https://www.openssl.org/docs/manmaster/man3/SSL_shutdown.html > > I think this was actually commited after pre8. > > > Kurt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgnet.dev at gmail.com Sun Aug 12 20:01:19 2018 From: pgnet.dev at gmail.com (PGNet Dev) Date: Sun, 12 Aug 2018 13:01:19 -0700 Subject: [openssl-users] TLS 1.3 and the release In-Reply-To: <14581.1534097568@localhost> References: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> <14581.1534097568@localhost> Message-ID: > I'm just dealing with trying to get openssl 1.1.0 to get installed on Ubuntu > bionic. Yes, there is a package, but all the other packages depend upon > 1.0.x.... and many things are linking against 1.0.x rather than 1.1, when > both are installed... I don't know why they build stuff against 1.0.x > rather than 1.1.0: I think it's a packaging oops. In the "I'm guessing this is NOT news to anyone HERE" category .... Even the packages that DO 'build against' 1.1.0 frequently do so by banking on deprecated symbols made possible by lazy (imo) api-compat usage. Packagers are frequently NOT cleaning up their openssl version-check logic, and cleaning out old-/deprecated- symbols. In my experience, most seem not to be interested, either; instead, the response mantra to entreaties about clean/modern "--api=1.1.0" compatibility is "that's not what the distros provide; just use that". From openssl-users at dukhovni.org Sun Aug 12 20:45:17 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 12 Aug 2018 16:45:17 -0400 Subject: [openssl-users] Shutdown details In-Reply-To: <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> References: <20180812184935.GA11729@roeckx.be> <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> Message-ID: <302CBD2F-16FD-4470-A015-EE73B1CE54DC@dukhovni.org> > On Aug 12, 2018, at 3:59 PM, Viktor Dukhovni wrote: > >> As far as I know, OpenSSL has always supported this, even when the >> RFC said that the other side needs to send the close_notify back >> on receiving it. > > We might want to double-check that, I would have expected RFC-compliance > here... Matt Caswell should know the definitive answer... It would also be good to know how the behaviour in master (pre8) differs (if at all) from 1.1.0 and/or 1.0.2. -- Viktor. From mcr at sandelman.ca Mon Aug 13 02:11:00 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Sun, 12 Aug 2018 22:11:00 -0400 Subject: [openssl-users] TLS 1.3 and the release In-Reply-To: References: <641FEB77-064E-4A49-A30B-41EDF127999F@akamai.com> <14581.1534097568@localhost> Message-ID: <22903.1534126260@localhost> PGNet Dev wrote: >> I'm just dealing with trying to get openssl 1.1.0 to get installed on Ubuntu >> bionic. Yes, there is a package, but all the other packages depend upon >> 1.0.x.... and many things are linking against 1.0.x rather than 1.1, when >> both are installed... I don't know why they build stuff against 1.0.x >> rather than 1.1.0: I think it's a packaging oops. > In the "I'm guessing this is NOT news to anyone HERE" category .... No kidding. If we want to push making TLS available 1.3, then we need to do some remedial work where. > Even the packages that DO 'build against' 1.1.0 frequently do so by banking > on deprecated symbols made possible by lazy (imo) api-compat usage. I found that libssl-dev was not upgraded from 1.0.0 version to 1.1.0 version when I did the dist-upgrade. Once I flushed that, I could then rebuild things like ruby (and it's openssl module) against 1.1.0 correctly, and *THEN* re-install libssl1.0 to make openssh happy. > Packagers are frequently NOT cleaning up their openssl version-check logic, > and cleaning out old-/deprecated- symbols. In my experience, most seem not > to be interested, either; instead, the response mantra to entreaties about > clean/modern "--api=1.1.0" compatibility is "that's not what the distros > provide; just use that". +1. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From tshort at akamai.com Mon Aug 13 03:31:47 2018 From: tshort at akamai.com (Short, Todd) Date: Mon, 13 Aug 2018 03:31:47 +0000 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: <11f43cf9-b343-9d48-e854-dd9577eaa3a6@blastwave.org> References: <20180808123950.GA92017@doctor.nl2k.ab.ca> <20180808201531.GA87719@doctor.nl2k.ab.ca> <1D47E3BA-2DB2-4EA9-92E8-E965003F7BBF@akamai.com> <11f43cf9-b343-9d48-e854-dd9577eaa3a6@blastwave.org> Message-ID: <98F6FD5F-7136-4312-8B61-6CCB6E796556@akamai.com> That site can?t be reached? (at least by me, unless it requires TLSv1.3?) -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." From: Dennis Clarke Reply-To: "openssl-users at openssl.org" Date: Friday, August 10, 2018 at 11:40 PM To: "openssl-users at openssl.org" Subject: Re: [openssl-users] About 1.0.2p version release !! On 08/10/2018 08:27 PM, Short, Todd via openssl-users wrote: RFC 8446 (TLS 1.3) was just published about ~30 minutes ago. Wonderful ! Todd are you okay[1] with your name being here : https://www.tls13.net/ Given that your name is in the maillist I figured .. sure, most likely .. but it is best to ask. Dennis -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Aug 13 08:07:36 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Aug 2018 09:07:36 +0100 Subject: [openssl-users] EDDSA key format In-Reply-To: References: Message-ID: <44e09f82-0a01-4054-7210-7eeba5cbaa25@openssl.org> On 10/08/18 23:43, Felipe Gasper wrote: > Hi all, > > Do EDDSA keys serialize to any format other than SPKI (public) and PKCS8 (private)? > > I ask because RSA and ECC both have ?native? formats as well as SPKI and PKCS8. > > Thanks! > No, there are no "native" formats for EdDSA. The native formats should be considered "legacy". Matt From matt at openssl.org Mon Aug 13 08:15:24 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Aug 2018 09:15:24 +0100 Subject: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken? In-Reply-To: <15661103.eW4U5Sr9IO@blindfold> References: <15661103.eW4U5Sr9IO@blindfold> Message-ID: Please could you raise this as a github issue? I'll try and take a look at it (although it may be a while since my current focus is on the 1.1.1 release). Matt On 11/08/18 16:22, Richard Weinberger wrote: > Hi! > > I have a hard time figuring how to write a DTLS UDP server that supports multiple > clients. My dummy single user server works fine. > > To support multiple clients I tried two approaches: > 1. singled threaded async IO, preferred since I have to deal with many clients > 2. multi threaded, one thread per client > > Both approaches seem to be doomed for the very same reason, namely that > DTLSv1_listen() does peek into the kernel queue and does not consume > the client hello from the UDP socket. > > Both loop around DTLSv1_listen() and as soon the function returns > 0 a new > socket for the client is created using bind/connect and the client address > as returned by DTLSv1_listen(). > > This client socket is then passed to a new thread or feed into the event loop. > In both cases the client hello is still in the queue of the server socket > and the program will over and over create new client sockets. > > After searching the web for examples I've found this thread[0], where the approaches > I tried are advertised. > In [1] the demo server at [3] is suggested as good example. > > dtls_udp_echo.c from [3] does exactly what I did in my 2nd approach, and it fails in > the same way. > As soon one client connects, it creates over and over new sockets until it dies due > to too many open files. > > After digging a bit into the source it looks to me like since commit [3], > DTLSv1_listen() assumes that you re-use the same socket for the new client. > Which makes supporting multiple clients impossible. > > Given that I'm not an OpenSSL DTLS expert I still hope I miss something. > Can you please help me to figure what the correct approach for multiple clients is? > > Thanks, > //richard > > P.s: I'm on Linux, OpenSSL 1.1.0h, but tried as OpenSSL git as of today. > > [0] https://mta.openssl.org/pipermail/openssl-users/2018-April/007861.html > [1] https://mta.openssl.org/pipermail/openssl-users/2018-April/007864.html > [2] https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c > [3] https://github.com/openssl/openssl/commit/e3d0dae7cf8363ca462ac425b72c7bb31c3b4b7a > From matt at openssl.org Mon Aug 13 12:08:12 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Aug 2018 13:08:12 +0100 Subject: [openssl-users] Shutdown details In-Reply-To: <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> References: <20180812184935.GA11729@roeckx.be> <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> Message-ID: On 12/08/18 20:59, Viktor Dukhovni wrote: > > >> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx wrote: >> >> TLS 1.3 makes it explicit that after you've send a close_notify, >> the peer is still allowed to send data, so you can still read >> data. It only closes the connection in one direction. > > Which is a change from previously required behaviour: > > https://tools.ietf.org/html/rfc8446#section-6.1 > > Each party MUST send a "close_notify" alert before closing its write > side of the connection, unless it has already sent some error alert. > This does not have any effect on its read side of the connection. > Note that this is a change from versions of TLS prior to TLS 1.3 in > which implementations were required to react to a "close_notify" by > discarding pending writes and sending an immediate "close_notify" > alert of their own. That previous requirement could cause truncation > in the read side. Both parties need not wait to receive a > "close_notify" alert before closing their read side of the > connection, though doing so would introduce the possibility of > truncation. > >> As far as I know, OpenSSL has always supported this, even when the >> RFC said that the other side needs to send the close_notify back >> on receiving it. > > We might want to double-check that, I would have expected RFC-compliance > here... Matt Caswell should know the definitive answer... > We didn't make any changes to enable that for TLSv1.3. The library already supported it - although perhaps the documentation wasn't so clear (which should hopefully be fixed now). Matt From hkario at redhat.com Mon Aug 13 14:18:52 2018 From: hkario at redhat.com (Hubert Kario) Date: Mon, 13 Aug 2018 16:18:52 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> Message-ID: <1662627.9JFfsJWyzN@pintsize.usersys.redhat.com> On Thursday, 9 August 2018 22:01:25 CEST Viktor Dukhovni wrote: > > On Aug 9, 2018, at 3:21 PM, Stephane van Hardeveld > > wrote: > > > > The certificate is signed with PSS. However, I try to indicate that the > > public key enclosed IN the certificate should be used with the OAEP > > padding > > mode while decrypting a separate message > > Keys in X.509 certiificates are mostly used for signing (e.g. TLS with > DHE or ECDHE key agreement). But I guess you could mint an encryption-only > certificate that is not useful for signing, and use it exclusively for > key wrapping. I don't know whether marking the key as an RSA-OAEP key > would then have the effect of restricting its usage by various libraries > to OAEP. it would, they would barf up just like they are barfing up while noticing rsa- pss OID in SPKI > More typically (e.g. IN CMS), the fact that OAEP was used to encrypt > the message is part of the message metadata, and so decryption will > automatically use OAEP when it is was explicitly selected at the time > the message was created. Thus OAEP is baked into the message, rather > than the certificate. the point is to have a certificate that can not be used for Bleichenbacher attacks, and for it it needs to be baked into certificate -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From KHenderson at verisign.com Mon Aug 13 17:00:38 2018 From: KHenderson at verisign.com (Henderson, Karl) Date: Mon, 13 Aug 2018 17:00:38 +0000 Subject: [openssl-users] Possible bug in 1.1.1-pre8 with NSTs and PSK in initial ClientHello handshake Message-ID: <4024C641-8D1A-43A5-BBCE-63AEAD09D066@verisign.com> According to RFC8446, Section C.4 ?Servers SHOULD issue new tickets with every connection?. Yet, in file ssl/statem/extensions_srvr.c, method tls_parse_ctos_psk, s->ext.ticket_expected = 0, preventing the NST from being sent. This appears to be a bug ? or am I missing something? Thanks, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Aug 13 17:23:27 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Aug 2018 13:23:27 -0400 Subject: [openssl-users] Possible bug in 1.1.1-pre8 with NSTs and PSK in initial ClientHello handshake In-Reply-To: <4024C641-8D1A-43A5-BBCE-63AEAD09D066@verisign.com> References: <4024C641-8D1A-43A5-BBCE-63AEAD09D066@verisign.com> Message-ID: > On Aug 13, 2018, at 1:00 PM, Henderson, Karl via openssl-users wrote: > > According to RFC8446, Section C.4 ?Servers SHOULD issue new tickets with every connection?. > > Yet, in file ssl/statem/extensions_srvr.c, method tls_parse_ctos_psk, s->ext.ticket_expected = 0, preventing the NST from being sent. > > This appears to be a bug ? or am I missing something? Have you observed behaviour different from the below documentation? NAME SSL_set_num_tickets, SSL_get_num_tickets, SSL_CTX_set_num_tickets, SSL_CTX_get_num_tickets - control the number of TLSv1.3 session tickets that are issued SYNOPSIS #include int SSL_set_num_tickets(SSL *s, size_t num_tickets); size_t SSL_get_num_tickets(SSL *s); int SSL_CTX_set_num_tickets(SSL_CTX *ctx, size_t num_tickets); size_t SSL_CTX_get_num_tickets(SSL_CTX *ctx); DESCRIPTION SSL_CTX_set_num_tickets() and SSL_set_num_tickets() can be called for a server application and set the number of session tickets that will be sent to the client after a full handshake. Set the desired value (which could be 0) in the num_tickets argument. Typically these functions should be called before the start of the handshake. The default number of tickets is 2; the default number of tickets sent following a resumption handshake is 1 but this cannot be changed using these functions. The number of tickets following a resumption handshake can be reduced to 0 using custom session ticket callbacks (see SSL_CTX_set_session_ticket_cb(3)). -- Viktor. From openssl at jordan.maileater.net Mon Aug 13 18:13:05 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 13 Aug 2018 11:13:05 -0700 Subject: [openssl-users] Shutdown details In-Reply-To: <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> References: <20180812184935.GA11729@roeckx.be> <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> Message-ID: <01c9c678-2693-e15b-d9a0-285e498d5b3d@jordan.maileater.net> On 8/12/2018 12:59 PM, Viktor Dukhovni wrote: > Which is a change from previously required behaviour: > > https://tools.ietf.org/html/rfc8446#section-6.1 > > Each party MUST send a "close_notify" alert before closing its write > side of the connection, unless it has already sent some error alert. > This does not have any effect on its read side of the connection. > Note that this is a change from versions of TLS prior to TLS 1.3 in > which implementations were required to react to a "close_notify" by > discarding pending writes and sending an immediate "close_notify" > alert of their own. That previous requirement could cause truncation > in the read side. Both parties need not wait to receive a > "close_notify" alert before closing their read side of the > connection, though doing so would introduce the possibility of > truncation. I'm curious:? how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response? -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Aug 13 18:25:56 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 13 Aug 2018 14:25:56 -0400 Subject: [openssl-users] Shutdown details In-Reply-To: <01c9c678-2693-e15b-d9a0-285e498d5b3d@jordan.maileater.net> References: <20180812184935.GA11729@roeckx.be> <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> <01c9c678-2693-e15b-d9a0-285e498d5b3d@jordan.maileater.net> Message-ID: > On Aug 13, 2018, at 2:13 PM, Jordan Brown wrote: > > I'm curious: how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response? This is no longer OpenSSL-specific. Best to wind down this thread. HTTP has a "Content-Length:" header or alternatively supports Chunked transfers. -- Viktor. From alexhultman at gmail.com Mon Aug 13 19:08:21 2018 From: alexhultman at gmail.com (Alex H) Date: Mon, 13 Aug 2018 21:08:21 +0200 Subject: [openssl-users] Shutdown details In-Reply-To: References: <20180812184935.GA11729@roeckx.be> <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> <01c9c678-2693-e15b-d9a0-285e498d5b3d@jordan.maileater.net> Message-ID: I don't mind upwinding it. These different reactions and input only help me design my things better. Very pleased with the discussion so far. Den m?n 13 aug. 2018 20:26Viktor Dukhovni skrev: > > > > On Aug 13, 2018, at 2:13 PM, Jordan Brown > wrote: > > > > I'm curious: how did this ever work for HTTPS, where for a POST request > you have to see the end of the request body before you can (in general) > send the response? > > This is no longer OpenSSL-specific. Best to wind down this thread. > HTTP has a "Content-Length:" header or alternatively supports Chunked > transfers. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon Aug 13 19:55:54 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 13 Aug 2018 19:55:54 +0000 Subject: [openssl-users] Shutdown details In-Reply-To: References: <20180812184935.GA11729@roeckx.be> <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> <01c9c678-2693-e15b-d9a0-285e498d5b3d@jordan.maileater.net> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Viktor Dukhovni > > HTTP has a "Content-Length:" header or alternatively supports Chunked > transfers. For HTTP/1.1, RFC 2616 also allows the message body length to be determined by the use of the self-delimiting content-type such as multipart/byteranges. HTTP/1.0 permitted this for any self-delimiting content-type, but I don't know that I've ever seen an HTTP/1.0 implementation do it. (And messages which are not allowed to have a body, such as GET and HEAD, don't need to delimit the body, since there isn't one.) Also relevant to Jordan's question: - Nothing says the client has to do a half-close after sending the request. In fact, when HTTP/1.1 made persistent conversations the default, user agents mostly switched to keeping the conversation open after a request, until the server closed it or some idle timer expired. - And, in fact, RFC 2616 implicitly *forbids* the client from using half-close to indicate the end of the response. The text oddly suggests the authors were unaware of half-close, though it's possible they simply wished to keep the same behavior if the transport didn't support half-close (as, indeed TLSv1.2 does not, if the specification is followed to the letter). At any rate, RFC 2616 4.4 #5 says: " Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response." That's clearly wrong, for transports such as TCP that support half-close; but it handily eliminates any problem of a UA trying to delimit a request message-body with half-close when running over TLS. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl at jordan.maileater.net Mon Aug 13 20:53:23 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 13 Aug 2018 13:53:23 -0700 Subject: [openssl-users] Shutdown details In-Reply-To: References: <20180812184935.GA11729@roeckx.be> <4EFEAC9A-E275-4F51-BF46-EFCF84AE98BA@dukhovni.org> <01c9c678-2693-e15b-d9a0-285e498d5b3d@jordan.maileater.net> Message-ID: <734a0d42-f24d-4932-e3d6-ed6c3bd52964@jordan.maileater.net> On 8/13/2018 11:25 AM, Viktor Dukhovni wrote: >> On Aug 13, 2018, at 2:13 PM, Jordan Brown wrote: >> >> I'm curious: how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response? > This is no longer OpenSSL-specific. Best to wind down this thread. > HTTP has a "Content-Length:" header or alternatively supports Chunked > transfers. You're right that it's not OpenSSL-specific, but the general topic of "how do you design protocols atop TLS" and "how do you take a TCP protocol and put it on top of TLS" seem relevant. Huh.? Looking closely, I see that HTTP requires header-based framing information when the request has a body - either Content-Length or Transfer-Encoding.? And here I thought I had a pretty decent understanding of basic HTTP.? Maybe I've just never hand-crafted a POST request.? I learn something new every day. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at bosa.fgov.be Tue Aug 14 08:06:51 2018 From: wouter.verhelst at bosa.fgov.be (Wouter Verhelst) Date: Tue, 14 Aug 2018 10:06:51 +0200 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: <98F6FD5F-7136-4312-8B61-6CCB6E796556@akamai.com> References: <20180808123950.GA92017@doctor.nl2k.ab.ca> <20180808201531.GA87719@doctor.nl2k.ab.ca> <1D47E3BA-2DB2-4EA9-92E8-E965003F7BBF@akamai.com> <11f43cf9-b343-9d48-e854-dd9577eaa3a6@blastwave.org> <98F6FD5F-7136-4312-8B61-6CCB6E796556@akamai.com> Message-ID: <4f25ddf3-b7ce-79b6-8d02-42a7112b2e41@bosa.fgov.be> It does (and that's the whole point of it) On 13-08-18 05:31, Short, Todd via openssl-users wrote: > > That site can?t be reached? (at least by me, unless it requires TLSv1.3?) > > ? > > -- > > -Todd Short > > // tshort at akamai.com > > // "One if by land, two if by sea, three if by the Internet." > > ? > > ? > > *From: *Dennis Clarke > *Reply-To: *"openssl-users at openssl.org" > *Date: *Friday, August 10, 2018 at 11:40 PM > *To: *"openssl-users at openssl.org" > *Subject: *Re: [openssl-users] About 1.0.2p version release !! > > ? > > On 08/10/2018 08:27 PM, Short, Todd via openssl-users wrote: > > RFC 8446 (TLS 1.3) was just published about ~30 minutes ago. > > ? > > Wonderful ! > > ? > > Todd are you okay[1] with your name being here : > > ? > > ???????????????? https://www.tls13.net/ > > ? > > ? > > Given that your name is in the maillist I figured .. sure, most likely > > ??.. but it is best to ask. > > ? > > ? > > Dennis > > ? > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > ? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Tue Aug 14 13:23:48 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 14 Aug 2018 13:23:48 +0000 Subject: [openssl-users] OpenSSL version 1.0.2p published Message-ID: <20180814132348.GA566@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.0.2p 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.0.2p 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.0.2-notes.html OpenSSL 1.0.2p 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.0.2p.tar.gz Size: 5338192 SHA1 checksum: f34b5322e92415755c7d58bf5d0d5cf37666382c SHA256 checksum: 50a98e07b1a89eb8f6a99477f262df71c6fa7bef77df4dc83025a2845c827d00 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2p.tar.gz openssl sha256 openssl-1.0.2p.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlty0pMACgkQ2cTSbQ5g RJGQoQf/TjfR+u6Hx2jdABRi6Vyi3T+VlGbHh8xyCP4l5c+JCqPMfxlKz/PF0Cbb 6KwIlc/2dUZZtCQOSITESxmI+xuuPWrwkSKilYetdqxe2ULWtCtDYDru/BgLASn7 M477ANTznqYoKC69vgbbiC0zYS1SdTbdw+agq1Ps+bLHk2GcbiVqRMMzTgvUqnD9 JdmTtAI4mVKJbiLejXz9c4I2Rii9MYTS1QKCpSdFg9irpNjRqLsieEwEoJ6m5eka rVkS567eT4IF1gXLYZeC03FWABUY0PcY9ZO2PhtfuyCKa0Y3dhlIkP8btMAmQAUQ JiIgeN2523E4DEWy4aAnOgsFqagvHQ== =aHv+ -----END PGP SIGNATURE----- From openssl at openssl.org Tue Aug 14 13:24:18 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 14 Aug 2018 13:24:18 +0000 Subject: [openssl-users] OpenSSL version 1.1.0i published Message-ID: <20180814132418.GA773@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.0i 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.0i 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.0i 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.0i.tar.gz Size: 5453234 SHA1 checksum: 6713f8b083e4c0b0e70fd090bf714169baf3717c SHA256 checksum: ebbfc844a8c8cc0ea5dc10b86c9ce97f401837f3fa08c17b2cdadc118253cf99 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0i.tar.gz openssl sha256 openssl-1.1.0i.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAltyztkACgkQ2cTSbQ5g RJE10gf6At9Ash5MVfgFwq03wqB0LGraQzSSKqAoraAZEgs2rTYGIaWY0HDTmeKf Ul35obSd5fsJ4ZyaIuL6zdFadlf0HkyYCcuZvl/GcPRB3BjiWrLcIyqJzL+HR3vc p6rxXAYAM1RV/u4+6OJ6LCh3UEB68yBL1mF1Gj2lwQNKxpIZsq+RxLD9Q9SZirzU eVgCiAeMfGY1FcCFuKlHxdowxE7IEveq56aRHFY2OLXS2NXp/KL0lfzeK0JSkCv9 0O4MLuNJoTNdIuYvElyiFWdpSauhh7Fx3wR2sv+3Z7Chm0XdKYDgiFEaPkCc+RYN nGk8eAsGEqP7eefHmMGXYVsA72PtgA== =Cpov -----END PGP SIGNATURE----- From artlemuel at gmail.com Tue Aug 14 14:22:05 2018 From: artlemuel at gmail.com (Jerry L) Date: Tue, 14 Aug 2018 10:22:05 -0400 Subject: [openssl-users] Compile Failure 1.0.2p AIX 7.1 using GCC Message-ID: This error message was transcribed from an air-gap network and not copied. I believe the error message has been correctly transcribed. This is the error we are getting when attempting to compile 1.0.2p for AIX 7.1 using GCC 4.3.5 making all in crypto..... /usr/bin/perl ../util/mkbuildinf.pl "gcc -I . -I.. -I../include -DZLIB -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCH_H -O -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -I /usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM "aix-gcc" >build.h gcc -I. -I.. -I../include -DZLIB -DOPENSSL_THREADS -pthread -DDSO_DLFCN -DHAVE_DLFCN_H -O -DB_ENDIAN -OPENSSL_BN_AMS_MONT -I/usr/local/ssl/fips-2.0/include -DSHA1_AMS -DSHA256_ASM -DSHA512_DSM -DAES_ASM -DVPAES_ASM -c cryptlib.c In file included from ../e_os.h:468, from cryptlib.h:65, from cryptlib.c:117: /usr/include/unistd.h:1062: error: expected ')' before '[' token /usr/include/unistd.h:1063: error expected declaration specifiers or '...' before 'rid_t' make: The error code from the last command is 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From shinelight at shininglightpro.com Tue Aug 14 14:49:13 2018 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Tue, 14 Aug 2018 07:49:13 -0700 Subject: [openssl-users] OpenSSL version 1.1.0i published In-Reply-To: <20180814132418.GA773@openssl.org> References: <20180814132418.GA773@openssl.org> Message-ID: <238ed6d2-7239-8732-6338-586855107c85@shininglightpro.com> I notice the release distribution for 1.1.0i includes a preconfigured makefile whereas 1.1.0h and earlier do not. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From jb-openssl at wisemo.com Tue Aug 14 18:01:36 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 14 Aug 2018 20:01:36 +0200 Subject: [openssl-users] The new BN_num_bits_word in 1.0.2o triggers bug in MS C 14.00.60131 for ARM In-Reply-To: <20180809212313.GA6279@roeckx.be> References: <20180809212313.GA6279@roeckx.be> Message-ID: On 09/08/2018 23:23, Kurt Roeckx wrote: > On Mon, Aug 06, 2018 at 04:30:54PM +0200, Jakob Bohm wrote: >> The patch below works around this, porting this to OpenSSL 1.1.x >> is left as an exercise for the reader: > Can you please open a pull request on github for that? > > > Kurt > This may be some extra work due to the additional rules and procedures for formal github contributions. I sent the report earlier than my larger patch collection as it fixed a very recently introduced issue. Could you at least treat it as a bug report until I can get the procedural stuff ready. P.S. Are you considering moving to a neutral hosting solution now that Github has been purchased by a major software publisher? 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 dclarke at blastwave.org Tue Aug 14 19:29:10 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 14 Aug 2018 15:29:10 -0400 Subject: [openssl-users] About 1.0.2p version release !! In-Reply-To: <4f25ddf3-b7ce-79b6-8d02-42a7112b2e41@bosa.fgov.be> References: <20180808123950.GA92017@doctor.nl2k.ab.ca> <20180808201531.GA87719@doctor.nl2k.ab.ca> <1D47E3BA-2DB2-4EA9-92E8-E965003F7BBF@akamai.com> <11f43cf9-b343-9d48-e854-dd9577eaa3a6@blastwave.org> <98F6FD5F-7136-4312-8B61-6CCB6E796556@akamai.com> <4f25ddf3-b7ce-79b6-8d02-42a7112b2e41@bosa.fgov.be> Message-ID: On 08/14/2018 04:06 AM, Wouter Verhelst wrote: > It does (and that's the whole point of it) > > > On 13-08-18 05:31, Short, Todd via openssl-users wrote: >> >> That site can?t be reached? (at least by me, unless it requires TLSv1.3?) >> >> -- >> >> -Todd Short >> >> // tshort at akamai.com >> >> // "One if by land, two if by sea, three if by the Internet." >> It is definately TLS 1.3 only and there is a link to drag out all the various variables of the session. There is a Mozilla site also but https://tls13.crypto.mozilla.org/ really doesn't tell you anything. dc From dclarke at blastwave.org Tue Aug 14 19:45:51 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 14 Aug 2018 15:45:51 -0400 Subject: [openssl-users] the whole internet gets real small real fast on TLS 1.3 Message-ID: <489eff53-03da-a65f-dc7f-db363b6c3d45@blastwave.org> Seems google.com supports TLS 1.3 as well as very very few others. There is also https://beta.tls13.net/ running apache-trunk where that site is based on OpenSSL 1.1.1-pre8 and supports TLS 1.3 and a fallback to TLS 1.2 however I think browsers will *not* perform tls version fallback from TLS 1.3. Not sure. Firefox ( chrome? ) have a local config var called security.tls.version.max which can be set to 4 and there is also a local var security.tls.version.fallback-limit to fiddle with. If you set your browser to TLS 1.3 only with fallback disabled then the whole internet gets real small real fast. However google.com does work with TLS 1.3 and that is just recent. Dennis From stephane at codingwizard.nl Tue Aug 14 20:55:38 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Tue, 14 Aug 2018 22:55:38 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> Message-ID: <02ef01d43411$28263cf0$7872b6d0$@codingwizard.nl> > > > On Aug 9, 2018, at 3:21 PM, Stephane van Hardeveld > wrote: > > > > The certificate is signed with PSS. However, I try to indicate that the > > public key enclosed IN the certificate should be used with the OAEP > padding > > mode while decrypting a separate message > > Keys in X.509 certiificates are mostly used for signing (e.g. TLS with > DHE or ECDHE key agreement). But I guess you could mint an encryption- > only > certificate that is not useful for signing, and use it exclusively for > key wrapping. I don't know whether marking the key as an RSA-OAEP key > would then have the effect of restricting its usage by various libraries > to OAEP. In the case of OpenSSL such an SPKI would simply not work at > all. :-( If someone contributed a quality implementation of this key > type, it would probably be a good candidate for inclusion in libcrypto. > > More typically (e.g. IN CMS), the fact that OAEP was used to encrypt > the message is part of the message metadata, and so decryption will > automatically use OAEP when it is was explicitly selected at the time > the message was created. Thus OAEP is baked into the message, rather > than the certificate. > > OpenSSL supports "oaep" in cms(1), pkeyutl(1) and rsautl(1) which > can create RSA encrypted objects, but does not presently support > X.509 certificates with RFC4055/RFC5756 OAEP SPKI. > > https://tools.ietf.org/html/rfc4055#section-4.1 > https://tools.ietf.org/html/rfc5756#section-4 > If I would try this endeavour, what would be the best interface to set this? For creation, use the EVP_PKEY type with the EVP_PKEY_CTX, and set attributes there? Something like: res = X509_set_pubkey(cert, contentKey); EVP_DigestSignInit(ctx, &pkey_ctx, EVP_sha256(), NULL, contentKey); EVP_PKEY_encrypt_init(pkey_ctx); EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_OAEP_PADDING); EVP_PKEY_CTX_set_signature_md(pkey_ctx, EVP_sha256()); Etc? And support RSA_PKCS1_PSS_PADDING as well, to indicate the key in the certificate should only be used for verification purposes? Retrieval of these keys should then automatically get the ameth struct filled with the appropriate RSA encryption and verification functions, so the rsa_asn1_meths should be extended with a set for RSA_OAEP encryption and RSA_PSS verification? Or am I going at this completely wrong? Regards, Stephane From openssl-users at dukhovni.org Tue Aug 14 21:16:15 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 14 Aug 2018 17:16:15 -0400 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <02ef01d43411$28263cf0$7872b6d0$@codingwizard.nl> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> <02ef01d43411$28263cf0$7872b6d0$@codingwizard.nl> Message-ID: <300531C6-612E-4624-BD69-7ACFB4696217@dukhovni.org> > On Aug 14, 2018, at 4:55 PM, Stephane van Hardeveld wrote: > > If I would try this endeavour, what would be the best interface to set this? > For creation, use the EVP_PKEY type with the EVP_PKEY_CTX, and set > attributes there? You'll need a new EVP_PKEY type that is mostly like RSA, but specialized for OAEP. > Something like: > res = X509_set_pubkey(cert, contentKey); > EVP_DigestSignInit(ctx, &pkey_ctx, EVP_sha256(), NULL, contentKey); > EVP_PKEY_encrypt_init(pkey_ctx); > EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_OAEP_PADDING); > EVP_PKEY_CTX_set_signature_md(pkey_ctx, EVP_sha256()); Nothing in EVP_PKEY_CTX has any effect on the key. The data flow is in the other direction. Different key types lead to different EVP_PKEY_CTX objects that are used to process data with that key. -- Viktor. From kgoldman at us.ibm.com Wed Aug 15 14:24:17 2018 From: kgoldman at us.ibm.com (Kenneth Goldman) Date: Wed, 15 Aug 2018 10:24:17 -0400 Subject: [openssl-users] I failed to add a git pull request for openssl Message-ID: What is the process for adding a pull request to an openssl branch? I tried from the web site, selecting 102stable and clicking 'new pull request'. It uploaded but said "kgoldman wants to merge 4,027 commits into master from OpenSSL_1_0_2-stable". I wanted to push one patch to 102stable. The status says "closed", presumably because I did something wrong. However, it also says 'approved'. ~~~~~~~~~~~~~ openssl-dev seems to be closed now. I will post the patch to this list. Can a developer pick it up? -- Ken Goldman kgoldman at us.ibm.com 914-945-2415 (862-2415) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Aug 15 15:26:17 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 15 Aug 2018 15:26:17 +0000 Subject: [openssl-users] I failed to add a git pull request for openssl In-Reply-To: References: Message-ID: When you create your pull request, use the pull-down to select the right branch. By default it picks master, which is (as you?ve seen) not always right. You can go to your PR, ?re target it? and re-open it. From: "kgoldman at us.ibm.com" Reply-To: openssl-users Date: Wednesday, August 15, 2018 at 11:23 AM To: openssl-users Subject: [openssl-users] I failed to add a git pull request for openssl What is the process for adding a pull request to an openssl branch? I tried from the web site, selecting 102stable and clicking 'new pull request'. It uploaded but said "kgoldman wants to merge 4,027 commits into master from OpenSSL_1_0_2-stable". I wanted to push one patch to 102stable. The status says "closed", presumably because I did something wrong. However, it also says 'approved'. ~~~~~~~~~~~~~ openssl-dev seems to be closed now. I will post the patch to this list. Can a developer pick it up? -- Ken Goldman kgoldman at us.ibm.com 914-945-2415 (862-2415) -------------- next part -------------- An HTML attachment was scrubbed... URL: From philipp_subx at redfish-solutions.com Wed Aug 15 19:36:30 2018 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 15 Aug 2018 13:36:30 -0600 Subject: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken? In-Reply-To: <15661103.eW4U5Sr9IO@blindfold> References: <15661103.eW4U5Sr9IO@blindfold> Message-ID: > On Aug 11, 2018, at 9:22 AM, Richard Weinberger wrote: > > Hi! > > I have a hard time figuring how to write a DTLS UDP server that supports multiple > clients. My dummy single user server works fine. > > To support multiple clients I tried two approaches: > 1. singled threaded async IO, preferred since I have to deal with many clients > 2. multi threaded, one thread per client > > Both approaches seem to be doomed for the very same reason, namely that > DTLSv1_listen() does peek into the kernel queue and does not consume > the client hello from the UDP socket. > > Both loop around DTLSv1_listen() and as soon the function returns > 0 a new > socket for the client is created using bind/connect and the client address > as returned by DTLSv1_listen(). > > This client socket is then passed to a new thread or feed into the event loop. > In both cases the client hello is still in the queue of the server socket > and the program will over and over create new client sockets. > > After searching the web for examples I've found this thread[0], where the approaches > I tried are advertised. > In [1] the demo server at [3] is suggested as good example. > > dtls_udp_echo.c from [3] does exactly what I did in my 2nd approach, and it fails in > the same way. > As soon one client connects, it creates over and over new sockets until it dies due > to too many open files. > > After digging a bit into the source it looks to me like since commit [3], > DTLSv1_listen() assumes that you re-use the same socket for the new client. > Which makes supporting multiple clients impossible. > > Given that I'm not an OpenSSL DTLS expert I still hope I miss something. > Can you please help me to figure what the correct approach for multiple clients is? > > Thanks, > //richard Have you tried using Libevent? It supports SSL/TLS/DTLS connections. -Philip From richard at nod.at Wed Aug 15 20:09:11 2018 From: richard at nod.at (Richard Weinberger) Date: Wed, 15 Aug 2018 22:09:11 +0200 Subject: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken? In-Reply-To: References: <15661103.eW4U5Sr9IO@blindfold> Message-ID: <4841365.AjxZZsZuHB@blindfold> Philip, Am Mittwoch, 15. August 2018, 21:36:30 CEST schrieben Sie: > > > On Aug 11, 2018, at 9:22 AM, Richard Weinberger wrote: > > > > Hi! > > > > I have a hard time figuring how to write a DTLS UDP server that supports multiple > > clients. My dummy single user server works fine. > > > > To support multiple clients I tried two approaches: > > 1. singled threaded async IO, preferred since I have to deal with many clients > > 2. multi threaded, one thread per client > > > > Both approaches seem to be doomed for the very same reason, namely that > > DTLSv1_listen() does peek into the kernel queue and does not consume > > the client hello from the UDP socket. > > > > Both loop around DTLSv1_listen() and as soon the function returns > 0 a new > > socket for the client is created using bind/connect and the client address > > as returned by DTLSv1_listen(). > > > > This client socket is then passed to a new thread or feed into the event loop. > > In both cases the client hello is still in the queue of the server socket > > and the program will over and over create new client sockets. > > > > After searching the web for examples I've found this thread[0], where the approaches > > I tried are advertised. > > In [1] the demo server at [3] is suggested as good example. > > > > dtls_udp_echo.c from [3] does exactly what I did in my 2nd approach, and it fails in > > the same way. > > As soon one client connects, it creates over and over new sockets until it dies due > > to too many open files. > > > > After digging a bit into the source it looks to me like since commit [3], > > DTLSv1_listen() assumes that you re-use the same socket for the new client. > > Which makes supporting multiple clients impossible. > > > > Given that I'm not an OpenSSL DTLS expert I still hope I miss something. > > Can you please help me to figure what the correct approach for multiple clients is? > > > > Thanks, > > //richard > > > Have you tried using Libevent? It supports SSL/TLS/DTLS connections. Can you please explain? I fear I miss something. Libevent seems to be able to deal with OpenSSL BIO objects. But how is it supposed to help me with the DTLSv1_listen() issue? A quick grep on the Libevent sources does not show calls to DTLSv1_listen() and I don't think that it is open coding it. At least I hope so. The problem I see is not about event processing, it is about OpenSSL 1.1.x's re-write of DTLSv1_listen(). Thanks, //richard From philipp_subx at redfish-solutions.com Wed Aug 15 21:35:49 2018 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 15 Aug 2018 15:35:49 -0600 Subject: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken? In-Reply-To: <4841365.AjxZZsZuHB@blindfold> References: <15661103.eW4U5Sr9IO@blindfold> <4841365.AjxZZsZuHB@blindfold> Message-ID: > On Aug 15, 2018, at 2:09 PM, Richard Weinberger wrote: > > Philip, > > Am Mittwoch, 15. August 2018, 21:36:30 CEST schrieben Sie: >> >>> [snip] >> >> >> Have you tried using Libevent? It supports SSL/TLS/DTLS connections. > > Can you please explain? I fear I miss something. Have a look at: http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html you don?t need a dedicated thread per connection. See the section ?Bufferevents and SSL? You can create an SSL context and then bind a connection listener to it. If the library doesn?t specifically handle the case of DTLS (I know it handles SSL and TLS), then it shouldn?t be too hard to cobble something together and even get it upstreamed. -Philip > > Libevent seems to be able to deal with OpenSSL BIO objects. > But how is it supposed to help me with the DTLSv1_listen() issue? > > A quick grep on the Libevent sources does not show calls to DTLSv1_listen() > and I don't think that it is open coding it. At least I hope so. > > The problem I see is not about event processing, it is about OpenSSL 1.1.x's > re-write of DTLSv1_listen(). > > Thanks, > //richard > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From richard.weinberger at gmail.com Wed Aug 15 21:47:44 2018 From: richard.weinberger at gmail.com (Richard Weinberger) Date: Wed, 15 Aug 2018 23:47:44 +0200 Subject: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken? In-Reply-To: References: <15661103.eW4U5Sr9IO@blindfold> <4841365.AjxZZsZuHB@blindfold> Message-ID: Philip, On Wed, Aug 15, 2018 at 11:36 PM Philip Prindeville wrote: > Have a look at: > > http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html > > you don?t need a dedicated thread per connection. I know. I have already full blown single threaded event loop that works fine with OpenSSL 1.0.x. > See the section ?Bufferevents and SSL? > > You can create an SSL context and then bind a connection listener to it. > > If the library doesn?t specifically handle the case of DTLS (I know it handles SSL and TLS), then it shouldn?t be too hard to cobble something together and even get it upstreamed. Well, it still seems to miss the fact that DTLSv1_listen() regressed in 1.1.x. I really don't see how layering libevent into my application should help here. -- Thanks, //richard From mcr at sandelman.ca Thu Aug 16 16:52:14 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 16 Aug 2018 12:52:14 -0400 Subject: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken? In-Reply-To: References: <15661103.eW4U5Sr9IO@blindfold> <4841365.AjxZZsZuHB@blindfold> Message-ID: <6962.1534438334@localhost> Philip Prindeville wrote: > You can create an SSL context and then bind a connection listener to > it. > If the library doesn?t specifically handle the case of DTLS (I know it > handles SSL and TLS), then it shouldn?t be too hard to cobble something > together and even get it upstreamed. Philip, DTLS is not just TLS over UDP. There is more to it that that. we are trying to do EXACTLY this, and we can't because the behaviour of DTLSv1_listen() does not let a library do this. And we can't open code actually, because it (DTLSv1_listen) uses APIs internal to libssl. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From stephane at codingwizard.nl Thu Aug 16 22:30:17 2018 From: stephane at codingwizard.nl (Stephane van Hardeveld) Date: Fri, 17 Aug 2018 00:30:17 +0200 Subject: [openssl-users] rsaOAEP OID in X509 certificate In-Reply-To: <300531C6-612E-4624-BD69-7ACFB4696217@dukhovni.org> References: <013e01d42f31$0a495cb0$1edc1610$@codingwizard.nl> <006b01d43016$3e092ef0$ba1b8cd0$@codingwizard.nl> <4F01408A-8962-46BB-87F3-7CB8D0EED315@dukhovni.org> <02ef01d43411$28263cf0$7872b6d0$@codingwizard.nl> <300531C6-612E-4624-BD69-7ACFB4696217@dukhovni.org> Message-ID: <04b701d435b0$b5663e80$2032bb80$@codingwizard.nl> > > On Aug 14, 2018, at 4:55 PM, Stephane van Hardeveld > wrote: > > > > If I would try this endeavour, what would be the best interface to set this? > > For creation, use the EVP_PKEY type with the EVP_PKEY_CTX, and set > > attributes there? > > You'll need a new EVP_PKEY type that is mostly like RSA, but specialized > for OAEP. Ok, makes sense > > > Something like: > > res = X509_set_pubkey(cert, contentKey); > > EVP_DigestSignInit(ctx, &pkey_ctx, EVP_sha256(), NULL, contentKey); > > EVP_PKEY_encrypt_init(pkey_ctx); > > EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_OAEP_PADDING); > > EVP_PKEY_CTX_set_signature_md(pkey_ctx, EVP_sha256()); > > Nothing in EVP_PKEY_CTX has any effect on the key. The data flow > is in the other direction. Different key types lead to different > EVP_PKEY_CTX objects that are used to process data with that key. Thank you for clearing this up Regards, Stephane From angus at magsys.co.uk Fri Aug 17 12:47:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Fri, 17 Aug 2018 13:47 +0100 (BST) Subject: [openssl-users] [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: <20180817.135513.218041365083823947.levitte@openssl.org> Message-ID: > Personally, I see this as a showstopper re a release on Tuesday, > but I think it's on all of us to come to an agreement, that is > unless we actually do label and fix everything that needs fixing > 'til Monday evening (Euro time)... The planned Tuesday release was only another beta, albeit perhaps the last. So even if the final 1.1.1 release is delayed, it would still be very useful to have an RFC compliant version of TLSv1.3 in a beta sooner rather than later, for final testing against browsers and clients. And then perhaps another final beta if lots of other stuff is changed? Angus From quae at daurnimator.com Fri Aug 17 13:25:01 2018 From: quae at daurnimator.com (Daurnimator) Date: Fri, 17 Aug 2018 23:25:01 +1000 Subject: [openssl-users] SSL_CTX ignores many X509_STORE fields and uses own fields In-Reply-To: References: Message-ID: On 12 July 2018 at 18:49, Daurnimator wrote: > When looking into https://github.com/wahern/luaossl/issues/140 I was > surprised to learn that an SSL_CTX* (and SSL*) does not use many of > the X509_STORE members. > > e.g. a store has a X509_VERIFY_PARAMS field, however although an > SSL_CTX* has a related store, it ignores the store's params and uses > it's own. > > For a connection pooling implementation, I need to check that an > existing SSL connection is something that could be approved by a given > SSL_CTX*. > I was hoping this would be as simple as doing (error handling omitted > for brevity): > > X509_STORE_CTX_init(vfy_ctx, SSL_CTX_get0_store(ctx), > SSL_get_certificate(ssl), NULL); > X509_verify_cert(vfy_ctx); > > However it appears that I really need to do: > > X509_STORE_CTX_init(vfy_ctx, SSL_CTX_get0_store(ctx), > SSL_get_certificate(ssl), NULL); > X509_VERIFY_PARAM_inherit(X509_STORE_CTX_get0_param(vfy_ctx), > SSL_CTX_get0_param(ctx)); > // X509_STORE_CTX_set_verify_cb based on SSL_CTX_get_verify_callback(ctx) > // X509_STORE_CTX_set0_dane > // etc. etc. > X509_verify_cert(vfy_ctx); > > Is this complexity warranted? > Is there any plan to remove the redundant fields? > > Daurn. Has anyone had time to look into this? I filed the related https://github.com/openssl/openssl/issues/6709 From beldmit at gmail.com Fri Aug 17 15:14:46 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 17 Aug 2018 18:14:46 +0300 Subject: [openssl-users] Behaviour changed between 1.1.0 and 1.1.1 Message-ID: Hello, I use my engine providing gost algorithms ( https://github.com/gost-engine/engine). It seems not to have any relevant changes between 1.1.0 and current master, but the command OPENSSL_CONF=engine.conf openssl pkey -pubout -text -in tmp.pem works ok for 1.1.0 version and does not work for current master. For the file a.pem both versions provide similar output. engine.conf is minimal conf to load gost engine: ============= openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] gost = gost_section [gost_section] engine_id = gost dynamic_path = /path/to/libgost.so default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet =============== I've found out that behavior of the function EC_POINT_get_affine_coordinates_GFp has changed between versions 1.1.0 and current master. Also I found that pkey command ignores result of the calls to EVP_PKEY_print_public and EVP_PKEY_print_private. Could you please clarify whether it's a bug in my engine or something incompatible in openssl code? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a.pem Type: application/x-x509-ca-cert Size: 153 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tmp.pem Type: application/x-x509-ca-cert Size: 153 bytes Desc: not available URL: From nic.tuv at gmail.com Fri Aug 17 15:42:04 2018 From: nic.tuv at gmail.com (Nicola) Date: Fri, 17 Aug 2018 18:42:04 +0300 Subject: [openssl-users] Behaviour changed between 1.1.0 and 1.1.1 In-Reply-To: References: Message-ID: I can't reproduce the issue, using latest master for both gost and openssl: /tmpram/gost > export OPENSSL_ENGINES=/tmpram/gost/engine/bin /tmpram/gost > /tmpram/openssl-111-pre9-dev/bin/openssl pkey -engine gost -pubout -text -in tmp.pem engine "gost" set. Private key: 28A509558DB1969DB89A4CB517D8A759EAB79A6D09FEECDAE87B03BECA604B36 /tmpram/gost > /tmpram/openssl-111-pre9-dev/bin/openssl pkey -engine gost -pubout -text -in a.pem engine "gost" set. -----BEGIN PUBLIC KEY----- MGMwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEDQwAEQORQaJaqv4S10bz4 jw112dGlrtD+DyGR8TqkhmOvlJB46VUIbpBsEHs8nn0pXtzsIfEwgV8Oxo/QA0Ri Qu5j7SU= -----END PUBLIC KEY----- Private key: 46150327559001221F9F1F9A50CD9E6A0CD5F5D0ADEA6439C1DB5E9EBD994BF6 Public key: X:789094AF6386A43AF191210FFED0AEA5D1D9750D8FF8BCD1B584BFAA966850E4 Y:25ED63EE42624403D08FC60E5F8130F121ECDC5E297D9E3C7B106C906E0855E9 Parameter set: id-GostR3410-2001-CryptoPro-A-ParamSet On Fri, 17 Aug 2018 at 18:15, Dmitry Belyavsky wrote: > Hello, > > I use my engine providing gost algorithms ( > https://github.com/gost-engine/engine). It seems not to have any relevant > changes between 1.1.0 and current master, but the command > > OPENSSL_CONF=engine.conf openssl pkey -pubout -text -in tmp.pem > > works ok for 1.1.0 version and does not work for current master. > For the file a.pem both versions provide similar output. > > engine.conf is minimal conf to load gost engine: > ============= > openssl_conf = openssl_def > [openssl_def] > engines = engine_section > > [engine_section] > gost = gost_section > > [gost_section] > engine_id = gost > dynamic_path = /path/to/libgost.so > default_algorithms = ALL > CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet > =============== > > I've found out that behavior of the > function EC_POINT_get_affine_coordinates_GFp has changed between versions > 1.1.0 and current master. > > Also I found that pkey command ignores result of the calls > to EVP_PKEY_print_public and EVP_PKEY_print_private. > > Could you please clarify whether it's a bug in my engine or something > incompatible in openssl code? > > Thank you! > -- > SY, Dmitry Belyavsky > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eldiariomx at gmail.com Fri Aug 17 16:51:24 2018 From: eldiariomx at gmail.com (Eldiario Mexico) Date: Fri, 17 Aug 2018 11:51:24 -0500 Subject: [openssl-users] Implementing help Message-ID: Good Moorning I really need your support , i've been trying to implement Openssl, cuase I need verify certifcates althrough OCSP and utilize this ceriticates to sign a docoument. I'm developing on Visual Studio (Visual Basic) but, I can't found the .dll Files , i dont find the correct way to utlize Oppenssl to Sign Documents I'll be really thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Aug 17 17:18:32 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 17 Aug 2018 13:18:32 -0400 Subject: [openssl-users] SSL_CTX ignores many X509_STORE fields and uses own fields In-Reply-To: References: Message-ID: <20180817171832.GI28851@straasha.imrryr.org> On Fri, Aug 17, 2018 at 11:25:01PM +1000, Daurnimator wrote: > > When looking into https://github.com/wahern/luaossl/issues/140 I was > > surprised to learn that an SSL_CTX* (and SSL*) does not use many of > > the X509_STORE members. There are no plans to change the design. You can set the verification store associated with the SSL_CTX via: SSL_CTX_set0_verify_cert_store(3) or SSL_CTX_set1_verify_cert_store(3) do this early, before using the SSL_CTX to create SSL handles with SSL_new(). Configure the store properties as you see fit. -- Viktor. From beldmit at gmail.com Fri Aug 17 17:59:58 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 17 Aug 2018 20:59:58 +0300 Subject: [openssl-users] Behaviour changed between 1.1.0 and 1.1.1 In-Reply-To: References: Message-ID: Dear Nicola, You just reproduced it :) Output for the file a.pem contains Private key, Public key and Parameter set; the one for tmp.pem does not. On Fri, Aug 17, 2018 at 6:42 PM Nicola wrote: > I can't reproduce the issue, using latest master for both gost and openssl: > > /tmpram/gost > export OPENSSL_ENGINES=/tmpram/gost/engine/bin > /tmpram/gost > /tmpram/openssl-111-pre9-dev/bin/openssl pkey -engine gost > -pubout -text -in tmp.pem > engine "gost" set. > Private key: > 28A509558DB1969DB89A4CB517D8A759EAB79A6D09FEECDAE87B03BECA604B36 > /tmpram/gost > /tmpram/openssl-111-pre9-dev/bin/openssl pkey -engine gost > -pubout -text -in a.pem > engine "gost" set. > -----BEGIN PUBLIC KEY----- > MGMwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEDQwAEQORQaJaqv4S10bz4 > jw112dGlrtD+DyGR8TqkhmOvlJB46VUIbpBsEHs8nn0pXtzsIfEwgV8Oxo/QA0Ri > Qu5j7SU= > -----END PUBLIC KEY----- > Private key: > 46150327559001221F9F1F9A50CD9E6A0CD5F5D0ADEA6439C1DB5E9EBD994BF6 > Public key: > X:789094AF6386A43AF191210FFED0AEA5D1D9750D8FF8BCD1B584BFAA966850E4 > Y:25ED63EE42624403D08FC60E5F8130F121ECDC5E297D9E3C7B106C906E0855E9 > Parameter set: id-GostR3410-2001-CryptoPro-A-ParamSet > > > On Fri, 17 Aug 2018 at 18:15, Dmitry Belyavsky wrote: > >> Hello, >> >> I use my engine providing gost algorithms ( >> https://github.com/gost-engine/engine). It seems not to have any >> relevant changes between 1.1.0 and current master, but the command >> >> OPENSSL_CONF=engine.conf openssl pkey -pubout -text -in tmp.pem >> >> works ok for 1.1.0 version and does not work for current master. >> For the file a.pem both versions provide similar output. >> >> engine.conf is minimal conf to load gost engine: >> ============= >> openssl_conf = openssl_def >> [openssl_def] >> engines = engine_section >> >> [engine_section] >> gost = gost_section >> >> [gost_section] >> engine_id = gost >> dynamic_path = /path/to/libgost.so >> default_algorithms = ALL >> CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet >> =============== >> >> I've found out that behavior of the >> function EC_POINT_get_affine_coordinates_GFp has changed between versions >> 1.1.0 and current master. >> >> Also I found that pkey command ignores result of the calls >> to EVP_PKEY_print_public and EVP_PKEY_print_private. >> >> Could you please clarify whether it's a bug in my engine or something >> incompatible in openssl code? >> >> Thank you! >> -- >> SY, Dmitry Belyavsky >> -- >> 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 > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From sreeees at gmail.com Fri Aug 17 18:04:31 2018 From: sreeees at gmail.com (Sreekanth Sukumaran) Date: Fri, 17 Aug 2018 23:34:31 +0530 Subject: [openssl-users] Setting Signature algorithm for Client Hello in openssl.cnf Message-ID: Hi All, I am looking for an option in "openssl.cnf" file to control the signature algorithms supported by an OpenSSL based TLS client application which it lists in the "Client Hello" message and also the signature algorithm used for signing the Client "CertificateVerify" message sent to the server for proof of possession of the client private key Is there an option to set this in openssl.cnf file?. I searched the man pages, but did not see a corresponding option. What i got so far is ----------------------------------------------------- ssl_conf = ssl_sect [ssl_sect] client = client_secion [client_section] ClientSignatureAlgorithms=RSA+SHA256 ------------------------------------------------------- Is this supported in conf file? Can somebody help me with this? Thanks. -- Regards, Sreekanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Fri Aug 17 19:48:10 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 17 Aug 2018 19:48:10 +0000 Subject: [openssl-users] Implementing help In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Eldiario Mexico > Sent: Friday, August 17, 2018 12:51 > I really need your support , i've been trying to implement Openssl, > cuase I need verify certifcates althrough OCSP and utilize this > ceriticates to sign a docoument. > I'm developing on Visual Studio (Visual Basic) but, I can't found the > .dll Files , i dont find the correct way to utlize Oppenssl to Sign > Documents Correct use of OpenSSL is a specialist skill, to be perfectly frank. I don't recommend it for anyone who is not prepared to put serious effort into learning OpenSSL's design and API, and learning significantly about contemporary cryptography (including algorithms, protocols, standards, industry conventions, and so on) in the process. Also, your problem is not well-defined. There are many formats for cryptographically signing documents. Do you need CMS? XML Signature? A signature for a binary file, such as Authenticode or a Java JAR signature? An OpenPGP signature? What problem are you actually trying to solve? If you're developing for Visual BASIC, then presumably your application is Windows-only. I'd suggest using the Windows built-in cryptography support: the OS-provided certificate stores and CryptoAPI, directly or through some additional layer (such as the .NET Framework if you're actually using VB.NET). Those are generally higher-level APIs than what OpenSSL provides, and they're available through various Microsoft scripting languages, which would make it easier to experiment. However, you'd very likely do best to simply find some existing library or package that does what you need to do. Writing cryptographic applications without a cryptography background is likely to produce insecure systems. -- Michael Wojcik Distinguished Engineer, Micro Focus From nic.tuv at gmail.com Fri Aug 17 19:59:57 2018 From: nic.tuv at gmail.com (Nicola) Date: Fri, 17 Aug 2018 22:59:57 +0300 Subject: [openssl-users] Behaviour changed between 1.1.0 and 1.1.1 In-Reply-To: References: Message-ID: > > You just reproduced it :) > > Output for the file a.pem contains Private key, Public key and Parameter > set; the one for tmp.pem does not. > You are right, I was expecting some kind of error, and realized that there was something strange just after hitting the Send button, as usual! Anyway, I think I found the problem, with the invaluable help of Billy Brumley in the backstage! It's a bug in the current GFp_simple_ladder implementation that was not catched by existing regression testing. I'll open a proper PR to fix this as soon as we finish to test the alternative implementation. In the meantime you might open a proper issue in Github for this problem so that the bug will be properly tracked! Thanks for reporting this, Nicola Tuveri -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Aug 17 21:14:29 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sat, 18 Aug 2018 00:14:29 +0300 Subject: [openssl-users] Behaviour changed between 1.1.0 and 1.1.1 In-Reply-To: References: Message-ID: Dear Nicola, On Fri, Aug 17, 2018 at 11:00 PM Nicola wrote: > You just reproduced it :) >> >> Output for the file a.pem contains Private key, Public key and Parameter >> set; the one for tmp.pem does not. >> > > You are right, I was expecting some kind of error, and realized that there > was something strange just after hitting the Send button, as usual! > > Anyway, I think I found the problem, with the invaluable help of Billy > Brumley in the backstage! > > It's a bug in the current GFp_simple_ladder implementation that was not > catched by existing regression testing. > > I'll open a proper PR to fix this as soon as we finish to test the > alternative implementation. > Thank you very much! > > In the meantime you might open a proper issue in Github for this problem > so that the bug will be properly tracked! > https://github.com/openssl/openssl/issues/6999 -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Fri Aug 17 21:24:26 2018 From: nic.tuv at gmail.com (Nicola) Date: Sat, 18 Aug 2018 00:24:26 +0300 Subject: [openssl-users] Behaviour changed between 1.1.0 and 1.1.1 In-Reply-To: References: Message-ID: Just created the PR: https://github.com/openssl/openssl/pull/7000 Thanks again for reporting this! Nicola Tuveri On Sat, 18 Aug 2018 at 00:15, Dmitry Belyavsky wrote: > Dear Nicola, > On Fri, Aug 17, 2018 at 11:00 PM Nicola wrote: > >> You just reproduced it :) >>> >>> Output for the file a.pem contains Private key, Public key and Parameter >>> set; the one for tmp.pem does not. >>> >> >> You are right, I was expecting some kind of error, and realized that >> there was something strange just after hitting the Send button, as usual! >> >> Anyway, I think I found the problem, with the invaluable help of Billy >> Brumley in the backstage! >> >> It's a bug in the current GFp_simple_ladder implementation that was not >> catched by existing regression testing. >> >> I'll open a proper PR to fix this as soon as we finish to test the >> alternative implementation. >> > > Thank you very much! > > >> >> In the meantime you might open a proper issue in Github for this problem >> so that the bug will be properly tracked! >> > > https://github.com/openssl/openssl/issues/6999 > > -- > SY, Dmitry Belyavsky > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From quae at daurnimator.com Sat Aug 18 02:52:18 2018 From: quae at daurnimator.com (Daurnimator) Date: Sat, 18 Aug 2018 12:52:18 +1000 Subject: [openssl-users] SSL_CTX ignores many X509_STORE fields and uses own fields In-Reply-To: <20180817171832.GI28851@straasha.imrryr.org> References: <20180817171832.GI28851@straasha.imrryr.org> Message-ID: On 18 August 2018 at 03:18, Viktor Dukhovni wrote: > On Fri, Aug 17, 2018 at 11:25:01PM +1000, Daurnimator wrote: > >> > When looking into https://github.com/wahern/luaossl/issues/140 I was >> > surprised to learn that an SSL_CTX* (and SSL*) does not use many of >> > the X509_STORE members. > > There are no plans to change the design. You can set the verification > store associated with the SSL_CTX via: > > SSL_CTX_set0_verify_cert_store(3) > or > SSL_CTX_set1_verify_cert_store(3) > > do this early, before using the SSL_CTX to create SSL handles with > SSL_new(). Configure the store properties as you see fit. I understand the current design; but I'm left wondering why it has an additional store member when VERIFY_PARAMS has the field there already. The design would seem to be much cleaner if all criteria for verification are taken from a single object. From openssl-users at dukhovni.org Sat Aug 18 03:56:43 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 17 Aug 2018 23:56:43 -0400 Subject: [openssl-users] SSL_CTX ignores many X509_STORE fields and uses own fields In-Reply-To: References: <20180817171832.GI28851@straasha.imrryr.org> Message-ID: <028C57E2-8EFD-4368-8A0F-9CFB96D615C0@dukhovni.org> > On Aug 17, 2018, at 10:52 PM, Daurnimator wrote: > > I understand the current design; but I'm left wondering why it has an > additional store member when VERIFY_PARAMS has the field there > already. > The design would seem to be much cleaner if all criteria for > verification are taken from a single object. They are taken from a single object, the X509 store associated with the SSL_CTX, which is used to verify the peer per SSL_CTX_set_verify(). -- Viktor. From jisoza at gmail.com Sat Aug 18 17:48:21 2018 From: jisoza at gmail.com (Juan Isoza) Date: Sat, 18 Aug 2018 19:48:21 +0200 Subject: [openssl-users] [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: References: <20180817.135513.218041365083823947.levitte@openssl.org> Message-ID: What is the difference between draft 28 and rfc for tls 1.3 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Sat Aug 18 18:20:30 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 18 Aug 2018 20:20:30 +0200 Subject: [openssl-users] [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: References: <20180817.135513.218041365083823947.levitte@openssl.org> Message-ID: <20180818182029.GA30642@roeckx.be> On Sat, Aug 18, 2018 at 07:48:21PM +0200, Juan Isoza wrote: > What is the difference between draft 28 and rfc for tls 1.3 ? The drafts used a version that said which draft version it was. The RFC version has a different version. So the version that's send in ClientHello is different, and a draft version will not talk to an RFC version using the TLS 1.3 protocol. Kurt From anton at picapica.im Sun Aug 19 12:36:30 2018 From: anton at picapica.im (Anton) Date: Sun, 19 Aug 2018 14:36:30 +0200 Subject: [openssl-users] Anonymous DH (ADH) in real world applications Message-ID: <20180819123630.GA24202@picapica.im> Hello Does anyone know some examples of applications using ADH ciphersuites for TLS connections in production environment? I know it is vulnerable to MITM, but it still can be useful, for example if communicating devices do not store state data for authentication (unique certificate per instance), but protection from passive eavesdropping is desirable. Is it reasonable to expect having ADH support enabled in future releases of OpenSSL? Anton From kurt at roeckx.be Sun Aug 19 12:41:57 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 19 Aug 2018 14:41:57 +0200 Subject: [openssl-users] Anonymous DH (ADH) in real world applications In-Reply-To: <20180819123630.GA24202@picapica.im> References: <20180819123630.GA24202@picapica.im> Message-ID: <20180819124157.GA14549@roeckx.be> On Sun, Aug 19, 2018 at 02:36:30PM +0200, Anton wrote: > Hello > > Does anyone know some examples of applications using > ADH ciphersuites for TLS connections in production > environment? At least postfix can use it for SMTP. Kurt From ece8537 at upnet.gr Mon Aug 20 10:34:38 2018 From: ece8537 at upnet.gr (Konstantinos Schoinas) Date: Mon, 20 Aug 2018 13:34:38 +0300 Subject: [openssl-users] TLS-Session Message-ID: <7c10f6aa7a381a46eb9003cce596938b@upnet.gr> Hello, I have deployed 3 VMs in my host (linux) pc.1 ubuntu Desktop and 2 ubuntu Servers. I am using ovs-dpdk(openvswitch-dpdk) in order to create a bridge and make the VMs speak to each other. The test-?case is this: VM1 : using openssl as a client to connect to an apache2 server hosted in VM3 VM2 : Dpdk application working as a L2 Switch that does DPI(Deep packet inspection) in the packet and check if there is a server name indication with a specific forbidden SNI .If yes it block the TLS session by replying with a TLS fatal(2) alert packet with Description Unrecognized_name (112).According to RFC this shall block the TLS session. VM3:Just an apache2 Server When i test this i am connecting from VM1 with this command openssl s_client -connect www.example.com:443 -servername www.example.com (where "www.example.com" is the forbidden name of the dpdk application). So my dpdk application is responding with the correct TLS alert and it actually block the TLS session.I have seen the correct packet in wireshark as well.I am also putting a picture with this mail in order to see the process. The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS session.Also i am getting some retransmits of client hello in wireshark. So my question is if anyone can confirm that this is a problem of openssl or if not maybe something else. In addition if anyone know how much time does TLS session takes to actually end? I wanna know if that 2-?3 seconds delay is normal or not from openssl perspective, or there is some problem with my dpdk application. Thanks for your time, Konstantinos Schoinas From ece8537 at upnet.gr Fri Aug 17 10:43:51 2018 From: ece8537 at upnet.gr (Konstantinos Schoinas) Date: Fri, 17 Aug 2018 13:43:51 +0300 Subject: [openssl-users] TLS-Session Message-ID: Hello, I have deployed 3 VMs in my host (linux) pc.1 ubuntu Desktop and 2 ubuntu Servers. I am using ovs-dpdk(openvswitch-dpdk) in order to create a bridge and make the VMs speak to each other. The test-case is this: VM1 : using openssl as a client to connect to an apache2 server hosted in VM3 VM2 : Dpdk application working as a L2 Switch that does DPI(Deep packet inspection) in the packet and check if there is a server name indication with a specific forbidden SNI .If yes it block the TLS session by replying with a TLS fatal(2) alert packet with Description Unrecognized_name (112).According to RFC this shall block the TLS session. VM3:Just an apache2 Server When i test this i am connecting from VM1 with this command openssl s_client -connect www.example.com:443 -servername www.example.com (where "www.example.com" is the forbidden name of the dpdk application). So my dpdk application is responding with the correct TLS alert and it actually block the TLS session.I have seen the correct packet in wireshark as well.I am also putting a picture with this mail in order to see the process. The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS session.Also i am getting some retransmits of client hello in wireshark. So my question is if anyone can confirm that this is a problem of openssl or if not maybe something else. In addition if anyone know how much time does TLS session takes to actually end? I wanna know if that 2-3 seconds delay is normal or not. Thanks for your time, Konstantinos Schoinas -------------- next part -------------- A non-text attachment was scrubbed... Name: 2018-08-17 1.39.51 PM.jpg Type: image/jpeg Size: 218096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2018-08-17 1.42.16 PM.jpg Type: image/jpeg Size: 324829 bytes Desc: not available URL: From openssl-users at dukhovni.org Mon Aug 20 13:39:07 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Aug 2018 09:39:07 -0400 Subject: [openssl-users] TLS-Session In-Reply-To: References: Message-ID: <7EFBAF0B-4EA0-433B-9843-28923B690B86@dukhovni.org> > On Aug 17, 2018, at 6:43 AM, Konstantinos Schoinas wrote: > > So my dpdk application is responding with the correct TLS alert and it actually block the TLS session.I have seen the correct packet in wireshark as well.I am also putting a picture with this mail in order to see the process. > > The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS session.Also i am getting some retransmits of client hello in wireshark. Re-transmission is a feature of the kernel TCP stack, and OpenSSL has no control over this behaviour. > So my question is if anyone can confirm that this is a problem of openssl or if not maybe something else. > In addition if anyone know how much time does TLS session takes to actually end? This *cannot* be an OpenSSL issue. Your DPI firewall must not be sending an ACK for the client HELLO payload. Or is otherwise failing to conform to TCP in a way that triggers re-transmission. -- Viktor. From beldmit at gmail.com Mon Aug 20 14:08:16 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 20 Aug 2018 17:08:16 +0300 Subject: [openssl-users] Problem using GOST engine with OpenSSL_1_1_0-stable Message-ID: Hello, I've found a problem when using GOST engine with OpenSSL_1_1_0-stable The command openssl s_client -connect tlsgost-256.cryptopro.ru:443 provides the following error report: 139771868619968:error:0306B067:bignum routines:BN_div:div by zero:crypto/bn/bn_div.c:179: 139771868619968:error:8006B010:lib(128):GOST_EC_COMPUTE_PUBLIC:EC lib:/home/beldmit/upstream/engine/gost_ec_sign.c:463: 139771868619968:error:80077068:lib(128):PKEY_GOST_ECCP_ENCRYPT:error computing shared key:/home/beldmit/upstream/engine/gost_ec_keyx.c:192: 139771868619968:error:14196112:SSL routines:tls_construct_cke_gost:library bug:ssl/statem/statem_clnt.c:2436: The error does not occur when using the master openssl branch. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Mon Aug 20 17:45:53 2018 From: tshort at akamai.com (Short, Todd) Date: Mon, 20 Aug 2018 17:45:53 +0000 Subject: [openssl-users] TLS-Session In-Reply-To: <7EFBAF0B-4EA0-433B-9843-28923B690B86@dukhovni.org> References: <7EFBAF0B-4EA0-433B-9843-28923B690B86@dukhovni.org> Message-ID: <6560E1EB-9B74-4F83-85AE-EE3CE8637039@akamai.com> TCP Nagle + TCP Delayed ACKs can cause what appears to be the ClientHello being retransmitted. Tweaking these TCP options will give you better initialization performance. TCP_NODELAY TCP_QUICKACK This may not help the "end session" issue. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 20, 2018, at 9:39 AM, Viktor Dukhovni > wrote: On Aug 17, 2018, at 6:43 AM, Konstantinos Schoinas > wrote: So my dpdk application is responding with the correct TLS alert and it actually block the TLS session.I have seen the correct packet in wireshark as well.I am also putting a picture with this mail in order to see the process. The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS session.Also i am getting some retransmits of client hello in wireshark. Re-transmission is a feature of the kernel TCP stack, and OpenSSL has no control over this behaviour. So my question is if anyone can confirm that this is a problem of openssl or if not maybe something else. In addition if anyone know how much time does TLS session takes to actually end? This *cannot* be an OpenSSL issue. Your DPI firewall must not be sending an ACK for the client HELLO payload. Or is otherwise failing to conform to TCP in a way that triggers re-transmission. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.c.roberts at gmail.com Mon Aug 20 21:39:53 2018 From: bill.c.roberts at gmail.com (William Roberts) Date: Mon, 20 Aug 2018 14:39:53 -0700 Subject: [openssl-users] How to encode R and S of an ECDSA signature to ASN1 sequence Message-ID: I can successfully deconstruct an an ECDSA Signature Sequence, but now I need to construct it, and I am getting lost. The format I need to build is: sECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } I have r and s as buffers in the same format as returned from: d2i_ASN1_INTEGER() if one used it to remove r or s from the sequence above. I am not sure how to compose the sequence given r and s, and if their is a routine to essentially do the opposite of d2i_ASN1_INTEGER. Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Aug 20 23:45:29 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 21 Aug 2018 01:45:29 +0200 Subject: [openssl-users] Anonymous DH (ADH) in real world applications In-Reply-To: <20180819123630.GA24202@picapica.im> References: <20180819123630.GA24202@picapica.im> Message-ID: <4ab4dc7a-b7bd-bf4a-abe1-2df4568cf54d@wisemo.com> On 19/08/2018 14:36, Anton wrote: > Hello > > Does anyone know some examples of applications using > ADH ciphersuites for TLS connections in production > environment? > > I know it is vulnerable to MITM, but it still can > be useful, for example if communicating devices do > not store state data for authentication (unique > certificate per instance), but protection from > passive eavesdropping is desirable. > > Is it reasonable to expect having ADH support enabled > in future releases of OpenSSL? > > Anton > The common secure use is to combine ADH with a mechanism that authenticates the session (handshake messages and or a derived value) over the connection, thus removing the MiTM problem. That mechanism is generally application level, but may or may not use various dedicated TLS features to get such a derived value, depending on the oldest TLS library originally supported by that application protocol (for example if the application protocol was originally designed to cope with TLS libraries that provide only "form X" of the handshake data, then the the application protocol would specify an element that authenticates the "form X" value and won't interoperate with code that uses a more modern "form Y" value even if the application code no longer supports TLS libraries not offering "form Y"). (As usual, X and Y are placeholders). 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 openssl-users at dukhovni.org Tue Aug 21 03:05:59 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Aug 2018 23:05:59 -0400 Subject: [openssl-users] Anonymous DH (ADH) in real world applications In-Reply-To: <20180819124157.GA14549@roeckx.be> References: <20180819123630.GA24202@picapica.im> <20180819124157.GA14549@roeckx.be> Message-ID: <90A8E269-032F-45A3-8E8E-BD7B91E7FB37@dukhovni.org> > On Aug 19, 2018, at 8:41 AM, Kurt Roeckx wrote: > >> Does anyone know some examples of applications using >> ADH ciphersuites for TLS connections in production >> environment? > > At least postfix can use it for SMTP. And prefers it by default with opportunistic TLS, when authentication is not enabled for the destination. http://www.postfix.org/TLS_README.html#client_tls_may http://www.postfix.org/TLS_README.html#client_cipher -- Viktor. From ian.bilek at gmail.com Tue Aug 21 04:51:51 2018 From: ian.bilek at gmail.com (Jan Bilek) Date: Tue, 21 Aug 2018 14:51:51 +1000 Subject: [openssl-users] Chinese remainder algorithm In-Reply-To: References: Message-ID: Hi Thulasi, Thank you for your email, it was an inspiration for our team to follow up. Final solution then looks like this: bool InitKey(RSA_ptr& pkey) { //Recalculate Modulus from provided components BnCtx ctx; { const BIGNUM* p; const BIGNUM* q; RSA_get0_factors(pkey.get(), &p, &q); auto n = BN_new(); BN_mul(n, p, q, ctx.get()); //Assign default exponent //Default Public exponent 65537 const unsigned char defaultPublicExponent[] = {0x01, 0x00, 0x01}; auto e = BN_bin2bn(defaultPublicExponent, sizeof(defaultPublicExponent), nullptr); RSA_set0_key(pkey.get(), n, e, nullptr); } #ifdef DEBUG size_t modulusLength = RSA_size(pkey.get()); std::cout << "modulusLength (n): " << modulusLength << std::endl; std::cout << "modulusLength * 8 (n bits): " << modulusLength * 8 << std::endl; #endif //Recalculate private key auto r0 = BN_CTX_get(ctx.get()); auto r1 = BN_CTX_get(ctx.get()); auto r2 = BN_CTX_get(ctx.get()); auto r3 = BN_CTX_get(ctx.get()); { const BIGNUM* p; const BIGNUM* q; RSA_get0_factors(pkey.get(), &p, &q); //Calculate d //p-1 if (!BN_sub(r1, p, BN_value_one())) return false; //q-1 if (!BN_sub(r2, q, BN_value_one())) return false; } //(p-1)(q-1) if (!BN_mul(r0, r1, r2, ctx.get())) return false; if (!BN_gcd(r3, r1, r2, ctx.get())) return false; //LCM((p-1)(q-1)) if (!BN_div(r0, nullptr, r0, r3, ctx.get())) return false; BnCtx ctx2; if (!ctx2.get()) { return false; } //d { const BIGNUM* e; RSA_get0_key(pkey.get(), nullptr, &e, nullptr); auto d = BN_mod_inverse(nullptr, e, r0, ctx2.get()); if (!d) return false; RSA_set0_key(pkey.get(), nullptr, nullptr, d); } return true; } void RecalculateRsaKeyFromItsFactorsAndParams () { .... RSA_ptr pkey(RSA_new(), ::RSA_free); RSA_set0_key(pkey.get(), BN_new(), BN_new(), BN_new()); RSA_set0_factors(pkey.get(), BN_bin2bn(secureP.data(), secureP.size(), nullptr), BN_bin2bn(secureQ.data(), secureQ.size(), nullptr)); RSA_set0_crt_params(pkey.get(), BN_bin2bn(secureDmp1.data(), secureDmp1.size(), nullptr), BN_bin2bn(secureDmq1.data(), secureDmq1.size(), nullptr), BN_bin2bn(secureIqmp.data(), secureIqmp.size(), nullptr)); if (!InitKey(pkey)) } Hope this is going to help someone one day :) Kind Regards, Jan On Wed, Aug 1, 2018 at 7:33 PM Thulasi Goriparthi < thulasi.goriparthi at gmail.com> wrote: > Hello Jan, > > Decide on what your public exponent(e) should be, and either use > RSA_X931_derive_ex() if you are using an older openssl which supports > this function or follow rsa_builtin_keygen() from crypto/rsa/rsa_gen.c > on how to derive private exponent(d) and modulus(n). > > By the way, technically, you do not need private exponent(d) for > signing, as you already have CRT components. > > What is the function that complained about missing d? > > Thanks, > Thulasi. > > On 31 July 2018 at 16:19, Jan Bilek wrote: > > Hi all, > > > > I need to reconstruct public and private keys for data signing operation > > from p, q, dmp1, dmq1 and iqmp. When I fill values in as per below then > > OpenSSL complains about missing d. > > > > RSA* pkey = RSA_new(); > > pkey->n = NULL; > > pkey->e = NULL; > > pkey->d = NULL; > > > > pkey->p = BN_bin2bn(secureP.data(), secureP.size(), NULL); > > pkey->q = BN_bin2bn(secureQ.data(), secureQ.size(), NULL); > > pkey->dmp1 = BN_bin2bn(secureDmp1.data(), secureDmp1.size(), NULL); > > pkey->dmq1 = BN_bin2bn(secureDmq1.data(), secureDmq1.size(), NULL); > > pkey->iqmp = BN_bin2bn(secureIqmp.data(), secureIqmp.size(), NULL); > > > > I did my homework on Google/Stackoverflow/OpenSSL docu, but I haven't > been > > able to find out any good way to do this, while it is obvious that > openssl > > needs to know this by deafult for its internals. > > Would you have any hint on where next with this? > > > > Thank you, > > Jan > > > > -- > > 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 openssl at openssl.org Tue Aug 21 12:36:02 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 21 Aug 2018 12:36:02 +0000 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published Message-ID: <20180821123602.GA29908@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1 pre release 9 (beta) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The beta release 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.1-pre9.tar.gz Size: 8411103 SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7 SHA256 checksum: 95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre9.tar.gz openssl sha256 openssl-1.1.1-pre9.tar.gz Please download and check this beta release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlt8Ah8ACgkQ2cTSbQ5g RJGYTAgAm4xPeNBGKAsmA9eoRm8FkQHew1zhf9G2P677n26+JKwoUBx7O6c/zhKV c9wP5xjvDl3KlUNw3gga2URIE95wj4RGMOcLUxWEVci+oR7luRXDocJKcAfppLcl 50T4OKL/5tqtAodI700t42SlA4EWyZIv+Kt5YMzQnkbbelGqFA8Loi1yDks+JwWU 2xlx4ukAvCNUuHvKIs85QaRi5PSWRZHE4o49ijP+ynUSxSqjGTLpeW+Ij6pHOH+e 2rKAScmx1Ll3ZK50dVnlWif6H7hjftWclqbNXrGy76SUQjmmzi1vxAm8ftmgUZEP qXxGwJpfpCirNBHPSXeaMSe4thZeCw== =etGy -----END PGP SIGNATURE----- From rgm at htt-consult.com Tue Aug 21 15:24:00 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 21 Aug 2018 11:24:00 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <20180821123602.GA29908@openssl.org> References: <20180821123602.GA29908@openssl.org> Message-ID: <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> Thanks! Once Fedora beta picks this up, I will run my scripts against it and see if all cases of hash with ED25519 are fixed. On 08/21/2018 08:36 AM, OpenSSL wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > OpenSSL version 1.1.1 pre release 9 (beta) > =========================================== > > OpenSSL - The Open Source toolkit for SSL/TLS > https://www.openssl.org/ > > OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 has now > been made available. For details of changes and known issues see the > release notes at: > > https://www.openssl.org/news/openssl-1.1.1-notes.html > > Note: This OpenSSL pre-release has been provided for testing ONLY. > It should NOT be used for security critical purposes. > > The beta release 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.1-pre9.tar.gz > Size: 8411103 > SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7 > SHA256 checksum: 95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c > > The checksums were calculated using the following commands: > > openssl sha1 openssl-1.1.1-pre9.tar.gz > openssl sha256 openssl-1.1.1-pre9.tar.gz > > Please download and check this beta release as soon as possible. > To report a bug, open an issue on GitHub: > > https://github.com/openssl/openssl/issues > > Please check the release notes and mailing lists to avoid duplicate > reports of known issues. (Of course, the source is also available > on GitHub.) > > Yours, > > The OpenSSL Project Team. > > -----BEGIN PGP SIGNATURE----- > > iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlt8Ah8ACgkQ2cTSbQ5g > RJGYTAgAm4xPeNBGKAsmA9eoRm8FkQHew1zhf9G2P677n26+JKwoUBx7O6c/zhKV > c9wP5xjvDl3KlUNw3gga2URIE95wj4RGMOcLUxWEVci+oR7luRXDocJKcAfppLcl > 50T4OKL/5tqtAodI700t42SlA4EWyZIv+Kt5YMzQnkbbelGqFA8Loi1yDks+JwWU > 2xlx4ukAvCNUuHvKIs85QaRi5PSWRZHE4o49ijP+ynUSxSqjGTLpeW+Ij6pHOH+e > 2rKAScmx1Ll3ZK50dVnlWif6H7hjftWclqbNXrGy76SUQjmmzi1vxAm8ftmgUZEP > qXxGwJpfpCirNBHPSXeaMSe4thZeCw== > =etGy > -----END PGP SIGNATURE----- From rgm at htt-consult.com Tue Aug 21 15:27:12 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 21 Aug 2018 11:27:12 -0400 Subject: [openssl-users] ED488 question Message-ID: <9b86ca15-13cd-1aa4-5786-85f6376cf40e@htt-consult.com> Was thinking about ED488 last night.? I am personally not interested in these larger curves, but perhaps I can make my draft 'more complete' if I include 488 along with 25519. Are there any parameters beyond changing the algorithm from ed25519 to ed488?? Is a hash needed for the version of ed488 implemented? thanks From openssl-users at dukhovni.org Tue Aug 21 15:29:38 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 21 Aug 2018 11:29:38 -0400 Subject: [openssl-users] ED488 question In-Reply-To: <9b86ca15-13cd-1aa4-5786-85f6376cf40e@htt-consult.com> References: <9b86ca15-13cd-1aa4-5786-85f6376cf40e@htt-consult.com> Message-ID: > On Aug 21, 2018, at 11:27 AM, Robert Moskowitz wrote: > > Was thinking about ED488 last night. I am personally not interested in these larger curves, but perhaps I can make my draft 'more complete' if I include 488 along with 25519. > > Are there any parameters beyond changing the algorithm from ed25519 to ed488? Is a hash needed for the version of ed488 implemented? Ed448 is a drop-in-replacement for Ed25519, only the sizes of keys and signatures change. -- Viktor. From rgm at htt-consult.com Tue Aug 21 15:40:17 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 21 Aug 2018 11:40:17 -0400 Subject: [openssl-users] ED488 question In-Reply-To: References: <9b86ca15-13cd-1aa4-5786-85f6376cf40e@htt-consult.com> Message-ID: <59322af0-1f29-1aae-3c62-019a1dd93ff2@htt-consult.com> On 08/21/2018 11:29 AM, Viktor Dukhovni wrote: > >> On Aug 21, 2018, at 11:27 AM, Robert Moskowitz wrote: >> >> Was thinking about ED488 last night. I am personally not interested in these larger curves, but perhaps I can make my draft 'more complete' if I include 488 along with 25519. >> >> Are there any parameters beyond changing the algorithm from ed25519 to ed488? Is a hash needed for the version of ed488 implemented? > Ed448 is a drop-in-replacement for Ed25519, only the sizes of keys and signatures > change. > Thought so, but decided to stick my neck out and ask before I run my scripts and test and then get interesting errors. May STILL get interesting errors :)? But that is the challenging part of it all. thanks From radiatejava at gmail.com Tue Aug 21 19:04:59 2018 From: radiatejava at gmail.com (radiatejava) Date: Tue, 21 Aug 2018 12:04:59 -0700 Subject: [openssl-users] openssl get certificate from SSL_CTX Message-ID: I want to get the client certificate and the CA certificates that I set to SSL_CTX. Is there any sample code to do this ? I have not been successful so far. I set the certificate and CA certs this way. char* cacertFile = "cacert.crt"; char* certFile = "client.crt"; char* keyFile = "client.key"; if (!SSL_CTX_load_verify_locations(ctx, cacertFile, NULL)) { std::cout << "cannot load cacerts" << std::endl; } else { std::cout << "cacert loaded" << std::endl; } if (!SSL_CTX_use_certificate_file(ctx, certFile, SSL_FILETYPE_PEM)) { std::cout << "cannot load certfile" << std::endl; } else { std::cout << "certfile loaded" << std::endl; } if (!SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM)) { std::cout << "cannot load private key" << std::endl; } else { std::cout << "private key loaded" << std::endl; } Later I want to see what is the client cert and CA certs. I am looking for any example code to do this. Thanks. From matt at openssl.org Tue Aug 21 22:31:57 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Aug 2018 23:31:57 +0100 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> References: <20180821123602.GA29908@openssl.org> <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> Message-ID: <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> On 21/08/18 16:24, Robert Moskowitz wrote: > Thanks! > > Once Fedora beta picks this up, I will run my scripts against it and see > if all cases of hash with ED25519 are fixed. Unfortunately the command line usability changes for this didn't make it into the beta. They should still be in the final release. Matt > > On 08/21/2018 08:36 AM, OpenSSL wrote: > > OpenSSL version 1.1.1 pre release 9 (beta) > =========================================== > > OpenSSL - The Open Source toolkit for SSL/TLS > https://www.openssl.org/ > > OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 > has now > been made available. For details of changes and known issues see the > release notes at: > > https://www.openssl.org/news/openssl-1.1.1-notes.html > > Note: This OpenSSL pre-release has been provided for testing ONLY. > It should NOT be used for security critical purposes. > > The beta release 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.1-pre9.tar.gz > Size: 8411103 > SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7 > SHA256 checksum: > 95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c > > The checksums were calculated using the following commands: > > openssl sha1 openssl-1.1.1-pre9.tar.gz > openssl sha256 openssl-1.1.1-pre9.tar.gz > > Please download and check this beta release as soon as possible. > To report a bug, open an issue on GitHub: > > https://github.com/openssl/openssl/issues > > Please check the release notes and mailing lists to avoid duplicate > reports of known issues. (Of course, the source is also available > on GitHub.) > > Yours, > > The OpenSSL Project Team. > > From rgm at htt-consult.com Tue Aug 21 23:53:59 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 21 Aug 2018 19:53:59 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> References: <20180821123602.GA29908@openssl.org> <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> Message-ID: <846878e8-0c36-fd21-81b1-d395244c2413@htt-consult.com> On 08/21/2018 06:31 PM, Matt Caswell wrote: > > On 21/08/18 16:24, Robert Moskowitz wrote: >> Thanks! >> >> Once Fedora beta picks this up, I will run my scripts against it and see >> if all cases of hash with ED25519 are fixed. > Unfortunately the command line usability changes for this didn't make it > into the beta. They should still be in the final release. Sigh.? That means you will get it right.? Right?? :) Change seems simple enough. > > Matt > > >> On 08/21/2018 08:36 AM, OpenSSL wrote: >> >> OpenSSL version 1.1.1 pre release 9 (beta) >> =========================================== >> >> OpenSSL - The Open Source toolkit for SSL/TLS >> https://www.openssl.org/ >> >> OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 >> has now >> been made available. For details of changes and known issues see the >> release notes at: >> >> https://www.openssl.org/news/openssl-1.1.1-notes.html >> >> Note: This OpenSSL pre-release has been provided for testing ONLY. >> It should NOT be used for security critical purposes. >> >> The beta release 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.1-pre9.tar.gz >> Size: 8411103 >> SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7 >> SHA256 checksum: >> 95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c >> >> The checksums were calculated using the following commands: >> >> openssl sha1 openssl-1.1.1-pre9.tar.gz >> openssl sha256 openssl-1.1.1-pre9.tar.gz >> >> Please download and check this beta release as soon as possible. >> To report a bug, open an issue on GitHub: >> >> https://github.com/openssl/openssl/issues >> >> Please check the release notes and mailing lists to avoid duplicate >> reports of known issues. (Of course, the source is also available >> on GitHub.) >> >> Yours, >> >> The OpenSSL Project Team. >> >> From matt at openssl.org Wed Aug 22 15:48:44 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 22 Aug 2018 16:48:44 +0100 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <846878e8-0c36-fd21-81b1-d395244c2413@htt-consult.com> References: <20180821123602.GA29908@openssl.org> <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> <846878e8-0c36-fd21-81b1-d395244c2413@htt-consult.com> Message-ID: <946eacb5-8b43-3849-e7e8-6d0cabb98507@openssl.org> On 22/08/18 00:53, Robert Moskowitz wrote: > > > On 08/21/2018 06:31 PM, Matt Caswell wrote: >> >> On 21/08/18 16:24, Robert Moskowitz wrote: >>> Thanks! >>> >>> Once Fedora beta picks this up, I will run my scripts against it and see >>> if all cases of hash with ED25519 are fixed. >> Unfortunately the command line usability changes for this didn't make it >> into the beta. They should still be in the final release. > > Sigh.? That means you will get it right.? Right?? :) > > Change seems simple enough. The relevant change has now been merged to master. Matt > >> >> Matt >> >> >>> On 08/21/2018 08:36 AM, OpenSSL wrote: >>> >>> ???? OpenSSL version 1.1.1 pre release 9 (beta) >>> ???? =========================================== >>> >>> ???? OpenSSL - The Open Source toolkit for SSL/TLS >>> ???? https://www.openssl.org/ >>> >>> ???? OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 >>> has now >>> ???? been made available. For details of changes and known issues see >>> the >>> ???? release notes at: >>> >>> ????????? https://www.openssl.org/news/openssl-1.1.1-notes.html >>> >>> ???? Note: This OpenSSL pre-release has been provided for testing ONLY. >>> ???? It should NOT be used for security critical purposes. >>> >>> ???? The beta release 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.1-pre9.tar.gz >>> ??????? Size: 8411103 >>> ??????? SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7 >>> ??????? SHA256 checksum: >>> 95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c >>> >>> ???? The checksums were calculated using the following commands: >>> >>> ????? openssl sha1 openssl-1.1.1-pre9.tar.gz >>> ????? openssl sha256 openssl-1.1.1-pre9.tar.gz >>> >>> ???? Please download and check this beta release as soon as possible. >>> ???? To report a bug, open an issue on GitHub: >>> >>> ????? https://github.com/openssl/openssl/issues >>> >>> ???? Please check the release notes and mailing lists to avoid duplicate >>> ???? reports of known issues. (Of course, the source is also available >>> ???? on GitHub.) >>> >>> ???? Yours, >>> >>> ???? The OpenSSL Project Team. >>> >>> > From mark.faine at pm.me Wed Aug 22 16:37:39 2018 From: mark.faine at pm.me (mark.faine at pm.me) Date: Wed, 22 Aug 2018 16:37:39 +0000 Subject: [openssl-users] error: void value not ingored as it to be crypto/err/err_all.c Message-ID: I'm trying to build OpenSSL with FIPS module in a centos docker container. The FIPS module builds fine but the openssl build fails with: _USE_NODELETE -MMD -MF crypto/err/err_all.d.tmp -MT crypto/err/err_all.o -c -o crypto/err/err_all.o crypto/err/err_all.c crypto/err/err_all.c: In function 'err_load_crypto_strings_int': crypto/err/err_all.c:47:9: error: void value not ignored as it ought to be FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata) == 0 || ^ crypto/err/err_all.c:95:9: error: void value not ignored as it ought to be ERR_load_FIPS_strings() == 0 || ^ make[1]: Leaving directory `/tmp/openssl-1.1.0i' The relevant parts of my dockerfile are: ENV PREFIX=/usr/local ENV FIPSVER=2.0.16 ENV SSLVER=1.1.0i ENV OPENSSLDIR=${PREFIX}/ssl ENV FIPSDIR="${OPENSSLDIR}/fips-2.0" ENV CFLAGS="-m64 -fPIC" ENV LDFLAGS="-m64 -fPIC -L${PREFIX}/lib64" ENV CC=gcc ENV CXX=g++ ENV SSL_CONFIG="fips -DSSL_ALLOW_ADH -fPIC -I/usr/local/ssl/fips-2.0/include shared zlib" # Custom FIPS enabled SSL ADD ssl/openssl-fips-${FIPSVER}.tar.gz /tmp WORKDIR /tmp/openssl-fips-${FIPSVER} RUN ./config --prefix=${FIPSDIR} RUN make RUN make install ADD ssl/openssl-${SSLVER}.tar.gz /tmp WORKDIR /tmp/openssl-${SSLVER} RUN ./Configure \ --prefix=${OPENSSLDIR} \ --openssldir=${OPENSSLDIR} \ ${SSL_CONFIG} linux-x86_64 RUN make RUN make test RUN make install Any help would be appreciated. -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From director at openca.org Wed Aug 22 14:55:02 2018 From: director at openca.org (Dr. Pala) Date: Wed, 22 Aug 2018 08:55:02 -0600 Subject: [openssl-users] How to Implement a new PubKey method correctly Message-ID: Hi all, I am working on providing a new Public Key method that will handle Composite Keys (i.e., multiple keys with different algos - e.g., one RSA and one EC) and Composite Signatures? (i.e., multiple signatures generated with the corresponding Composite Keys). In particular, I would like to be able to add a method that will, in turn, call the methods supported by the different keys that form the COMPOSITE_PKEY structure. I have looked around how to do it and I am a bit confused about how to proceed as there are some conflicting implementations for different algorithms. Here's some high-level questions related to the EVP_PKEY interface, in particular: * *EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD *- when these two different types of methods are used? Shall both be implemented? * *After providing the implementation for the ameth/pmeth, how does the integration work with openssl?* In particular, should I add them to the list of the default ameth/pmeth supported? Here's some more specific questions: o It seems there is an *app_method stack* of EVP_PKEY_ASN1_METHOD - how do I add the method there (in case I will use a user-level - i.e., not integrated into OpenSSL code - approach by using the functions in the crypto/asn1/ameth_lib.c file). Will the EVP_PKEY_asn1_add0() function call be sufficient? o It seems there is an standard_methods stack of EVP_PKEY_ASN1_METHOD - how do I add the method there if we need to have a more tight integration with the core of the library (in case we can not do our proof-of-concept without touching the openssl's code / requiring a fork) * *COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct.* I noticed that, for example, both RSA and EC implement some form of _CTX and _PKEY structures. Are these used only internally or should they be implemented and integrated with the METHOD(s) ? * *Given the above is implemented correctly - will this enable the use of the method for processing signatures with the new (pseudo-)algorithm for different structures (e.g., CRLs, X509, X509_REQ, OCSP_REQ, OCSP_RESP, etc.)* ? I see that there is some sort of different usages that can be implemented in the CTRL of the ameth (e.g., rsa_pkey_ctrl), however this seems to be targeted to the following operations: ??????? ASN1_PKEY_CTRL_PKCS7_SIGN ??????? ASN1_PKEY_CTRL_PKCS7_ENCRYPT ??????? ASN1_PKEY_CTRL_CMS_SIGN ??????? ASN1_PKEY_CTRL_CMS_ENVELOPE ??????? ASN1_PKEY_CTRL_CMS_RI_TYPE ??????? ASN1_PKEY_CTRL_DEFAULT_MD_NID * Last but not least, since the EVP_PKEY has a union that points to the internal key (i.e., crypto/internal/evp_int.h - evp_pkey_st) where, besides the rsa, dsa, dh, and ec pointers, a void * ptr is defined. Shall I use that pointer to reference the composite_pkey_st (at least for the user-space implementation) ? Thanks for any help for understanding all these details... :D Cheers, Max -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: eonooiokingombaf.png Type: image/png Size: 3146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3994 bytes Desc: S/MIME Cryptographic Signature URL: From Matthias.St.Pierre at ncp-e.com Wed Aug 22 17:16:49 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 22 Aug 2018 17:16:49 +0000 Subject: [openssl-users] error: void value not ingored as it to be crypto/err/err_all.c In-Reply-To: References: Message-ID: <71dc01d7f23b41979def436fd7db31aa@Ex13.ncp.local> Hi Mark, I guess your problem is that you are trying to build OpenSSL 1.1.0 with FIPS. Only OpenSSL 1.0.2 has FIPS support. Regards, Matthias Von: openssl-users Im Auftrag von Mark via openssl-users Gesendet: Mittwoch, 22. August 2018 18:38 An: openssl-users at openssl.org Betreff: [openssl-users] error: void value not ingored as it to be crypto/err/err_all.c I'm trying to build OpenSSL with FIPS module in a centos docker container. The FIPS module builds fine but the openssl build fails with: _USE_NODELETE -MMD -MF crypto/err/err_all.d.tmp -MT crypto/err/err_all.o -c -o crypto/err/err_all.o crypto/err/err_all.c crypto/err/err_all.c: In function 'err_load_crypto_strings_int': crypto/err/err_all.c:47:9: error: void value not ignored as it ought to be FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata) == 0 || ^ crypto/err/err_all.c:95:9: error: void value not ignored as it ought to be ERR_load_FIPS_strings() == 0 || ^ make[1]: Leaving directory `/tmp/openssl-1.1.0i' The relevant parts of my dockerfile are: ENV PREFIX=/usr/local ENV FIPSVER=2.0.16 ENV SSLVER=1.1.0i ENV OPENSSLDIR=${PREFIX}/ssl ENV FIPSDIR="${OPENSSLDIR}/fips-2.0" ENV CFLAGS="-m64 -fPIC" ENV LDFLAGS="-m64 -fPIC -L${PREFIX}/lib64" ENV CC=gcc ENV CXX=g++ ENV SSL_CONFIG="fips -DSSL_ALLOW_ADH -fPIC -I/usr/local/ssl/fips-2.0/include shared zlib" # Custom FIPS enabled SSL ADD ssl/openssl-fips-${FIPSVER}.tar.gz /tmp WORKDIR /tmp/openssl-fips-${FIPSVER} RUN ./config --prefix=${FIPSDIR} RUN make RUN make install ADD ssl/openssl-${SSLVER}.tar.gz /tmp WORKDIR /tmp/openssl-${SSLVER} RUN ./Configure \ --prefix=${OPENSSLDIR} \ --openssldir=${OPENSSLDIR} \ ${SSL_CONFIG} linux-x86_64 RUN make RUN make test RUN make install Any help would be appreciated. -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From qzeng at odva.org Wed Aug 22 17:56:16 2018 From: qzeng at odva.org (Qi Zeng) Date: Wed, 22 Aug 2018 13:56:16 -0400 Subject: [openssl-users] using NULL ciphers Message-ID: <00a601d43a41$6e5115c0$4af34140$@odva.org> Hello, I'm trying to use NULL cipher such as ECDHE-ECDSA-NULL-SHA for debugging purpose. With OpenSSL version 1.0.2p, I was able to make it work. However with version 1.1.0i or 1.1.1 prev 9, SSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-NULL-SHA") succeeded but SSL_Connect () failed. Is there any way to enable NULL ciphers with version 1.1.0i or later? Thanks, Qi -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Aug 22 18:08:42 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 22 Aug 2018 14:08:42 -0400 Subject: [openssl-users] using NULL ciphers In-Reply-To: <00a601d43a41$6e5115c0$4af34140$@odva.org> References: <00a601d43a41$6e5115c0$4af34140$@odva.org> Message-ID: <3CE35E6F-7A95-4712-916E-64688CC94ADF@dukhovni.org> > On Aug 22, 2018, at 1:56 PM, Qi Zeng wrote: > > I?m trying to use NULL cipher such as ECDHE-ECDSA-NULL-SHA for debugging purpose. With OpenSSL version 1.0.2p, I was able to make it work. However with version 1.1.0i or 1.1.1 prev 9, SSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-NULL-SHA") succeeded but SSL_Connect () failed. Is there any way to enable NULL ciphers with version 1.1.0i or later? Yes, you need to use: "ECDHE-ECDSA-NULL-SHA:@SECLEVEL=0" at present there are no separate controls to distinguish between the authentication security level and the encryption security level, so this also removes floors on the keys used in the certificates, but for debugging that should not be an obstacle... -- Viktor. From kurt at roeckx.be Wed Aug 22 18:12:24 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 22 Aug 2018 20:12:24 +0200 Subject: [openssl-users] using NULL ciphers In-Reply-To: <3CE35E6F-7A95-4712-916E-64688CC94ADF@dukhovni.org> References: <00a601d43a41$6e5115c0$4af34140$@odva.org> <3CE35E6F-7A95-4712-916E-64688CC94ADF@dukhovni.org> Message-ID: <20180822181223.GA16085@roeckx.be> On Wed, Aug 22, 2018 at 02:08:42PM -0400, Viktor Dukhovni wrote: > > > > On Aug 22, 2018, at 1:56 PM, Qi Zeng wrote: > > > > I?m trying to use NULL cipher such as ECDHE-ECDSA-NULL-SHA for debugging purpose. With OpenSSL version 1.0.2p, I was able to make it work. However with version 1.1.0i or 1.1.1 prev 9, SSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-NULL-SHA") succeeded but SSL_Connect () failed. Is there any way to enable NULL ciphers with version 1.1.0i or later? > > Yes, you need to use: > > "ECDHE-ECDSA-NULL-SHA:@SECLEVEL=0" > > at present there are no separate controls to distinguish between the > authentication security level and the encryption security level, so > this also removes floors on the keys used in the certificates, but > for debugging that should not be an obstacle... With 1.1.1 pre 9 you also might try to be using TLS 1.3, and that does not support a NULL cipher. Kurt From levitte at openssl.org Wed Aug 22 18:20:56 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 22 Aug 2018 20:20:56 +0200 (CEST) Subject: [openssl-users] How to Implement a new PubKey method correctly In-Reply-To: References: Message-ID: <20180822.202056.1732964589245522693.levitte@openssl.org> In message on Wed, 22 Aug 2018 08:55:02 -0600, "Dr. Pala" said: director> Hi all, director> director> I am working on providing a new Public Key method that will handle director> Composite Keys (i.e., multiple keys with different algos - e.g., one RSA director> and one EC) and Composite Signatures? (i.e., multiple signatures director> generated with the corresponding Composite Keys). In particular, I would director> like to be able to add a method that will, in turn, call the methods director> supported by the different keys that form the COMPOSITE_PKEY structure. director> director> I have looked around how to do it and I am a bit confused about how to director> proceed as there are some conflicting implementations for different director> algorithms. director> director> Here's some high-level questions related to the EVP_PKEY interface, in director> particular: director> director> * *EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD *- when these two director> different types of methods are used? Shall both be implemented? Frankly, I'm a bit confused by this myself at times, so you have my understanding. The way I understand it is that: - EVP_PKEY_ASN1_METHOD is related to the type itself, and defines everything that deals with manipulating the type itself and its contents. This is also much more focused on ASN.1, i.e. encoding and decoding to/from DER, or printing out in a human readable form. - EVP_PKEY_METHOD is about operations using the type. The type itself is simply context to perform the operations in. This is where the common operations (encryption, decryption, signing, verifying) belong. These methods also usually combine the pkey type with appropriate digest algos. It can be argued that these two methods have methods that might belong in the other, and one might also wonder why there is a pkey check in both... director> * *After providing the implementation for the ameth/pmeth, how does director> the integration work with openssl?* In particular, should I add them director> to the list of the default ameth/pmeth supported? Here's some more director> specific questions: director> director> o It seems there is an *app_method stack* of EVP_PKEY_ASN1_METHOD director> - how do I add the method there (in case I will use a user-level director> - i.e., not integrated into OpenSSL code - approach by using the director> functions in the crypto/asn1/ameth_lib.c file). Will the director> EVP_PKEY_asn1_add0() function call be sufficient? A call to EVP_PKEY_asn1_add0() should be sufficient. director> o It seems there is an standard_methods stack of director> EVP_PKEY_ASN1_METHOD - how do I add the method there if we need director> to have a more tight integration with the core of the library director> (in case we can not do our proof-of-concept without touching the director> openssl's code / requiring a fork) If you want to integrate it more tightly, you will have to include some code called att init time that does the EVP_PKEY_asn1_add0() call mentioned above, or you will have to bite the bullet and fork (hey, PRs welcome!) director> * *COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct.* I noticed director> that, for example, both RSA and EC implement some form of _CTX and director> _PKEY structures. Are these used only internally or should they be director> implemented and integrated with the METHOD(s) ? EVP_PKEY and EVP_PKEY_CTX? Is that what you're talking about? director> * *Given the above is implemented correctly - will this enable the use director> of the method for processing signatures with the new director> (pseudo-)algorithm for different structures (e.g., CRLs, X509, director> X509_REQ, OCSP_REQ, OCSP_RESP, etc.)* ? I see that there is some director> sort of different usages that can be implemented in the CTRL of the director> ameth (e.g., rsa_pkey_ctrl), however this seems to be targeted to director> the following operations: director> director> ??????? ASN1_PKEY_CTRL_PKCS7_SIGN director> ??????? ASN1_PKEY_CTRL_PKCS7_ENCRYPT director> ??????? ASN1_PKEY_CTRL_CMS_SIGN director> ??????? ASN1_PKEY_CTRL_CMS_ENVELOPE director> ??????? ASN1_PKEY_CTRL_CMS_RI_TYPE director> ??????? ASN1_PKEY_CTRL_DEFAULT_MD_NID (I'm currently digging through that, and am not quite done) director> * Last but not least, since the EVP_PKEY has a union that points to director> the internal key (i.e., crypto/internal/evp_int.h - evp_pkey_st) director> where, besides the rsa, dsa, dh, and ec pointers, a void * ptr is director> defined. Shall I use that pointer to reference the composite_pkey_st director> (at least for the user-space implementation) ? Use the ->ptr field, or even better (because evp_int.h is internal so you shouldn't look), use EVP_PKEY_get0(). director> Thanks for any help for understanding all these details... :D Let's keep talking... I need to dig deeper anyway ;-) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From qzeng at odva.org Wed Aug 22 18:25:54 2018 From: qzeng at odva.org (Qi Zeng) Date: Wed, 22 Aug 2018 14:25:54 -0400 Subject: [openssl-users] using NULL ciphers In-Reply-To: <20180822181223.GA16085@roeckx.be> References: <00a601d43a41$6e5115c0$4af34140$@odva.org> <3CE35E6F-7A95-4712-916E-64688CC94ADF@dukhovni.org> <20180822181223.GA16085@roeckx.be> Message-ID: <00c501d43a45$9036c550$b0a44ff0$@odva.org> Viktor and Kurt, Thanks for the help! Now it's working. Qi -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx Sent: Wednesday, August 22, 2018 2:12 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] using NULL ciphers On Wed, Aug 22, 2018 at 02:08:42PM -0400, Viktor Dukhovni wrote: > > > > On Aug 22, 2018, at 1:56 PM, Qi Zeng wrote: > > > > I?m trying to use NULL cipher such as ECDHE-ECDSA-NULL-SHA for debugging purpose. With OpenSSL version 1.0.2p, I was able to make it work. However with version 1.1.0i or 1.1.1 prev 9, SSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-NULL-SHA") succeeded but SSL_Connect () failed. Is there any way to enable NULL ciphers with version 1.1.0i or later? > > Yes, you need to use: > > "ECDHE-ECDSA-NULL-SHA:@SECLEVEL=0" > > at present there are no separate controls to distinguish between the > authentication security level and the encryption security level, so > this also removes floors on the keys used in the certificates, but > for debugging that should not be an obstacle... With 1.1.1 pre 9 you also might try to be using TLS 1.3, and that does not support a NULL cipher. Kurt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rgm at htt-consult.com Thu Aug 23 00:08:15 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 22 Aug 2018 20:08:15 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <946eacb5-8b43-3849-e7e8-6d0cabb98507@openssl.org> References: <20180821123602.GA29908@openssl.org> <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> <846878e8-0c36-fd21-81b1-d395244c2413@htt-consult.com> <946eacb5-8b43-3849-e7e8-6d0cabb98507@openssl.org> Message-ID: <01786187-dbaf-b828-a9f7-e3624f0eef07@htt-consult.com> On 08/22/2018 11:48 AM, Matt Caswell wrote: > > On 22/08/18 00:53, Robert Moskowitz wrote: >> >> On 08/21/2018 06:31 PM, Matt Caswell wrote: >>> On 21/08/18 16:24, Robert Moskowitz wrote: >>>> Thanks! >>>> >>>> Once Fedora beta picks this up, I will run my scripts against it and see >>>> if all cases of hash with ED25519 are fixed. >>> Unfortunately the command line usability changes for this didn't make it >>> into the beta. They should still be in the final release. >> Sigh.? That means you will get it right.? Right?? :) >> >> Change seems simple enough. > The relevant change has now been merged to master. Fedora had already built pre9.1.? But on the off chance, I will look at it with tomorrow's build. > > Matt > > >>> Matt >>> >>> >>>> On 08/21/2018 08:36 AM, OpenSSL wrote: >>>> >>>> ???? OpenSSL version 1.1.1 pre release 9 (beta) >>>> ???? =========================================== >>>> >>>> ???? OpenSSL - The Open Source toolkit for SSL/TLS >>>> ???? https://www.openssl.org/ >>>> >>>> ???? OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 9 >>>> has now >>>> ???? been made available. For details of changes and known issues see >>>> the >>>> ???? release notes at: >>>> >>>> ????????? https://www.openssl.org/news/openssl-1.1.1-notes.html >>>> >>>> ???? Note: This OpenSSL pre-release has been provided for testing ONLY. >>>> ???? It should NOT be used for security critical purposes. >>>> >>>> ???? The beta release 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.1-pre9.tar.gz >>>> ??????? Size: 8411103 >>>> ??????? SHA1 checksum: 01a42e93a34746340974b9fafe960226f7d10ff7 >>>> ??????? SHA256 checksum: >>>> 95ebdfbb05e8451fb01a186ccaa4a7da0eff9a48999ede9fe1a7d90db75ccb4c >>>> >>>> ???? The checksums were calculated using the following commands: >>>> >>>> ????? openssl sha1 openssl-1.1.1-pre9.tar.gz >>>> ????? openssl sha256 openssl-1.1.1-pre9.tar.gz >>>> >>>> ???? Please download and check this beta release as soon as possible. >>>> ???? To report a bug, open an issue on GitHub: >>>> >>>> ????? https://github.com/openssl/openssl/issues >>>> >>>> ???? Please check the release notes and mailing lists to avoid duplicate >>>> ???? reports of known issues. (Of course, the source is also available >>>> ???? on GitHub.) >>>> >>>> ???? Yours, >>>> >>>> ???? The OpenSSL Project Team. >>>> >>>> From matt at openssl.org Thu Aug 23 09:17:37 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Aug 2018 10:17:37 +0100 Subject: [openssl-users] How to Implement a new PubKey method correctly In-Reply-To: References: Message-ID: <665d74b5-b070-b652-b7f1-111031b87fc4@openssl.org> On 22/08/18 15:55, Dr. Pala wrote: > Hi all, > > I am working on providing a new Public Key method that will handle > Composite Keys (i.e., multiple keys with different algos - e.g., one RSA > and one EC) and Composite Signatures? (i.e., multiple signatures > generated with the corresponding Composite Keys). In particular, I would > like to be able to add a method that will, in turn, call the methods > supported by the different keys that form the COMPOSITE_PKEY structure. > > I have looked around how to do it and I am a bit confused about how to > proceed as there are some conflicting implementations for different > algorithms. > > Here's some high-level questions related to the EVP_PKEY interface, in > particular: > > * *EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD *- when these two > different types of methods are used? Shall both be implemented? It's a bit confusing and not particularly well defined, with some anomalies. EVP_PKEY_ASN1_METHOD generally contain functions that operate *on* keys and parameters. EVP_PKEY_METHOD generally contains functions that *use* keys and parameters to perform their operations. A significant distinction is that (almost) all the EVP_PKEY_METHOD functions operate within the context of an EVP_PKEY_CTX while none of the EVP_PKEY_ASN1_METHOD functions do. Typically you would define both method types for a particular algorithm. > > * *After providing the implementation for the ameth/pmeth, how does > the integration work with openssl?* In particular, should I add them > to the list of the default ameth/pmeth supported? Here's some more > specific questions: > > o It seems there is an *app_method stack* of EVP_PKEY_ASN1_METHOD > - how do I add the method there (in case I will use a user-level > - i.e., not integrated into OpenSSL code - approach by using the > functions in the crypto/asn1/ameth_lib.c file). Will the > EVP_PKEY_asn1_add0() function call be sufficient? Yes, that is the purpose of that function. See: https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_asn1_add0.html > > o It seems there is an standard_methods stack of > EVP_PKEY_ASN1_METHOD - how do I add the method there if we need > to have a more tight integration with the core of the library > (in case we can not do our proof-of-concept without touching the > openssl's code / requiring a fork) It's defined in crypto/asn1/standard_methods.h, so you just need to add your custom method in there. Obviously, you will then need to also add an implementation of that method and integrate it into the OpenSSL build system. It's probably worth looking at how other methods have been integrated, e.g. you could look at ed448_asn1_meth which was recently added to 1.1.1. > > * *COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct.* I noticed > that, for example, both RSA and EC implement some form of _CTX and > _PKEY structures. Are these used only internally or should they be > implemented and integrated with the METHOD(s) ? These are used internally only. You don't *need* to have them - but you may want to have them if you have algorithm specific data that you need to store. > > * *Given the above is implemented correctly - will this enable the use > of the method for processing signatures with the new > (pseudo-)algorithm for different structures (e.g., CRLs, X509, > X509_REQ, OCSP_REQ, OCSP_RESP, etc.)* ? I see that there is some > sort of different usages that can be implemented in the CTRL of the > ameth (e.g., rsa_pkey_ctrl), however this seems to be targeted to > the following operations: > > ??????? ASN1_PKEY_CTRL_PKCS7_SIGN > ??????? ASN1_PKEY_CTRL_PKCS7_ENCRYPT > ??????? ASN1_PKEY_CTRL_CMS_SIGN > ??????? ASN1_PKEY_CTRL_CMS_ENVELOPE > ??????? ASN1_PKEY_CTRL_CMS_RI_TYPE > ??????? ASN1_PKEY_CTRL_DEFAULT_MD_NID In general once the methods are in place they should be useable throughout the library. However you may find that some areas may need additional tweaks to get them working, e.g. see the X509_certificate_type() function. If integration into TLS was an objective then that would definitely require additional custom code. > > * Last but not least, since the EVP_PKEY has a union that points to > the internal key (i.e., crypto/internal/evp_int.h - evp_pkey_st) > where, besides the rsa, dsa, dh, and ec pointers, a void * ptr is > defined. Shall I use that pointer to reference the composite_pkey_st > (at least for the user-space implementation) ? Yes. If you go down the tighter integration route then you can add your own custom type there. Matt > > Thanks for any help for understanding all these details... :D > > Cheers, > Max > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > > From mann.patidar at gmail.com Thu Aug 23 09:45:47 2018 From: mann.patidar at gmail.com (Manish Patidar) Date: Thu, 23 Aug 2018 15:15:47 +0530 Subject: [openssl-users] Backup of existing ssl connection Message-ID: Hi I want to take backup of existing ssl connection. Use this backup connection in other slave board. This backup include keys and sequence no, ssl version etc. Is Openssl support any api to take backup of existing ssl connection? Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Aug 23 12:36:48 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 23 Aug 2018 12:36:48 +0000 Subject: [openssl-users] Backup of existing ssl connection In-Reply-To: References: Message-ID: >I want to take backup of existing ssl connection. Use this backup connection in other slave board. This backup include keys and sequence no, ssl version etc. >Is Openssl support any api to take backup of existing ssl connection? No. This is not currently possible, and is unlikely to ever happen in OpenSSL. It?s too hard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Thu Aug 23 13:00:03 2018 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 23 Aug 2018 15:00:03 +0200 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <01786187-dbaf-b828-a9f7-e3624f0eef07@htt-consult.com> References: <20180821123602.GA29908@openssl.org> <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> <846878e8-0c36-fd21-81b1-d395244c2413@htt-consult.com> <946eacb5-8b43-3849-e7e8-6d0cabb98507@openssl.org> <01786187-dbaf-b828-a9f7-e3624f0eef07@htt-consult.com> Message-ID: <1535029203.7900.20.camel@redhat.com> On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: > > On 08/22/2018 11:48 AM, Matt Caswell wrote: > > > > On 22/08/18 00:53, Robert Moskowitz wrote: > > > > > > On 08/21/2018 06:31 PM, Matt Caswell wrote: > > > > On 21/08/18 16:24, Robert Moskowitz wrote: > > > > > Thanks! > > > > > > > > > > Once Fedora beta picks this up, I will run my scripts against > > > > > it and see > > > > > if all cases of hash with ED25519 are fixed. > > > > > > > > Unfortunately the command line usability changes for this > > > > didn't make it > > > > into the beta. They should still be in the final release. > > > > > > Sigh. That means you will get it right. Right? :) > > > > > > Change seems simple enough. > > > > The relevant change has now been merged to master. > > Fedora had already built pre9.1. But on the off chance, I will look > at > it with tomorrow's build. I'm sorry but no, I am not updating Fedora with current git tree checkout. You'll have to wait for the next prerelease or the final version if there are no further prereleases. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From rgm at htt-consult.com Thu Aug 23 14:35:01 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 23 Aug 2018 10:35:01 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <1535029203.7900.20.camel@redhat.com> References: <20180821123602.GA29908@openssl.org> <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> <846878e8-0c36-fd21-81b1-d395244c2413@htt-consult.com> <946eacb5-8b43-3849-e7e8-6d0cabb98507@openssl.org> <01786187-dbaf-b828-a9f7-e3624f0eef07@htt-consult.com> <1535029203.7900.20.camel@redhat.com> Message-ID: <2181e701-a196-424b-1ce1-1c6faab2643a@htt-consult.com> On 08/23/2018 09:00 AM, Tomas Mraz wrote: > On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: >> On 08/22/2018 11:48 AM, Matt Caswell wrote: >>> On 22/08/18 00:53, Robert Moskowitz wrote: >>>> On 08/21/2018 06:31 PM, Matt Caswell wrote: >>>>> On 21/08/18 16:24, Robert Moskowitz wrote: >>>>>> Thanks! >>>>>> >>>>>> Once Fedora beta picks this up, I will run my scripts against >>>>>> it and see >>>>>> if all cases of hash with ED25519 are fixed. >>>>> Unfortunately the command line usability changes for this >>>>> didn't make it >>>>> into the beta. They should still be in the final release. >>>> Sigh. That means you will get it right. Right? :) >>>> >>>> Change seems simple enough. >>> The relevant change has now been merged to master. >> Fedora had already built pre9.1. But on the off chance, I will look >> at >> it with tomorrow's build. > I'm sorry but no, I am not updating Fedora with current git tree > checkout. You'll have to wait for the next prerelease or the final > version if there are no further prereleases. > Tomas, Thanks for responding here. I have been preparing an Internet Draft on how to build an ED25519 pki.? I know have the choice of: building my own 1.1.1 pre9 for testing. Wait to push the draft out until 1.1.1 is fully released. Fudge the draft by adding yet another caveat (yes there is a caveat section that I developed in creating the ECDSA pki draft) that the commands are for how it is suppose to work in production 1.1.1, not what I had to do in the prerelease. Decisions decisions.? Thing is I want the draft out so I can push for EDDSA support in IEEE 802.1AR with the next meeting early Sept. From matt at openssl.org Thu Aug 23 15:05:02 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Aug 2018 16:05:02 +0100 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <2181e701-a196-424b-1ce1-1c6faab2643a@htt-consult.com> References: <20180821123602.GA29908@openssl.org> <62068b53-9277-3d78-5213-869d4e97119d@htt-consult.com> <142ae878-fecd-aa44-e86b-7d4b910b2a08@openssl.org> <846878e8-0c36-fd21-81b1-d395244c2413@htt-consult.com> <946eacb5-8b43-3849-e7e8-6d0cabb98507@openssl.org> <01786187-dbaf-b828-a9f7-e3624f0eef07@htt-consult.com> <1535029203.7900.20.camel@redhat.com> <2181e701-a196-424b-1ce1-1c6faab2643a@htt-consult.com> Message-ID: On 23/08/18 15:35, Robert Moskowitz wrote: > building my own 1.1.1 pre9 for testing. Note - you would have to build off of git master to get the usability fixes since 1.1.1-pre9 was created prior them being merged. Matt > Wait to push the draft out until 1.1.1 is fully released. > Fudge the draft by adding yet another caveat (yes there is a caveat > section that I developed in creating the ECDSA pki draft) that the > commands are for how it is suppose to work in production 1.1.1, not what > I had to do in the prerelease. > > Decisions decisions.? Thing is I want the draft out so I can push for > EDDSA support in IEEE 802.1AR with the next meeting early Sept. > > From dclarke at blastwave.org Fri Aug 24 02:03:36 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 23 Aug 2018 22:03:36 -0400 Subject: [openssl-users] OpenSSL 1.1.1 pre-7 or pre-8 connect to 1.1.1 pre-9 oddity? In-Reply-To: <20180821123602.GA29908@openssl.org> References: <20180821123602.GA29908@openssl.org> Message-ID: <9555a50a-8db1-5686-cb3f-13b91448669d@blastwave.org> I find it interesting that openssl 1.1.1-pre7 can not connect to a server which has openssl 1.1.1-pre9 in place. Nor can Firefox nightly. $ /usr/local/bin/openssl version OpenSSL 1.1.1-pre7 (beta) 29 May 2018 $ /usr/local/bin/openssl s_client -connect 68.179.116.201:443 -tls1_3 CONNECTED(00000003) 4294967296:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1569:SSL alert number 70 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 242 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent SSL-Session: Protocol : TLSv1.3 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1535074652 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- $ Looks similar to a system with OpenSSL 1.1.1-pre8 : $ /usr/local/bin/openssl version OpenSSL 1.1.1-pre8 (beta) 20 Jun 2018 $ /usr/local/bin/openssl s_client -connect 68.179.116.201:443 -tls1_3 CONNECTED(00000003) 4294967296:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1556:SSL alert number 70 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 242 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent SSL-Session: Protocol : TLSv1.3 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1535074764 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- $ However a client with OpenSSL 1.1.1-pre9 has much more to say : min_$ /usr/local/bin/openssl version OpenSSL 1.1.1-pre9 (beta) 21 Aug 2018 min_$ /usr/local/bin/openssl s_client -connect 68.179.116.201:443 -tls1_3 CONNECTED(00000005) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = *.tls13.net verify return:1 --- Certificate chain 0 s:CN = *.tls13.net i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- MIIGAjCCBOqgAwIBAgISA3lbcjYuS0tUnszwWevJIyQaMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODA1MjgwNjAzNDBaFw0x ODA4MjYwNjAzNDBaMBYxFDASBgNVBAMMCyoudGxzMTMubmV0MIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsBAe67Fo6plfaNkcKLwN9t9YqT0K56RHZ8U2 3AdLG3P56jPfZJ72JmVZB7GcxIQJL02DOmgLEv2Z2YCJyMqkSZFRpDEVR/Y5URN6 DXqxLr5GTX421aTgBY10+9psJnoBgeV5PlEipZ6cQEg9CrF+RYZcOn/FzEQL1eXC /G4K03X0r8YOn5zPWj8NXhHptC9qRImy6REnivWs3CEEQLg5+tzQwjYt8V/IiRrl SbMCZlpAYxVMOeAtvhQXffbXYIgnm6ypmaBzSWM+z/25yPgwhXUDyktn6r6k6mRH D5mnjPoVg0Xk0SgqE0oHAONfCwRnP0ZYtYUp40sSc2k3BygceQIDAQABo4IDFDCC AxAwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD AjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBS9g2YSl7BF5PPZD7xb8hOxBrQJXDAf BgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcBAQRjMGEw LgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlwdC5vcmcw LwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlwdC5vcmcv MBYGA1UdEQQPMA2CCyoudGxzMTMubmV0MIH+BgNVHSAEgfYwgfMwCAYGZ4EMAQIB MIHmBgsrBgEEAYLfEwEBATCB1jAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRz ZW5jcnlwdC5vcmcwgasGCCsGAQUFBwICMIGeDIGbVGhpcyBDZXJ0aWZpY2F0ZSBt YXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBSZWx5aW5nIFBhcnRpZXMgYW5kIG9u bHkgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91 bmQgYXQgaHR0cHM6Ly9sZXRzZW5jcnlwdC5vcmcvcmVwb3NpdG9yeS8wggEFBgor BgEEAdZ5AgQCBIH2BIHzAPEAdwApPFGWVMg5ZbqqUPxYB9S3b79Yeily3KTDDPTl RUf0eAAAAWOlj0izAAAEAwBIMEYCIQC5o0yxNe2SY1sA6ZvPhHCEo6J4itPKKQ0s EnCgEWq1gQIhAPsDEFYOPxHrii5/B8pDtTvQGuj9HfPFqiDES9QJ73XMAHYAb1N2 rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RMAAAFjpY9JuwAABAMARzBFAiEA g0nicYbN9QLQbprHPQUdzFVDFt1L1XAn9Z3NvFY8OH4CIC+gq3Bb1C/TMWhDrcCb 4W+BzWQup0B1GGdIGKC+N8zcMA0GCSqGSIb3DQEBCwUAA4IBAQBurQFuNye9qk4W hsIYfRh3zDyB3oW0x9XZFxeWVS5Lyk05DE9cgTku1roZ2d+OMNOOOeUhhUWZfGQO /C/972Am/4gT5QyiiEXZjeASQz5zvrbur0b5qI4nhAUdQ54be7D+vvqMjSN5BH0F 0+7Y7DxIIvUWmWPtyfA3mQI0anbA3WelnDoon/HiAwvdzj130fABl4M81PUN3GVf ySsGXKitxY8HofArokYLygbwFVe3A1H4cyWwLQk+vHXDyYJWqh78UFhXS2A6kjwg 1vNRzOHTLCQfYIoWw8CePPeKTbxc7sr3zRBhNCYN/5rhzniBymc72wDcPOXpXSB3 PrK8bh7S -----END CERTIFICATE----- subject=CN = *.tls13.net issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 3277 bytes and written 318 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: 28BDFEE2BCCD4A96147F0896C2140A6F011904108294FF4E1BD777CCFFCD65AA Session-ID-ctx: Resumption PSK: 2942321AF1EAC0C009D578AD3F33707B0715A28A734296AEE627D3924A5FEE4BA5D57EAA3422401460D14AB2EC66784C PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 29 2d 6e a5 eb f0 24 15-09 4b a7 c7 80 61 21 12 )-n...$..K...a!. 0010 - 55 21 07 47 d2 ad f8 73-fa 60 95 c4 d9 7e bf 69 U!.G...s.`...~.i 0020 - 8e a8 b5 3b 8d 58 10 8e-5e 21 67 7e 73 8d f7 49 ...;.X..^!g~s..I 0030 - 28 66 84 b9 96 b2 de 4a-f4 92 47 35 bf b9 19 b0 (f.....J..G5.... 0040 - b9 5b 78 13 7a 9e e1 51-a6 ed e0 b0 09 14 91 5b .[x.z..Q.......[ 0050 - c8 94 1c b9 ac d2 ce 1d-bf b4 47 63 77 49 75 71 ..........GcwIuq 0060 - 40 cc 01 d5 6f 77 0d b1-ea 96 81 48 5e 9d 89 da @...ow.....H^... 0070 - 30 d0 2e e8 a7 a7 1c 07-e2 1c f3 f5 aa 96 58 4c 0.............XL 0080 - f9 ba 8e 01 c7 ad 38 6e-da ee 15 ed 24 53 81 26 ......8n....$S.& 0090 - 9d 34 cd c2 c7 70 39 36-43 44 0d 40 05 3e 45 5f .4...p96CD. at .>E_ 00a0 - d8 65 5f 6b 77 ab f2 fa-a5 ea 47 7e 5f 82 d8 db .e_kw.....G~_... 00b0 - 32 7d b5 8b 25 e9 83 23-fe 1a f0 79 d3 c8 52 23 2}..%..#...y..R# 00c0 - ec c8 76 a6 b6 c3 00 99-e8 21 91 cf 69 50 3c d0 ..v......!..iP<. 00d0 - b7 5f d7 ed 70 0b b3 02-34 d3 90 fb 4d 21 b8 1d ._..p...4...M!.. Start Time: 1535075008 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK --- Post-Handshake New Session Ticket arrived: SSL-Session: Protocol : TLSv1.3 Cipher : TLS_AES_256_GCM_SHA384 Session-ID: D8D05B640BF1B476B096BA4DD5CD188DD25F2DCC7799A6C8ED39800BBC6C1D71 Session-ID-ctx: Resumption PSK: 427A9747E8A65332AB7C61E556D3320995AE950ED35B162D4268BD8A909B268DA75F87B36A551344C534F3D2C63AD21E PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 29 2d 6e a5 eb f0 24 15-09 4b a7 c7 80 61 21 12 )-n...$..K...a!. 0010 - 6d 59 da 8b 91 bb 5e c9-c9 4b c3 ec 45 9c ca 0c mY....^..K..E... 0020 - 45 65 32 38 da e4 e4 e7-8e f8 eb 43 08 8e 25 64 Ee28.......C..%d 0030 - 22 65 a3 f5 2f b3 e1 90-d2 8a 0c e4 94 a1 5d 9a "e../.........]. 0040 - 22 f3 14 5d 08 6b 53 fa-0f 82 47 0d b5 ea be a0 "..].kS...G..... 0050 - e0 9c 58 7d 57 00 81 89-e7 1e df 25 cd 42 38 96 ..X}W......%.B8. 0060 - 93 56 1f 12 14 22 db 84-19 c0 23 de 16 4d 60 72 .V..."....#..M`r 0070 - 4c b8 33 96 68 a1 aa 10-45 69 ab 38 e0 c1 10 be L.3.h...Ei.8.... 0080 - 7d cf 5e 86 8a 37 9a 41-f4 e5 f5 ab 82 04 59 42 }.^..7.A......YB 0090 - 50 a1 ad bb 45 c6 26 89-22 59 a3 72 6f e2 15 31 P...E.&."Y.ro..1 00a0 - fa 93 ed d4 f4 fc 17 bb-d8 4d ed 31 b2 85 a5 e0 .........M.1.... 00b0 - b4 7e 6c 7f 94 4e ce d8-72 ac 97 28 61 bf bb 21 .~l..N..r..(a..! 00c0 - 79 74 8a 4b 28 5e ee 98-ef d1 0a 7b 4d bc e3 b3 yt.K(^.....{M... 00d0 - 7b 0c c5 3e a6 3c be 4b-03 16 5d d4 ce 83 dd d4 {..>.<.K..]..... Start Time: 1535075008 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no Max Early Data: 0 --- read R BLOCK GET HTTP/1.1 400 Bad Request Date: Fri, 24 Aug 2018 01:43:34 GMT Server: Apache/2.5.1-dev (Unix) OpenSSL/1.1.1-pre9 Strict-Transport-Security: max-age=31536000; includeSubdomains; Last-Modified: Mon, 28 May 2018 19:03:30 GMT ETag: "2b0-56d48c600191c" Accept-Ranges: bytes Content-Length: 688 Connection: close Content-Type: text/html error code 400 bad request error code 400 bad request ... that is all for now closed min_$ Seems to have been some interesting changes between pre7 and pre8 upwards to pre9. All systems have a full pile of CA cert data in /usr/local/ssl/certs and similar openssl.cnf files. So this is odd or fully expected? Dennis ps: https://www.tls13.net/ is running with OpenSSL 1.1.1-pre9 From rsalz at akamai.com Fri Aug 24 02:12:02 2018 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Aug 2018 02:12:02 +0000 Subject: [openssl-users] OpenSSL 1.1.1 pre-7 or pre-8 connect to 1.1.1 pre-9 oddity? In-Reply-To: <9555a50a-8db1-5686-cb3f-13b91448669d@blastwave.org> References: <20180821123602.GA29908@openssl.org> <9555a50a-8db1-5686-cb3f-13b91448669d@blastwave.org> Message-ID: I find it interesting that openssl 1.1.1-pre7 can not connect to a server which has openssl 1.1.1-pre9 in place. Nor can Firefox nightly. This is to be expected. Pre-9 implements the official RFC version of TLS 1.3, while the earlier beta releases implement drafts. One of the major differences between the RFC and the drafts, is that (a) they don't interoperate, by design; and (b) fallback is an error. From dclarke at blastwave.org Fri Aug 24 02:16:46 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 23 Aug 2018 22:16:46 -0400 Subject: [openssl-users] OpenSSL 1.1.1 pre-7 or pre-8 connect to 1.1.1 pre-9 oddity? In-Reply-To: References: <20180821123602.GA29908@openssl.org> <9555a50a-8db1-5686-cb3f-13b91448669d@blastwave.org> Message-ID: <2a11cdbc-17e6-9dd6-554a-f7e0602f7a35@blastwave.org> On 08/23/2018 10:12 PM, Salz, Rich via openssl-users wrote: > I find it interesting that openssl 1.1.1-pre7 can not connect to a > server which has openssl 1.1.1-pre9 in place. Nor can Firefox nightly. > > This is to be expected. Pre-9 implements the official RFC version of TLS 1.3, while the earlier beta releases implement drafts. One of the major differences between the RFC and the drafts, is that (a) they don't interoperate, by design; and (b) fallback is an error. > > OKay, thank you. I'll add a note to the Mozilla bug : https://bugzilla.mozilla.org/show_bug.cgi?id=1485866 Seems that tls13.crypto.mozilla.org is on draft 28 and not the final protocol spec. Makes perfect sense. Dennis From dclarke at blastwave.org Fri Aug 24 02:28:27 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 23 Aug 2018 22:28:27 -0400 Subject: [openssl-users] OpenSSL 1.1.1 pre-7 or pre-8 connect to 1.1.1 pre-9 oddity? In-Reply-To: References: <20180821123602.GA29908@openssl.org> <9555a50a-8db1-5686-cb3f-13b91448669d@blastwave.org> Message-ID: <4ff1dbda-8e7a-a414-14f7-2774e03a5db7@blastwave.org> On 08/23/2018 10:12 PM, Salz, Rich via openssl-users wrote: > I find it interesting that openssl 1.1.1-pre7 can not connect to a > server which has openssl 1.1.1-pre9 in place. Nor can Firefox nightly. > > This is to be expected. Pre-9 implements the official RFC version of TLS 1.3, while the earlier beta releases implement drafts. One of the major differences between the RFC and the drafts, is that (a) they don't interoperate, by design; and (b) fallback is an error. > > OKay .. I was told to chill out over at Mozilla : https://bugzilla.mozilla.org/show_bug.cgi?id=1485866 https://bugzilla.mozilla.org/show_bug.cgi?id=1457761 So .. a few days or so .. or more. Dennis From jay-jordan82 at outlook.com Fri Aug 24 03:10:28 2018 From: jay-jordan82 at outlook.com (Jason Jordan) Date: Fri, 24 Aug 2018 03:10:28 +0000 Subject: [openssl-users] help I'm lost Message-ID: Get Outlook for Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay-jordan82 at outlook.com Fri Aug 24 03:23:04 2018 From: jay-jordan82 at outlook.com (Jason Jordan) Date: Fri, 24 Aug 2018 03:23:04 +0000 Subject: [openssl-users] TLSv1.3, TLS_AE3_256_GMC_SHA384 Message-ID: Wtf do I have to do now? Thank you Get Outlook for Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From mann.patidar at gmail.com Fri Aug 24 04:18:51 2018 From: mann.patidar at gmail.com (Manish Patidar) Date: Fri, 24 Aug 2018 09:48:51 +0530 Subject: [openssl-users] Regarding Openssl 1.0.2p bn changes Message-ID: Hi, I have doubt regarding the bn change in Openssl version 1.0.2p. There is new flag introduced BN_FLG_FIXED_TOP, value of this flag is zero untill BN_DEBUG is defined. By default BN_DEBUG is not defined. So what is the purpose of this flag.? Regards Mwnish -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Aug 24 07:55:20 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 24 Aug 2018 10:55:20 +0300 Subject: [openssl-users] How to Implement a new PubKey method correctly In-Reply-To: References: Message-ID: Dear Max, You can take a look at https://github.com/gost-engine/engine as an example of providing new algorithms via engine. On Fri, Aug 24, 2018 at 10:45 AM Dr. Pala wrote: > Hi all, > > I am working on providing a new Public Key method that will handle > Composite Keys (i.e., multiple keys with different algos - e.g., one RSA > and one EC) and Composite Signatures (i.e., multiple signatures generated > with the corresponding Composite Keys). In particular, I would like to be > able to add a method that will, in turn, call the methods supported by the > different keys that form the COMPOSITE_PKEY structure. > > I have looked around how to do it and I am a bit confused about how to > proceed as there are some conflicting implementations for different > algorithms. > > Here's some high-level questions related to the EVP_PKEY interface, in > particular: > > - *EVP_PKEY_ASN1_METHOD vs. EVP_PKEY_METHOD *- when these two > different types of methods are used? Shall both be implemented? > > The 1st one is for processing ASN1 structures and the 2nd is for crypto-operations. > > - > - *After providing the implementation for the ameth/pmeth, how does > the integration work with openssl?* In particular, should I add them > to the list of the default ameth/pmeth supported? Here's some more specific > questions: > > - It seems there is an *app_method stack* of EVP_PKEY_ASN1_METHOD - > how do I add the method there (in case I will use a user-level - i.e., not > integrated into OpenSSL code - approach by using the functions in the > crypto/asn1/ameth_lib.c file). Will the EVP_PKEY_asn1_add0() function call > be sufficient? > > - It seems there is an standard_methods stack of > EVP_PKEY_ASN1_METHOD - how do I add the method there if we need to have a > more tight integration with the core of the library (in case we can not do > our proof-of-concept without touching the openssl's code / requiring a fork) > > See register_ameth/register_pmeth in GOST engine. > - > - *COMPOSITE_PKEY struct and COMPOSITE_PKEY_CTX struct.* I noticed > that, for example, both RSA and EC implement some form of _CTX and _PKEY > structures. Are these used only internally or should they be implemented > and integrated with the METHOD(s) ? > > I suspect you need your own representation of key owning RSA and EC keys and manage themselves. > > - > - *Given the above is implemented correctly - will this enable the use > of the method for processing signatures with the new (pseudo-)algorithm for > different structures (e.g., CRLs, X509, X509_REQ, OCSP_REQ, OCSP_RESP, > etc.)* ? I see that there is some sort of different usages that can be > implemented in the CTRL of the ameth (e.g., rsa_pkey_ctrl), however this > seems to be targeted to the following operations: > > ASN1_PKEY_CTRL_PKCS7_SIGN > ASN1_PKEY_CTRL_PKCS7_ENCRYPT > ASN1_PKEY_CTRL_CMS_SIGN > ASN1_PKEY_CTRL_CMS_ENVELOPE > ASN1_PKEY_CTRL_CMS_RI_TYPE > ASN1_PKEY_CTRL_DEFAULT_MD_NID > > - Last but not least, since the EVP_PKEY has a union that points to > the internal key (i.e., crypto/internal/evp_int.h - evp_pkey_st) where, > besides the rsa, dsa, dh, and ec pointers, a void * ptr is defined. Shall I > use that pointer to reference the composite_pkey_st (at least for the > user-space implementation) ? > > Yes. > > > Thanks for any help for understanding all these details... :D > > Cheers, > Max > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: eonooiokingombaf.png Type: image/png Size: 3146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: eonooiokingombaf.png Type: image/png Size: 3146 bytes Desc: not available URL: From jisoza at gmail.com Mon Aug 27 12:50:14 2018 From: jisoza at gmail.com (Juan Isoza) Date: Mon, 27 Aug 2018 14:50:14 +0200 Subject: [openssl-users] openssl 1.1.1 release Message-ID: Openssl 1.1.1 pre 9 is now compatible with final RFC tls 1.3 but I see several recent commit , so I suppose we'll see a pre 10 before final openssl 1.1.1 Any idea for the possible date of publication of 1.1.1 final (if there is no major bug/problem) ? regards juan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Aug 27 13:12:01 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Aug 2018 14:12:01 +0100 Subject: [openssl-users] openssl 1.1.1 release In-Reply-To: References: Message-ID: On 27/08/18 13:50, Juan Isoza wrote: > Openssl 1.1.1 pre 9 is now compatible with final RFC tls 1.3 > > but I see several recent commit , so I suppose we'll see a pre 10 before > final openssl 1.1.1 > > > Any idea for the possible date of publication of 1.1.1 final (if there > is no major bug/problem) ? We are hoping that pre 9 will be the last beta and the next release will be the final one. We have tentatively discussed 11th September as a possible release date - but no definitive decisions on this yet. Matt > > regards > juan > > From hkario at redhat.com Mon Aug 27 18:29:51 2018 From: hkario at redhat.com (Hubert Kario) Date: Mon, 27 Aug 2018 20:29:51 +0200 Subject: [openssl-users] [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves? In-Reply-To: References: <20180817.135513.218041365083823947.levitte@openssl.org> Message-ID: <2751048.TOCydn2eQE@pintsize.usersys.redhat.com> On Saturday, 18 August 2018 19:48:21 CEST Juan Isoza wrote: > What is the difference between draft 28 and rfc for tls 1.3 ? the downgrade protection mechanism gets enabled for the first time -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From hkario at redhat.com Mon Aug 27 18:33:45 2018 From: hkario at redhat.com (Hubert Kario) Date: Mon, 27 Aug 2018 20:33:45 +0200 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <2181e701-a196-424b-1ce1-1c6faab2643a@htt-consult.com> References: <20180821123602.GA29908@openssl.org> <1535029203.7900.20.camel@redhat.com> <2181e701-a196-424b-1ce1-1c6faab2643a@htt-consult.com> Message-ID: <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > On 08/23/2018 09:00 AM, Tomas Mraz wrote: > > On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: > >> On 08/22/2018 11:48 AM, Matt Caswell wrote: > >>> On 22/08/18 00:53, Robert Moskowitz wrote: > >>>> On 08/21/2018 06:31 PM, Matt Caswell wrote: > >>>>> On 21/08/18 16:24, Robert Moskowitz wrote: > >>>>>> Thanks! > >>>>>> > >>>>>> Once Fedora beta picks this up, I will run my scripts against > >>>>>> it and see > >>>>>> if all cases of hash with ED25519 are fixed. > >>>>> > >>>>> Unfortunately the command line usability changes for this > >>>>> didn't make it > >>>>> into the beta. They should still be in the final release. > >>>> > >>>> Sigh. That means you will get it right. Right? :) > >>>> > >>>> Change seems simple enough. > >>> > >>> The relevant change has now been merged to master. > >> > >> Fedora had already built pre9.1. But on the off chance, I will look > >> at > >> it with tomorrow's build. > > > > I'm sorry but no, I am not updating Fedora with current git tree > > checkout. You'll have to wait for the next prerelease or the final > > version if there are no further prereleases. > > Tomas, > > Thanks for responding here. > > I have been preparing an Internet Draft on how to build an ED25519 pki. > I know have the choice of: > > building my own 1.1.1 pre9 for testing. > Wait to push the draft out until 1.1.1 is fully released. > Fudge the draft by adding yet another caveat (yes there is a caveat > section that I developed in creating the ECDSA pki draft) that the > commands are for how it is suppose to work in production 1.1.1, not what > I had to do in the prerelease. > > Decisions decisions. Thing is I want the draft out so I can push for > EDDSA support in IEEE 802.1AR with the next meeting early Sept. I'm not sure if providing command line examples for one particular tool are a good idea... Example certificates, sure, but not commands to generate them... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From uri at ll.mit.edu Mon Aug 27 18:42:24 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 27 Aug 2018 18:42:24 +0000 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> References: <20180821123602.GA29908@openssl.org> <1535029203.7900.20.camel@redhat.com> <2181e701-a196-424b-1ce1-1c6faab2643a@htt-consult.com> <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> Message-ID: <19A96ABA-7696-4EE5-9D83-2E72958DC1FC@ll.mit.edu> Since this example would show how to generate certificates that people may not have a lot of experience dealing with - I think it would make a lot of sense to document as much as possible. In short: yes please do include the examples of both what the certs should look like, and how to generate them. ?On 8/27/18, 2:34 PM, "openssl-users on behalf of Hubert Kario" wrote: On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > On 08/23/2018 09:00 AM, Tomas Mraz wrote: > > On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: > >> On 08/22/2018 11:48 AM, Matt Caswell wrote: > >>> On 22/08/18 00:53, Robert Moskowitz wrote: > >>>> On 08/21/2018 06:31 PM, Matt Caswell wrote: > >>>>> On 21/08/18 16:24, Robert Moskowitz wrote: > >>>>>> Thanks! > >>>>>> > >>>>>> Once Fedora beta picks this up, I will run my scripts against > >>>>>> it and see > >>>>>> if all cases of hash with ED25519 are fixed. > >>>>> > >>>>> Unfortunately the command line usability changes for this > >>>>> didn't make it > >>>>> into the beta. They should still be in the final release. > >>>> > >>>> Sigh. That means you will get it right. Right? :) > >>>> > >>>> Change seems simple enough. > >>> > >>> The relevant change has now been merged to master. > >> > >> Fedora had already built pre9.1. But on the off chance, I will look > >> at > >> it with tomorrow's build. > > > > I'm sorry but no, I am not updating Fedora with current git tree > > checkout. You'll have to wait for the next prerelease or the final > > version if there are no further prereleases. > > Tomas, > > Thanks for responding here. > > I have been preparing an Internet Draft on how to build an ED25519 pki. > I know have the choice of: > > building my own 1.1.1 pre9 for testing. > Wait to push the draft out until 1.1.1 is fully released. > Fudge the draft by adding yet another caveat (yes there is a caveat > section that I developed in creating the ECDSA pki draft) that the > commands are for how it is suppose to work in production 1.1.1, not what > I had to do in the prerelease. > > Decisions decisions. Thing is I want the draft out so I can push for > EDDSA support in IEEE 802.1AR with the next meeting early Sept. I'm not sure if providing command line examples for one particular tool are a good idea... Example certificates, sure, but not commands to generate them... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic From rgm at htt-consult.com Mon Aug 27 18:57:53 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 27 Aug 2018 14:57:53 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> References: <20180821123602.GA29908@openssl.org> <1535029203.7900.20.camel@redhat.com> <2181e701-a196-424b-1ce1-1c6faab2643a@htt-consult.com> <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> Message-ID: On 08/27/2018 02:33 PM, Hubert Kario wrote: > On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: >> On 08/23/2018 09:00 AM, Tomas Mraz wrote: >>> On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: >>>> On 08/22/2018 11:48 AM, Matt Caswell wrote: >>>>> On 22/08/18 00:53, Robert Moskowitz wrote: >>>>>> On 08/21/2018 06:31 PM, Matt Caswell wrote: >>>>>>> On 21/08/18 16:24, Robert Moskowitz wrote: >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Once Fedora beta picks this up, I will run my scripts against >>>>>>>> it and see >>>>>>>> if all cases of hash with ED25519 are fixed. >>>>>>> Unfortunately the command line usability changes for this >>>>>>> didn't make it >>>>>>> into the beta. They should still be in the final release. >>>>>> Sigh. That means you will get it right. Right? :) >>>>>> >>>>>> Change seems simple enough. >>>>> The relevant change has now been merged to master. >>>> Fedora had already built pre9.1. But on the off chance, I will look >>>> at >>>> it with tomorrow's build. >>> I'm sorry but no, I am not updating Fedora with current git tree >>> checkout. You'll have to wait for the next prerelease or the final >>> version if there are no further prereleases. >> Tomas, >> >> Thanks for responding here. >> >> I have been preparing an Internet Draft on how to build an ED25519 pki. >> I know have the choice of: >> >> building my own 1.1.1 pre9 for testing. >> Wait to push the draft out until 1.1.1 is fully released. >> Fudge the draft by adding yet another caveat (yes there is a caveat >> section that I developed in creating the ECDSA pki draft) that the >> commands are for how it is suppose to work in production 1.1.1, not what >> I had to do in the prerelease. >> >> Decisions decisions. Thing is I want the draft out so I can push for >> EDDSA support in IEEE 802.1AR with the next meeting early Sept. > I'm not sure if providing command line examples for one particular tool are a > good idea... > > Example certificates, sure, but not commands to generate them... > "We can't test out the security part of the protocol because we cannot get certificates" "We ran our tests with security disable because we could not afford the cost and time for a test pki." "We did test with RSA certificates from vendor A." (and they were using old libs that would not support ecdsa, but marketed it as such.)" Over the years and in protocol design development, I have heard too many we can't.? So I set about with, "here is one way."? Since then I have had a few people actually thank me for making it possible for them to build an ecdsa pki for their product testing needs.? Just one justifies my effort. If my making EDDSA certs easy for testing and I get one IoT product using certs that would otherwise claim that their product could not support the overhead of certs, it has been worth it. I don't expect RFCs? from these draft.? Now Internet Drafts live forever (the drafts Yakov and I did for RFC 1597 are gone).? So my work will be around for others to use without a lot of pecking at google and this list to get it working. And with eddsa, I did find one issue.? I was on the front side of things for a change. From hkario at redhat.com Mon Aug 27 20:07:55 2018 From: hkario at redhat.com (Hubert Kario) Date: Mon, 27 Aug 2018 22:07:55 +0200 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: References: <20180821123602.GA29908@openssl.org> <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> Message-ID: <5887097.POWF1JhDzr@pintsize.usersys.redhat.com> On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: > On 08/27/2018 02:33 PM, Hubert Kario wrote: > > On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > >> On 08/23/2018 09:00 AM, Tomas Mraz wrote: > >>> On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: > >>>> On 08/22/2018 11:48 AM, Matt Caswell wrote: > >>>>> On 22/08/18 00:53, Robert Moskowitz wrote: > >>>>>> On 08/21/2018 06:31 PM, Matt Caswell wrote: > >>>>>>> On 21/08/18 16:24, Robert Moskowitz wrote: > >>>>>>>> Thanks! > >>>>>>>> > >>>>>>>> Once Fedora beta picks this up, I will run my scripts against > >>>>>>>> it and see > >>>>>>>> if all cases of hash with ED25519 are fixed. > >>>>>>> > >>>>>>> Unfortunately the command line usability changes for this > >>>>>>> didn't make it > >>>>>>> into the beta. They should still be in the final release. > >>>>>> > >>>>>> Sigh. That means you will get it right. Right? :) > >>>>>> > >>>>>> Change seems simple enough. > >>>>> > >>>>> The relevant change has now been merged to master. > >>>> > >>>> Fedora had already built pre9.1. But on the off chance, I will look > >>>> at > >>>> it with tomorrow's build. > >>> > >>> I'm sorry but no, I am not updating Fedora with current git tree > >>> checkout. You'll have to wait for the next prerelease or the final > >>> version if there are no further prereleases. > >> > >> Tomas, > >> > >> Thanks for responding here. > >> > >> I have been preparing an Internet Draft on how to build an ED25519 pki. > >> I know have the choice of: > >> > >> building my own 1.1.1 pre9 for testing. > >> Wait to push the draft out until 1.1.1 is fully released. > >> Fudge the draft by adding yet another caveat (yes there is a caveat > >> section that I developed in creating the ECDSA pki draft) that the > >> commands are for how it is suppose to work in production 1.1.1, not what > >> I had to do in the prerelease. > >> > >> Decisions decisions. Thing is I want the draft out so I can push for > >> EDDSA support in IEEE 802.1AR with the next meeting early Sept. > > > > I'm not sure if providing command line examples for one particular tool > > are a good idea... > > > > Example certificates, sure, but not commands to generate them... > > "We can't test out the security part of the protocol because we cannot > get certificates" > "We ran our tests with security disable because we could not afford the > cost and time for a test pki." > "We did test with RSA certificates from vendor A." (and they were using > old libs that would not support ecdsa, but marketed it as such.)" > > Over the years and in protocol design development, I have heard too many > we can't. So I set about with, "here is one way." Since then I have > had a few people actually thank me for making it possible for them to > build an ecdsa pki for their product testing needs. Just one justifies > my effort. well, I see nothing wrong with providing documentation and how-to's, I just don't see that it should be elevated to an Internet Draft level... by its very nature it needs to be constantly updated, so having it in a static RFC is contrary to that now, for generating testing certificates (and what's more important, the whole PKI) we are using this script to provide sensible defaults and easy way to generate certificates with just few options departing from those defaults: https://github.com/redhat-qe-security/certgen to get a PKI you run those commands: source certgen/lib.sh x509KeyGen ca x509KeyGen server x509SelfSign ca x509CertSign --CA ca server The private key file will be printed by use of: x509Key server to get certificate file name you run: x509Cert server (easy switches are also provided to get DER files or PKCS#12 files instead of the default PEM format) to get ecdsa certificate, you just need to change one of the above lines with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do `-t rsa-pss`. See runtest.sh for other examples. It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if a given feature is supported in that version of openssl. (while ed25519 support is not yet there, it will be in few weeks, I was running just basic tests of it, without involving full PKI) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From rgm at htt-consult.com Mon Aug 27 20:38:24 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 27 Aug 2018 16:38:24 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <5887097.POWF1JhDzr@pintsize.usersys.redhat.com> References: <20180821123602.GA29908@openssl.org> <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> <5887097.POWF1JhDzr@pintsize.usersys.redhat.com> Message-ID: <1888cdb2-a1ca-a9ba-06d7-b576472fd6d6@htt-consult.com> On 08/27/2018 04:07 PM, Hubert Kario wrote: > On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: >> On 08/27/2018 02:33 PM, Hubert Kario wrote: >>> On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: >>>> On 08/23/2018 09:00 AM, Tomas Mraz wrote: >>>>> On Wed, 2018-08-22 at 20:08 -0400, Robert Moskowitz wrote: >>>>>> On 08/22/2018 11:48 AM, Matt Caswell wrote: >>>>>>> On 22/08/18 00:53, Robert Moskowitz wrote: >>>>>>>> On 08/21/2018 06:31 PM, Matt Caswell wrote: >>>>>>>>> On 21/08/18 16:24, Robert Moskowitz wrote: >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Once Fedora beta picks this up, I will run my scripts against >>>>>>>>>> it and see >>>>>>>>>> if all cases of hash with ED25519 are fixed. >>>>>>>>> Unfortunately the command line usability changes for this >>>>>>>>> didn't make it >>>>>>>>> into the beta. They should still be in the final release. >>>>>>>> Sigh. That means you will get it right. Right? :) >>>>>>>> >>>>>>>> Change seems simple enough. >>>>>>> The relevant change has now been merged to master. >>>>>> Fedora had already built pre9.1. But on the off chance, I will look >>>>>> at >>>>>> it with tomorrow's build. >>>>> I'm sorry but no, I am not updating Fedora with current git tree >>>>> checkout. You'll have to wait for the next prerelease or the final >>>>> version if there are no further prereleases. >>>> Tomas, >>>> >>>> Thanks for responding here. >>>> >>>> I have been preparing an Internet Draft on how to build an ED25519 pki. >>>> I know have the choice of: >>>> >>>> building my own 1.1.1 pre9 for testing. >>>> Wait to push the draft out until 1.1.1 is fully released. >>>> Fudge the draft by adding yet another caveat (yes there is a caveat >>>> section that I developed in creating the ECDSA pki draft) that the >>>> commands are for how it is suppose to work in production 1.1.1, not what >>>> I had to do in the prerelease. >>>> >>>> Decisions decisions. Thing is I want the draft out so I can push for >>>> EDDSA support in IEEE 802.1AR with the next meeting early Sept. >>> I'm not sure if providing command line examples for one particular tool >>> are a good idea... >>> >>> Example certificates, sure, but not commands to generate them... >> "We can't test out the security part of the protocol because we cannot >> get certificates" >> "We ran our tests with security disable because we could not afford the >> cost and time for a test pki." >> "We did test with RSA certificates from vendor A." (and they were using >> old libs that would not support ecdsa, but marketed it as such.)" >> >> Over the years and in protocol design development, I have heard too many >> we can't. So I set about with, "here is one way." Since then I have >> had a few people actually thank me for making it possible for them to >> build an ecdsa pki for their product testing needs. Just one justifies >> my effort. > well, I see nothing wrong with providing documentation and how-to's, I just > don't see that it should be elevated to an Internet Draft level... > > by its very nature it needs to be constantly updated, so having it in a static > RFC is contrary to that that is the value of Internet Drafts that many of us IETFers have figured out.? draft versions can just keep on going and the tools will take you to the current draft.? IDs have become neat working documents, though there is more github work coming along.? More workgroups are doing requirements docs that will never be published as RFCs; they will stay as IDs.? Much better source of why did the wg do? than plow through the old mailing list archives.? The IESG is actually encouraging such a use of IDs. > now, for generating testing certificates (and what's more important, the whole > PKI) we are using this script to provide sensible defaults and easy way to > generate certificates with just few options departing from those defaults: > https://github.com/redhat-qe-security/certgen I will take a look at this.? It did not come up in my google searches a year ago.? Guess just not asking the right question or github is protected from google... > to get a PKI you run those commands: > source certgen/lib.sh > x509KeyGen ca > x509KeyGen server > x509SelfSign ca > x509CertSign --CA ca server > > The private key file will be printed by use of: > x509Key server > to get certificate file name you run: > x509Cert server In testing situations I have been in, intermediate CAs, revocation, the like are needed. Plus getting more interest in 802.1AR certs with vendors (can't get certs to test out my product design). > (easy switches are also provided to get DER files or PKCS#12 files instead of > the default PEM format) I will be interested to see how you handle DER, as I found cases where the command line was broken.? Read my caveat section.? In some cases you have to make the file in PEM then convert to DER.? Plus there is no DER way to handle cert chains as was discussed here a year ago.? So I will be interested to see how you handle cert chains non-PEM. > to get ecdsa certificate, you just need to change one of the above lines > with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do `-t > rsa-pss`. > > See runtest.sh for other examples. I will take a look. > It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if a > given feature is supported in that version of openssl. > > (while ed25519 support is not yet there, it will be in few weeks, I was > running just basic tests of it, without involving full PKI) Nice.? See https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki I am right now adding an algorithm variable to support ed488. This actually does not work right with 1.1.1-pre9, as PR 6901 did not make that build, so I have to do my command and .cnf patches still.? If I publish prior to 9/11 (2nd day of Rosh Hashana, so I won't be doing any work the beginning of next week), I will have to include text (that a later draft version will remove) about this caveat.? Given what I have to do this week, I will probably not publish until middle of next week.? IEEE 802.1 will be meeting in Oslo, so I will be working remotely to get a PAR going to rev 802.1AR to support EDDSA based on my work.? Now there is a standards org that has real challenges with advances like this.? 802.1AR-2018 only supports RSA and ECDSA p256 and p384. From bkaduk at akamai.com Mon Aug 27 20:55:31 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 27 Aug 2018 15:55:31 -0500 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <1888cdb2-a1ca-a9ba-06d7-b576472fd6d6@htt-consult.com> References: <20180821123602.GA29908@openssl.org> <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> <5887097.POWF1JhDzr@pintsize.usersys.redhat.com> <1888cdb2-a1ca-a9ba-06d7-b576472fd6d6@htt-consult.com> Message-ID: <20180827205531.GO5819@akamai.com> On Mon, Aug 27, 2018 at 04:38:24PM -0400, Robert Moskowitz wrote: > > > On 08/27/2018 04:07 PM, Hubert Kario wrote: > >On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: > >>On 08/27/2018 02:33 PM, Hubert Kario wrote: > >>>On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: > >> > >>Over the years and in protocol design development, I have heard too many > >>we can't. So I set about with, "here is one way." Since then I have > >>had a few people actually thank me for making it possible for them to > >>build an ecdsa pki for their product testing needs. Just one justifies > >>my effort. > >well, I see nothing wrong with providing documentation and how-to's, I just > >don't see that it should be elevated to an Internet Draft level... Well, see https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/ . > >by its very nature it needs to be constantly updated, so having it in a static > >RFC is contrary to that > > that is the value of Internet Drafts that many of us IETFers have figured > out.? draft versions can just keep on going and the tools will take you to > the current draft.? IDs have become neat working documents, though there is > more github work coming along.? More workgroups are doing requirements docs > that will never be published as RFCs; they will stay as IDs.? Much better > source of why did the wg do? than plow through the old mailing list > archives.? The IESG is actually encouraging such a use of IDs. Yup! Internet-Draft is a fine terminus for some types of document. Many TLS registries now have a registration policy that explicitly calls out an internet-draft that is never published as anything else, as a valid specification for getting a codepoint assignment. -Ben From rgm at htt-consult.com Mon Aug 27 21:14:08 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 27 Aug 2018 17:14:08 -0400 Subject: [openssl-users] OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <20180827205531.GO5819@akamai.com> References: <20180821123602.GA29908@openssl.org> <1902260.uyPTuYLMlB@pintsize.usersys.redhat.com> <5887097.POWF1JhDzr@pintsize.usersys.redhat.com> <1888cdb2-a1ca-a9ba-06d7-b576472fd6d6@htt-consult.com> <20180827205531.GO5819@akamai.com> Message-ID: On 08/27/2018 04:55 PM, Benjamin Kaduk via openssl-users wrote: > On Mon, Aug 27, 2018 at 04:38:24PM -0400, Robert Moskowitz wrote: >> >> On 08/27/2018 04:07 PM, Hubert Kario wrote: >>> On Monday, 27 August 2018 20:57:53 CEST Robert Moskowitz wrote: >>>> On 08/27/2018 02:33 PM, Hubert Kario wrote: >>>>> On Thursday, 23 August 2018 16:35:01 CEST Robert Moskowitz wrote: >>>> Over the years and in protocol design development, I have heard too many >>>> we can't. So I set about with, "here is one way." Since then I have >>>> had a few people actually thank me for making it possible for them to >>>> build an ecdsa pki for their product testing needs. Just one justifies >>>> my effort. >>> well, I see nothing wrong with providing documentation and how-to's, I just >>> don't see that it should be elevated to an Internet Draft level... > Well, see https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/ . Warren is a riot.? I really should have put in a typo comment to him about 'safely razor' which probably should be 'safety razor'.? But then kind of knowing Warren, this could have been intentional so I left it alone. :) > >>> by its very nature it needs to be constantly updated, so having it in a static >>> RFC is contrary to that >> that is the value of Internet Drafts that many of us IETFers have figured >> out.? draft versions can just keep on going and the tools will take you to >> the current draft.? IDs have become neat working documents, though there is >> more github work coming along.? More workgroups are doing requirements docs >> that will never be published as RFCs; they will stay as IDs.? Much better >> source of why did the wg do? than plow through the old mailing list >> archives.? The IESG is actually encouraging such a use of IDs. > Yup! Internet-Draft is a fine terminus for some types of document. > Many TLS registries now have a registration policy that explicitly calls out > an internet-draft that is never published as anything else, as a valid specification > for getting a codepoint assignment. > > -Ben From hkario at redhat.com Mon Aug 27 22:17:58 2018 From: hkario at redhat.com (Hubert Kario) Date: Tue, 28 Aug 2018 00:17:58 +0200 Subject: [openssl-users] Wrapper script for creating PKI with openssl Was: OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <1888cdb2-a1ca-a9ba-06d7-b576472fd6d6@htt-consult.com> References: <20180821123602.GA29908@openssl.org> <5887097.POWF1JhDzr@pintsize.usersys.redhat.com> <1888cdb2-a1ca-a9ba-06d7-b576472fd6d6@htt-consult.com> Message-ID: <1719876.rvBO8iizTT@pintsize.usersys.redhat.com> Changing Subject to help googlability :) On Monday, 27 August 2018 22:38:24 CEST Robert Moskowitz wrote: > On 08/27/2018 04:07 PM, Hubert Kario wrote: > > now, for generating testing certificates (and what's more important, the > > whole PKI) we are using this script to provide sensible defaults and easy > > way to generate certificates with just few options departing from those > > defaults: https://github.com/redhat-qe-security/certgen > > I will take a look at this. It did not come up in my google searches a > year ago. Guess just not asking the right question or github is > protected from google... definitely isn't; most of the visits on my other repos come from google (if github stats are to be believed) likely because similar scripts are not uncommon (e.g. OpenVPN ships with something similar) and this one is hardly well known, so it got delegated to "2nd page" > > to get a PKI you run those commands: > > source certgen/lib.sh > > x509KeyGen ca > > x509KeyGen server > > x509SelfSign ca > > x509CertSign --CA ca server > > > > The private key file will be printed by use of: > > x509Key server > > to get certificate file name you run: > > x509Cert server > > In testing situations I have been in, intermediate CAs, revocation, the > like are needed. it allows you to create arbitrarily complex CA structure, this is just the simplest example; there is also support for generating client certificates, OCSP reponder certificates, subject alternative names, etc. to get an intermediate you have to run the following commands: x509KeyGen subca x509CertSign --CA ca -t CA subca" the you can use 'subca' instead of 'ca' for signing the server cert: x509CertSign --CA subca server (the -t of 'webserver' is simply the default) revocation is not implemented yet, but as the tool keeps all the information about CA's signed certificates (it does use internally the `openssl ca` tool), adding it shouldn't be too hard... (and you can always do it manually) > Plus getting more interest in 802.1AR certs with vendors (can't get > certs to test out my product design). that I'm not familiar with > > (easy switches are also provided to get DER files or PKCS#12 files instead > > of the default PEM format) > > I will be interested to see how you handle DER, as I found cases where > the command line was broken. Read my caveat section. In some cases you > have to make the file in PEM then convert to DER. Plus there is no DER > way to handle cert chains as was discussed here a year ago. So I will > be interested to see how you handle cert chains non-PEM. The scripts internally keep everything as PEM files; DER, PKCS#12, etc. are for export only. If you want cert chains you have to create them manually. As I started to work on this script for the CA cross-signing, the built-in assumption was that there is no One True Cert Chain?. So it considers all CAs as stand-alone. If you want a cert chain you have to assemble it yourself. > > to get ecdsa certificate, you just need to change one of the above lines > > with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS certificate? do > > `-t rsa-pss`. > > > > See runtest.sh for other examples. > > I will take a look. Limited time offer! Call now and get Ed25519 support completely free! ;) https://github.com/redhat-qe-security/certgen/commit/ 4b71e0a7d77929d944cc20f16f2ccf9514d6d94d > > It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), if > > a > > given feature is supported in that version of openssl. > > > > (while ed25519 support is not yet there, it will be in few weeks, I was > > running just basic tests of it, without involving full PKI) > > Nice. See https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki > > I am right now adding an algorithm variable to support ed488. > > This actually does not work right with 1.1.1-pre9, as PR 6901 did not > make that build, so I have to do my command and .cnf patches still. yes, there are quite a few warts you need to worry about when working with different versions of OpenSSL, then there is the problem of updating it as recommended key sizes or hashes change... reading that draft feels like reading a heavily commented script ? not a criticism, rather observation about the problem at hand -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From lintamaria194 at gmail.com Tue Aug 28 11:08:36 2018 From: lintamaria194 at gmail.com (Linta Maria) Date: Tue, 28 Aug 2018 16:38:36 +0530 Subject: [openssl-users] Openssl api for signature verification using digest Message-ID: Hi All, I have started using open ssl recently for implementing some cryptographic operation. Now I want to implement signature verification by taking Signature and hashed data as input, but I am not able to get the proper API. I have used below code, but it?s not working. Please help me to get the correct API. #include #include EVP_PKEY_CTX *ctx; unsigned char *md, *sig; size_t mdlen, siglen; EVP_PKEY *verify_key; /* * NB: assumes verify_key, sig, siglen md and mdlen are already set up * and that verify_key is an RSA public key */ ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); if (!ctx) /* Error occurred */ if (EVP_PKEY_verify_init(ctx) <= 0) /* Error */ if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) /* Error */ if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) /* Error */ /* Perform operation */ ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); /* * ret == 1 indicates success, 0 verify failure and < 0 for some * other error. */ Best regards, *George Linta Maria* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Tue Aug 28 11:47:34 2018 From: nic.tuv at gmail.com (Nicola) Date: Tue, 28 Aug 2018 14:47:34 +0300 Subject: [openssl-users] Openssl api for signature verification using digest In-Reply-To: References: Message-ID: Hi! I would suggest using the newer `EVP_DigestSign` interface. You could find more documentation about it here: https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying Here is the relevant manpage: https://www.openssl.org/docs/man1.1.1/man3/EVP_DigestVerifyInit.html Best regards, Nicola Tuveri On Tue, Aug 28, 2018, 14:09 Linta Maria wrote: > > > Hi All, > > > > > > I have started using open ssl recently for implementing some cryptographic > operation. > > Now I want to implement signature verification by taking Signature and > hashed data as input, but I am not able to get the proper API. > > I have used below code, but it?s not working. Please help me to get the > correct API. > > > > > > #include > > #include > > > > EVP_PKEY_CTX *ctx; > > unsigned char *md, *sig; > > size_t mdlen, siglen; > > EVP_PKEY *verify_key; > > > > /* > > * NB: assumes verify_key, sig, siglen md and mdlen are already set up > > * and that verify_key is an RSA public key > > */ > > ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); > > if (!ctx) > > /* Error occurred */ > > if (EVP_PKEY_verify_init(ctx) <= 0) > > /* Error */ > > if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) > > /* Error */ > > if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) > > /* Error */ > > > > /* Perform operation */ > > ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); > > > > /* > > * ret == 1 indicates success, 0 verify failure and < 0 for some > > * other error. > > */ > > > > > > > > Best regards, > > *George Linta Maria* > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lintamaria194 at gmail.com Tue Aug 28 14:06:29 2018 From: lintamaria194 at gmail.com (Linta Maria) Date: Tue, 28 Aug 2018 19:36:29 +0530 Subject: [openssl-users] Openssl api for signature verification using digest In-Reply-To: References: Message-ID: Thanks Nicola for the updates. But I need to verify signature with hashed data or digest not with original message. Is there any openssl API to implement that? On Tue 28 Aug, 2018, 5:18 PM Nicola, wrote: > Hi! > > I would suggest using the newer `EVP_DigestSign` interface. > > You could find more documentation about it here: > https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying > > Here is the relevant manpage: > https://www.openssl.org/docs/man1.1.1/man3/EVP_DigestVerifyInit.html > > Best regards, > > Nicola Tuveri > > On Tue, Aug 28, 2018, 14:09 Linta Maria wrote: > >> >> >> Hi All, >> >> >> >> >> >> I have started using open ssl recently for implementing some >> cryptographic operation. >> >> Now I want to implement signature verification by taking Signature and >> hashed data as input, but I am not able to get the proper API. >> >> I have used below code, but it?s not working. Please help me to get the >> correct API. >> >> >> >> >> >> #include >> >> #include >> >> >> >> EVP_PKEY_CTX *ctx; >> >> unsigned char *md, *sig; >> >> size_t mdlen, siglen; >> >> EVP_PKEY *verify_key; >> >> >> >> /* >> >> * NB: assumes verify_key, sig, siglen md and mdlen are already set up >> >> * and that verify_key is an RSA public key >> >> */ >> >> ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); >> >> if (!ctx) >> >> /* Error occurred */ >> >> if (EVP_PKEY_verify_init(ctx) <= 0) >> >> /* Error */ >> >> if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) >> >> /* Error */ >> >> if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) >> >> /* Error */ >> >> >> >> /* Perform operation */ >> >> ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); >> >> >> >> /* >> >> * ret == 1 indicates success, 0 verify failure and < 0 for some >> >> * other error. >> >> */ >> >> >> >> >> >> >> >> Best regards, >> >> *George Linta Maria* >> -- >> 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 openssl-users at dukhovni.org Tue Aug 28 15:37:33 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Aug 2018 11:37:33 -0400 Subject: [openssl-users] Openssl api for signature verification using digest In-Reply-To: References: Message-ID: [ Please post plain text, not HTML ] > On Aug 28, 2018, at 7:08 AM, Linta Maria wrote: > > I have used below code, but it?s not working. Please help me to get the correct API. > > /* > * NB: assumes verify_key, sig, siglen md and mdlen are already set up > * and that verify_key is an RSA public key > */ In what form is the message digest? Is it the raw digest octets, or some hex or base64 encoding? In what form is the signature? > ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); > if (!ctx) > /* Error occurred */ > > if (EVP_PKEY_verify_init(ctx) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) > /* Error */ Since you're verifying a hash, do not configure a message digest. > /* Perform operation */ > > ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); This is the right function for verifying public key signatures over some input. For more help, post the *public* key used, the signature and the input digest. You can find similar code in the source code of the rsautl and pkeyutl commands. -- Viktor. From tshort at akamai.com Tue Aug 28 19:27:37 2018 From: tshort at akamai.com (Short, Todd) Date: Tue, 28 Aug 2018 19:27:37 +0000 Subject: [openssl-users] Backup of existing ssl connection In-Reply-To: References: Message-ID: <9960DDE9-54EB-441E-9B63-E7F618854616@akamai.com> Agreed, Iooked at this when creating a failover service, and trying to replicate all the TCP and TLS data ended up using significant CPU processing and network bandwidth that it wasn?t worth it; in addition to intrusive OpenSSL changes. You should try to have a way to detect and re-establish a failed connection; it?s significantly easier to do, and requires no modification of the OpenSSL code. Alternatively, having two simultaneous connections might work out. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 23, 2018, at 8:36 AM, Salz, Rich via openssl-users > wrote: >I want to take backup of existing ssl connection. Use this backup connection in other slave board. This backup include keys and sequence no, ssl version etc. >Is Openssl support any api to take backup of existing ssl connection? No. This is not currently possible, and is unlikely to ever happen in OpenSSL. It?s too hard. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Tue Aug 28 19:31:31 2018 From: tshort at akamai.com (Short, Todd) Date: Tue, 28 Aug 2018 19:31:31 +0000 Subject: [openssl-users] Regarding Openssl 1.0.2p bn changes In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/commit/327b2c01 -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 24, 2018, at 12:18 AM, Manish Patidar > wrote: Hi, I have doubt regarding the bn change in Openssl version 1.0.2p. There is new flag introduced BN_FLG_FIXED_TOP, value of this flag is zero untill BN_DEBUG is defined. By default BN_DEBUG is not defined. So what is the purpose of this flag.? Regards Mwnish -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lintamaria194 at gmail.com Wed Aug 29 05:05:00 2018 From: lintamaria194 at gmail.com (Linta Maria) Date: Wed, 29 Aug 2018 10:35:00 +0530 Subject: [openssl-users] Openssl api for signature verification using digest Message-ID: Thanks Viktor for the help?. Please find below the input format. Still its not working. > On Aug 28, 2018, at 7:08 AM, Linta Maria wrote: > > I have used below code, but it?s not working. Please help me to get the correct API. > > /* > * NB: assumes verify_key, sig, siglen md and mdlen are already set up > * and that verify_key is an RSA public key > */ In what form is the message digest? Is it the raw digest octets, or some hex or base64 encoding? In what form is the signature? Message digest and signature is given in hex format. Msg ={ 0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} PublicKey- In evp_pkey format ----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf 5QIDAQAB -----END PUBLIC KEY----- > ctx = EVP_PKEY_CTX_new(verify_key, NULL /* no engine */); > if (!ctx) > /* Error occurred */ > > if (EVP_PKEY_verify_init(ctx) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_rsa_padding(ctx, RSA_PKCS1_PADDING) <= 0) > /* Error */ > > if (EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) > /* Error */ Since you're verifying a hash, do not configure a message digest. > /* Perform operation */ > > ret = EVP_PKEY_verify(ctx, sig, siglen, md, mdlen); This is the right function for verifying public key signatures over some input. For more help, post the *public* key used, the signature and the input digest. Message digest and signature is given in hex format. Msg ={ 0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} PublicKey- In evp_pkey format ----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf 5QIDAQAB -----END PUBLIC KEY----- You can find similar code in the source code of the rsautl and pkeyutl commands. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Aug 29 06:00:07 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Aug 2018 02:00:07 -0400 Subject: [openssl-users] Openssl api for signature verification using digest In-Reply-To: References: Message-ID: <2C83585A-D006-45C2-AECA-88DBC7785683@dukhovni.org> > On Aug 29, 2018, at 1:05 AM, Linta Maria wrote: > > Still its not working. The code is working correctly. The real problem is that the PEM format 2048-bit RSA key you posted: > ----BEGIN PUBLIC KEY----- > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH > FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji > bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK > yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq > lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN > 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf > 5QIDAQAB > -----END PUBLIC KEY----- is NOT the key that was used to generate the below signature, or the signature was subsequently altered. > Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} $ od -tx1 < /tmp/sig 0000000 24 b8 ec b4 4f 31 a6 08 72 61 c9 d3 1c d0 9b ee 0000020 26 2d 3d ef ff 2c 05 78 04 d3 a3 ff dc 97 53 e6 0000040 6e 85 41 1b b2 2c ed bd a6 5d 6f ac bb d5 b8 a0 0000060 09 2b f1 f5 b6 ce dd 70 8a 1a a1 20 11 2b f0 17 0000100 41 83 80 f6 61 d4 6d 53 8f f1 8c 19 42 93 96 a9 0000120 b6 f2 8f 27 9c 66 17 c5 ca 3d a9 3f c5 76 5f 1b 0000140 31 f2 d3 0e 78 53 97 cb 9d c4 e6 41 61 58 44 5c 0000160 f5 c4 67 69 08 0a 92 d5 7e 9c b9 7e 54 8b 8a 0b 0000200 a1 9a 63 bf cc ed 63 2c f8 14 25 06 a2 02 00 07 0000220 2e 1c c1 eb 16 89 aa 69 e2 75 57 39 71 68 0e 0f 0000240 a4 7a c5 14 97 88 67 d1 36 91 3b 49 e7 b4 f3 cb 0000260 ca f6 e9 b1 22 e9 85 89 ab 02 04 3c 2e bd 56 03 0000300 8a 8b 54 c6 e6 ed 5b 4c a4 9e 1b aa 90 c6 0b 27 0000320 54 c0 50 5f 58 97 0c 99 5c 02 74 fc 9f 4c 78 4e 0000340 c3 b4 6d 14 a1 dc 62 c5 fe 27 b8 7d 98 79 82 50 0000360 3a be 6f 83 79 0d 8a b8 3e ac 0a eb 62 d5 5e 95 $ openssl rsa -pubin -in /tmp/key writing RSA key -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf 5QIDAQAB -----END PUBLIC KEY----- Which match your post, but raw public key encryption of the signature data does not yield a PKCS1 padded message: $ openssl rsautl -encrypt -pubin -inkey /tmp/key -raw -in /tmp/sig | od -tx1 0000000 95 ca 3c b7 cf d3 19 3d 1d 4a 29 61 67 59 21 d1 0000020 61 47 9f 09 69 23 cc 05 77 21 e6 5c 12 9b ed 39 0000040 06 7c 23 51 5f e3 3f 48 45 df 41 89 2e d6 92 4a 0000060 bd b2 e8 36 e6 83 2a 1e 71 5e 5b 97 52 f2 bc 18 0000100 63 3b 45 e0 c1 0a ec 48 ae 42 a3 e5 46 dc 80 77 0000120 87 19 a0 29 94 e7 33 2a 77 2b bb 54 39 06 92 ca 0000140 df b2 21 04 98 d7 cb 16 a6 a0 5b ac c3 d8 20 df 0000160 ac 8f 3a 6d b9 20 7c cb 52 5e 7f f8 69 fc 39 7f 0000200 8b db c1 16 4c df ca ba d7 33 5f 8e 21 87 6b ae 0000220 a8 e1 20 1b e5 1f 8c 3f 18 2d b4 c0 0d 66 ec 1e 0000240 f2 7b 78 ab ad 3c 8c da 80 24 25 3d c8 19 ad 48 0000260 b3 21 ca 90 40 ce dd 22 85 6d 8b 6f ed da 77 be 0000300 81 02 d3 d5 5a ec fd 9f 6e 4a 52 f1 18 31 d4 e1 0000320 14 43 17 02 ff 74 f8 ee cf 2c 09 bc 60 d8 65 e3 0000340 3c c2 e1 a9 09 5e 21 42 d2 0f 4f aa d5 75 47 69 0000360 51 f0 87 98 bd 7f 99 83 e1 22 33 56 0b 13 8e 37 0000400 By way of contrast: $ openssl genrsa -out /tmp/key2.pem 2048 2>/dev/null $ echo foobar | openssl dgst -sha256 -sign /tmp/key2.pem -out /tmp/sig2 $ openssl rsa -in /tmp/key2.pem -pubout > /tmp/pub2.pem 2>/dev/null $ openssl rsautl -encrypt -pubin -inkey /tmp/pub2.pem -raw -in /tmp/sig2 | od -vtx1 0000000 00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000120 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000220 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000240 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000260 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000300 ff ff ff ff ff ff ff ff ff ff ff ff 00 30 31 30 0000320 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 0000340 ae c0 70 64 5f e5 3e e3 b3 76 30 59 37 61 34 f0 0000360 58 cc 33 72 47 c9 78 ad d1 78 b6 cc df b0 01 9f 0000400 Above you see that using the same key for a raw public encrypt as was used for signing, yields content that is PKCS1-padded as expected. -- Viktor. From lintamaria194 at gmail.com Wed Aug 29 09:53:27 2018 From: lintamaria194 at gmail.com (Linta Maria) Date: Wed, 29 Aug 2018 15:23:27 +0530 Subject: [openssl-users] Fwd: Openssl api for signature verification using digest In-Reply-To: References: Message-ID: Hi Viktor, As you suggested, signature wasn't correct. With below input also it's not working. Pubkey is read to evp_PKEY format EVP_PKEY * vkey; char PubKey [] ="-----BEGIN PUBLIC KEY-----""\n" "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxEZo8DRHBFBN0w1YYw3w" "\n" "C/C/IxCH3WSDCBTZgPux+/Cm+Q+LtSHjxV2x+hHuR8+cWMgFIrpvN0jw1F6g0f3A" "\n" "QQvQmPkyIUZGN1C9Da+SEdpc12gZdAOdILUaeiDRNUYXJinbBPQaNGAQIWwuzCuj" "\n" "5sjZPrlJYDQ52kq2U86ZNcS/NVRZi+pFB4u0YHHiqJkQYT6yCQjR9Rdvxvjyg9L5" "\n" "9petX/xa0tBurw5eTLOC9UlufblJnS7zrVkpoHdtt9rRgDBJ4kTJypeHq0Tybgro" "\n" "hhxG1EqdAjoD0OjLV93JWr0DOmwWVE1SoJH/UBbgRXf40hxhdzswgJFWJLIdxfdj" "\n" "BwIDAQAB" "\n" "-----END PUBLIC KEY-----"; BIO *bio; bio = BIO_new_mem_buf(PubKey, strlen(PubKey) ); PEM_read_bio_PUBKEY( bio, &vkey, NULL, NULL ); unsigned char signew[]={0x14, 0x7e, 0x86, 0x9f, 0xfb, 0x10, 0xc8, 0xa4, 0x98, 0xae, 0xcb, 0xf8, 0xd4, 0xd7, 0xad, 0xf2, 0x18, 0x40, 0xaf, 0x06, 0x85, 0x8a, 0x69, 0xde, 0x29, 0x50, 0xf2, 0x52, 0x1c, 0x01, 0xbc, 0x3c, 0x45, 0x42, 0xb1, 0x32, 0xd8, 0x19, 0xf6, 0xf3, 0x11, 0x39, 0x03, 0xbf, 0x23, 0xfb, 0x5d, 0x97, 0x41, 0xb9, 0x85, 0xaf, 0x31, 0xf8, 0x32, 0x2f, 0xd2, 0xb6, 0x5b, 0xf1, 0x22, 0xfd, 0xda, 0x28, 0x58, 0x6f, 0x45, 0x4b, 0x5c, 0x74, 0xf0, 0x84, 0xf2, 0x1e, 0xfa, 0x33, 0xa3, 0x83, 0x38, 0x9f, 0xcf, 0x71, 0x37, 0x77, 0x6d, 0x86, 0x84, 0xc6, 0x5e, 0x3b, 0x71, 0xf5, 0x29, 0x2a, 0x43, 0xf4, 0x43, 0x38, 0x0a, 0x18, 0xf5, 0xbe, 0x6f, 0x03, 0xd3, 0x16, 0x79, 0x13, 0x89, 0x95, 0xb2, 0xd7, 0x27, 0xcf, 0xd4, 0x2b, 0x6b, 0xa1, 0xbd, 0xe3, 0x8e, 0xac, 0x24, 0x1b, 0xdd, 0x17, 0xf8, 0xe1, 0xf5, 0xb9, 0x5a, 0xd4, 0x97, 0xf4, 0xc3, 0xfc, 0x69, 0xc8, 0x40, 0x30, 0x76, 0x7d, 0x18, 0x7c, 0x58, 0x11, 0x3d, 0x78, 0x27, 0x41, 0xab, 0x1c, 0xd2, 0xd3, 0x5f, 0xe2, 0x94, 0xe1, 0x49, 0xba, 0x6b, 0xd7, 0xbe, 0x3a, 0x9d, 0x86, 0x62, 0xdc, 0xd7, 0x46, 0xae, 0xa3, 0x8e, 0xe1, 0x46, 0x27, 0xbc, 0xb2, 0x31, 0x69, 0xc5, 0x54, 0x15, 0x85,0x74, 0x1a, 0x66, 0x94, 0xa6, 0x68, 0x5e, 0xa2,0x1c, 0x38, 0x3d, 0x84, 0xd8, 0x3f, 0x84, 0x81,0x56, 0xc2, 0x9c, 0xac, 0xef, 0x68, 0xef, 0x68,0x96, 0xb3, 0xd1, 0xa9, 0x3a, 0x43, 0x75, 0xef,0xaf, 0xf2, 0x1b, 0xea, 0x96, 0xb8, 0x23, 0xef,0xa6, 0x09, 0x89, 0x15, 0x52, 0x26, 0xce, 0x1f,0x98, 0x02, 0x83, 0x22, 0x08, 0x60, 0x6c, 0xd9,0x14, 0x64, 0xe8, 0xef, 0x53, 0xea, 0x48, 0x60,0xbb, 0x69, 0x49, 0x64, 0xa3, 0x0d, 0xdb, 0xaa}; unsigned char hashnew[]={0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; ---------- Forwarded message --------- From: *Viktor Dukhovni* Date: Wed 29 Aug, 2018, 11:30 AM Subject: Re: [openssl-users] Openssl api for signature verification using digest To: openssl-users at openssl.org > On Aug 29, 2018, at 1:05 AM, Linta Maria wrote: > > Still its not working. The code is working correctly. The real problem is that the PEM format 2048-bit RSA key you posted: > ----BEGIN PUBLIC KEY----- > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH > FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji > bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK > yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq > lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN > 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf > 5QIDAQAB > -----END PUBLIC KEY----- is NOT the key that was used to generate the below signature, or the signature was subsequently altered. > Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0 xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} $ od -tx1 < /tmp/sig 0000000 24 b8 ec b4 4f 31 a6 08 72 61 c9 d3 1c d0 9b ee 0000020 26 2d 3d ef ff 2c 05 78 04 d3 a3 ff dc 97 53 e6 0000040 6e 85 41 1b b2 2c ed bd a6 5d 6f ac bb d5 b8 a0 0000060 09 2b f1 f5 b6 ce dd 70 8a 1a a1 20 11 2b f0 17 0000100 41 83 80 f6 61 d4 6d 53 8f f1 8c 19 42 93 96 a9 0000120 b6 f2 8f 27 9c 66 17 c5 ca 3d a9 3f c5 76 5f 1b 0000140 31 f2 d3 0e 78 53 97 cb 9d c4 e6 41 61 58 44 5c 0000160 f5 c4 67 69 08 0a 92 d5 7e 9c b9 7e 54 8b 8a 0b 0000200 a1 9a 63 bf cc ed 63 2c f8 14 25 06 a2 02 00 07 0000220 2e 1c c1 eb 16 89 aa 69 e2 75 57 39 71 68 0e 0f 0000240 a4 7a c5 14 97 88 67 d1 36 91 3b 49 e7 b4 f3 cb 0000260 ca f6 e9 b1 22 e9 85 89 ab 02 04 3c 2e bd 56 03 0000300 8a 8b 54 c6 e6 ed 5b 4c a4 9e 1b aa 90 c6 0b 27 0000320 54 c0 50 5f 58 97 0c 99 5c 02 74 fc 9f 4c 78 4e 0000340 c3 b4 6d 14 a1 dc 62 c5 fe 27 b8 7d 98 79 82 50 0000360 3a be 6f 83 79 0d 8a b8 3e ac 0a eb 62 d5 5e 95 $ openssl rsa -pubin -in /tmp/key writing RSA key -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf 5QIDAQAB -----END PUBLIC KEY----- Which match your post, but raw public key encryption of the signature data does not yield a PKCS1 padded message: $ openssl rsautl -encrypt -pubin -inkey /tmp/key -raw -in /tmp/sig | od -tx1 0000000 95 ca 3c b7 cf d3 19 3d 1d 4a 29 61 67 59 21 d1 0000020 61 47 9f 09 69 23 cc 05 77 21 e6 5c 12 9b ed 39 0000040 06 7c 23 51 5f e3 3f 48 45 df 41 89 2e d6 92 4a 0000060 bd b2 e8 36 e6 83 2a 1e 71 5e 5b 97 52 f2 bc 18 0000100 63 3b 45 e0 c1 0a ec 48 ae 42 a3 e5 46 dc 80 77 0000120 87 19 a0 29 94 e7 33 2a 77 2b bb 54 39 06 92 ca 0000140 df b2 21 04 98 d7 cb 16 a6 a0 5b ac c3 d8 20 df 0000160 ac 8f 3a 6d b9 20 7c cb 52 5e 7f f8 69 fc 39 7f 0000200 8b db c1 16 4c df ca ba d7 33 5f 8e 21 87 6b ae 0000220 a8 e1 20 1b e5 1f 8c 3f 18 2d b4 c0 0d 66 ec 1e 0000240 f2 7b 78 ab ad 3c 8c da 80 24 25 3d c8 19 ad 48 0000260 b3 21 ca 90 40 ce dd 22 85 6d 8b 6f ed da 77 be 0000300 81 02 d3 d5 5a ec fd 9f 6e 4a 52 f1 18 31 d4 e1 0000320 14 43 17 02 ff 74 f8 ee cf 2c 09 bc 60 d8 65 e3 0000340 3c c2 e1 a9 09 5e 21 42 d2 0f 4f aa d5 75 47 69 0000360 51 f0 87 98 bd 7f 99 83 e1 22 33 56 0b 13 8e 37 0000400 By way of contrast: $ openssl genrsa -out /tmp/key2.pem 2048 2>/dev/null $ echo foobar | openssl dgst -sha256 -sign /tmp/key2.pem -out /tmp/sig2 $ openssl rsa -in /tmp/key2.pem -pubout > /tmp/pub2.pem 2>/dev/null $ openssl rsautl -encrypt -pubin -inkey /tmp/pub2.pem -raw -in /tmp/sig2 | od -vtx1 0000000 00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000120 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000220 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000240 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000260 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000300 ff ff ff ff ff ff ff ff ff ff ff ff 00 30 31 30 0000320 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 0000340 ae c0 70 64 5f e5 3e e3 b3 76 30 59 37 61 34 f0 0000360 58 cc 33 72 47 c9 78 ad d1 78 b6 cc df b0 01 9f 0000400 Above you see that using the same key for a raw public encrypt as was used for signing, yields content that is PKCS1-padded as expected. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgiles at coyotesong.com Wed Aug 29 12:49:52 2018 From: bgiles at coyotesong.com (Bear Giles) Date: Wed, 29 Aug 2018 06:49:52 -0600 Subject: [openssl-users] Wrapper script for creating PKI with openssl Was: OpenSSL version 1.1.1 pre release 9 published In-Reply-To: <1719876.rvBO8iizTT@pintsize.usersys.redhat.com> References: <20180821123602.GA29908@openssl.org> <5887097.POWF1JhDzr@pintsize.usersys.redhat.com> <1888cdb2-a1ca-a9ba-06d7-b576472fd6d6@htt-consult.com> <1719876.rvBO8iizTT@pintsize.usersys.redhat.com> Message-ID: This is a total aside but I prototyped a PostgreSQL extension that implemented the PKI infrastructure using OpenSSL. (The OpenSSL C API... shudder.) The database server already had it present, for SSL support, so I could piggyback on that and not worry about export restrictions since anyone that couldn't use OpenSSL couldn't run my extension either. It was a hobby project and I largely dropped it for various reasons. Some of it was specific to PostgreSQL (migrating away from OpenSSL) but a lot of it was because there was already enough "good enough" solutions that the perceived need had gone away. Many open source projects had documentation for EasyRSA, but now they have integrated support for LetsEncrypt. Anyway the point is that these type of projects have to be careful that they don't invent a better mousetrap in a world where nobody is looking for one. It's a fun project where you can learn a lot but it won't get much traction unless it's a totally new approach. The existing solutions may have flaws but most of the places where you need a CA already have documentation on how to use EasyRSA, if not outright integration with a solution. On Mon, Aug 27, 2018 at 4:18 PM Hubert Kario wrote: > Changing Subject to help googlability :) > > On Monday, 27 August 2018 22:38:24 CEST Robert Moskowitz wrote: > > On 08/27/2018 04:07 PM, Hubert Kario wrote: > > > now, for generating testing certificates (and what's more important, > the > > > whole PKI) we are using this script to provide sensible defaults and > easy > > > way to generate certificates with just few options departing from those > > > defaults: https://github.com/redhat-qe-security/certgen > > > > I will take a look at this. It did not come up in my google searches a > > year ago. Guess just not asking the right question or github is > > protected from google... > > definitely isn't; most of the visits on my other repos come from google > (if > github stats are to be believed) > > likely because similar scripts are not uncommon (e.g. OpenVPN ships with > something similar) and this one is hardly well known, so it got delegated > to > "2nd page" > > > > to get a PKI you run those commands: > > > source certgen/lib.sh > > > x509KeyGen ca > > > x509KeyGen server > > > x509SelfSign ca > > > x509CertSign --CA ca server > > > > > > The private key file will be printed by use of: > > > x509Key server > > > to get certificate file name you run: > > > x509Cert server > > > > In testing situations I have been in, intermediate CAs, revocation, the > > like are needed. > > it allows you to create arbitrarily complex CA structure, this is just the > simplest example; there is also support for generating client > certificates, > OCSP reponder certificates, subject alternative names, etc. > > to get an intermediate you have to run the following commands: > x509KeyGen subca > x509CertSign --CA ca -t CA subca" > > the you can use 'subca' instead of 'ca' for signing the server cert: > x509CertSign --CA subca server > > (the -t of 'webserver' is simply the default) > > revocation is not implemented yet, but as the tool keeps all the > information > about CA's signed certificates (it does use internally the `openssl ca` > tool), > adding it shouldn't be too hard... (and you can always do it manually) > > > Plus getting more interest in 802.1AR certs with vendors (can't get > > certs to test out my product design). > > that I'm not familiar with > > > > (easy switches are also provided to get DER files or PKCS#12 files > instead > > > of the default PEM format) > > > > I will be interested to see how you handle DER, as I found cases where > > the command line was broken. Read my caveat section. In some cases you > > have to make the file in PEM then convert to DER. Plus there is no DER > > way to handle cert chains as was discussed here a year ago. So I will > > be interested to see how you handle cert chains non-PEM. > > The scripts internally keep everything as PEM files; DER, PKCS#12, etc. > are > for export only. > > If you want cert chains you have to create them manually. As I started to > work > on this script for the CA cross-signing, the built-in assumption was that > there is no One True Cert Chain?. So it considers all CAs as stand-alone. > If > you want a cert chain you have to assemble it yourself. > > > > to get ecdsa certificate, you just need to change one of the above > lines > > > with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS > certificate? do > > > `-t rsa-pss`. > > > > > > See runtest.sh for other examples. > > > > I will take a look. > > Limited time offer! Call now and get Ed25519 support completely free! ;) > https://github.com/redhat-qe-security/certgen/commit/ > 4b71e0a7d77929d944cc20f16f2ccf9514d6d94d > > > > It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), > if > > > a > > > given feature is supported in that version of openssl. > > > > > > (while ed25519 support is not yet there, it will be in few weeks, I was > > > running just basic tests of it, without involving full PKI) > > > > Nice. See https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki > > > > I am right now adding an algorithm variable to support ed488. > > > > This actually does not work right with 1.1.1-pre9, as PR 6901 did not > > make that build, so I have to do my command and .cnf patches still. > > yes, there are quite a few warts you need to worry about when working with > different versions of OpenSSL, then there is the problem of updating it as > recommended key sizes or hashes change... > > reading that draft feels like reading a heavily commented script ? not a > criticism, rather observation about the problem at hand > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic-- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Aug 29 14:09:34 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Aug 2018 10:09:34 -0400 Subject: [openssl-users] Fwd: Openssl api for signature verification using digest In-Reply-To: References: Message-ID: <2B0F58F6-CD9B-4E55-A283-84F32EB7EE38@dukhovni.org> > On Aug 29, 2018, at 5:53 AM, Linta Maria wrote: > > As you suggested, signature wasn't correct. > With below input also it's not working. Once again, the code is working correct, the key below did not produce the posted signature. Please use "openssl rsautl" as shown in my previous message to check that the signature matches the code, before using these to test your code. There's no use asking for help with making work something that should not and must not work. > > Pubkey is read to evp_PKEY format > > EVP_PKEY * vkey; > char PubKey [] ="-----BEGIN PUBLIC KEY-----""\n" > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxEZo8DRHBFBN0w1YYw3w" "\n" > > "C/C/IxCH3WSDCBTZgPux+/Cm+Q+LtSHjxV2x+hHuR8+cWMgFIrpvN0jw1F6g0f3A" "\n" > > "QQvQmPkyIUZGN1C9Da+SEdpc12gZdAOdILUaeiDRNUYXJinbBPQaNGAQIWwuzCuj" "\n" > > "5sjZPrlJYDQ52kq2U86ZNcS/NVRZi+pFB4u0YHHiqJkQYT6yCQjR9Rdvxvjyg9L5" "\n" > > "9petX/xa0tBurw5eTLOC9UlufblJnS7zrVkpoHdtt9rRgDBJ4kTJypeHq0Tybgro" "\n" > > "hhxG1EqdAjoD0OjLV93JWr0DOmwWVE1SoJH/UBbgRXf40hxhdzswgJFWJLIdxfdj" "\n" > > "BwIDAQAB" "\n" > > "-----END PUBLIC KEY-----"; > > BIO *bio; > > bio = BIO_new_mem_buf(PubKey, strlen(PubKey) ); > > PEM_read_bio_PUBKEY( bio, &vkey, NULL, NULL ); > > > > unsigned char signew[]={0x14, 0x7e, 0x86, 0x9f, 0xfb, 0x10, 0xc8, 0xa4, 0x98, 0xae, 0xcb, 0xf8, 0xd4, 0xd7, 0xad, 0xf2, 0x18, 0x40, 0xaf, 0x06, 0x85, 0x8a, 0x69, 0xde, 0x29, 0x50, 0xf2, 0x52, 0x1c, 0x01, 0xbc, 0x3c, 0x45, 0x42, 0xb1, 0x32, 0xd8, 0x19, 0xf6, 0xf3, 0x11, 0x39, 0x03, 0xbf, 0x23, 0xfb, 0x5d, 0x97, 0x41, 0xb9, 0x85, 0xaf, 0x31, 0xf8, 0x32, 0x2f, 0xd2, 0xb6, 0x5b, 0xf1, 0x22, 0xfd, 0xda, 0x28, 0x58, 0x6f, 0x45, 0x4b, 0x5c, 0x74, 0xf0, 0x84, 0xf2, 0x1e, 0xfa, 0x33, 0xa3, 0x83, 0x38, 0x9f, 0xcf, 0x71, 0x37, 0x77, 0x6d, 0x86, 0x84, 0xc6, 0x5e, 0x3b, 0x71, 0xf5, 0x29, 0x2a, 0x43, 0xf4, 0x43, 0x38, 0x0a, 0x18, 0xf5, 0xbe, 0x6f, 0x03, 0xd3, 0x16, 0x79, 0x13, 0x89, 0x95, 0xb2, 0xd7, 0x27, 0xcf, 0xd4, 0x2b, 0x6b, 0xa1, 0xbd, 0xe3, 0x8e, 0xac, 0x24, 0x1b, 0xdd, 0x17, 0xf8, 0xe1, 0xf5, 0xb9, 0x5a, 0xd4, 0x97, 0xf4, 0xc3, 0xfc, 0x69, 0xc8, 0x40, 0x30, 0x76, 0x7d, 0x18, 0x7c, 0x58, 0x11, 0x3d, 0x78, 0x27, 0x41, 0xab, 0x1c, 0xd2, 0xd3, 0x5f, 0xe2, 0x94, 0xe1, 0x49, 0xba, 0x6b, 0xd7, 0xbe, 0x3a, 0x9d, 0x86, 0x62, 0xdc, 0xd7, 0x46, 0xae, 0xa3, 0x8e, 0xe1, 0x46, 0x27, 0xbc, 0xb2, 0x31, 0x69, 0xc5, 0x54, 0x15, 0x85,0x74, 0x1a, 0x66, 0x94, 0xa6, 0x68, 0x5e, 0xa2,0x1c, 0x38, 0x3d, 0x84, 0xd8, 0x3f, 0x84, 0x81,0x56, 0xc2, 0x9c, 0xac, 0xef, 0x68, 0xef, 0x68,0x96, 0xb3, 0xd1, 0xa9, 0x3a, 0x43, 0x75, 0xef,0xaf, 0xf2, 0x1b, 0xea, 0x96, 0xb8, 0x23, 0xef,0xa6, 0x09, 0x89, 0x15, 0x52, 0x26, 0xce, 0x1f,0x98, 0x02, 0x83, 0x22, 0x08, 0x60, 0x6c, 0xd9,0x14, 0x64, 0xe8, 0xef, 0x53, 0xea, 0x48, 0x60,0xbb, 0x69, 0x49, 0x64, 0xa3, 0x0d, 0xdb, 0xaa}; $ perl -pe 'chomp; s/(..)/chr(hex($1))/eg' /tmp/sig.hex | od -vtx1 0000000 14 7e 86 9f fb 10 c8 a4 98 ae cb f8 d4 d7 ad f2 0000020 18 40 af 06 85 8a 69 de 29 50 f2 52 1c 01 bc 3c 0000040 45 42 b1 32 d8 19 f6 f3 11 39 03 bf 23 fb 5d 97 0000060 41 b9 85 af 31 f8 32 2f d2 b6 5b f1 22 fd da 28 0000100 58 6f 45 4b 5c 74 f0 84 f2 1e fa 33 a3 83 38 9f 0000120 cf 71 37 77 6d 86 84 c6 5e 3b 71 f5 29 2a 43 f4 0000140 43 38 0a 18 f5 be 6f 03 d3 16 79 13 89 95 b2 d7 0000160 27 cf d4 2b 6b a1 bd e3 8e ac 24 1b dd 17 f8 e1 0000200 f5 b9 5a d4 97 f4 c3 fc 69 c8 40 30 76 7d 18 7c 0000220 58 11 3d 78 27 41 ab 1c d2 d3 5f e2 94 e1 49 ba 0000240 6b d7 be 3a 9d 86 62 dc d7 46 ae a3 8e e1 46 27 0000260 bc b2 31 69 c5 54 15 85 74 1a 66 94 a6 68 5e a2 0000300 1c 38 3d 84 d8 3f 84 81 56 c2 9c ac ef 68 ef 68 0000320 96 b3 d1 a9 3a 43 75 ef af f2 1b ea 96 b8 23 ef 0000340 a6 09 89 15 52 26 ce 1f 98 02 83 22 08 60 6c d9 0000360 14 64 e8 ef 53 ea 48 60 bb 69 49 64 a3 0d db aa 0000400 $ perl -pe 'chomp; s/(..)/chr(hex($1))/eg' /tmp/sig.hex | openssl rsautl -inkey /tmp/key.pem -pubin -encrypt -raw | od -vtx1 0000000 19 5c c4 8f 80 35 35 17 c6 17 b9 71 4d 8b 04 a2 0000020 f7 e4 8f 95 dc 1f 5d 15 b8 c2 41 16 78 fd 44 77 0000040 88 c1 b9 46 3d 48 d4 d6 b3 5e d2 bc 4b 8e 0e bc 0000060 7d bb 6d b5 2b 2d aa 40 01 a3 5e 48 31 76 a7 23 0000100 1f 90 d4 0a d3 b1 1a 10 05 a0 c3 49 e7 5e 60 04 0000120 82 02 34 43 d4 90 af 63 0f 90 67 3f 97 2a e7 9c 0000140 c4 4d 2c 1a ca d3 c5 95 9f d7 92 cd 71 32 b1 60 0000160 28 88 25 7a ea 58 dd 22 83 f1 cb 4d a7 39 ab f3 0000200 4f d8 b6 7d e3 a6 74 77 76 73 f5 1f 9e d3 09 5e 0000220 b3 a1 6f f8 84 0c 75 14 11 c8 0a 93 32 d7 ea 78 0000240 7c f3 48 7e 1c 0e 89 77 3d 48 ac ba 80 fc b3 01 0000260 f8 84 f4 cc 08 da 98 d7 67 00 9a b6 f2 9e 38 db 0000300 b4 af d7 38 ec 0d f4 06 6a 3f 32 8e c6 74 88 94 0000320 00 3d 11 fe e7 f5 96 0c 7e 7a bf 4c 1b 32 b4 7f 0000340 c3 ae 7e a3 c9 d5 5b e9 c5 2d 34 25 31 84 69 3c 0000360 eb d9 7f f5 a9 46 12 c3 35 a7 e4 19 68 69 d2 bc 0000400 That's not PKCS1 padding. -- Viktor. From srafidah40 at gmail.com Wed Aug 29 16:13:52 2018 From: srafidah40 at gmail.com (Siti Rafidah) Date: Thu, 30 Aug 2018 00:13:52 +0800 Subject: [openssl-users] Fwd: Openssl api for signature verification using digest In-Reply-To: References: Message-ID: All on my phone Pada 29 Aug 2018, at 17:53, Linta Maria menulis: > Hi Viktor, > > As you suggested, signature wasn't correct. > With below input also it's not working. > > Pubkey is read to evp_PKEY format > > EVP_PKEY * vkey; > char PubKey [] ="-----BEGIN PUBLIC KEY-----""\n" > "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxEZo8DRHBFBN0w1YYw3w" "\n" > > "C/C/IxCH3WSDCBTZgPux+/Cm+Q+LtSHjxV2x+hHuR8+cWMgFIrpvN0jw1F6g0f3A" "\n" > > "QQvQmPkyIUZGN1C9Da+SEdpc12gZdAOdILUaeiDRNUYXJinbBPQaNGAQIWwuzCuj" "\n" > > "5sjZPrlJYDQ52kq2U86ZNcS/NVRZi+pFB4u0YHHiqJkQYT6yCQjR9Rdvxvjyg9L5" "\n" > > "9petX/xa0tBurw5eTLOC9UlufblJnS7zrVkpoHdtt9rRgDBJ4kTJypeHq0Tybgro" "\n" > > "hhxG1EqdAjoD0OjLV93JWr0DOmwWVE1SoJH/UBbgRXf40hxhdzswgJFWJLIdxfdj" "\n" > > "BwIDAQAB" "\n" > > "-----END PUBLIC KEY-----"; > > BIO *bio; > > bio = BIO_new_mem_buf(PubKey, strlen(PubKey) ); > > PEM_read_bio_PUBKEY( bio, &vkey, NULL, NULL ); > > > > unsigned char signew[]={0x14, 0x7e, 0x86, 0x9f, 0xfb, 0x10, 0xc8, 0xa4, 0x98, 0xae, 0xcb, 0xf8, 0xd4, 0xd7, 0xad, 0xf2, 0x18, 0x40, 0xaf, 0x06, 0x85, 0x8a, 0x69, 0xde, 0x29, 0x50, 0xf2, 0x52, 0x1c, 0x01, 0xbc, 0x3c, 0x45, 0x42, 0xb1, 0x32, 0xd8, 0x19, 0xf6, 0xf3, 0x11, 0x39, 0x03, 0xbf, 0x23, 0xfb, 0x5d, 0x97, 0x41, 0xb9, 0x85, 0xaf, 0x31, 0xf8, 0x32, 0x2f, 0xd2, 0xb6, 0x5b, 0xf1, 0x22, 0xfd, 0xda, 0x28, 0x58, 0x6f, 0x45, 0x4b, 0x5c, 0x74, 0xf0, 0x84, 0xf2, 0x1e, 0xfa, 0x33, 0xa3, 0x83, 0x38, 0x9f, 0xcf, 0x71, 0x37, 0x77, 0x6d, 0x86, 0x84, 0xc6, 0x5e, 0x3b, 0x71, 0xf5, 0x29, 0x2a, 0x43, 0xf4, 0x43, 0x38, 0x0a, 0x18, 0xf5, 0xbe, 0x6f, 0x03, 0xd3, 0x16, 0x79, 0x13, 0x89, 0x95, 0xb2, 0xd7, 0x27, 0xcf, 0xd4, 0x2b, 0x6b, 0xa1, 0xbd, 0xe3, 0x8e, 0xac, 0x24, 0x1b, 0xdd, 0x17, 0xf8, 0xe1, 0xf5, 0xb9, 0x5a, 0xd4, 0x97, 0xf4, 0xc3, 0xfc, 0x69, 0xc8, 0x40, 0x30, 0x76, 0x7d, 0x18, 0x7c, 0x58, 0x11, 0x3d, 0x78, 0x27, 0x41, 0xab, 0x1c, 0xd2, 0xd3, 0x5f, 0xe2, 0x94, 0xe1, 0x49, 0xba, 0x6b, 0xd7, 0xbe, 0x3a, 0x9d, 0x86, 0x62, 0xdc, 0xd7, 0x46, 0xae, 0xa3, 0x8e, 0xe1, 0x46, 0x27, 0xbc, 0xb2, 0x31, 0x69, 0xc5, 0x54, 0x15, 0x85,0x74, 0x1a, 0x66, 0x94, 0xa6, 0x68, 0x5e, 0xa2,0x1c, 0x38, 0x3d, 0x84, 0xd8, 0x3f, 0x84, 0x81,0x56, 0xc2, 0x9c, 0xac, 0xef, 0x68, 0xef, 0x68,0x96, 0xb3, 0xd1, 0xa9, 0x3a, 0x43, 0x75, 0xef,0xaf, 0xf2, 0x1b, 0xea, 0x96, 0xb8, 0x23, 0xef,0xa6, 0x09, 0x89, 0x15, 0x52, 0x26, 0xce, 0x1f,0x98, 0x02, 0x83, 0x22, 0x08, 0x60, 0x6c, 0xd9,0x14, 0x64, 0xe8, 0xef, 0x53, 0xea, 0x48, 0x60,0xbb, 0x69, 0x49, 0x64, 0xa3, 0x0d, 0xdb, 0xaa}; > > > > > > unsigned char hashnew[]={0x8f,0x43,0x43,0x46,0x64,0x8f,0x6b,0x96,0xdf,0x89,0xdd,0xa9,0x1c,0x51,0x76,0xb1,0x0a,0x6d,0x83,0x96,0x1d,0xd3,0xc1,0xac,0x88,0xb5,0x9b,0x2d,0xc3,0x27,0xaa,0x4}; > > > > > > > > > > ---------- Forwarded message --------- > From: Viktor Dukhovni > Date: Wed 29 Aug, 2018, 11:30 AM > Subject: Re: [openssl-users] Openssl api for signature verification using digest > To: openssl-users at openssl.org > > > > > > On Aug 29, 2018, at 1:05 AM, Linta Maria wrote: > > > > Still its not working. > > The code is working correctly. The real problem is that the PEM > format 2048-bit RSA key you posted: > > > ----BEGIN PUBLIC KEY----- > > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH > > FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji > > bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK > > yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq > > lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN > > 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf > > 5QIDAQAB > > -----END PUBLIC KEY----- > > is NOT the key that was used to generate the below signature, or > the signature was subsequently altered. > > > Signature={ 0x24,0xb8,0xec,0xb4,0x4f,0x31,0xa6,0x8,0x72,0x61,0xc9,0xd3,0x1c,0xd0,0x9b,0xee,0x26,0x2d,0x3d,0xef,0xff,0x2c,0x5,0x78,0x4,0xd3,0xa3,0xff,0xdc,0x97,0x53,0xe6,0x6e,0x85,0x41,0x1b,0xb2,0x2c,0xed,0xbd,0xa6,0x5d,0x6f,0xac,0xbb,0xd5,0xb8,0xa0,0x9,0x2b,0xf1,0xf5,0xb6,0xce,0xdd,0x70,0x8a,0x1a,0xa1,0x20,0x11,0x2b,0xf0,0x17,0x41,0x83,0x80,0xf6,0x61,0xd4,0x6d,0x53,0x8f,0xf1,0x8c,0x19,0x42,0x93,0x96,0xa9,0xb6,0xf2,0x8f,0x27,0x9c,0x66,0x17,0xc5,0xca,0x3d,0xa9,0x3f,0xc5,0x76,0x5f,0x1b,0x31,0xf2,0xd3,0xe,0x78,0x53,0x97,0xcb,0x9d,0xc4,0xe6,0x41,0x61,0x58,0x44,0x5c,0xf5,0xc4,0x67,0x69,0x8,0xa,0x92,0xd5,0x7e,0x9c,0xb9,0x7e,0x54,0x8b,0x8a,0xb,0xa1,0x9a,0x63,0xbf,0xcc,0xed,0x63,0x2c,0xf8,0x14,0x25,0x6,0xa2,0x2,0x0,0x7,0x2e,0x1c,0xc1,0xeb,0x16,0x89,0xaa,0x69,0xe2,0x75,0x57,0x39,0x71,0x68,0xe,0xf,0xa4,0x7a,0xc5,0x14,0x97,0x88,0x67,0xd1,0x36,0x91,0x3b,0x49,0xe7,0xb4,0xf3,0xcb,0xca,0xf6,0xe9,0xb1,0x22,0xe9,0x85,0x89,0xab,0x2,0x4,0x3c,0x2e,0xbd,0x56,0x3,0x8a,0x8b,0x54,0xc6,0xe6,0xed,0x5b,0x4c,0 > xa4,0x9e,0x1b,0xaa,0x90,0xc6,0xb,0x27,0x54,0xc0,0x50,0x5f,0x58,0x97,0xc,0x99,0x5c,0x2,0x74,0xfc,0x9f,0x4c,0x78,0x4e,0xc3,0xb4,0x6d,0x14,0xa1,0xdc,0x62,0xc5,0xfe,0x27,0xb8,0x7d,0x98,0x79,0x82,0x50,0x3a,0xbe,0x6f,0x83,0x79,0xd,0x8a,0xb8,0x3e,0xac,0xa,0xeb,0x62,0xd5,0x5e,0x95} > > $ od -tx1 < /tmp/sig > 0000000 24 b8 ec b4 4f 31 a6 08 72 61 c9 d3 1c d0 9b ee > 0000020 26 2d 3d ef ff 2c 05 78 04 d3 a3 ff dc 97 53 e6 > 0000040 6e 85 41 1b b2 2c ed bd a6 5d 6f ac bb d5 b8 a0 > 0000060 09 2b f1 f5 b6 ce dd 70 8a 1a a1 20 11 2b f0 17 > 0000100 41 83 80 f6 61 d4 6d 53 8f f1 8c 19 42 93 96 a9 > 0000120 b6 f2 8f 27 9c 66 17 c5 ca 3d a9 3f c5 76 5f 1b > 0000140 31 f2 d3 0e 78 53 97 cb 9d c4 e6 41 61 58 44 5c > 0000160 f5 c4 67 69 08 0a 92 d5 7e 9c b9 7e 54 8b 8a 0b > 0000200 a1 9a 63 bf cc ed 63 2c f8 14 25 06 a2 02 00 07 > 0000220 2e 1c c1 eb 16 89 aa 69 e2 75 57 39 71 68 0e 0f > 0000240 a4 7a c5 14 97 88 67 d1 36 91 3b 49 e7 b4 f3 cb > 0000260 ca f6 e9 b1 22 e9 85 89 ab 02 04 3c 2e bd 56 03 > 0000300 8a 8b 54 c6 e6 ed 5b 4c a4 9e 1b aa 90 c6 0b 27 > 0000320 54 c0 50 5f 58 97 0c 99 5c 02 74 fc 9f 4c 78 4e > 0000340 c3 b4 6d 14 a1 dc 62 c5 fe 27 b8 7d 98 79 82 50 > 0000360 3a be 6f 83 79 0d 8a b8 3e ac 0a eb 62 d5 5e 95 > > $ openssl rsa -pubin -in /tmp/key > writing RSA key > -----BEGIN PUBLIC KEY----- > MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMjyWZfVfBpmNKmIm9HH > FnrhDLZaCmQvZz57uJHhBLwLk/UAJ+kLKV9Lox8eKfimzisPFBad/TUfwPUaQmji > bPKCp+or2EHvPFooOnPWjSd57zPCohDdo0nOLw7iTUOMCvoqvJcdor+t1zBb8MQK > yNTycuoGlT19lr8msJFtR+ulfKucj/zk5w/jr0SsxysqFsvtEfa62Wu/wSDYIfsq > lKlRGLTlqJNtQybtTVv2Uu2KFrbe0C8+FBkxgtBS+0MkhzpJ37/02J+mHFx1bsgN > 09QnQY+T05te+6/mmlsHP3PYRqXqJOLl9AkLd/9kiMhSFshowFehKmls9PYt1xGf > 5QIDAQAB > -----END PUBLIC KEY----- > > Which match your post, but raw public key encryption of the signature > data does not yield a PKCS1 padded message: > > $ openssl rsautl -encrypt -pubin -inkey /tmp/key -raw -in /tmp/sig | od -tx1 > 0000000 95 ca 3c b7 cf d3 19 3d 1d 4a 29 61 67 59 21 d1 > 0000020 61 47 9f 09 69 23 cc 05 77 21 e6 5c 12 9b ed 39 > 0000040 06 7c 23 51 5f e3 3f 48 45 df 41 89 2e d6 92 4a > 0000060 bd b2 e8 36 e6 83 2a 1e 71 5e 5b 97 52 f2 bc 18 > 0000100 63 3b 45 e0 c1 0a ec 48 ae 42 a3 e5 46 dc 80 77 > 0000120 87 19 a0 29 94 e7 33 2a 77 2b bb 54 39 06 92 ca > 0000140 df b2 21 04 98 d7 cb 16 a6 a0 5b ac c3 d8 20 df > 0000160 ac 8f 3a 6d b9 20 7c cb 52 5e 7f f8 69 fc 39 7f > 0000200 8b db c1 16 4c df ca ba d7 33 5f 8e 21 87 6b ae > 0000220 a8 e1 20 1b e5 1f 8c 3f 18 2d b4 c0 0d 66 ec 1e > 0000240 f2 7b 78 ab ad 3c 8c da 80 24 25 3d c8 19 ad 48 > 0000260 b3 21 ca 90 40 ce dd 22 85 6d 8b 6f ed da 77 be > 0000300 81 02 d3 d5 5a ec fd 9f 6e 4a 52 f1 18 31 d4 e1 > 0000320 14 43 17 02 ff 74 f8 ee cf 2c 09 bc 60 d8 65 e3 > 0000340 3c c2 e1 a9 09 5e 21 42 d2 0f 4f aa d5 75 47 69 > 0000360 51 f0 87 98 bd 7f 99 83 e1 22 33 56 0b 13 8e 37 > 0000400 > > By way of contrast: > > $ openssl genrsa -out /tmp/key2.pem 2048 2>/dev/null > $ echo foobar | openssl dgst -sha256 -sign /tmp/key2.pem -out /tmp/sig2 > $ openssl rsa -in /tmp/key2.pem -pubout > /tmp/pub2.pem 2>/dev/null > $ openssl rsautl -encrypt -pubin -inkey /tmp/pub2.pem -raw -in /tmp/sig2 | od -vtx1 > 0000000 00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000100 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000120 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000220 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000240 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000260 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > 0000300 ff ff ff ff ff ff ff ff ff ff ff ff 00 30 31 30 > 0000320 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 > 0000340 ae c0 70 64 5f e5 3e e3 b3 76 30 59 37 61 34 f0 > 0000360 58 cc 33 72 47 c9 78 ad d1 78 b6 cc df b0 01 9f > 0000400 > > Above you see that using the same key for a raw public encrypt as was used > for signing, yields content that is PKCS1-padded as expected. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From waqar_chdry at yahoo.com Thu Aug 30 05:49:14 2018 From: waqar_chdry at yahoo.com (Waqar Chaudhry) Date: Thu, 30 Aug 2018 05:49:14 +0000 (UTC) Subject: [openssl-users] OpenSSL Integration with DPDK References: <1118110119.729650.1535608154992.ref@mail.yahoo.com> Message-ID: <1118110119.729650.1535608154992@mail.yahoo.com> I am new to OpenSSL. Does anyone have any information on how to integrate OpenSSL?1.1.x with DPDK?? Intel has a video on OpenSSL?1.1.x integration using QAT_engine for Intel QAT PCI-E?card but nothing on OpenSSL using DPDK.? Has anyone done this or point me to something? What I am looking for is how can I take OpenSSL 1.1.x and integrate it with DPDK. I do see Intel DPDK has a lib_crypto directory under lib directory.? Thanks,? -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Thu Aug 30 09:59:21 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 30 Aug 2018 12:59:21 +0300 Subject: [openssl-users] DECLARE_ASN1* etc. Message-ID: Hello, Is there any description how to use openssl macros describing the necessary ASN1 structures? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From swamy.j-s at in.abb.com Thu Aug 30 12:03:36 2018 From: swamy.j-s at in.abb.com (Swamy J-S) Date: Thu, 30 Aug 2018 12:03:36 +0000 Subject: [openssl-users] Problem in Building openssl_1.0.2p in Visual Studio 2015 Message-ID: Am building new release of openssl_1.0.2p using Visual Studio 2015 Command Prompts. I have installed perl and sed. I have written some batch files to build x86 and x64 libraries. When I built same openssl version in VS 2013 and VS 2017 am not facing any issue. But while building in VS 2015 am unable to build. When I build x86 library in "VS2015 x86 Native Tools Command Prompt" then its building fine and resulting in generating include and lib folder. But when I try to build DLL library then am getting fatal error which says rc /fo"tmp32dll\libeay32.res" /d CRYPTO ms\version32.rc 'rc' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error V1077: 'rc' : return code '0x1' Stop. 1 dir(s) moved. 1 dir(s) moved." I have attached screenshot too. Thanks and Regards, SWAMY J S -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: VS 2015.png Type: image/png Size: 61659 bytes Desc: VS 2015.png URL: From Michael.Wojcik at microfocus.com Thu Aug 30 14:20:22 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 30 Aug 2018 14:20:22 +0000 Subject: [openssl-users] Problem in Building openssl_1.0.2p in Visual Studio 2015 In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Swamy J-S > Sent: Thursday, August 30, 2018 08:04 > But while building in VS 2015 am unable to build. When I build x86 library in ?VS2015 x86 Native Tools Command > Prompt? then its building fine and resulting in generating include and lib folder. But when I try to build DLL library > then am getting fatal error which says > ?rc? is not recognized as an internal or external command, > operable program or batch file. This is a Visual Studio issue, not an OpenSSL one. You should really be asking on a Visual Studio forum. rc is part of the Visual Studio toolchain, so the problem is either in your Visual Studio installation or your environment. The latter is more likely. The problem may be that you're using an x86 Native Tools window. If you're running on a 64-bit version of Windows, you should be using a Visual Studio x64 x86 Cross Tools window. -- Michael Wojcik Distinguished Engineer, Micro Focus From kvenkatarao at infinera.com Fri Aug 31 05:52:49 2018 From: kvenkatarao at infinera.com (Kumar Venkatarao) Date: Fri, 31 Aug 2018 05:52:49 +0000 Subject: [openssl-users] Question w.r.t EVP Signing and Verifying Message-ID: Hi, I am writing a program to do pairwise consistency checks using EVP API's for RSA and ECDSA keys. The private and public keys are obtained from a PKCS12 file. I've based my program on the sample code provided at - https://wiki.openssl.org/index.php/EVP_Signing_and_Verifying Version of openssl used is OpenSSL 1.0.2n/FIPS v2.0.16 The code works well for RSA based keys. However, with ECDSA the EVP_VerifyDigestFinal Function always return 0. The Man page seem to indicate a return value of 0 doesn't Indicate of any serious error, but says verification is a failure. The questions are - 1. Why does EVP_DigestVerifyFinal fail for ECDSA keys ? Is it a known problem ? 2. If I need to use ECDSA_sign and ECDSA_verify call, I need to convert the EVP_PKEY Structure to EC_KEY. I do find a supporting API - EVP_PKEY_set1_EC_KEY. However, This seems true for Only private keys. Is there any function that would accept EVP_PKEYs (private/public) and generate a single EC_KEY structure so that ECDSA_sign/ECDSA_verify can be used ? Thanks Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Aug 31 15:09:57 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 31 Aug 2018 11:09:57 -0400 Subject: [openssl-users] Question w.r.t EVP Signing and Verifying In-Reply-To: References: Message-ID: > On Aug 31, 2018, at 1:52 AM, Kumar Venkatarao wrote: > > Why does EVP_DigestVerifyFinal fail for ECDSA keys? Because you're not using it correctly. > Is it a known problem ? Yes, incorrect use will lead to unexpected results. No, there is no known problem in correct use of EC signature verification. You can test EC signing and verification with: $ openssl genpkey -out /tmp/eckey.pem -algorithm ec \ -pkeyopt "ec_paramgen_curve:prime256v1" \ -pkeyopt ec_param_enc:named_curve $ openssl pkey -in /tmp/eckey.pem -pubout -out /tmp/ecpub.pem $ echo foobar | openssl dgst -sign /tmp/eckey.pem > /tmp/sig.dat $ echo foobar | openssl dgst -verify /tmp/ecpub.pem -signature /tmp/sig.dat ; echo $? Verified OK 0 $ echo goobar | openssl dgst -verify /tmp/ecpub.pem -signature /tmp/sig.dat ; echo $? Verification Failure 1 Your code should be able to generated signature files that "openssl dgst -verify" can verify, or verify signatures that "openssl dgest -sign" produced. The default digest algoritm in the operations above was SHA256, you can make it explicit if you like via appropriate additional options. -- Viktor.