This is the
talk page for discussing improvements to the
Camellia (cipher) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It is requested that a photograph be
included in this article to
improve its quality.
The external tool WordPress Openverse may be able to locate suitable images on Flickr and other web sites. |
Matt, why did you revert the sentence structure in the first paragraph? Its awkward with the colon and ambiguous as well. I thought E2 and Misty were companies until I hovered and checked the links. Arvindn 15:57, 16 Apr 2004 (UTC)
— Matt 16:08, 16 Apr 2004 (UTC)
The Camellia specification is unclear in its description of the GF(28) inversion used in the S-boxes. It would be very helpful if its details could be clarified. In particular, how does one go from the expression of the inversion using the GF(24) sub-field, to a straight-forward hardware implementation. Cmcqueen1975 ( talk) 12:42, 18 December 2008 (UTC)
There's a lot of tenical jargon in this article, especially in the Security analysis section. I know it's a very technical topic, but a lot can be done to make it less intimidating.
Don't relay only on interlinks ( [[ ]] ), explain really technical things briefly. Remember, it's supposed to read like a encyclopedia, not a manual. lol -- ℐℴℯℓ ℳ. ℂℌAT ✐ 22:07, 12 August 2010 (UTC)
The IETF does not endorse the use of any cryptographic algorithms. The IETF merely assigns code points which allows their use. -- 66.30.5.63 ( talk) 20:12, 15 November 2011 (UTC)
I don't want to change the page, but after doing some light research, it appears that using Camellia makes your product regulated by Japan. See the Camellia IP page here http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html , specifically "Important Notice" number 3 which reads: Any product equipped with one or more of the above-mentioned encryption algorithms (including the open sources) is a controlled product regulated under the Japanese Foreign Exchange and Foreign Trade Law, though the algorithms are public. When you plan to export or take this product out of Japan, or provide any juridical person having its main office in Japan, concerning property or business of such a juridical person which is located overseas, please obtain a permission, as required by the Law and related regulations, from the Japanese Government. — Preceding unsigned comment added by 50.169.251.228 ( talk) 17:18, 13 January 2014 (UTC)
The article states that the contents may be too technical with regards to the security analysis. But you cannot explain a security analysis for a 5 year old. This is a block cipher that has not been standardized by NIST, I don't think the security analysis needs to be put in a different form. If people don't understand it they should deepen their knowledge. — Preceding unsigned comment added by 62.195.211.133 ( talk) 22:28, 22 December 2014 (UTC)
I have some doubts about two bug reports in Bugzilla. It is a little difficult sometimes to know if those bug reports actually correspond to the claims they are trying to back up.
Support for Camellia was added to the final release of Mozilla Firefox 3 in 2008[7] (disabled by default as of Firefox 33 in 2014[8] in spirit of the "Proposal to Change the Default TLS Ciphersuites Offered by Browsers",[9] and will be dropped from version 37 in 2015[10]).
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765 [10] https://bugzilla.mozilla.org/show_bug.cgi?id=1037098
I'm not saying that it is wrong. In fact, the information provided by the article seems to be correct (as Mozilla seems to be taking the AES/Rijndael-only path, which can be risky). But bug reports can be really messy and confusing sometimes to be used as a encyclopaedic source. Additional information from articles instead of bug reports can be helpful. I did a little research but couldn't nothing better than these: [1] [2] (the first one seems to be a good for article reference, the second one maybe not, although is linked by Mozilla). MPA Neto ( talk) 01:15, 10 March 2015 (UTC)
I added a one-line sentence to cover what it's named after. I found this covered on the NTT link -- so it's definitely not original research, but don't know if a specific citation is necessary for this. ( https://info.isl.ntt.co.jp/crypt/eng/camellia/intro.html) Gushi ( talk) 00:50, 7 April 2019 (UTC)
https://www.researchgate.net/publication/220833839_Truncated_Differential_Cryptanalysis_of_Camellia
December 2001DOI:10.1007/3-540-45861-1_3
SourceDBLPConference: Information Security and Cryptology - ICISC 2001, 4th International Conference Seoul, Korea, December 6-7, 2001.
Proceedings Camellia is a block cipher cooperatively designed by NTT and Mitsubshi Electric Corporation and submitted to NESSIE.
In this paper, we present truncated differential cryptanalysis of modified Camellia reduced to 7 and 8 rounds.For modified Camellia with 7 rounds we can find 8-bit key with 3 of 281 plaintexts and for modified Camellia with 8 rounds we can find 16-bit key with 3 of 282 plaintexts.
2A02:C7C:BEBF:C300:C560:41FD:99A0:FD7E ( talk) 10:39, 14 October 2022 (UTC)
https://www.sciencedirect.com/science/article/abs/pii/S0020019015000472
•We analyze the security of Camellia in the impossible differential context.
•We improve the complexity of the impossible differential attacks on 12 rounds of Camellia-192 and 14 rounds of Camellia-256.
•We present the first attack on 13 rounds of Camellia-192.
In this paper, we study the security of the block ciphers Camellia-192 and Camellia-256 in the impossible differential context. In particular, we present the first attack on 13 rounds of Camellia-192 with layers. An attack on 14 rounds of Camellia-256 requiring less complexity than the previous impossible differential attacks is also described.
2A02:C7C:BEBF:C300:95C5:4DE4:5393:204A ( talk) 23:07, 21 October 2022 (UTC)
This is the
talk page for discussing improvements to the
Camellia (cipher) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It is requested that a photograph be
included in this article to
improve its quality.
The external tool WordPress Openverse may be able to locate suitable images on Flickr and other web sites. |
Matt, why did you revert the sentence structure in the first paragraph? Its awkward with the colon and ambiguous as well. I thought E2 and Misty were companies until I hovered and checked the links. Arvindn 15:57, 16 Apr 2004 (UTC)
— Matt 16:08, 16 Apr 2004 (UTC)
The Camellia specification is unclear in its description of the GF(28) inversion used in the S-boxes. It would be very helpful if its details could be clarified. In particular, how does one go from the expression of the inversion using the GF(24) sub-field, to a straight-forward hardware implementation. Cmcqueen1975 ( talk) 12:42, 18 December 2008 (UTC)
There's a lot of tenical jargon in this article, especially in the Security analysis section. I know it's a very technical topic, but a lot can be done to make it less intimidating.
Don't relay only on interlinks ( [[ ]] ), explain really technical things briefly. Remember, it's supposed to read like a encyclopedia, not a manual. lol -- ℐℴℯℓ ℳ. ℂℌAT ✐ 22:07, 12 August 2010 (UTC)
The IETF does not endorse the use of any cryptographic algorithms. The IETF merely assigns code points which allows their use. -- 66.30.5.63 ( talk) 20:12, 15 November 2011 (UTC)
I don't want to change the page, but after doing some light research, it appears that using Camellia makes your product regulated by Japan. See the Camellia IP page here http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html , specifically "Important Notice" number 3 which reads: Any product equipped with one or more of the above-mentioned encryption algorithms (including the open sources) is a controlled product regulated under the Japanese Foreign Exchange and Foreign Trade Law, though the algorithms are public. When you plan to export or take this product out of Japan, or provide any juridical person having its main office in Japan, concerning property or business of such a juridical person which is located overseas, please obtain a permission, as required by the Law and related regulations, from the Japanese Government. — Preceding unsigned comment added by 50.169.251.228 ( talk) 17:18, 13 January 2014 (UTC)
The article states that the contents may be too technical with regards to the security analysis. But you cannot explain a security analysis for a 5 year old. This is a block cipher that has not been standardized by NIST, I don't think the security analysis needs to be put in a different form. If people don't understand it they should deepen their knowledge. — Preceding unsigned comment added by 62.195.211.133 ( talk) 22:28, 22 December 2014 (UTC)
I have some doubts about two bug reports in Bugzilla. It is a little difficult sometimes to know if those bug reports actually correspond to the claims they are trying to back up.
Support for Camellia was added to the final release of Mozilla Firefox 3 in 2008[7] (disabled by default as of Firefox 33 in 2014[8] in spirit of the "Proposal to Change the Default TLS Ciphersuites Offered by Browsers",[9] and will be dropped from version 37 in 2015[10]).
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1036765 [10] https://bugzilla.mozilla.org/show_bug.cgi?id=1037098
I'm not saying that it is wrong. In fact, the information provided by the article seems to be correct (as Mozilla seems to be taking the AES/Rijndael-only path, which can be risky). But bug reports can be really messy and confusing sometimes to be used as a encyclopaedic source. Additional information from articles instead of bug reports can be helpful. I did a little research but couldn't nothing better than these: [1] [2] (the first one seems to be a good for article reference, the second one maybe not, although is linked by Mozilla). MPA Neto ( talk) 01:15, 10 March 2015 (UTC)
I added a one-line sentence to cover what it's named after. I found this covered on the NTT link -- so it's definitely not original research, but don't know if a specific citation is necessary for this. ( https://info.isl.ntt.co.jp/crypt/eng/camellia/intro.html) Gushi ( talk) 00:50, 7 April 2019 (UTC)
https://www.researchgate.net/publication/220833839_Truncated_Differential_Cryptanalysis_of_Camellia
December 2001DOI:10.1007/3-540-45861-1_3
SourceDBLPConference: Information Security and Cryptology - ICISC 2001, 4th International Conference Seoul, Korea, December 6-7, 2001.
Proceedings Camellia is a block cipher cooperatively designed by NTT and Mitsubshi Electric Corporation and submitted to NESSIE.
In this paper, we present truncated differential cryptanalysis of modified Camellia reduced to 7 and 8 rounds.For modified Camellia with 7 rounds we can find 8-bit key with 3 of 281 plaintexts and for modified Camellia with 8 rounds we can find 16-bit key with 3 of 282 plaintexts.
2A02:C7C:BEBF:C300:C560:41FD:99A0:FD7E ( talk) 10:39, 14 October 2022 (UTC)
https://www.sciencedirect.com/science/article/abs/pii/S0020019015000472
•We analyze the security of Camellia in the impossible differential context.
•We improve the complexity of the impossible differential attacks on 12 rounds of Camellia-192 and 14 rounds of Camellia-256.
•We present the first attack on 13 rounds of Camellia-192.
In this paper, we study the security of the block ciphers Camellia-192 and Camellia-256 in the impossible differential context. In particular, we present the first attack on 13 rounds of Camellia-192 with layers. An attack on 14 rounds of Camellia-256 requiring less complexity than the previous impossible differential attacks is also described.
2A02:C7C:BEBF:C300:95C5:4DE4:5393:204A ( talk) 23:07, 21 October 2022 (UTC)