# RFC Errata

### 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