[openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Rich Salz via RT
Hello,

see GitHub pull request at
https://github.com/openssl/openssl/pull/374

Which adds support for Camellia GCM and adds the correspondent TLS cipher
suites. Most of the code comes from the AES GCM implementation, so maybe
there's an opportunity for some refactoring there.

This fixes issue #320 on GitHub
https://github.com/openssl/openssl/issues/320

Cheers

_______________________________________________
openssl-bugs-mod mailing list
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Hanno Böck-4
On Sat, 22 Aug 2015 10:21:42 +0000
Alessandro Ghedini via RT <[hidden email]> wrote:

> Which adds support for Camellia GCM and adds the correspondent TLS
> cipher suites. Most of the code comes from the AES GCM
> implementation, so maybe there's an opportunity for some refactoring
> there.

May I ask one question: Why?

From what I observed others are moving away from camellia [1]. So why
should openssl add more camellia support?

From what I'm aware camellia is a block cipher like aes, and there is
no serious problem with AES. Does camellia offer any significant
advantage in any situation that would justify increasing support?

I think a large problem of TLS in general and OpenSSL in particular is
feature bloat. In the past features got added not because there was a
clear need for them, but "because we can". After all the whole
heartbleed story can largely be explained by that. I'd propose that
OpenSSL doesn't add any new features without a clear explanation what
advantage they bring in which situation - and who is likely going to
use that feature.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Rich Salz via RT
On Sat, 22 Aug 2015 10:21:42 +0000
Alessandro Ghedini via RT <[hidden email]> wrote:

> Which adds support for Camellia GCM and adds the correspondent TLS
> cipher suites. Most of the code comes from the AES GCM
> implementation, so maybe there's an opportunity for some refactoring
> there.

May I ask one question: Why?

From what I observed others are moving away from camellia [1]. So why
should openssl add more camellia support?

From what I'm aware camellia is a block cipher like aes, and there is
no serious problem with AES. Does camellia offer any significant
advantage in any situation that would justify increasing support?

I think a large problem of TLS in general and OpenSSL in particular is
feature bloat. In the past features got added not because there was a
clear need for them, but "because we can". After all the whole
heartbleed story can largely be explained by that. I'd propose that
OpenSSL doesn't add any new features without a clear explanation what
advantage they bring in which situation - and who is likely going to
use that feature.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Rich Salz via RT
In reply to this post by Hanno Böck-4
> May I ask one question: Why?

Excellent question.  "Because there is an RFC" is not a good enough reason any more, I think.
 
> Does camellia offer any significant advantage in
> any situation that would justify increasing support?

Yes, I'd like to know who needs it.

GOST is going to move to an externally-maintained ENGINE (thanks, Dimitry:).  We should look at moving other ciphers out of the core the same way.  The OID's will need to be maintained, since the run-time really wants to deal with NID's, and figuring out how to make them first-class citizens with an EVP interface would take some thought, but Blowfish, Cast, Camellia, SEED, and Whirlpool could all be pushed out, IMHO.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Viktor Dukhovni
On Mon, Aug 24, 2015 at 05:41:19PM +0000, Salz, Rich via RT wrote:

> > Does camellia offer any significant advantage in
> > any situation that would justify increasing support?
>
> Yes, I'd like to know who needs it.
>
> GOST is going to move to an externally-maintained ENGINE (thanks, Dimitry:).
> We should look at moving other ciphers out of the core the same way.  The
> OID's will need to be maintained, since the run-time really wants to deal
> with NID's, and figuring out how to make them first-class citizens with
> an EVP interface would take some thought, but Blowfish, Cast, Camellia,
> SEED, and Whirlpool could all be pushed out, IMHO.

IIRC Camellia is more equal than the others.  In particular its
inclusion in NESSIE and broad adoption make it a plausible "backup"
block cipher after AES.

So while we can consider dropping many of the more obscure and
obsolete algorithms, Camellia is probably best retained.

It is not clear that Intel et. al. will devoide any chip real-estate
to supporting it in hardware, so it will not be quite as attractive
as AES for most users, but it seems to be a fine cipher in most
other regards.

--
        Viktor.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Hubert Kario
In reply to this post by Hanno Böck-4
On Monday 24 August 2015 19:25:24 Hanno Böck wrote:
> On Sat, 22 Aug 2015 10:21:42 +0000
>
> Alessandro Ghedini via RT <[hidden email]> wrote:
> > Which adds support for Camellia GCM and adds the correspondent TLS
> > cipher suites. Most of the code comes from the AES GCM
> > implementation, so maybe there's an opportunity for some refactoring
> > there.
>
> May I ask one question: Why?

because it's the only standardised, widely audited and recommended alternative
to AES, having a different cryptographic construction (Feistel network) that
has been studied even longer is also a good thing

> After all the whole
> heartbleed story can largely be explained by that. I'd propose that
> OpenSSL doesn't add any new features without a clear explanation what
> advantage they bring in which situation - and who is likely going to
> use that feature.

bugs happen, refusing to accept patches just because they can have bugs is
short sighted at best

or can I expect you to express the exact same concerns when ChaCha20 patches
will be proposed?
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Rich Salz via RT
On Monday 24 August 2015 19:25:24 Hanno Böck wrote:
> On Sat, 22 Aug 2015 10:21:42 +0000
>
> Alessandro Ghedini via RT <[hidden email]> wrote:
> > Which adds support for Camellia GCM and adds the correspondent TLS
> > cipher suites. Most of the code comes from the AES GCM
> > implementation, so maybe there's an opportunity for some refactoring
> > there.
>
> May I ask one question: Why?

because it's the only standardised, widely audited and recommended alternative
to AES, having a different cryptographic construction (Feistel network) that
has been studied even longer is also a good thing

> After all the whole
> heartbleed story can largely be explained by that. I'd propose that
> OpenSSL doesn't add any new features without a clear explanation what
> advantage they bring in which situation - and who is likely going to
> use that feature.

bugs happen, refusing to accept patches just because they can have bugs is
short sighted at best

or can I expect you to express the exact same concerns when ChaCha20 patches
will be proposed?
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Hanno Böck-4
In reply to this post by Hubert Kario
On Mon, 24 Aug 2015 22:32:24 +0200
Hubert Kario <[hidden email]> wrote:

> > After all the whole
> > heartbleed story can largely be explained by that. I'd propose that
> > OpenSSL doesn't add any new features without a clear explanation
> > what advantage they bring in which situation - and who is likely
> > going to use that feature.
>
> bugs happen, refusing to accept patches just because they can have
> bugs is short sighted at best
>
> or can I expect you to express the exact same concerns when ChaCha20
> patches will be proposed?
I think the situation with chacha20 is very different. Its advantages
seem convincing enough that some major players responsible for a
large part of internet connections are already using it.
I see nothing alike with camellia.

If you can give me a convincing argument who would use camellia and for
what I may reconsider my opinion. "It's standardized" doesn't mean
anyone actually uses or wants to use it. Right now I only see people
deprecating it.

I think the thing that bite with heartbleed was: A very obscure
feature, nobody used it, nobody cared for it, so nobody looked at it.
Camellia looks very similar, I doubt it will gain any significant use
even if openssl supported camellia-gcm modes.

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Rich Salz via RT
On Mon, 24 Aug 2015 22:32:24 +0200
Hubert Kario <[hidden email]> wrote:

> > After all the whole
> > heartbleed story can largely be explained by that. I'd propose that
> > OpenSSL doesn't add any new features without a clear explanation
> > what advantage they bring in which situation - and who is likely
> > going to use that feature.
>
> bugs happen, refusing to accept patches just because they can have
> bugs is short sighted at best
>
> or can I expect you to express the exact same concerns when ChaCha20
> patches will be proposed?
I think the situation with chacha20 is very different. Its advantages
seem convincing enough that some major players responsible for a
large part of internet connections are already using it.
I see nothing alike with camellia.

If you can give me a convincing argument who would use camellia and for
what I may reconsider my opinion. "It's standardized" doesn't mean
anyone actually uses or wants to use it. Right now I only see people
deprecating it.

I think the thing that bite with heartbleed was: A very obscure
feature, nobody used it, nobody cared for it, so nobody looked at it.
Camellia looks very similar, I doubt it will gain any significant use
even if openssl supported camellia-gcm modes.

--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Hubert Kario
In reply to this post by Hanno Böck-4
On Tuesday 25 August 2015 08:58:57 Hanno Böck wrote:

> On Mon, 24 Aug 2015 22:32:24 +0200
>
> Hubert Kario <[hidden email]> wrote:
> > > After all the whole
> > > heartbleed story can largely be explained by that. I'd propose that
> > > OpenSSL doesn't add any new features without a clear explanation
> > > what advantage they bring in which situation - and who is likely
> > > going to use that feature.
> >
> > bugs happen, refusing to accept patches just because they can have
> > bugs is short sighted at best
> >
> > or can I expect you to express the exact same concerns when ChaCha20
> > patches will be proposed?
>
> I think the situation with chacha20 is very different. Its advantages
> seem convincing enough that some major players responsible for a
> large part of internet connections are already using it.
> I see nothing alike with camellia.
https://yourlogicalfallacyis.com/bandwagon

> If you can give me a convincing argument who would use camellia and for
> what I may reconsider my opinion. "It's standardized" doesn't mean
> anyone actually uses or wants to use it. Right now I only see people
> deprecating it.

Some devices supported only RC4 since "everybody else does support it anyway
so there is no need for fallback ciphers and it's fast", now it is biting us
hard...

And yes, servers do use it (44%) and prefer it. With Firefox 29 client hello
close to 1% of connections to TLS enabled Alexa top 1 million servers ended up
with some kind of Camellia cipher.

> I think the thing that bite with heartbleed was: A very obscure
> feature, nobody used it, nobody cared for it, so nobody looked at it.
> Camellia looks very similar, I doubt it will gain any significant use
> even if openssl supported camellia-gcm modes.

Unlike heartbeat, disabling camellia ciphers does not require recompilation of
openssl, application's that use openssl or both.

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)

