[openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Rich Salz via RT]

Re-closing this; nobody on the team is interested. Kurt also pointed out some
concerns.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Hubert Kario via RT]

On Thursday 04 February 2016 17:10:45 Kurt Roeckx via RT wrote:
> On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote:
> > Really?
> > 
> > That's all we get, a one-liner, no explanation, no rationale,
> > response? It's not even "brand new" functionality, Camellia as a
> > raw cipher is already in there, the only difference is wrapping it
> > into GCM-based suites. Patches are available, too.
> 
> I think the concerns are:
> - Nobody else seems to be using Camellia

over 40% of Alexa top 1 million TLS enabled servers enable Camellia

GnuTLS has implementation of Camellia-GCM for quite some time already

> - We don't have a constant time implementation of it

I don't see it mentioned anywhere in documentation, especially not in 
ciphers(1) man page. So, is it not so severe, or should the Camellia be 
removed from DEFAULT?

> - For processors that have AESNI, it's slower than AES

Irrelevant, nobody proposes to replace AES with Camellia

> - Adding more ciphers to the default list will just increase the
>   client hello and not change anything.
> 
> That being said, I don't think there should be a problem adding
> the support.  I'm just not sure about enabling it by default.

I don't think anyone argues that it needs to be added to DEFAULT.

-- 
Regards,
Hubert Kario
Senior 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
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich via RT]

> over 40% of Alexa top 1 million TLS enabled servers enable Camellia

That's different than actual use, as you know.
 
> I don't see it mentioned anywhere in documentation, especially not in
> ciphers(1) man page. So, is it not so severe, or should the Camellia be
> removed from DEFAULT?

It probably will be.

I think the bottom line is that nobody on the team is enthusiastic, or even 
willing, to put into the work to add and support it.  And nobody is wiling to 
put it into the codebase these days without an internal commitment to support 
it. 

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich]

> over 40% of Alexa top 1 million TLS enabled servers enable Camellia

That's different than actual use, as you know.
 
> I don't see it mentioned anywhere in documentation, especially not in
> ciphers(1) man page. So, is it not so severe, or should the Camellia be
> removed from DEFAULT?

It probably will be.

I think the bottom line is that nobody on the team is enthusiastic, or even 
willing, to put into the work to add and support it.  And nobody is wiling to 
put it into the codebase these days without an internal commitment to support 
it. 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey via RT]

I said I would be willing to help, but got no reply on how best to ramp up
on developing a stable addition likely to be accepted by the dev team.

I read the material online about contributing, and it refers ultimately
back to this mailing list. Are there other online materials/resources I can
read up on to get a better handle on contributing meaningful additions? I
am aware that my work may still not be adopted by the core dev team, but
would like to take on this project for my own edification.

Thanks in advance for your consideration and help in this matter,
Nich
On Feb 8, 2016 6:49 AM, "Salz, Rich via RT"  wrote:

>
> > over 40% of Alexa top 1 million TLS enabled servers enable Camellia
>
> That's different than actual use, as you know.
>
> > I don't see it mentioned anywhere in documentation, especially not in
> > ciphers(1) man page. So, is it not so severe, or should the Camellia be
> > removed from DEFAULT?
>
> It probably will be.
>
> I think the bottom line is that nobody on the team is enthusiastic, or
> even willing, to put into the work to add and support it.  And nobody is
> wiling to put it into the codebase these days without an internal
> commitment to support it.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey]

I said I would be willing to help, but got no reply on how best to ramp up
on developing a stable addition likely to be accepted by the dev team.

I read the material online about contributing, and it refers ultimately
back to this mailing list. Are there other online materials/resources I can
read up on to get a better handle on contributing meaningful additions? I
am aware that my work may still not be adopted by the core dev team, but
would like to take on this project for my own edification.

Thanks in advance for your consideration and help in this matter,
Nich
On Feb 8, 2016 6:49 AM, "Salz, Rich via RT"  wrote:

>
> > over 40% of Alexa top 1 million TLS enabled servers enable Camellia
>
> That's different than actual use, as you know.
>
> > I don't see it mentioned anywhere in documentation, especially not in
> > ciphers(1) man page. So, is it not so severe, or should the Camellia be
> > removed from DEFAULT?
>
> It probably will be.
>
> I think the bottom line is that nobody on the team is enthusiastic, or
> even willing, to put into the work to add and support it.  And nobody is
> wiling to put it into the codebase these days without an internal
> commitment to support it.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey via RT]

Ok thanks for clarifying. What does it take to become a member of the dev
team?

I'm still years away from having enough crypto/C programming experience,
what in particular should I be working on?

Basically, what kind of skills would you like to see?

Thanks again for the quick reply, I'll check out the link you sent.

Stay awesome,
Nich
On Feb 8, 2016 9:38 AM, "Salz, Rich via RT"  wrote:

>
> > I said I would be willing to help, but got no reply on how best to ramp
> up on
> > developing a stable addition likely to be accepted by the dev team.
>
> There's no hard-and-fast rules.  We recently added some text:
> https://openssl.org/community/getting-started.html
>
> But again, for the specific request here, someone from the dev team has to
> be willing to do it.
>
> If it's really important, well, someone can always start a fork.  Or work
> on making it an external ENGINE, like GOST.
>
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich]

> I'm still years away from having enough crypto/C programming experience,
> what in particular should I be working on?

Read the link.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich via RT]

> I'm still years away from having enough crypto/C programming experience,
> what in particular should I be working on?

Read the link.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey]

Ok thanks for clarifying. What does it take to become a member of the dev
team?

I'm still years away from having enough crypto/C programming experience,
what in particular should I be working on?

Basically, what kind of skills would you like to see?

Thanks again for the quick reply, I'll check out the link you sent.

Stay awesome,
Nich
On Feb 8, 2016 9:38 AM, "Salz, Rich via RT"  wrote:

>
> > I said I would be willing to help, but got no reply on how best to ramp
> up on
> > developing a stable addition likely to be accepted by the dev team.
>
> There's no hard-and-fast rules.  We recently added some text:
> https://openssl.org/community/getting-started.html
>
> But again, for the specific request here, someone from the dev team has to
> be willing to do it.
>
> If it's really important, well, someone can always start a fork.  Or work
> on making it an external ENGINE, like GOST.
>
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich via RT]

> I said I would be willing to help, but got no reply on how best to ramp up on
> developing a stable addition likely to be accepted by the dev team.

There's no hard-and-fast rules.  We recently added some text: 
https://openssl.org/community/getting-started.html

But again, for the specific request here, someone from the dev team has to be 
willing to do it.

If it's really important, well, someone can always start a fork.  Or work on 
making it an external ENGINE, like GOST.
 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Alessandro Ghedini via RT]

On Mon, Feb 08, 2016 at 05:30:52pm +, Nich Ramsey via RT wrote:
> I said I would be willing to help, but got no reply on how best to ramp up
> on developing a stable addition likely to be accepted by the dev team.

FWIW, the necessary code has already been written (by me) for this particular
feature [0]... the problem isn't lack of code here.

Cheers

[0] https://github.com/openssl/openssl/pull/374

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4075
Please log in as guest with password guest if prompted



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

Really?

That's all we get, a one-liner, no explanation, no rationale, response?
It's not even "brand new" functionality, Camellia as a raw cipher is already
in there, the only difference is wrapping it into GCM-based suites. Patches
are available, too.

Sounds like OpenSSL isn't as open as one might think.

On 04/02/2016 05:38, Rich Salz via RT wrote:
> We're not taking on these new Camellia ciphers for now. -- Rich Salz,
> OpenSSL dev team; rs...@openssl.org
>
>
>



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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Really?

That's all we get, a one-liner, no explanation, no rationale, response?
It's not even "brand new" functionality, Camellia as a raw cipher is already
in there, the only difference is wrapping it into GCM-based suites. Patches
are available, too.

Sounds like OpenSSL isn't as open as one might think.

On 04/02/2016 05:38, Rich Salz via RT wrote:
> We're not taking on these new Camellia ciphers for now. -- Rich Salz,
> OpenSSL dev team; rs...@openssl.org
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iF4EAREIAAYFAlazIiQACgkQEguw022l8qw2wQD8CuBYlCXVKk2VUvMSxYcqnKDg
LULZr0x5hCfalVbl/cIA/3Ro3hbllmrL6RqBy6ir/l6bUSmlWnB+nG++scYIkNem
=koMx
-END PGP SIGNATURE-


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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey]

