SHA1MSG2

SHA1MSG2 finishes four words of SHA-1’s message schedule. FIPS 180-4 defines W[t] for t from 16 to 79 as the XOR of W[t-3], W[t-8], W[t-14] and W[t-16], rotated left by one bit. SHA1MSG1 and a PXOR leave the XOR of the last three in each dword of the first operand, W[t] in dword 3 down to W[t+3] in dword 0; SHA1MSG2 XORs in the W[t-3] terms, rotates, and writes W[t] to W[t+3] back in the same order.

The serial word#

Three of the W[t-3] terms are old words, W[t-3], W[t-2] and W[t-1], which the second operand holds in dwords 2, 1 and 0; its dword 3 is not read. The fourth word, W[t+3], needs W[t], which the instruction has only just computed, so the hardware forms W[t] first and feeds it into the last dword. This dependency is why the schedule is split in two: everything before it is plain XORs that SHA1MSG1 and PXOR can do on all four dwords at once.

Two cases recorded on Zen 5 show the rotates. With a first operand of zeros and words of all ones, all four results were all ones. With a first operand of all ones and W[t-3] = 3B73215Eh, dword 3 became 8919BD43h, the complement of 3B73215Eh rotated left by one, and dword 0, built from that value, became EDCC8578h.

Fitting it in#

The second operand is the newest of the four registers that hold the last sixteen words, so a schedule rotates through four registers and each step’s SHA1MSG2 reads the result of the step before. Each output then goes to SHA1NEXTE, which adds E to its first word for SHA1RNDS4. The legacy SSE form is the only one: it keeps bits 128 and up of the register, and a memory operand must be aligned to 16 bytes. The SHA-256 counterpart is SHA256MSG2. AMD’s Zen 5 guide lists SHA1MSG2 as microcoded.

In the optimization guide

What the optimization guide says about SHA1MSG2, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Silvermont to Goldmont Plus

• Vectors and cryptography: Goldmont is the first Atom core with the SHA extensions and RDSEED.

Tremont

• Vectors and cryptography: Intel improved the SHA extensions on Tremont: the round instructions run on port 20 and the message instructions on port 21, so the two can overlap.

Forms

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

# xmm1: W[i-16] ^ W[i-14] ^ W[i-8] for i
# from t to t + 3; src2: W[t-4] to W[t-1];
# the result: W[t] to W[t+3]
src1 = xmm1.read()
w = rol(src1.d[3] ^ src2.d[2], 1, 32)
xmm1.d[3] = w              # W[t]
for i in range(2, -1, -1):
    x = src2.d[i - 1] if i else w  # 3 words
    xmm1.d[i] = rol(src1.d[i] ^ x, 1, 32)
# bits 128 and up of the register are unchanged

Operands

Flags

None: XED records no flag that the forms test or change.

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

All forms

SSE_TYPE_4

Attributes

What else XED records about the forms. How to read.

Memory forms

aligned memory operand

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to SHA1MSG2, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More SHA instructions

• SHA1MSG1
• SHA1NEXTE
• SHA1RNDS4
• SHA256MSG1
• SHA256MSG2
• SHA256RNDS2