Re: Adding support for Camellia on OpenSSH.
2010/07/19 17:41, Damien Miller wrote: We won't add Camellia until we update OpenSSL (no point in having multiple library version cranks), I'll take a look at it then. OK, I will wait until OpenBSD use OpenSSL version = 1.0. Then I will send you and ML the updated patch again.
Re: Adding support for Camellia on OpenSSH.
2010/7/18 Yoshisato YANAGISAWA yanagis...@csg.is.titech.ac.jp: other people use it shows that the algorithm is well-tested. I know AES is also approved cipher of NESSIE. However, I see some reasons to believe Camellia is better than AES. - Full spec. Camellia 128bits, 192bits, and 256bits are not broken yet. While, AES-192 is logically broken. [1] All these related key attacks against AES are rather irrelevant in practice. OpenSSH does not use a contrived scheme to derive a new session key from the previous session keys. - More compact hardware implementation. [2] - Run faster under small amount of memory. [2] A lot of platforms have hardware acceleration for AES, but not for Camellia. A good recent example is Intel AES-NI. Best regards, Dries
Re: Adding support for Camellia on OpenSSH.
On Mon, 19 Jul 2010, Yoshisato YANAGISAWA wrote: OpenBSD has already included Camellia source code as a part of OpenSSL. It is disabled by default, though. At the time OpenSSL included Camellia, NTT had shown following news release: http://www.ntt.co.jp/news/news01e/0104/010417.html NTT also announced that their Camellia implementation also becomes open source distributed under BSDL, GPL, and so on: http://www.ntt.co.jp/news/news06e/0604/060413a.html Are there any problems? We won't add Camellia until we update OpenSSL (no point in having multiple library version cranks), I'll take a look at it then. -d
Re: Adding support for Camellia on OpenSSH.
Free software you can't modify is not free software. This is totally true. We've been here before. Please get this situation resolved.
Re: Adding support for Camellia on OpenSSH.
On Monday 19 July 2010 18:26:15 Ted Unangst wrote: On Sun, Jul 18, 2010 at 11:14 AM, Yoshisato YANAGISAWA yanagis...@csg.is.titech.ac.jp wrote: Not to mention there are software patent claims againt camellia. That's a no go right there. OpenBSD has already included Camellia source code as a part of OpenSSL. It is disabled by default, though. At the time OpenSSL included Camellia, NTT had shown following news release: http://www.ntt.co.jp/news/news01e/0104/010417.html NTT also announced that their Camellia implementation also becomes open source distributed under BSDL, GPL, and so on: http://www.ntt.co.jp/news/news06e/0604/060413a.html Are there any problems? The first link says Caution: This statement is valid only for implementing Camellia, EPOC, PSEC, and ESIGN, respectively, as is, and does not permit modification of said algorithms. The second link says you no longer need to apply to get a license, but still restricts it to only people using Camellia. Free software you can't modify is not free software. That's especially galling for software where there are real security considerations: suppose you find a flaw in the algorithm--you can't fix it? Gag. -- STeve Andre' Disease Control Warden Dept. of Political Science Michigan State University A day without Windows is like a day without a nuclear incident.
Re: Adding support for Camellia on OpenSSH.
On Mon, Jul 19, 2010 at 8:22 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jul 19, 2010 at 06:37:21PM -0400, STeve Andre' wrote: On Monday 19 July 2010 18:26:15 Ted Unangst wrote: Free software you can't modify is not free software. Algorithm != implementation (== software). That's especially galling for software where there are real security considerations: suppose you find a flaw in the algorithm--you can't fix it? You mean like Debian fixed the usage of uninitialized variables in OpenSSL? In the cryptographic community the need to fix an algorithm is generally considered a good sign to stay away from the algorithm completely. Can you name a case where an algorithm was fixed and the result was actually a stronger algorithm? Avoiding weak keys for example is not a modification of an algorithm, it is just a more specific choice of choosing random keys. I am talking about actually modifying the encryption algorithm. Side note: the complain is also pointless because a modified algorithm wouldn't be interoperable anyway, making the point mood as well. Bullshit. If blowfish had come with such retarded no-modification terms, we wouldn't have the bcrypt password hashing scheme we use today.
Re: Adding support for Camellia on OpenSSH.
On Mon, Jul 19, 2010 at 09:02:35PM -0400, Ted Unangst wrote: On Mon, Jul 19, 2010 at 8:22 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Mon, Jul 19, 2010 at 06:37:21PM -0400, STeve Andre' wrote: On Monday 19 July 2010 18:26:15 Ted Unangst wrote: Free software you can't modify is not free software. Algorithm != implementation (== software). That's especially galling for software where there are real security considerations: suppose you find a flaw in the algorithm--you can't fix it? You mean like Debian fixed the usage of uninitialized variables in OpenSSL? In the cryptographic community the need to fix an algorithm is generally considered a good sign to stay away from the algorithm completely. Can you name a case where an algorithm was fixed and the result was actually a stronger algorithm? Avoiding weak keys for example is not a modification of an algorithm, it is just a more specific choice of choosing random keys. I am talking about actually modifying the encryption algorithm. Side note: the complain is also pointless because a modified algorithm wouldn't be interoperable anyway, making the point mood as well. Bullshit. If blowfish had come with such retarded no-modification terms, we wouldn't have the bcrypt password hashing scheme we use today. And where excatly does bcrypt modify the Blowfish algorithm? Of course, it greatly helps to prove your point that the description of the algorithm in the source is generic for any ECB algorithm... Joerg
Re: Adding support for Camellia on OpenSSH.
2010/07/18 12:22, Ted Unangst wrote: In general, other people do it is a weak justification. I don't see any reason to believe camellia would actually be better than aes. Nessie picked aes too, you know. other people use it shows that the algorithm is well-tested. I know AES is also approved cipher of NESSIE. However, I see some reasons to believe Camellia is better than AES. - Full spec. Camellia 128bits, 192bits, and 256bits are not broken yet. While, AES-192 is logically broken. [1] - More compact hardware implementation. [2] - Run faster under small amount of memory. [2] [1] http://eprint.iacr.org/2010/248.pdf [2] http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/c02e_report2.pdf Not to mention there are software patent claims againt camellia. That's a no go right there. OpenBSD has already included Camellia source code as a part of OpenSSL. It is disabled by default, though. At the time OpenSSL included Camellia, NTT had shown following news release: http://www.ntt.co.jp/news/news01e/0104/010417.html NTT also announced that their Camellia implementation also becomes open source distributed under BSDL, GPL, and so on: http://www.ntt.co.jp/news/news06e/0604/060413a.html Are there any problems?
Adding support for Camellia on OpenSSH.
Hi all, Will you try my following patch to enable the Camellia block cipher on OpenSSH? The Camellia block cipher is one of the approved encryption method in European Union (NESSIE) and Japan (CRYPTREC) as well as has been specified in several Internet RFCs. It is also used by several OSS projects, such as Linux, FreeBSD, OpenSSL, Firefox and so on. My patch contains two parts. First part enables Camellia in OpenSSL, and second part makes it available in OpenSSH. It is patch for lib/libssl and usr.bin/ssh, respectively. In 2009, Biryukov showed AES was not as safe as expected. [1] Is it a good time to have an alternative? Thank you in advance, Yoshisato Yanagisawa. [1] http://eprint.iacr.org/2009/317 Index: crypto/Makefile === RCS file: /cvs/src/lib/libssl/crypto/Makefile,v retrieving revision 1.52 diff -c -r1.52 Makefile *** crypto/Makefile 3 Feb 2010 20:49:00 - 1.52 --- crypto/Makefile 20 Jun 2010 03:56:10 - *** *** 82,89 SRCS+=bn_sqr.c bn_recp.c bn_mont.c bn_mpi.c bn_mod.c SRCS+=bn_exp2.c bn_ctx.c bn_opt.c SRCS+=bn_sqrt.c bn_kron.c bn_x931p.c bn_const.c bn_depr.c bn_gf2m.c bn_nist.c ! #SRCS+= camellia.c cmll_cbc.c cmll_cfb.c cmll_ctr.c ! #SRCS+= cmll_ecb.c cmll_misc.c cmll_ofb.cq #SRCS+= cms_asn1.c cms_att.c cms_cd.c cms_dd.c cms_enc.c cms_env.c #SRCS+= cms_err.c cms_ess.c cms_io.c cms_lib.c cms_sd.c cms_smime.c SRCS+=rsa_eay.c rsa_gen.c rsa_lib.c rsa_sign.c --- 82,89 SRCS+=bn_sqr.c bn_recp.c bn_mont.c bn_mpi.c bn_mod.c SRCS+=bn_exp2.c bn_ctx.c bn_opt.c SRCS+=bn_sqrt.c bn_kron.c bn_x931p.c bn_const.c bn_depr.c bn_gf2m.c bn_nist.c ! SRCS+=camellia.c cmll_cbc.c cmll_cfb.c cmll_ctr.c ! SRCS+=cmll_ecb.c cmll_misc.c cmll_ofb.c #SRCS+= cms_asn1.c cms_att.c cms_cd.c cms_dd.c cms_enc.c cms_env.c #SRCS+= cms_err.c cms_ess.c cms_io.c cms_lib.c cms_sd.c cms_smime.c SRCS+=rsa_eay.c rsa_gen.c rsa_lib.c rsa_sign.c *** *** 115,121 SRCS+= bio_enc.c e_cast.c e_xcbc_d.c m_dss.c m_sha1.c p_seal.c SRCS+= bio_md.c e_des.c encode.c m_dss1.c names.c p_sign.c SRCS+= bio_ok.c e_des3.c dig_eng.c evp_enc.c m_md2.c p_verify.c m_ecdsa.c ! #SRCS+= e_camellia.c e_seed.c SRCS+= c_all.c evp_err.c evp_acnf.c evp_cnf.c m_md4.c p5_crpt.c e_old.c SRCS+= c_allc.c evp_key.c m_md5.c p5_crpt2.c SRCS+= c_alld.c e_null.c evp_lib.c p_dec.c --- 115,122 SRCS+= bio_enc.c e_cast.c e_xcbc_d.c m_dss.c m_sha1.c p_seal.c SRCS+= bio_md.c e_des.c encode.c m_dss1.c names.c p_sign.c SRCS+= bio_ok.c e_des3.c dig_eng.c evp_enc.c m_md2.c p_verify.c m_ecdsa.c ! SRCS+= e_camellia.c ! #SRCS+= e_seed.c SRCS+= c_all.c evp_err.c evp_acnf.c evp_cnf.c m_md4.c p5_crpt.c e_old.c SRCS+= c_allc.c evp_key.c m_md5.c p5_crpt2.c SRCS+= c_alld.c e_null.c evp_lib.c p_dec.c Index: crypto/arch/alpha/opensslconf.h === RCS file: /cvs/src/lib/libssl/crypto/arch/alpha/opensslconf.h,v retrieving revision 1.5 diff -c -r1.5 opensslconf.h *** crypto/arch/alpha/opensslconf.h 9 Jan 2009 12:32:25 - 1.5 --- crypto/arch/alpha/opensslconf.h 20 Jun 2010 03:56:10 - *** *** 4,12 /* OpenSSL was configured with the following options: */ #ifndef OPENSSL_DOING_MAKEDEPEND - #ifndef OPENSSL_NO_CAMELLIA - # define OPENSSL_NO_CAMELLIA - #endif #ifndef OPENSSL_NO_CAPIENG # define OPENSSL_NO_CAPIENG #endif --- 4,9 Index: crypto/arch/amd64/opensslconf.h === RCS file: /cvs/src/lib/libssl/crypto/arch/amd64/opensslconf.h,v retrieving revision 1.5 diff -c -r1.5 opensslconf.h *** crypto/arch/amd64/opensslconf.h 9 Jan 2009 12:32:25 - 1.5 --- crypto/arch/amd64/opensslconf.h 20 Jun 2010 03:56:10 - *** *** 4,12 /* OpenSSL was configured with the following options: */ #ifndef OPENSSL_DOING_MAKEDEPEND - #ifndef OPENSSL_NO_CAMELLIA - # define OPENSSL_NO_CAMELLIA - #endif #ifndef OPENSSL_NO_CAPIENG # define OPENSSL_NO_CAPIENG #endif --- 4,9 Index: crypto/arch/arm/opensslconf.h === RCS file: /cvs/src/lib/libssl/crypto/arch/arm/opensslconf.h,v retrieving revision 1.5 diff -c -r1.5 opensslconf.h *** crypto/arch/arm/opensslconf.h 9 Jan 2009 12:32:25 - 1.5 --- crypto/arch/arm/opensslconf.h 20 Jun 2010 03:56:10 - *** *** 4,12 /* OpenSSL was configured with the following options: */ #ifndef OPENSSL_DOING_MAKEDEPEND - #ifndef OPENSSL_NO_CAMELLIA - # define OPENSSL_NO_CAMELLIA - #endif #ifndef OPENSSL_NO_CAPIENG # define OPENSSL_NO_CAPIENG #endif --- 4,9 Index: crypto/arch/hppa/opensslconf.h === RCS file:
Re: Adding support for Camellia on OpenSSH.
In general, other people do it is a weak justification. I don't see any reason to believe camellia would actually be better than aes. Nessie picked aes too, you know. Not to mention there are software patent claims againt camellia. That's a no go right there. On Jul 17, 2010, at 7:12 PM, Yoshisato YANAGISAWA yanagis...@csg.is.titech.ac.jp wrote: Hi all, Will you try my following patch to enable the Camellia block cipher on OpenSSH? The Camellia block cipher is one of the approved encryption method in European Union (NESSIE) and Japan (CRYPTREC) as well as has been specified in several Internet RFCs. It is also used by several OSS projects, such as Linux, FreeBSD, OpenSSL, Firefox and so on. My patch contains two parts. First part enables Camellia in OpenSSL, and second part makes it available in OpenSSH. It is patch for lib/libssl and usr.bin/ssh, respectively. In 2009, Biryukov showed AES was not as safe as expected. [1] Is it a good time to have an alternative? Thank you in advance, Yoshisato Yanagisawa. [1] http://eprint.iacr.org/2009/317 Index: crypto/Makefile === RCS file: /cvs/src/lib/libssl/crypto/Makefile,v retrieving revision 1.52 diff -c -r1.52 Makefile *** crypto/Makefile3 Feb 2010 20:49:00 -1.52 --- crypto/Makefile20 Jun 2010 03:56:10 - *** *** 82,89 SRCS+=bn_sqr.c bn_recp.c bn_mont.c bn_mpi.c bn_mod.c SRCS+=bn_exp2.c bn_ctx.c bn_opt.c SRCS+=bn_sqrt.c bn_kron.c bn_x931p.c bn_const.c bn_depr.c bn_gf2m.c bn_nist.c ! #SRCS+=camellia.c cmll_cbc.c cmll_cfb.c cmll_ctr.c ! #SRCS+=cmll_ecb.c cmll_misc.c cmll_ofb.cq #SRCS+=cms_asn1.c cms_att.c cms_cd.c cms_dd.c cms_enc.c cms_env.c #SRCS+=cms_err.c cms_ess.c cms_io.c cms_lib.c cms_sd.c cms_smime.c SRCS+=rsa_eay.c rsa_gen.c rsa_lib.c rsa_sign.c --- 82,89 SRCS+=bn_sqr.c bn_recp.c bn_mont.c bn_mpi.c bn_mod.c SRCS+=bn_exp2.c bn_ctx.c bn_opt.c SRCS+=bn_sqrt.c bn_kron.c bn_x931p.c bn_const.c bn_depr.c bn_gf2m.c bn_nist.c ! SRCS+=camellia.c cmll_cbc.c cmll_cfb.c cmll_ctr.c ! SRCS+=cmll_ecb.c cmll_misc.c cmll_ofb.c #SRCS+=cms_asn1.c cms_att.c cms_cd.c cms_dd.c cms_enc.c cms_env.c #SRCS+=cms_err.c cms_ess.c cms_io.c cms_lib.c cms_sd.c cms_smime.c SRCS+=rsa_eay.c rsa_gen.c rsa_lib.c rsa_sign.c *** *** 115,121 SRCS+= bio_enc.c e_cast.c e_xcbc_d.c m_dss.c m_sha1.c p_seal.c SRCS+= bio_md.c e_des.c encode.c m_dss1.c names.c p_sign.c SRCS+= bio_ok.c e_des3.c dig_eng.c evp_enc.c m_md2.c p_verify.c m_ecdsa.c ! #SRCS+= e_camellia.c e_seed.c SRCS+= c_all.c evp_err.c evp_acnf.c evp_cnf.c m_md4.c p5_crpt.c e_old.c SRCS+= c_allc.c evp_key.c m_md5.c p5_crpt2.c SRCS+= c_alld.c e_null.c evp_lib.c p_dec.c --- 115,122 SRCS+= bio_enc.c e_cast.c e_xcbc_d.c m_dss.c m_sha1.c p_seal.c SRCS+= bio_md.c e_des.c encode.c m_dss1.c names.c p_sign.c SRCS+= bio_ok.c e_des3.c dig_eng.c evp_enc.c m_md2.c p_verify.c m_ecdsa.c ! SRCS+= e_camellia.c ! #SRCS+= e_seed.c SRCS+= c_all.c evp_err.c evp_acnf.c evp_cnf.c m_md4.c p5_crpt.c e_old.c SRCS+= c_allc.c evp_key.c m_md5.c p5_crpt2.c SRCS+= c_alld.c e_null.c evp_lib.c p_dec.c Index: crypto/arch/alpha/opensslconf.h === RCS file: /cvs/src/lib/libssl/crypto/arch/alpha/opensslconf.h,v retrieving revision 1.5 diff -c -r1.5 opensslconf.h *** crypto/arch/alpha/opensslconf.h9 Jan 2009 12:32:25 - 1.5 --- crypto/arch/alpha/opensslconf.h20 Jun 2010 03:56:10 - *** *** 4,12 /* OpenSSL was configured with the following options: */ #ifndef OPENSSL_DOING_MAKEDEPEND - #ifndef OPENSSL_NO_CAMELLIA - # define OPENSSL_NO_CAMELLIA - #endif #ifndef OPENSSL_NO_CAPIENG # define OPENSSL_NO_CAPIENG #endif --- 4,9 Index: crypto/arch/amd64/opensslconf.h === RCS file: /cvs/src/lib/libssl/crypto/arch/amd64/opensslconf.h,v retrieving revision 1.5 diff -c -r1.5 opensslconf.h *** crypto/arch/amd64/opensslconf.h9 Jan 2009 12:32:25 - 1.5 --- crypto/arch/amd64/opensslconf.h20 Jun 2010 03:56:10 - *** *** 4,12 /* OpenSSL was configured with the following options: */ #ifndef OPENSSL_DOING_MAKEDEPEND - #ifndef OPENSSL_NO_CAMELLIA - # define OPENSSL_NO_CAMELLIA - #endif #ifndef OPENSSL_NO_CAPIENG # define OPENSSL_NO_CAPIENG #endif --- 4,9 Index: crypto/arch/arm/opensslconf.h === RCS file: /cvs/src/lib/libssl/crypto/arch/arm/opensslconf.h,v retrieving revision 1.5 diff -c -r1.5 opensslconf.h *** crypto/arch/arm/opensslconf.h9 Jan 2009 12:32:25 -1.5 --- crypto/arch/arm/opensslconf.h20 Jun 2010 03:56:10 - *** *** 4,12 /* OpenSSL was configured with the following options: */ #ifndef