Moonchild: what advantages does Camellia have over AES? Sincerely asking
since I'm not familiar.

OpenSSL team: I second Moonchild's curiosity, why is there no plan for
integration when the raw cipher is already present in the code base? If
it's a lack of resources you can dedicate, would you be open to someone
outside the dev team contributing the necessary code?

Thanks in advance for your consideration,
Nich
On Feb 4, 2016 2:10 AM, "Moonchild via RT"  wrote:

> Really?
>
> That's all we get, a one-liner, no explanation, no rationale, response?
> It's not even "brand new" functionality, Camellia as a raw cipher is
> already
> in there, the only difference is wrapping it into GCM-based suites. Patches
> are available, too.
>
> Sounds like OpenSSL isn't as open as one might think.
>
> On 04/02/2016 05:38, Rich Salz via RT wrote:
> > We're not taking on these new Camellia ciphers for now. -- Rich Salz,
> > OpenSSL dev team; rs...@openssl.org
> >
> >
> >
>
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey via RT]

Moonchild: what advantages does Camellia have over AES? Sincerely asking
since I'm not familiar.

OpenSSL team: I second Moonchild's curiosity, why is there no plan for
integration when the raw cipher is already present in the code base? If
it's a lack of resources you can dedicate, would you be open to someone
outside the dev team contributing the necessary code?

Thanks in advance for your consideration,
Nich
On Feb 4, 2016 2:10 AM, "Moonchild via RT"  wrote:

> Really?
>
> That's all we get, a one-liner, no explanation, no rationale, response?
> It's not even "brand new" functionality, Camellia as a raw cipher is
> already
> in there, the only difference is wrapping it into GCM-based suites. Patches
> are available, too.
>
> Sounds like OpenSSL isn't as open as one might think.
>
> On 04/02/2016 05:38, Rich Salz via RT wrote:
> > We're not taking on these new Camellia ciphers for now. -- Rich Salz,
> > OpenSSL dev team; rs...@openssl.org
> >
> >
> >
>
>
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/02/2016 11:18, Nich Ramsey via RT wrote:
> Moonchild: what advantages does Camellia have over AES? Sincerely asking 
> since I'm not familiar.

It's comparable to AES in terms of how it can theoretically be broken with
algebra, as well as its processing capabilities, but as far as I know there
are no known successful attacks that weaken it, and the closest anyone has
come to attacking it has been against a reduced/non-full version of the
128-bit strength cipher that still required 2^116 encryptions and the same
amount of plaintexts. The full one has never budged. That alone would make
it a very desirable cipher.
Unless, of course, you have a personal grudge against ciphers not coming
from American soil (it's a Japanese-origin cipher).
See also my rationale in my original post on this topic about international
diversity with strong, modern encryption. Camellia is widely-adopted in a
whole range of security applications.

There are plenty of RFCs about Camellia, but in this context most notably
RFC6367 proposing exactly this for inclusion in TLS with GCM.

RFC5932 is a standards document describing Camellia in TLS as a whole.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iF4EAREIAAYFAlazMLsACgkQEguw022l8qy+KwD9H3Rm0qaXxcts49jvKuL54frb
rzpF/WlvtiMlYDNXgEUA/1k9HjoEbLp9THY3nrHZ4Rx0wXcgT0O4b/817Cr+3iJM
=JoAw
-END PGP SIGNATURE-


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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich via RT]

I missed a link: https://github.com/openssl/openssl/issues/320

Nobody is pressuring us.  I am sure you mean that in a kind and concerned way, 
and are not trying to be insulting.

If you can find someone on the openssl-dev team who is willing to take on the 
work, then it could go into OpenSSL.  Otherwise, consider implementing it as an 
external engine (like GOST), or do your own downstream fork.



-
http://rt.openssl.org/Ticket/Display.html?id=4075

Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich]

> If you see ways in which the code in proposed pull requests is
> unmaintainable, share them.

Nobody on the team is able to take the time to do it.  
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Kurt Roeckx]

On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote:
> Really?
> 
> That's all we get, a one-liner, no explanation, no rationale, response?
> It's not even "brand new" functionality, Camellia as a raw cipher is already
> in there, the only difference is wrapping it into GCM-based suites. Patches
> are available, too.

I think the concerns are:
- Nobody else seems to be using Camellia
- We don't have a constant time implementation of it
- For processors that have AESNI, it's slower than AES
- Adding more ciphers to the default list will just increase the
  client hello and not change anything.

That being said, I don't think there should be a problem adding
the support.  I'm just not sure about enabling it by default.


Kurt

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Hubert Kario]

On Thursday 04 February 2016 13:08:15 Salz, Rich via RT wrote:
> > That's all we get, a one-liner, no explanation, no rationale,
> > response?
> Take a look at some of the discussion here:
>   https://github.com/openssl/openssl/pull/154
>   https://github.com/openssl/openssl/pull/148

You mean the "Many thanks for your patch. Applied"? :>

If you see ways in which the code in proposed pull requests is 
unmaintainable, share them.

Saying "we may not have resources later" is unconvincing. Especially 
given that we're talking just about a new mode created by combining 
already implemented cipher and integrity mechanism. Mode necessary to 
support an ENISA recommended cipher in TLSv1.3.

-- 
Regards,
Hubert Kario
Senior 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

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Kurt Roeckx via RT]

On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote:
> Really?
> 
> That's all we get, a one-liner, no explanation, no rationale, response?
> It's not even "brand new" functionality, Camellia as a raw cipher is already
> in there, the only difference is wrapping it into GCM-based suites. Patches
> are available, too.

I think the concerns are:
- Nobody else seems to be using Camellia
- We don't have a constant time implementation of it
- For processors that have AESNI, it's slower than AES
- Adding more ciphers to the default list will just increase the
  client hello and not change anything.

That being said, I don't think there should be a problem adding
the support.  I'm just not sure about enabling it by default.


Kurt



-
http://rt.openssl.org/Ticket/Display.html?id=4075

Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/02/2016 14:08, Salz, Rich via RT wrote:
> 
>> That's all we get, a one-liner, no explanation, no rationale,
>> response?
> 
> Take a look at some of the discussion here: 
> https://github.com/openssl/openssl/pull/374 
> https://github.com/openssl/openssl/pull/154 
> https://github.com/openssl/openssl/pull/148

None of these have any discussion. 148 and 154 are dupes and got merged. 374
was closed because nobody bothered to give it any attention and the dev got
tired of rebasing when there was no indication that it would ever get
attention. What did you expect, that someone would just keep working on
something for naught?

So, basically, you ignored someone long enough that they dropped it.

Once again, no explanation is given, no rationale.
Are you being put under pressure by someone? Should someone make a sane fork
of OpenSSL instead? Or can we just actually work together to improve a lib
here? Seriously.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iF4EAREIAAYFAlazVn8ACgkQEguw022l8qx3rgEAndOysatLhd3j5LxxIdhfMiAS
I3ZEyMQQxgewPU60CQ8A/2vkByqPlDCrHITP3+ZQTh/ffwOgMlNugvqGjDW0s2BE
=qACi
-END PGP SIGNATURE-



-
http://rt.openssl.org/Ticket/Display.html?id=4075

Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich via RT]

> That's all we get, a one-liner, no explanation, no rationale, response?

Take a look at some of the discussion here:
https://github.com/openssl/openssl/pull/374
https://github.com/openssl/openssl/pull/154
https://github.com/openssl/openssl/pull/148

I would suggest that if you want to continue the discussion, do it on 
openssl-dev with a new subject line (so it doesn't get threaded into this RT 
ticket)


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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Blumenthal, Uri - 0553 - MITLL]

On 2/4/16, 12:10 , "openssl-dev on behalf of Kurt Roeckx via RT"
 wrote:

>On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote:
>> Really?
>> 
>> That's all we get, a one-liner, no explanation, no rationale, response?
>> It's not even "brand new" functionality, Camellia as a raw cipher is
>>already
>> in there, the only difference is wrapping it into GCM-based suites.
>>Patches
>> are available, too.
>
>I think the concerns are:
>- Nobody else seems to be using Camellia

I thought it’s used pretty widely in Asia.

>- We don't have a constant time implementation of it

Something to write in the documentation - not everybody needs to worry
about this (contrary to what some academia publications seemed to imply).

>- For processors that have AESNI, it's slower than AES

So…? 

People who want to use it, most likely do it for reasons other than speed.

>- Adding more ciphers to the default list will just increase the
>  client hello and not change anything.

