Subject: Re: [Cfrg] I-D Action:draft-kiyomoto-kcipher2-02.txt

From: "Wook Shin" <[email-masked]>
Date: Wed, 13 Apr 2011 10:39:28 +0900

Hello all,

I've revised our previous draft that explains the KCipher-2 stream cipher.
The current version includes some code snippets written in the C language
syntax, so that it could help implementers get clearer idea of how it works
and help them check their outputs with the test vectors mentioned in the
draft.
The new version of the draft can be found at
   http://www.ietf.org/internet-drafts/draft-kiyomoto-kcipher2-02.txt

I have attached a naive implementation of KCipher-2 written in C.
Two files, KCipher2.c and KCipher2.h, are in the attached .zip file,
and no special option is required to compile and run the program.
The code snippets and the test vector running examples in the draft are
 from the the attached code.

Please look at the new version of the draft and the code, and let me
have your comments.

Thank you,

Wook

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 13 Apr 2011 01:23:10 -0700

You have a notation that is leaving me puzzled.

In section 2.1 you say

     <<n   Left circular rotation by n bits

      >>n   Right circular rotation by n bits

Which makes sense.

However in section 2.3.2 you use the notation

           SubK2((IK[3] <<32 8) XOR (IK[3] >>32 24)) XOR
            (0x01, 0x00, 0x00, 0x00);

Which is not covered by the above.  

Additionally I wonder if you mean to use IK[3] in both locations here as (I think)

(IK[3] << 8) XOR (IK[3] >> 24) ---> (IK[3] << 8) XOR (IK[3] << (32-24)) --> (IK[3] << 8) XOR (IK[3] << 8)

jim

> -----Original Message-----
> From: Wook Shin [mailto:[email-masked]]
> Sent: Tuesday, April 12, 2011 6:39 PM
> To: [email-masked]
> Subject: Re: I-D Action:draft-kiyomoto-kcipher2-02.txt
> 
> Hello all,
> 
> Two files, KCipher2.c and KCipher2.h, are in the attached .zip file, and no
> special option is required to compile and run the program.
> Please look at the new version of the draft and the code, and let me have
> your comments.
> 
> Thank you,
> 
> Wook

---

From: "Wook Shin" <[email-masked]>
Date: Wed, 13 Apr 2011 17:30:47 +0900

Jim,

That's my mistake. I think I made that mistake while converting
circular shift operations to the combination of XOR and
non-circular shit operations.

The notation in Section 2.1 should be corrected to

   <<n t     t-bit left shift in an n-bit register
   >>n t     t-bit right shift in an n-bit register

and then, the code

   SubK2((IK[3] <<32 8) XOR (IK[3] >>32 24))
     XOR (0x01, 0x00, 0x00, 0x00);

should mean that

  (1) IK[3] gets left-shifted by 8 bits
  (2) IK[3] gets right-shifted by 24 bits
  (3) call SubK2() by giving "(1) XOR (2) XOR 0x01000000"
      as the input parameter

Best regards,

Wook

On Wed, 13 Apr 2011 17:23:10 +0900, Jim Schaad <[email-masked]>  
wrote:

>> and no
>> have

-- 
Wook Shin
Information Security Laboratory,
KDDI R&D Laboratories, Inc.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Wed, 13 Apr 2011 07:30:35 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Wook Shin
> Sent: Wednesday, April 13, 2011 4:31 AM
> To: [email-masked]; Jim Schaad
> Subject: Re: [Cfrg] I-D Action:draft-kiyomoto-kcipher2-02.txt
> 
> Jim,
> 

If that's what you meant, well, that's a really odd notation.
Typically, where someone writes:
    Func(A) op B
They usually mean:
   - Give the value A to function Func, then take the result, and use it
to perform the operation with B.

A more conventional way of writing what you said you meant would be:

    SubK2((IK[3] <<32 8) XOR (IK[3] >>32 24) XOR
                            (0x01, 0x00, 0x00, 0x00));

So, did you mean what you wrote, or did you mean what you said you
meant?

> > Additionally I wonder if you mean to use IK[3] in both locations
here
> as
> > (I think)
> >
> > (IK[3] << 8) XOR (IK[3] >> 24) ---> (IK[3] << 8) XOR (IK[3] << (32-
> 24))
> > --> (IK[3] << 8) XOR (IK[3] << 8)
> >
> > jim
> >
> >> syntax, so that it could help implementers get clearer idea of how
> it
> >> works
> >> and help them check their outputs with the test vectors mentioned
in
> the
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 13 Apr 2011 17:47:54 -0700

Personal opinion.  It will be easier and clearer if you go back to using circular shift operations.  

Jim

> Sent: Wednesday, April 13, 2011 1:31 AM
> That's my mistake. I think I made that mistake while converting circular shift
> operations to the combination of XOR and non-circular shit operations.
> 
> > (IK[3] << 8) XOR (IK[3] >> 24) ---> (IK[3] << 8) XOR (IK[3] <<
> > (32-24))
> >> The current version includes some code snippets written in the C
> >> language syntax, so that it could help implementers get clearer idea
> >> of how it works and help them check their outputs with the test
> >> vectors mentioned in the draft.
> >> The code snippets and the test vector running examples in the draft
> >> are from the the attached code.
> >>

---

From: "Wook Shin" <[email-masked]>
Date: Thu, 14 Apr 2011 09:42:10 +0900

Scott,

Oops, I was wrong about the location of the right parenthesis in
my previous message. It is (as described in the draft)

SubK2((IK[3] <<32 8) XOR (IK[3] >>32 24)) XOR (0x01, 0x00, 0x00, 0x00);

and that means (as it is written in the above)

   (1) IK[3] gets left-shifted by 8 bits
   (2) IK[3] gets right-shifted by 24 bits
   (3) call SubK2() by giving "(1) XOR (2)" as its input
       and the result will be XOR-ed with 0x01000000

not
>>   (3) call SubK2() by giving "(1) XOR (2) XOR 0x01000000"

Sorry for the confusions.

Wook

On Wed, 13 Apr 2011 23:30:35 +0900, Scott Fluhrer (sfluhrer)  
<[email-masked]> wrote:

>> >> language

---

From: "Wook Shin" <[email-masked]>
Date: Thu, 14 Apr 2011 09:43:56 +0900

> circular shift operations.

I agree. I will go with the circular shift notations in the next
version of the draft.

Wook

On Thu, 14 Apr 2011 09:47:54 +0900, Jim Schaad <[email-masked]>  
wrote:

>> circular shift

---

From: Joachim Strömbergson <[email-masked]>
Date: Thu, 21 Apr 2011 09:52:55 +0200

Aloha!

I've looked at the draft, the code and tested it using the clang+llvm
compiler. Here are some comments. Most things are minor nits.

* I would recommend that you change the name of the code from CamelCase
and esp from ANaiveKCipher2Impl to something more readable. How about
kcipher2_simple, kcipher2_basic or similarly. Naive has a bit of a bad
ring to it.

* Is CamelCase the naming convention used by you? I'm quite certain it
is generally not for C code and makes it a bit harder to read. And
readibility and understandability is the point of this code.

* Move the S_box, INIT and NORMAL definitions to the .c-file. They are
internal to the cipher, not part of the API. A small name thing: In the
draft it is S-box, in the code S_box. Almost the same, just a detail.

* You get extra points for presenting internal state values during
execution of the test vectors. Very usable, good!

* There are two minor errors in the code, probably simple copy crimes.
KCipher2.c:201:51: warning: data argument not used by format string
[-Wformat-extra-args]
    printf("\nFinally, after the Init() call:\n", i); // for debugging
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^

KCipher2.c:380:39: warning: data argument not used by format string
[-Wformat-extra-args]
        printf(" are as follows: \n", j);
               ~~~~~~~~~~~~~~~~~~~~~  ^

* I really like the comment structure of the code with headers
describing what is done, what is being changed etc.

* I would change the declarations to use definitions in <stdint.h>
instead of "unsigned int", "unisgned char". This makes more clear what
bit widths are used.

* Add a license/copyright header to the .h-file too.

* Question: What is the license for KCipher2? The code points to the
draft which reiterates the IETF copyright. Basically this states that
the code is under simplified BSD license. (And you should probably add
such license in the code to make it clearer)

But what I would like to see, both in the draft and in the code is
something that clarifies the KDDI R&D Laboratories, Inc stand on the
license for the KCipher2. Is if free for non commercial, is there patent
claims related to the cipher etc?

Compare to the statement for CAST-128:
http://tools.ietf.org/html/rfc2144#section-3

* In the draft, how about calling the shift registers "LFSR"? They are
normal linear shift registers as far as I can see and IMHO LFSR is the
more common term.

That is all for now.

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================

---

From: "Wook Shin" <[email-masked]>
Date: Fri, 22 Apr 2011 21:41:42 +0900

Hello all,

Now I am revising the draft reflecting the comments that I got from
Joachim, Jim and Uri. (Thank you for the precious comments!)
I think I would be able to have the next version of the draft on
Tuesday next week.

I have a question regarding the copyright issue though. By the IETF
policy, is there a way of giving rights only to non-commercial uses?
My company is preparing the IPR disclosure and just want to know
what kind of options they could have.

Best regards,

Wook

---

From: David McGrew <[email-masked]>
Date: Fri, 22 Apr 2011 06:28:04 -0700

Hi Wook,

> what kind of options they could have.

right to what, exactly?  If you mean rights to "code components", that  
is, snippets of source code that appear in the draft, then the answer  
is yes, if you choose a license statement for the draft that forbids  
derivative works.  From the Trust Legal Provisions, http://trustee.ietf.org/license-info/ 
, "unless one of the legends contained in Section 6.c.i or 6.c.ii is  
included in an IETF Document containing Code Components, such Code  
Components are also licensed to each person who wishes to receive such  
a license on the terms of the “Simplified BSD License", as described  
below."  Section 6.c.i says : "If a Contributor chooses to limit the  
right to make modifications and derivative works of an IETF  
Contribution, then one of the notices in clause (i) or (ii) below must  
be included. Note that an IETF Contribution with such a notice cannot  
become a Standards Track document or, in most cases, a working group  
document."  But note that the current draft includes the statement  
"Code Components extracted from this document must include Simplified  
BSD License text as described in Section 4.e of the Trust Legal  
Provisions and are provided without warranty as described in the  
Simplified BSD License", so that code components in that draft can be  
used under those terms.

If by rights you mean IPR, that is, the right to use a patent, there  
are many options open to your company.  See http://www.ietf.org/ipr/  
for the details and examples of IPR statements made by other  
companies.  Please also note that, if you are aware of patents that  
are essential to the implementation of the draft, you have an  
obligation to the IETF to disclose them.

The above is the IETF policy.  I would like to add a personal note: I  
encourage your employer to consider an IPR statement that allows for  
royalty-free use, and which does not require every implementer to have  
to hire a lawyer, which would be the case if the IPR statement  
requires that some legal paperwork needs to be done.  Here is an  
example of a royalty-free, lawyer-free IPR statement, chosen at  
random: https://datatracker.ietf.org/ipr/752/.  Experience has shown  
that crypto algorithms that require royalties from implementers see  
very low adoption, and are typically rejected by working groups that  
are developing standards.  Even a royalty-free license that requires  
some legal paperwork inhibits adoption, especially in open source  
projects.

David