The SEED Encryption Algorithm
draft-lee-rfc4009bis-02

[Ballot discuss]
The issue raise in Brian's comment appears to be a technical error.
  Please correct the error, and then the document can be approved.

[Ballot comment]
Apparent text ambiguities (from review by Joel Halpern):

This is nearly ready for publication as an informational RFC.  However, it still retains ambiguities that seem distinctly undesirable.


The algorithm in section 2 reads:
      Input : (L, R)

        for i = 1 to 15
                  L = R, R = L ^ F(Ki, R)

        L = L ^ F(K16, R), R=R

        Output : (L, R)
The problem with this is that, as written, this appears t discard the upper 64 bits of key each time through.
I presume that the intent is to save the original R, use the original L and R, and end up with the old R in L and the new R in R. i.e.
    T  = R;
    R = L ^ F(Ki, R);
    L = T;
Presumably the authors intended comma separated expressions in pseudo code to be simultaneous assignment.  Most readers won't read it that way.  Such usage is at best confusing.

This is also the only section where the lack of explicit definition for the pseudo-code language matters.  But it does matter here.

It would be helpful if the division of blocks (or keys) into parts in sections 2 and 2.1 was more explicit (as section 2.2 is) about which part gets the more significant bits, and which part gets the less significant bits.  The reader can guess, but guessing is not good specification.  Thus, the L and R of section 2 should indicate which block is the most significant 64 bits of the input block.  Similarly, Section 2.1 should explicitly indicate which block (R0 and R1) is the more significant 32 bits of R.  And Ki0 and Ki1 should explicitly state which portions of the Ki input they correspond to.  I believe the authors intended the reader to make assumptions based on the notation (L, R), but since this notation is never defined, such assumptions are unwarranted.  Section 2.2 does this properly.

I don't know if it matters, but I can not find the definitions of m0, m1, m2, and m3 in section 2.2.  (It does not seem to matter much, since the actual usage of the m's is captured in teh relationship between the S and SS values, which are documented in the appendix.)

[Ballot discuss]
Apparent text ambiguities (from review by Joel Halpern):

This is nearly ready for publication as an informational RFC.  However, it still retains ambiguities that seem distinctly undesirable.


The algorithm in section 2 reads:
      Input : (L, R)

        for i = 1 to 15
                  L = R, R = L ^ F(Ki, R)

        L = L ^ F(K16, R), R=R

        Output : (L, R)
The problem with this is that, as written, this appears t discard the upper 64 bits of key each time through.
I presume that the intent is to save the original R, use the original L and R, and end up with the old R in L and the new R in R. i.e.
    T  = R;
    R = L ^ F(Ki, R);
    L = T;
Presumably the authors intended comma separated expressions in pseudo code to be simultaneous assignment.  Most readers won't read it that way.  Such usage is at best confusing.

This is also the only section where the lack of explicit definition for the pseudo-code language matters.  But it does matter here.

It would be helpful if the division of blocks (or keys) into parts in sections 2 and 2.1 was more explicit (as section 2.2 is) about which part gets the more significant bits, and which part gets the less significant bits.  The reader can guess, but guessing is not good specification.  Thus, the L and R of section 2 should indicate which block is the most significant 64 bits of the input block.  Similarly, Section 2.1 should explicitly indicate which block (R0 and R1) is the more significant 32 bits of R.  And Ki0 and Ki1 should explicitly state which portions of the Ki input they correspond to.  I believe the authors intended the reader to make assumptions based on the notation (L, R), but since this notation is never defined, such assumptions are unwarranted.  Section 2.2 does this properly.

I don't know if it matters, but I can not find the definitions of m0, m1, m2, and m3 in section 2.2.  (It does not seem to matter much, since the actual usage of the m's is captured in teh relationship between the S and SS values, which are documented in the appendix.)