[openssl-dev] use SIPhash for OPENSSL_LH_strhash?

2017-01-09 Thread Salz, Rich
Should we move to using SIPHash for the default string hashing function in OpenSSL? It's now in the kernel https://lkml.org/lkml/2017/1/9/619 Overview at https://131002.net/siphash/ -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz -- o

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

2017-01-09 Thread Salz, Rich
> Doesn't the fact that AES-192 seems to be more resistant against related key > attacks than AES-256 "in a world of 2^50 keys" count as an argument for > inclusion? > > A related question, is the fact that AES-192 is more resistant to related key > attacks caused by the fact that it uses a key si

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

2017-01-09 Thread Leonard den Ottolander
Hello Rich, On Mon, 2017-01-09 at 19:52 +, Salz, Rich wrote: > AES 192 has been discussed at various times in the IETF mailing lists > (see CFRG and TLS for most likely places). Here's one posting: > https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html > > My short summary is tha

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

2017-01-09 Thread Salz, Rich
> Has anyone ever attempted to get such ciphers included in that IANA list? It > seems AES-192 is being treated rather stepmotherly in the standards. AES 192 has been discussed at various times in the IETF mailing lists (see CFRG and TLS for most likely places). Here's one posting: https://www

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

2017-01-09 Thread Leonard den Ottolander
Hello Viktor, On Mon, 2017-01-09 at 19:25 +, Viktor Dukhovni wrote: > There are no AES-192 ciphersuites in the IANA TLS registry: > > > http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 > > so these cannot (interoperably) be used with TLS. Right. I th

Re: [openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

2017-01-09 Thread Viktor Dukhovni
On Mon, Jan 09, 2017 at 07:57:43PM +0100, Leonard den Ottolander wrote: > Considering that AES-192 seems to be very resistant against related key > attacks (http://eprint.iacr.org/2009/317) and the algorithm is already > available in the openssl code I am trying to expose the AES-192 > ciphers.

[openssl-dev] Enabling AES-192 ciphers, how to expose DHE-RSA-AES192-GCM-SHA384

2017-01-09 Thread Leonard den Ottolander
Hello, Considering that AES-192 seems to be very resistant against related key attacks (http://eprint.iacr.org/2009/317) and the algorithm is already available in the openssl code I am trying to expose the AES-192 ciphers. Attached is a patch against 1.0.1u (adapted from the version I created ag

Re: [openssl-dev] Revert commit 10621ef white space nightmare

2017-01-09 Thread Leonard den Ottolander
Hello Matt, On Mon, 2017-01-09 at 18:06 +, Matt Caswell wrote: > That particular commit was the result of a lot work and discussion on > this list and in other places. This is the code reformat commit and > changes the format of the source to be consistent with the OpenSSL > coding style: > >

Re: [openssl-dev] Revert commit 10621ef white space nightmare

2017-01-09 Thread John Denker
On 01/09/2017 10:46 AM, Leonard den Ottolander wrote: > I don't remember ever seeing directives being indented by adding > white space between the hash sign and the directive. In my world, that is quite common. > If one wants to indent directives space is normally inserted before > the hash sign

Re: [openssl-dev] Revert commit 10621ef white space nightmare

2017-01-09 Thread Claus Assmann
On Mon, Jan 09, 2017, Leonard den Ottolander wrote: > If one wants to indent directives space is normally inserted before the > hash sign. I don't remember ever seeing directives being indented by > adding white space between the hash sign and the directive. Then you didn't look at source code fo

Re: [openssl-dev] Revert commit 10621ef white space nightmare

2017-01-09 Thread Matt Caswell
On 09/01/17 17:46, Leonard den Ottolander wrote: > Hello, > > https://github.com/openssl/openssl/commit/10621efd3296a92f489f6ab26a88e88d9790930e#diff-4b59eddb1c722b1dc3d17b5f64149e12 > > is a white space nightmare. The replacement of "#define"s by "# define"s > etc. is just silly and makes it u

Re: [openssl-dev] Revert commit 10621ef white space nightmare

2017-01-09 Thread Salz, Rich
Sorry you feel this way, but the patch is not being reverted. First of all, 1.0.1 is now end of life and gets no updates :) As for the specific pre-processor, there are systems out there that only recognized the poundsign if it was in the first column (silly but true). Also, we prefer the whit

[openssl-dev] Revert commit 10621ef white space nightmare

2017-01-09 Thread Leonard den Ottolander
Hello, https://github.com/openssl/openssl/commit/10621efd3296a92f489f6ab26a88e88d9790930e#diff-4b59eddb1c722b1dc3d17b5f64149e12 is a white space nightmare. The replacement of "#define"s by "# define"s etc. is just silly and makes it unnecessarily hard to port patches between different releases (w

[openssl-dev] x509 extension support

2017-01-09 Thread Freemon Johnson
Hello, Can anyone help me in discerning which version of openssl supports sbgp-autonomousSysNum and sbgp-ipAddrBlock? If it has been deprecated then providing the alternative would be greatly appreciated. A sample openssl.cnf is provided below. When I perform a request for req it fails because