Re: [Cfrg] KCipher-2

"David McGrew (mcgrew)" <> Fri, 07 December 2012 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBAC821F8798 for <>; Fri, 7 Dec 2012 10:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mPFnunMgo8nX for <>; Fri, 7 Dec 2012 10:23:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B573B21F85E1 for <>; Fri, 7 Dec 2012 10:23:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2792; q=dns/txt; s=iport; t=1354904593; x=1356114193; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=/LIucKslh4QgJT6Wx3oNfxIr4Z89oCjR4rzX8IUwg4I=; b=Ykxw6v5HjuCLKAcK1JexQk+2s/Tuf5EnSiKXcnOAWx2Hrf0viq15zVbj FlWJE9y8in/D8q6cS7/eFCAEGPwvZYzx0fX3A/j/OJbdQdxeUvYrBS0s4 B1Xqm3suDKnnkvJWyslO7WNvSSorWhAbfNE037ZN/9rnl5sjaHjiNcCTI s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=McAfee;i="5400,1158,6919"; a="150583235"
Received: from ([]) by with ESMTP; 07 Dec 2012 18:23:13 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qB7INDpp004773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 18:23:13 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 12:23:12 -0600
From: "David McGrew (mcgrew)" <>
To: Jim Schaad <>, "" <>
Thread-Topic: [Cfrg] KCipher-2
Thread-Index: Ac3UOkozciLafGFZSP6gO4lpsIWbxAAdgC4A
Date: Fri, 07 Dec 2012 18:23:12 +0000
Message-ID: <>
In-Reply-To: <015c01cdd43a$f18f3b60$d4adb220$>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Cfrg] KCipher-2
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Dec 2012 18:23:14 -0000

Hi Jim,

On 12/7/12 12:23 AM, "Jim Schaad" <> wrote:

>The ISE is debating the publication of the document
>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
>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
>table lookup.  Is there any reason to require that actual values be
>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
>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.



>Thanks for any and all input,
>Jim Schaad
>Cfrg mailing list