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
--
> 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
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
> 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:
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
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.
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
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:
>
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
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
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
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
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
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
14 matches
Mail list logo