???

>That being said, I don't think there should be a problem adding
>the support.  I'm just not sure about enabling it by default.

Enabling by default probably is unnecessary, IMHO.


smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey via RT]

I'm new to implementing crypto, but this seems like a great learning
opportunity.

What's the best way for me to get ramped up through self-study? I'm
interested in the Camellia cipher, and contributing meaningful additions to
the OpenSSL library.

Moonchild: thank you for your detailed explanation of the Camellia cipher.
This seems like a worthwhile cause, since having many alternative, strong
cipher suites is of great benefit.

Kurt: I agree with you, until there are more people using Camellia it
shouldn't be on by default. It would be nice to have the option to manually
enable it though, especially for people like Moonchild that have a special
need/affinity for the cipher.

Thanks to everyone for continued discussion on this topic.

Nich
On Feb 4, 2016 9:11 AM, "Kurt Roeckx via RT"  wrote:

> On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote:
> > Really?
> >
> > That's all we get, a one-liner, no explanation, no rationale, response?
> > It's not even "brand new" functionality, Camellia as a raw cipher is
> already
> > in there, the only difference is wrapping it into GCM-based suites.
> Patches
> > are available, too.
>
> I think the concerns are:
> - Nobody else seems to be using Camellia
> - We don't have a constant time implementation of it
> - For processors that have AESNI, it's slower than AES
> - Adding more ciphers to the default list will just increase the
>   client hello and not change anything.
>
> That being said, I don't think there should be a problem adding
> the support.  I'm just not sure about enabling it by default.
>
>
> Kurt
>
>
>
> -
> http://rt.openssl.org/Ticket/Display.html?id=4075
>
> Please log in as guest with password guest if prompted
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


-
http://rt.openssl.org/Ticket/Display.html?id=4075

Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Nich Ramsey]

I'm new to implementing crypto, but this seems like a great learning
opportunity.

What's the best way for me to get ramped up through self-study? I'm
interested in the Camellia cipher, and contributing meaningful additions to
the OpenSSL library.

Moonchild: thank you for your detailed explanation of the Camellia cipher.
This seems like a worthwhile cause, since having many alternative, strong
cipher suites is of great benefit.

Kurt: I agree with you, until there are more people using Camellia it
shouldn't be on by default. It would be nice to have the option to manually
enable it though, especially for people like Moonchild that have a special
need/affinity for the cipher.

Thanks to everyone for continued discussion on this topic.

Nich
On Feb 4, 2016 9:11 AM, "Kurt Roeckx via RT"  wrote:

> On Thu, Feb 04, 2016 at 10:10:06AM +, Moonchild via RT wrote:
> > Really?
> >
> > That's all we get, a one-liner, no explanation, no rationale, response?
> > It's not even "brand new" functionality, Camellia as a raw cipher is
> already
> > in there, the only difference is wrapping it into GCM-based suites.
> Patches
> > are available, too.
>
> I think the concerns are:
> - Nobody else seems to be using Camellia
> - We don't have a constant time implementation of it
> - For processors that have AESNI, it's slower than AES
> - Adding more ciphers to the default list will just increase the
>   client hello and not change anything.
>
> That being said, I don't think there should be a problem adding
> the support.  I'm just not sure about enabling it by default.
>
>
> Kurt
>
>
>
> -
> http://rt.openssl.org/Ticket/Display.html?id=4075
>
> Please log in as guest with password guest if prompted
>
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Rich Salz via RT]

We're not taking on these new Camellia ciphers for now.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 12:47:21AM +, Moonchild via RT wrote:
> Hello people,
> 
> An enhancement request here for OpenSSL to add support for Camellia in GCM
> with ECC key exchange.
> 
> Rationale:
> Camellia has been recognized as a modern and supported cipher by ENISA,
> NESSIE, CRYPTREC, ISO and IETF among others so should be supported
> long-term. OpenSSL currently only supports the (rather expensive) DHE/RSA
> CBC+IV versions of the suite, and should be updated with the ECC and GCM
> modes of operation.
> 
> It's important to have at least one cipher coming from non-US expert bodies
> that is maintained to the same level as AES currently is, and OpenSSL seems
> to be trailing behind in that respect. I would request addition of at least
> the following:
> 
> TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc086)
> TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc08a)
> And possibly their 256-bit counterparts

Patches for this are available at [0], however there has been some resistance
to adding the new TLS cipher suites to OpenSSL (see [1]), so the discussion has
stalled.

> These suites are already supported in e.g. GNUTLS, Botan and PolarSSL, iiuc.
> Firefox will also be adding the GCM versions of Camellia to NSS

Do you have a source for the news above? IIRC Firefox used to support Camellia,
but dropped it in v37 or so.

Cheers

[0] https://github.com/openssl/openssl/pull/374
[1] https://rt.openssl.org/Ticket/Display.html?id=4017


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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/10/2015 10:53, Alessandro Ghedini via RT wrote:
> Patches for this are available at [0], however there has been some
> resistance to adding the new TLS cipher suites to OpenSSL (see [1]), so
> the discussion has stalled.

That's really disappointing! I don't understand the resistance to this
addition. It's a cipher with no known attacks found over the past decade or
so...

>> These suites are already supported in e.g. GNUTLS, Botan and PolarSSL,
>> iiuc. Firefox will also be adding the GCM versions of Camellia to NSS
> 
> Do you have a source for the news above? IIRC Firefox used to support
> Camellia, but dropped it in v37 or so.

Other libs supporting this:

GNUTLS: http://gnutls.org/manual/html_node/Supported-ciphersuites.html
Botan: http://botan.randombit.net/manual/tls.html#tls-policies
PolarSSL: https://tls.mbed.org/supported-ssl-ciphersuites

Addition to Firefox/NSS:
See recent discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=1211248
(which addresses the premature removal of Camellia CBC ciphers)
and recent activity on
https://bugzilla.mozilla.org/show_bug.cgi?id=940119
(the actual implementation bug, which had stalled for a while but seems to
want to get moving again. It has a reviewed patch.)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iF4EAREIAAYFAlYWQZkACgkQEguw022l8qzFBgD/d+FXvjUQA8CiqpA1ID1hm5em
DFTBvTWBq5h5TIITRQ0A/0szG+yjimez7doxczfqzCpa8pb67BgegSAkUpsF6z8a
=hAzy
-END PGP SIGNATURE-


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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Salz, Rich via RT]

Also, note that the earliest this could happen is for 1.1 (it's a new feature), 
and it's not high on our priority list for that release right now.  Patches 
that are regularly rebased against master would help.


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

Re: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Alessandro Ghedini via RT]

On Thu, Oct 08, 2015 at 11:39:56am +, Salz, Rich via RT wrote:
> Also, note that the earliest this could happen is for 1.1 (it's a new
> feature), and it's not high on our priority list for that release right now.
> Patches that are regularly rebased against master would help.

I rebase my patches on master regularly when changes that cause merge conflicts
are pushed, so my camellia patches should merge cleanly.

Cheers


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

[openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites

[Moonchild via RT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello people,

An enhancement request here for OpenSSL to add support for Camellia in GCM
with ECC key exchange.

Rationale:
Camellia has been recognized as a modern and supported cipher by ENISA,
NESSIE, CRYPTREC, ISO and IETF among others so should be supported
long-term. OpenSSL currently only supports the (rather expensive) DHE/RSA
CBC+IV versions of the suite, and should be updated with the ECC and GCM
modes of operation.

It's important to have at least one cipher coming from non-US expert bodies
that is maintained to the same level as AES currently is, and OpenSSL seems
to be trailing behind in that respect. I would request addition of at least
the following:

TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc086)
TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc08a)
And possibly their 256-bit counterparts

These suites are already supported in e.g. GNUTLS, Botan and PolarSSL, iiuc.
Firefox will also be adding the GCM versions of Camellia to NSS, and my own
browser (Pale Moon) also has it slated for the next milestone. Considering
the large use of OpenSSL to build other software on, including big names,
e.g. nginx, it's of great importance to add these suites.

Thanks for your consideration,
  Moonchild (AKA Mark)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)

iF4EAREIAAYFAlYVsD8ACgkQEguw022l8qzGgAD+K6r2gxYYQRjrfAqz+JX1ClG9
1wsCrrMe1GZlnQLjAS0BAJmLVXej56Xpd8qNK4+tMucquUIjip8TNxTKyQu/MOeB
=wzz5
-END PGP SIGNATURE-

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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