> 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
Why not offer another set of get_XYZ_byname() which resticts the caller to
socially acceptable algorithms. Or allows the opposite, it really doesn't
matter but restricted being the newer API breaks less code by default.
Give it the same call syntax and it's simply an #ifdef in the OpenSSL
heade
On Tue, 2015-11-17 at 00:01 +, Viktor Dukhovni wrote:
On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote:
Disabling algorithms isn't the right answer IMO. I do like the idea of a
"liblegacycrypto". That way people that only have need of current
up-to-date crypto can stick with the
On Mon, Nov 16, 2015 at 11:23:52PM +, Matt Caswell wrote:
> Disabling algorithms isn't the right answer IMO. I do like the idea of a
> "liblegacycrypto". That way people that only have need of current
> up-to-date crypto can stick with the main library. Others who need the
> older crypto can s
Huge +1.
I find Viktor’s arguments more than convincing - irrefutable.
As for “weakening the library”, I don’t find this argument correct. It is
not about libssl - it’s about libcrypto. Quite a different animal.
--
Regards,
Uri Blumenthal
On 11/16/15, 18:23 , "openssl-dev on behalf of Matt
Meant to send this to openssl-dev not openssl-users so resending...
On 16/11/15 15:51, Emilia Käsper wrote:
> 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,
The reason for keeping the old crypto. algorithms around is the obvious
one, that's been stated over and over. OpenSSL's SSL isn't the only
consumer of the algorithms, remove the low level algorithms and you risk
breaking more than OpenSSL. SSH, IKE,IPSec, Kerberos and I'm sure there
are more, and
> 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
Dear Stephen,
On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT
wrote:
> On Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are
> not
>
Dear Stephen,
On Mon, Nov 16, 2015 at 5:22 PM, Stephen Henson via RT
wrote:
> On Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> > Hello!
> >
> > In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> > the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are
> not
>
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
On Mon, Nov 16, 2015 at 04:51:10PM +0100, Emilia Käsper wrote:
> As for specific deprecation strategies:
> - Don't forget that all applications will have to recompile against 1.1.
The EVP_get_cipherbyname() and EVP_get_digestbyname() interfaces
remain, so nothing changes at compile-time. Most co
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 Sun Nov 15 10:04:28 2015, beld...@gmail.com wrote:
> Hello!
>
> In the commit 5e3d21fef150f020e2d33439401da8f7e311aa24 you set
> the SSL_SSLV3 for the GOST ciphersuites. But the GOST ciphersuites are not
> usable with SSLv3, they require TLSv1.
>
> Could you turn the flag back for the GOST ciphe
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
Thanks for your reply.
Am 12.11.2015 um 18:45 schrieb stefan.n...@t-online.de:
Hi,
You might want to upgrade to OpenSSL-1.0.2 which seems to support the
RSA PSS algorithm, see https://openssl.org/news/changelog.html#x5.
Regards,
Stefan
...
we are up to
20 matches
Mail list logo