Subject: RFC 4009

From: Alfred Hönes <[email-masked]>
Date: Mon, 28 Feb 2005 10:09:20 +0100 (MEZ)

Hello,

I just picked up and read the new RFC 4009 authored by you,
to find significant concerns with section 2.2. (on pages 3
and 4 of the RFC):

(A)

Unfortunately, within a few lines in the RFC text, the variable
name 'X' gets used for two very distinct purposes and contexts:

  o   X = X0 || X1 || X2 || X3                            (2)
      ... the 32 bit wide input to the function G

  o   X used as formal argument in the defining equations for
      the 'SS-boxes' SS0 ... SS3
      ... a single octet (8 bit wide entity),
          [application of the formulas - see (3) below - will
           substitute X0, ..., X3 in turn for the arguments]

Perhaps, it would have been better to use another symbol,
e.g. 'x', for the latter purpose.

(B)

As far as I can see, feeding the definition of the SS-boxes given
in the last 4 text/formule lines on page 3 into the formula on top
of page 4,

     Z = SS0(X0) ^ SS1(X1) ^ SS2(X2) ^ SS3(X3)            (3)

does ***NOT*** yield the same result as using the primary defining
formulas given for Z0  ... Z3  in the first formula block of
section 2.2., together with

     Z = Z0 || Z1 || Z2 || Z3                             (1).

I suspect a mis-ordering in the use of m0 ... m3 in the
equations defining SS0 ... SS3 :

With regard to the formulas (1), (2), and (3) (as numbered above),
the 'matrix' pattern of the 4x4 terms in braces { ... } , obtained
from the formula block defining SS0 ... SS3 by substitution of Xi
for the argument of SSi (i=0,1,2,3) - as required in (3) -, should
be the matrix transpose of the pattern of the same terms in braces
appearing in the formula block defining Z0 ... Z3 , e. g. the
first 'column' of {...} terms for SSi() should contain the {...}
terms appearing in the formula for Z0.
But this is not the case.

Therefore, I suspect that the last 6 text/formula lines on page 3
of RFC 4009 should in fact read (including the enhancement from (A)
above):

  "
  To increase the efficiency of the G function, four extended S-boxes
  'SS-box' (See Appendix A.2) are defined as follows:

   SS0(x)= {S1(x) & m0} || {S1(x) & m1} || {S1(x) & m2} || {S1(x) & m3}
   SS1(x)= {S2(x) & m1} || {S2(x) & m2} || {S2(x) & m3} || {S2(x) & m0}
   SS2(x)= {S1(x) & m2} || {S1(x) & m3} || {S1(x) & m0} || {S1(x) & m1}
   SS3(x)= {S2(x) & m3} || {S2(x) & m0} || {S2(x) & m1} || {S2(x) & m2}
  "

Please check and comment.

If you agree with my arguments, we should immediately submit an
errata note for these issues to the RFC Editor for publication
on the RFC Errata web page.

In this case, I also recommend to include a textual enhancement
for the first sentence of section 2.3., replacing:

    "The key schedule generates each round subkeys."
by:
    "The key schedule generates subkeys for each round."

And finally, for completeness, it would have been useful as well to
give additional Informational Reference(s) for the seedMAC (and the
[seed]CBC) algorithm(s)/construct(s) mentioned in section 2.5. -
e.g.  RFC 3610 (and RFC 2451 / NIST SP 800-38A) [?].

Best Regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+