Re: Informational RFC to be: <draft-katagi-clefia-03.txt>

[The IESG <[e-mail]>]

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.