Test Vectors

Cryptographic implementations MUST be tested against published vectors. NIST publishes them for SHA-256:

""                 -> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
"abc"              -> ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
"a" * 1000000      -> cdc76e5c9914fb9281a1c7e284d73e67f1809a48a497200e046d39ccc7112cd0

Why test against vectors? Off-by-one errors in:

• Message schedule loop bounds (16 vs 17)
• Padding boundary calculations
• Endianness (big vs little)
• Initialization values

...can produce a hash that LOOKS like a hash (random-looking 32 bytes) but isn't SHA-256. Vectors catch these silently-wrong implementations.

Common test sets:

• NIST CAVS (Cryptographic Algorithm Validation System)
• Wycheproof (Google) — adversarial test vectors finding bugs
• Empty input + single-block input + multi-block input + boundary cases (55, 56, 57 bytes for one-block padding edge)

SHA-256 itself is already constant-time: every input takes the same 64 rounds of the same operations, and nothing branches or indexes on the data. The timing risk lives in the code around it — comparing a computed tag against an expected one with a byte-by-byte == that returns early leaks how many leading bytes matched. Compare tags with a constant-time equality check instead.