Why did revert the sentence structure in the first paragraph? edit

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)

Erk, sorry, didn't realise it was a revert; and you're absolutely right. I've put it back to your version with parentheses, which may help.

— Matt 16:08, 16 Apr 2004 (UTC)

The Camellia specification is unclear edit

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)Reply

There's a lot of tenical jargon in this article edit

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)Reply

Not approved for use by IETF edit

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)Reply

Japanese Export Laws? edit

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)Reply

FAQ about export of encryption systems (only Japanese version is available) says:
  • Export of encryption systems (softwares and hardwares) shown in below is regulated by Japanese law.
    • symmetric-key encryption with 56 bit or longer key size
    • public-key encryption with 512 bit or longer key size (in case of ECC, 112 bit or longer)
  • In case of encryption softwares, we do not need to get permission from Japanese government in these cases:
    • softwares are provided to the general public via website, or
    • softwares are not provided to the general public via website (purchased software, via CD, etc.), but satisfy these 3 demands:
      • anyone can buy or download with no fee, and
      • users can not modify encryption system, and
      • special support from supplier or shop is not required
  • In case of encryption hardwares, we do not need to get permission from Japanese government in these cases:
    • hardwares satisfy these 3 demands:
      • anyone can buy, and
      • users can not modify encryption system, and
      • special support from supplier or shop is not required, or
    • temporary export (and re-import): ex. cellular phones or PCs for business use in oversea, or
    • hardwares are cheaper than ¥1,000,000 (except for Iran, Iraq, or North Korea)
I think this regulation is similar to that of U.S. (Java, AES, etc.) --Claw of Slime (talk) 17:14, 14 January 2014 (UTC)Reply
"(…)When you plan to export or take this product out of Japan(…)"[1] "(…)I think this regulation is similar to that of U.S. (Java, AES, etc.)(…)"[2] 50.169.251.228, I think that quote you posted[1] and the other by CoS[2] pretty much explains the big picture. There are restrictions for products that will exported from Japan with strong encryption (because cryptography is considered by several governments a weapon), but not general or international restrictions for specific ciphers/cyphers (most of them are patent free, royalty free, patent expired, open source or public domain). There are some articles here on this subject: Cryptography law, Export of cryptography, Export of cryptography from the United States and also Restrictions on the import of cryptography. Camellia has been shipped in several open source projects with no publicly available legal issues. MPA Neto (talk) 05:05, 10 March 2015 (UTC)Reply

Too technical edit

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)Reply

I think the explanation is adequate, but maybe too concise. I think the technical box shoud be removed. Modern cryptology is not simple, even for "5 year old"'s. :P The article just needs to be expanded and things are going to get clearer. MPA Neto (talk) 12:00, 9 March 2015 (UTC)Reply
I agree with MPA Neto. --Claw of Slime (talk) 15:04, 9 March 2015 (UTC)Reply
Maybe things get clearer also when the article gets some diagrams, like in the AES/Rijndael article. But getting diagrams has always been a problem in WP. Unfortunately the images in that article doesn't seem to make available templates and softwares that have been used to make those SVGs. MPA Neto (talk) 00:33, 10 March 2015 (UTC)Reply

Some doubts about bug reports (Bugzilla) sources edit

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)Reply

Yes. MDC article "Site Compatibility for Firefox 33" is a good candidate of reference for disabling Camellia in Fx 33. Discussion in Google Group is not needed. On the other hand, bugzilla is the only reference for dropping of support of Camellia in Fx 37 now. I hope MDC article "Site Compatibility for Firefox 37" or release note of Fx 37 will mention about drop of Camellia. --Claw of Slime (talk) 03:52, 11 March 2015 (UTC)Reply

Name origin edit

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)Reply

Truncated Differential Cryptanalysis of Camellia (Lee, Hong and others, 2001) edit

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)Reply

Impossible differential attack on 13-round Camellia-192 and Camellia-256 (Blondeau and others, 2015) edit

https://www.sciencedirect.com/science/article/abs/pii/S0020019015000472

Highlights edit

•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.

Abstract edit

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)Reply