The IESG has no problem with the publication of 'The 128-bit Blockcipher CLEFIA' <draft-katagi-clefia-03.txt> as an Informational RFC. The IESG would also like the RFC-Editor to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-katagi-clefia/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the comment log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-katagi-clefia/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary This is an independent stream submission. Document Quality The CLEFIA cipher appears to be quite good. It has been invented for "lightweight" cryptography. In three years since CLEFIA has been announced, the only attacks that were found were those where a fault was introduced in the later rounds of CLEFIA. This might be theoretically interesting but not very practical, as far as I can tell. On the other hand, there were papers ? mostly, in Japanese, but also two independent ones in English, presented at the Indocrypt and the Inscrypt conferences - where the authors demonstrated the futility of many commonly known attacks. They could not even break CLEFIA with a reduced number of rounds. There are some similarities between CLEFIA and AES. The block size and the available key sizes are the same in both algorithms. Both algorithms employ the substitution tables (S-boxes) and each one uses key scheduling. CLEFIA uses the Feistel structure and this is the construction that makes the only known attach ? the fault induction attack described in the previous paragraph ? possible. My guess is that the Feistel structure was needed to produce a ?lightweight? algorithm. Personnel Tim Polk reviewed this document for the IESG. Allen Roginsky performed a more detailed review of the algorithm. RFC Editor Note Proposed response to the RFC Editor 1. The IESG has concluded that there is no conflict between this document and IETF work.
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