Rich Salz via RT
On Tuesday 25 August 2015 08:58:57 Hanno Böck wrote:

> On Mon, 24 Aug 2015 22:32:24 +0200
>
> Hubert Kario <[hidden email]> wrote:
> > > After all the whole
> > > heartbleed story can largely be explained by that. I'd propose that
> > > OpenSSL doesn't add any new features without a clear explanation
> > > what advantage they bring in which situation - and who is likely
> > > going to use that feature.
> >
> > bugs happen, refusing to accept patches just because they can have
> > bugs is short sighted at best
> >
> > or can I expect you to express the exact same concerns when ChaCha20
> > patches will be proposed?
>
> I think the situation with chacha20 is very different. Its advantages
> seem convincing enough that some major players responsible for a
> large part of internet connections are already using it.
> I see nothing alike with camellia.
https://yourlogicalfallacyis.com/bandwagon

> If you can give me a convincing argument who would use camellia and for
> what I may reconsider my opinion. "It's standardized" doesn't mean
> anyone actually uses or wants to use it. Right now I only see people
> deprecating it.

Some devices supported only RC4 since "everybody else does support it anyway
so there is no need for fallback ciphers and it's fast", now it is biting us
hard...

And yes, servers do use it (44%) and prefer it. With Firefox 29 client hello
close to 1% of connections to TLS enabled Alexa top 1 million servers ended up
with some kind of Camellia cipher.

> I think the thing that bite with heartbleed was: A very obscure
> feature, nobody used it, nobody cared for it, so nobody looked at it.
> Camellia looks very similar, I doubt it will gain any significant use
> even if openssl supported camellia-gcm modes.

Unlike heartbeat, disabling camellia ciphers does not require recompilation of
openssl, application's that use openssl or both.

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (1K) Download Attachment