* Kurt Roeckx:
> On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote:
>> * Viktor Dukhovni:
>>
>> > If I were to guess, it would be that the base crypto implementations
>> > of IDEA, SEED and binary elliptic curves need to stay. We could
>> > perhaps get away with removing CAST and RI
On Tue, Nov 17, 2015 at 07:10:00PM +0100, Florian Weimer wrote:
> * Viktor Dukhovni:
>
> > If I were to guess, it would be that the base crypto implementations
> > of IDEA, SEED and binary elliptic curves need to stay. We could
> > perhaps get away with removing CAST and RIPEMD.
>
> Just one dat
* Viktor Dukhovni:
> If I were to guess, it would be that the base crypto implementations
> of IDEA, SEED and binary elliptic curves need to stay. We could
> perhaps get away with removing CAST and RIPEMD.
Just one data point: CAST5 is still the default for GnuPG when using
symmetric encryption.
> Don’t punish users for choosing OpenSSL library to handle their non-SSL
> cryptographic needs and implicitly trusting the developers that they won’t be
> left in the cold.
Can we please be less inflammatory?
Old unused code is a security risk. We’re trying to reduce the attack surface
*resp
Ø If you are aware of a concrete use of MD2 or any of the other algorithms,
please let us know!
Also, note that we have an extended alpha and-beta test period, so we can add
things back if mistakes are made.
/r$
___
openssl-dev mai
te: 17/11/2015 06:29
Subject: Re: [openssl-dev] Removing obsolete crypto from OpenSSL 1.1 -
seeking feedback
Sent by:"openssl-dev"
On 16 November 2015 at 19:05, Hubert Kario wrote:
Example: CAdES V1.2.2 was published in late 2000, the first serious
> On 16 November 2015 at 19:05, Hubert Kario wrote:
>> Example: CAdES V1.2.2 was published in late 2000, the first serious
>> attacks on MD2 were not published until 2004. I think it is not
>> unreasonable for CAdES-A documents to exist today which were originally
>> signed with MD2 while it was s
On 16 November 2015 at 19:05, Hubert Kario wrote:
> Example: CAdES V1.2.2 was published in late 2000, the first serious
> attacks on MD2 were not published until 2004. I think it is not
> unreasonable for CAdES-A documents to exist today which were originally
> signed with MD2 while it was still
On Monday 16 November 2015 19:51:08 Emilia Käsper wrote:
> One more time,
>
> I know that someone, somewhere is probably using any given feature of
> OpenSSL. I am looking to gather information about concrete, actively
> maintained applications that may be using one of those algorithms, to
> build
One more time,
I know that someone, somewhere is probably using any given feature of
OpenSSL. I am looking to gather information about concrete, actively
maintained applications that may be using one of those algorithms, to build
a more complete picture.
If you are aware of a concrete use of MD2
On Monday 16 November 2015 16:51:10 Emilia Käsper wrote:
> IDEA, MD2, MDC2, RC5, RIPEMD, SEED, Whirlpool, binary curves
>
> This isn't of course entirely representative of widespread usage.
> However Google's multi-billion line codebase now builds against
> BoringSSL and therefore largely does not
Thanks all for your feedback!
I asked for mainstream use-cases for algorithms whose removal could cause
widespread pain. Some individual users, undoubtedly, will be hit by this,
and I acknowledge that they may not be reading this list. But I wanted to
know if I'd missed something endemic. I also a
On Friday 13 November 2015 14:40:33 Emilia Käsper wrote:
> Hi all,
>
> We are considering removing from OpenSSL 1.1 known broken or outdated
> cryptographic primitives. As you may know the forks have already done
> this but I'd like to seek careful feedback for OpenSSL first to
> ensure we won't b
On 15/11/15 21:16, Viktor Dukhovni wrote:
> Is the pain worth the gain? I'm inclined to think that dropping
> TLS ciphersuite code points, and assembly support, is a rather
> sensible first step.
I agree with this. I am wary of dropping too much too quickly.
Matt
_
On Sun, Nov 15, 2015 at 09:14:43PM +0100, Richard Levitte wrote:
> openssl-users> If the engine is not automatically loaded, then scripting
> languages
> openssl-users> that provide wrappers around the various algorithms [break],
> as does other
> openssl-users> software that needs the legacy al
In message <20151115170948.ga18...@mournblade.imrryr.org> on Sun, 15 Nov 2015
17:09:48 +, Viktor Dukhovni said:
openssl-users> On Sun, Nov 15, 2015 at 01:11:37PM +0100, Richard Levitte wrote:
openssl-users>
openssl-users> > pl> It is perhaps time to split crypto library in two libraries
ope
On Sun, Nov 15, 2015 at 01:11:37PM +0100, Richard Levitte wrote:
> pl> It is perhaps time to split crypto library in two libraries
> pl> libcryptolegacy and libcryptostrong...
> pl>
> pl> My two cents.
>
> I though could be to make a "legacy" engine that holds the removed
> crypto algos. It cou
On Sun, Nov 15, 2015 at 10:24:02AM +, Loganaden Velvindron wrote:
> Perhaps, it might be worth looking at what LibreSSL has already
> removed without affecting their 3rd party packages ?
There are not many arms-length packages for OpenBSD, the ports are
maintained by the same crowd as the OS.
In message <564846e4.4060...@artisanlogiciel.net> on Sun, 15 Nov 2015 09:48:36
+0100, pl said:
pl> On 14/11/2015 18:32, Viktor Dukhovni wrote:
pl> > The proposed list was:
pl> >
pl> > CAST
pl> > IDEA
pl> > MDC2
pl> > MD2 [ already disabled by default ]
pl> > RC5 [ already dis
On Sun, Nov 15, 2015 at 8:48 AM, pl wrote:
> On 14/11/2015 18:32, Viktor Dukhovni wrote:
>> On Sat, Nov 14, 2015 at 07:32:33AM +, Peter Waltenberg wrote:
>>
>>>I also can't see any point expunging old algorithms from the sources,
>>>making them not build by default should be enough.
>>
On 14/11/2015 18:32, Viktor Dukhovni wrote:
> On Sat, Nov 14, 2015 at 07:32:33AM +, Peter Waltenberg wrote:
>
>>I also can't see any point expunging old algorithms from the sources,
>>making them not build by default should be enough.
> It is difficult enough to maintain code that is ty
On Sat, Nov 14, 2015 at 07:32:33AM +, Peter Waltenberg wrote:
>I also can't see any point expunging old algorithms from the sources,
>making them not build by default should be enough.
It is difficult enough to maintain code that is typically built,
dead code is even harder to keep co
I also can't see any point expunging old algorithms from the sources, making them not build by default should be enough. They are known to work and there's always the issue of 'legacy' support. With the number and variety of consumers OpenSSL has that's likely to be a problem for years to come.The
On Fri, Nov 13, 2015 at 10:02:02PM +, Salz, Rich wrote:
> > So I'm trying to help move forward, without creating artificial barriers.
> > Let's fix TLS (libssl) first, and we can tackle libcrypto in a later
> > release.
>
> I disagree.
>
> I think the main driver will be OpenSSL 1.1-next, wh
crypto from OpenSSL 1.1 - seeking
feedback
> So I'm trying to help move forward, without creating artificial barriers.
> Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release.
I disagree.
I think the main driver will be OpenSSL 1.1-next, which will have TLS
On Fri, Nov 13, 2015 at 05:24:01PM -0500, Daniel Kahn Gillmor wrote:
> I'm less sympathetic in this case, since these functions have
> well-defined semantics when a cipher has been removed (or simply isn't
> present in the first place): they return NULL on error, and if code X
> doesn't handle err
On Fri 2015-11-13 16:16:56 -0500, Viktor Dukhovni wrote:
> This is very difficult, because most applications use libcrypto
> algorithms indirectly, via EVP_get_cipherbyname(), EVP_get_digestbyname()
> and so on. So the code will link, but there'll be runtime errors
> due to missing ciphers or dige
> So I'm trying to help move forward, without creating artificial barriers.
> Let's fix TLS (libssl) first, and we can tackle libcrypto in a later release.
I disagree.
I think the main driver will be OpenSSL 1.1-next, which will have TLS 1.3
support. So the purpose of this realease will be to
On Fri, Nov 13, 2015 at 09:20:47PM +, Salz, Rich wrote:
> > Actually deleting algorithms is *very* difficult.
>
> Yes.
>
> And we're doing the best we can by asking reasonably.
>
> Some people may get burnt. Oh well. It's open source, fork if you have to.
What we primarily don't want to
On 11/13/2015 1:20 PM, Salz, Rich wrote:
Actually deleting algorithms is *very* difficult.
Yes.
And we're doing the best we can by asking reasonably.
Some people may get burnt. Oh well. It's open source, fork if you have to.
With all of the "unacceptable" rules coming down from Gov'ts a
> Actually deleting algorithms is *very* difficult.
Yes.
And we're doing the best we can by asking reasonably.
Some people may get burnt. Oh well. It's open source, fork if you have to.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl
On Fri, Nov 13, 2015 at 03:20:58PM -0500, Daniel Kahn Gillmor wrote:
> Perhaps it would be useful to gather data on this by looking at large
> codebases (e.g. large linux distros like fedora or debian) to see
> whether these particular functions of libcrypto are being used or linked
> to.
>
> I h
On 11/13/2015 02:20 PM, Daniel Kahn Gillmor wrote:
> On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote:
>> The simplest approach is to remove ciphersuites from the SSL/TLS
>> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL),
>> but leave the underlying crypto in the lib
On Fri 2015-11-13 14:48:41 -0500, Viktor Dukhovni wrote:
> The simplest approach is to remove ciphersuites from the SSL/TLS
> code (effectively making them unavailable even via ALL:COMPLEMENTOFALL),
> but leave the underlying crypto in the library.
>
> Similarly, one might remove algorithms from S/
On Fri, Nov 13, 2015 at 06:03:33PM +, Jonathan Larmour wrote:
> I strongly agree with this. Not every OpenSSL user reads the openssl-dev
> mailing list (nor -announce). I have been bitten by this in the past in
> other FOSS projects which only solicited comments from mailing list readers.
>
>
Hi,
On 13/11/15 17:08, stefan.n...@t-online.de wrote:
>> We are considering removing from OpenSSL 1.1 known broken
>> or outdated cryptographic primitives.
> [...]
>> My preference would be to remove these algorithms completely
>> (as in, delete the code).
>
> From the formal[istic] point of vie
Hi,
> We are considering removing from OpenSSL 1.1 known broken
> or outdated cryptographic primitives. As you may know the forks
> have already done this but I'd like to seek careful feedback for
> OpenSSL first to ensure we won't be breaking any major applications.
[...]
> My preference woul
Hi all,
We are considering removing from OpenSSL 1.1 known broken or outdated
cryptographic primitives. As you may know the forks have already done this
but I'd like to seek careful feedback for OpenSSL first to ensure we won't
be breaking any major applications.
These algorithms are currently ca
38 matches
Mail list logo