Skip to main content

The SEED Encryption Algorithm
draft-lee-rfc4009bis-02

Yes

(Russ Housley)

No Objection

(David Kessens)
(Margaret Cullen)
(Mark Townsley)
(Scott Hollenbeck)
(Ted Hardie)

Note: This ballot was opened for revision 02 and is now closed.

Russ Housley Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection (2005-05-26) Unknown
state in abstract that 4009 is obsoleted
Brian Carpenter Former IESG member
(was Discuss) No Objection
No Objection (2005-05-26) Unknown
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.)
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown