Subject: [Cfrg] KCipher-2

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Dec 2012 21:23:08 -0800

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?

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.

Thanks for any and all input,

Jim Schaad

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Fri, 7 Dec 2012 18:23:12 +0000

Hi Jim,

>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"

>to what they have said is the method of deriving them and that the lookup

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

>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Jon Callas <[email-masked]>
Date: Fri, 7 Dec 2012 11:00:30 -0800

My answers:

No, and yes.

Publish the document. It's an *informational* RFC. In general, I think that an informational RFC should default against editorializing. For a cipher, yes, you don't want to document something that is bad. We all know and agree that. We all also know the dangers of too many options. But we also know the dangers of monoculture. Providing information is different than interpreting it. I think KCipher-2 meets a bar on that. 

Yes, put the table in. It's a long-standing frustration of mine that crypto documents seem to think that part of the fun is to guess about implementation until you finally get it right. A sort of gameification, I suppose, that makes a spec a choose-your-own adventure. This gets boring, fast. The vast majority of us implementors want to get it done, fast and accurate. Anything that helps that is a Good Thing.

	Jon