Re: [Cfrg] KCipher-2

["David McGrew (mcgrew)" <[e-mail]>]

Hi Jim,

On 12/7/12 12:23 AM, "Jim Schaad" <[e-mail]> wrote:

>The ISE is debating the publication of the document
>http://tools.ietf.org/html/draft-kiyomoto-kcipher2-07
>which describes the KCipher2 algorithm.  I would like to get more eyes to
>look at the draft and provide comments on the following issues:
>
>1.  Does anybody know any reason why we should not publish this document?

I think it is appropriate for the document to be published by ISE.   It
seems like sound work and a well written document.   My comments are:

* it appears that only one independent security analysis has been done.
This is OK, but not great.   If other analyses have been done, I suggest
the authors cite them directly.

* the document should state what the requirements on the IV are; is it
intended to be distinct (as with counter mode), or does it need to be
random or pseudorandom (as with CBC mode)?   Also, the security
considerations should describe what security properties go away when the
IV is poorly chosen.

* the security considerations should note the absence of authentication,
and the importance of that security service.  "Kcipher2 does not provide
data origin authentication, and thus it SHOULD be used in conjunction with
a message authentication code of comparable cryptographic strength", or
something like that.

* it would be good to verify that there have been multiple independent
implementations.   Perhaps this requirement could slide because there is
reference code in the draft.

A nit: I noticed a stray comma in the line " , where GF_mult_by_2 and
GF_mult_by_3 are multiplication functions"

>
>2.  In section 2.4.2 of the document, a procedure is given to determine
>the
>values of a0, a1, a2 and a3.  In appendix A, a simple lookup table is
>provided which allows the normal program to not care about what the values
>of a0, a1, a2 and a3 are as they can do the required multiplication step
>by
>table lookup.  Is there any reason to require that actual values be
>provided
>for a0, a1, a2 and a3 so that somebody who is not well up on the math (for
>example me) could actually check that the values are both correct
>according
>to what they have said is the method of deriving them and that the lookup
>tables are correct.

I think it is reasonable to ask for more information on the field
representation and what the elements of the table mean.   The authors
should be able to provide this with little trouble.   But I wouldn't rate
it as critical, it seems possible to figure it out.

Regards,

David

>
>
>Thanks for any and all input,
>
>Jim Schaad
>
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg