Draft; draft-lee-rfc4009bis-01.txt
Review: Joel M. Halpern
Date: 21 maj 2005
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.)