[openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
I think this is a duplicate. We're still not implementing Camellia-GCM :) -- 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 #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Tuesday 25 August 2015 08:58:57 Hanno Böck wrote: On Mon, 24 Aug 2015 22:32:24 +0200 Hubert Kario hka...@redhat.com 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 signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Tuesday 25 August 2015 08:58:57 Hanno Böck wrote: On Mon, 24 Aug 2015 22:32:24 +0200 Hubert Kario hka...@redhat.com 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 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 #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Mon, 24 Aug 2015 22:32:24 +0200 Hubert Kario hka...@redhat.com 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: ha...@hboeck.de GPG: BBB51E42 pgp3rZeH9NrDa.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Mon, 24 Aug 2015 22:32:24 +0200 Hubert Kario hka...@redhat.com 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: ha...@hboeck.de GPG: BBB51E42 pgpYAEWAnbRVm.pgp Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org 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: ha...@hboeck.de GPG: BBB51E42 pgpcZUFWrovNx.pgp Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Mon, Aug 24, 2015 at 05:41:19PM +, 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
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org 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: ha...@hboeck.de GPG: BBB51E42 pgpZa5ZbkffsO.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
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
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Monday 24 August 2015 19:25:24 Hanno Böck wrote: On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org 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 signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Monday 24 August 2015 19:25:24 Hanno Böck wrote: On Sat, 22 Aug 2015 10:21:42 + Alessandro Ghedini via RT r...@openssl.org 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 signature.asc Description: This is a digitally signed message part. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
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 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
[openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Sat Aug 22 10:21:42 2015, alessan...@ghedini.me wrote: 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. Note that the AES-GCM IV generation is purely there to satisfy the FIPS requirements. Since Camellia doesn't have such requirements it could instead use the sequence number directly and remove the generation, simplifying the code in the process. The recently added AES-CCM code does this. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4017] [PATCH] Implement Camellia GCM suites (RFC 6367)
On Sat, Aug 22, 2015 at 01:17:36PM +, Stephen Henson via RT wrote: On Sat Aug 22 10:21:42 2015, alessan...@ghedini.me wrote: 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. Note that the AES-GCM IV generation is purely there to satisfy the FIPS requirements. Since Camellia doesn't have such requirements it could instead use the sequence number directly and remove the generation, simplifying the code in the process. The recently added AES-CCM code does this. Ok. I removed the IV generation now, and everything seems to work fine (I've also done some tests with gnutls as well), but more testing may be needed. Cheers ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
