# SHA-3 hash function standard references

I have noticed a slight change in the standard documentation of FIPS-202 and ISO/IEC 10118-3 documents for algorithm 5:rc(t) as below:

ISO/IEC 10118-3

Algorithm 5: rc(t)
Input: integer t
Output: bit rc(t)
Steps:
a)If t mod 255 = 0, return 1.
c)For i from 1 to t mod 255, let:
b) Let R = 10 000 000.
1) R = 0 || R;
2) R[0] = R[0] ⊕ R[8];
3) R[6] = R[6] ⊕ R[8];
4) R[3] = R[3] ⊕ R[8];
5) R[2] = R[2] ⊕ R[8];
6) R = Trunc8


FIPS-202

Algorithm 5: rc(t)
Input:
integer t.
Output:
bit rc(t).
Steps:
1. If t mod 255 = 0, return 1.
2. Let R = 10000000.
3. For i from 1 to t mod 255, let:
a. R = 0 || R;
b. R[0] = R[0] ⊕ R[8];
c. R[4] = R[4] ⊕ R[8];
d. R[5] = R[5] ⊕ R[8];
e. R[6] = R[6] ⊕ R[8];
f. R =Trunc8[R].
4. Return R[0]


Can anybody explain these difference or are the same?

• ISO/IEC 10118-3 is usually paywalled.. Apr 25 at 9:00
• Is the ISO/IEC 10118-3 pseudocode from the published standard ISO/IEC 10118-3:2018 (october 2018), from some FDIS or CD, or from some other source?
– fgrieu
Apr 25 at 14:38
• I've voted to close this since without all of the pseudo-code and definitions from ISO/IEC 10118-3, this question is not answerable at all! Apr 25 at 16:25

The aim of ISO/IEC 10118-3:2018 (partial preview) sections 19 to 22, and appendixes B.14 to B.17, is (I believe) to match the algorithm, results, and test vectors of FIPS 202. Any discrepancy there may be in ISO/IEC 10118-3 w.r.t. FIPS 202 that would change the output is probably unintentional and should be ignored IMHO.

Update: As pointed in comment, even if in the ISO/IEC 10118-3 pseudocode of the question we reorder b) and c), ignore conventions for numbering, and assume the result is implicit, the two algorithms are NOT equivalent due to differences in indexes. I initially missed that.

I can't believe such discrepancy is intentional. I don't have a copy of ISO/IEC 10118-3:2018 to check (this is the fourth and current version, and the only one with SHA3).

• The two algorithms are not the same: the ISO document twiddles different bits ({6,3,2} vs {4,5,6}). This can't be explained by different a endianness convention (it would be {4,3,2}). It could be explained by attempting an endianness flip but accidentally keeping one of the original positions. I don't have the ISO document so I don't know whether it uses the same notations and I don't know if the question quotes it correctly. Apr 25 at 10:07
• SHA3 is SHA3. The ultimate source is NIST and their test vectors. Apr 25 at 10:53
• Ignore ISO. Not just for this but in general. Their whole approach is ridiculous. It's way too behind closed doors. Security standards should not be paywalled. They have also made careless mistakes in the past. Apr 25 at 17:07
• @samuel-lucas6: NIST and other US agencies are not exemplary either. They consistently attempt to standardize or otherwise sneak breakable crypto: 56-bit key in DES, Dual_EC_DRBG (reportedly made default in BSAFE for \$10M), PBKDF2 still deemed acceptable for password hashing, and more. OTOH they tend to make less silly mistakes and err on the side of caution.
– fgrieu
Apr 25 at 17:19
• @fgrieu I completely agree and shouldn't have left that out of my comment. I'm also not a fan of how NIST writes documents. Everybody complains about implementation mistakes and yet specifications are needlessly difficult to read. Apr 25 at 19:56