On Thu, 2014-03-27 at 19:27 +0100, Dr. Stephen Henson wrote:
I'd rather see the ability to add a new section openssl.cnf, like
[ cipher-profile ]
redhat-recommended = AES256-CGM-SHA384
and then you could do things like
-ciphers profile@redhat-recommended:RC4-SHA128
On Mon, Mar 31, 2014 at 02:13:22PM +0200, Nikos Mavrogiannopoulos wrote:
This looks indeed cleaner, but based on my understanding of openssl, I
think the main issues with that, is (1) that applications may not call
OPENSSL_config at all,
Perhaps to deliberately isolate themselves from
- Original Message -
From: Viktor Dukhovni openssl-us...@dukhovni.org
To: openssl-dev@openssl.org
Sent: Friday, 28 March, 2014 8:25:50 PM
Subject: Re: Insecure DEFAULT cipher set
On Fri, Mar 28, 2014 at 03:11:46PM -0400, Hubert Kario wrote:
I am much more concerned about
On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:
There is no benefit in excluding RC4-SHA1 from the default list.
When servers support stronger algorithms, those will be negotiated.
All you get by exclusing RC4-SHA1 is loss of interoperability, which
may be OK for dedicated
On Mon, 2014-03-31 at 12:23 +, Viktor Dukhovni wrote:
and (2) it is not easy to modify just a single
section of that file with system scripts (especially since that file is
expected to be modified manually by the administrator).
This is likely a good thing. Once a default is set,
On Mon, Mar 31, 2014 at 03:39:10PM +0200, Nikos Mavrogiannopoulos wrote:
This too feels like intrusive overreach. What problem are you
trying to solve?
The goal is to allow the configuration of the security level of
applications centrally in a system. That is, to not require the
- Original Message -
From: Viktor Dukhovni openssl-us...@dukhovni.org
To: openssl-dev@openssl.org
Sent: Monday, 31 March, 2014 3:09:12 PM
Subject: Re: Insecure DEFAULT cipher set
On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:
There is no benefit in excluding
On Mon, 2014-03-31 at 13:55 +, Viktor Dukhovni wrote:
This too feels like intrusive overreach. What problem are you
trying to solve?
The goal is to allow the configuration of the security level of
applications centrally in a system. That is, to not require the
administrator to
On Po, 2014-03-31 at 16:24 +0200, Nikos Mavrogiannopoulos wrote:
On Mon, 2014-03-31 at 13:55 +, Viktor Dukhovni wrote:
This too feels like intrusive overreach. What problem are you
trying to solve?
The goal is to allow the configuration of the security level of
applications
You're still playing my security level is bigger than yours.
There is no benefit in excluding RC4-SHA1 from the default list.
When servers support stronger algorithms, those will be negotiated.
But that is only true as long as there is no new attack which succesfully
downgrades the cipher
On Mon, Mar 31, 2014 at 07:36:19PM +0200, stefan.n...@t-online.de wrote:
To me, carefully starting to drop outdated/weak
ciphersuites, so early adopters can test and provide
feedback (both asking the communication partner to
upgrade their software and giving feedback on how
usable the new
On Mon, Mar 31, 2014 at 01:09:12PM +, Viktor Dukhovni wrote:
On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:
There is no benefit in excluding RC4-SHA1 from the default list.
When servers support stronger algorithms, those will be negotiated.
All you get by exclusing
Are you looking at x,y values or an encoded (external) point?
If the latter, it might be different encoding format, there are 3.
Otherwise, you probably have something wrong, since OpenSSL
successfully interoperates with other EC implementations.
Post details - if you want to keep K
13 matches
Mail list logo
