RFC 4009, "The SEED Encryption Algorithm", February 2005

Note: This RFC has been obsoleted by RFC 4269

Errata ID: 751
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-02-28
Held for Document Update by: Russ Housley

(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}
>   "
>
>

> 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) [?].

It should say:

[see above]

Notes:

from pending

Report New Errata