TWI900865B - A processor and a method for processing data in the processor - Google Patents

Abstract

A processor includes an execution unit for executing a message padding instruction including an operand field indicating a register buffering a message block segment of a message block to be padded and a mode field indicating which hash function is to be applied to the message block. The execution unit includes a padding circuit configured to receive a message block segment from a register indicated by the operand field, where the message block spans multiple registers in a register file. Based on which hash function is indicated by the mode field, the padding circuit selects a byte location in the message block segment at which to insert at least one padding byte and inserts the at least one padding byte at the byte location within the message block segment. The message block segment as padded by the at least one padding byte is written back to the register file.

Description

A processor and a method for processing data in the processor

The present invention relates generally to data processing, and more particularly to efficiently filling message blocks in hashing algorithms.

An important aspect of data security is the protection of data at rest (e.g., when stored on a data storage device) or in transit (e.g., during transmission) through encryption. Generally speaking, encryption involves converting unencrypted data (called plaintext) into encrypted data (called ciphertext) by combining the plaintext with one or more encryption keys using an encryption function. To recover the plaintext from the ciphertext, the ciphertext is processed using a decryption function using one or more decryption keys. Thus, encryption provides data security by requiring that an additional secret (i.e., a decryption key) be known to a party before they can access the protected plaintext.

In many implementations, data encryption is performed in software running on a general-purpose processor. While implementing encryption in software offers the advantages of being able to choose from a variety of encryption algorithms and easily adapting the chosen encryption algorithm to work with various data lengths, performing encryption in software has the attendant disadvantage of relatively poor performance. As the size of data sets continues to increase dramatically in the "Big Data" era, the performance achieved by implementing encryption in software may become unacceptable when encrypting large messages and/or data sets. Concerns about encryption performance have also arisen due to the increasing need to run enterprise applications using encrypted data in order to mitigate the consequences of "hacktivism" and other cyberattacks and to ensure regulatory compliance. Therefore, there is often a need to provide support for encryption in hardware to achieve improved performance.

The present invention recognizes that one class of cryptographic algorithms for which hardware support is desirable is hash functions, including but not limited to hash functions belonging to the Secure Hash Algorithm (SHA) family of standards. As is known in the art, the SHA family of standards defines hash algorithms approved by the National Institute of Standards (NIST) for generating compressed representations of messages (i.e., message digests). The SHA family of standards is specified in two Federal Information Processing Standards (FIPS): FIPS 180-4, "Secure Hash Standard," and FIPS 202, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions," which are incorporated herein by reference. FIPS 180-4 specifies seven hashing algorithms: Secure Hash Algorithm-1 (SHA-1) and the SHA-2 family of hashing algorithms, including SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. FIPS 202 additionally specifies four SHA-3 hashing algorithms with fixed-length outputs (i.e., SHA3-224, SHA3-256, SHA3-384, and SHA3-512) and two closely related "extendable output" functions (XOFs) named SHAKE128 and SHAKE256 (where SHAKE is an abbreviation for Secure Hash Algorithm and Keccak). Additional uses of the SHA family of standards (e.g., as a stream cipher, an authenticated encryption system, or a tree hashing scheme) have not yet been adopted as NIST standards.

Given the wide variety of hash functions and the data sizes they handle (even within the SHA family of standards), widespread support in hardware for hash functions can result in a significant area of the processor layout being consumed by the circuitry implementing the hash functions. As a result, some hardware solutions choose to implement this circuitry separately from the processor core, for example in a bus-attached application-specific integrated circuit (ASIC) or accelerator. While offering the potential for better performance than some software solutions, the use of such auxiliary circuitry is still subject to bus and memory access latency and message passing overhead, again limiting performance compared to what could be achieved within a high-performance processor core. This performance loss is particularly severe for relatively small messages (e.g., messages that fit within a single message block), which are the majority of SHA messages processed in enterprise servers. The present invention addresses these and other design considerations by efficiently implementing the hash function, including associated message block padding, in the processor.

In one embodiment, a processor includes an instruction fetch unit that fetches instructions to be executed, a register file that includes a plurality of registers for storing source and destination operands, and an execution unit that executes a fill instruction. The fill instruction includes an operand field that indicates one of the plurality of registers for buffering a message block segment of a message block to be filled, and a mode field that indicates which of a plurality of different hash functions is to be applied to the message block. The execution unit includes a fill circuit configured to receive a message block segment from one of the plurality of registers indicated by the operand field of the message fill instruction based on the message fill instruction, wherein the message block spans multiple registers in the register file. Based on which of the plurality of different hash functions is indicated by the mode field of the message fill instruction, the fill circuit selects a byte position in the message block segment at which to insert at least one padding byte and inserts the at least one padding byte at the byte position within the message block segment. The message block segment filled with the at least one padding byte is then written back to the register file.

In one embodiment, a data processing method includes fetching, by an instruction fetch unit of a processor, instructions to be executed by the processor, wherein the instructions include a fill instruction, the fill instruction including an operand field and a mode field, the operand field indicating one of a plurality of registers of a message block segment of a buffer to be filled with a message block, and the mode field indicating which of a plurality of different hash functions to apply to the message block. Upon receiving the fill instruction, an execution unit of the processor executes the fill instruction. Executing the message fill instruction includes receiving a message block segment from one of the plurality of registers indicated by the operand field of the message fill instruction from a register file, wherein the message block spans multiple registers in the register file. Based on which of the plurality of different hash functions is indicated by the mode field of the message fill instruction, selecting a byte position in the message block segment at which to insert at least one padding byte, and inserting the at least one padding byte at the byte position within the message block segment. The message block segment filled with the at least one padding byte is written back to the register file.

In one embodiment, the message block includes a plurality of message block segments, and the execution unit is configured to detect which of the plurality of message block segments the message block segment is based on an indication in the mode field.

In one embodiment, the plurality of different hash functions include a first hash function and a second hash function, and the execution unit is configured to insert both end-of-message (EOM) padding and end-of-block (EOB) padding in the message block segment based on the mode field indicating the first hash function, and is configured to insert EOM padding but not EOB padding in the message block segment based on the mode field indicating the second hash function.

In one embodiment, the operand field of the message fill instruction indicates a length parameter of one of the plurality of registers buffering the message segment, and the execution unit is configured to interpret the length parameter differently based on which of the plurality of hash functions is indicated by the mode field.

In one embodiment, the at least one padding byte includes an end-of-message (EOM) padding byte, selecting the byte position includes generating an EOM enable vector having a length corresponding to the message block segment, and inserting the at least one padding byte includes inserting the EOM padding byte at the byte position in the message block segment based on the EOM enable vector.

In one embodiment, the fill circuit includes a selection circuit configured to select a value of the EOM fill byte based on which of the plurality of different hash functions is indicated by the mode field of the fill instruction.

In one embodiment, the register file is a first register file including a first plurality of registers; the processor includes a second register file including a second plurality of registers, each of which has a length less than a length of the first plurality of registers; and the execution unit is further configured to combine multiple blocks of the message block segment into multiple registers among the second plurality of registers, and transfer all of the multiple blocks to one of the first plurality of registers to form the message block segment. In one embodiment, the processor is further configured to insert end-of-block (EOB) padding into one of the plurality of registers in the second plurality of registers before transferring the plurality of blocks to the one of the first plurality of registers.

In one embodiment, the at least one padding byte includes an end-of-block (EOB) padding byte, selecting the byte position includes generating an EOB enable vector having a length corresponding to the message block segment, and inserting the at least one padding byte includes inserting the EOB padding byte at the byte position in the message block segment based on the EOB enable vector.

In one embodiment, inserting the at least one pad byte includes logically combining the EOB pad byte with an end-of-message (EOM) pad byte.

In one embodiment, the execution unit includes a hash circuit configured to apply a hash function from the SHA family of hash functions to a padded message block including the padded message block segment based on a hash instruction.

In one embodiment, the message block segment is a portion of a message including a plurality of message blocks having a same length of r bits, the padded message blocks include r bits; and each of the plurality of registers has a length less than r bits.

Referring now to the figures and in particular to FIG1 , a high-level block diagram of a data processing system 100 is shown according to one embodiment. In some implementations, the data processing system 100 can be, for example, a server computer system (e.g., one of the POWER series servers available from Business Machines), a mainframe computer system, a mobile computing device (e.g., a smartphone or tablet), a laptop or desktop personal computer system, or an embedded processor system.

As shown, data processing system 100 includes one or more processors 102 for processing instructions and data. As is known in the art, each processor 102 can be implemented as a separate integrated circuit having a semiconductor substrate in which the integrated circuitry is formed. In at least some embodiments, processor 102 can generally implement any of a number of commercially available processor architectures, such as POWER, ARM, Intel x86, NVidia, Apple silicon, etc. In the depicted example, each processor 102 includes one or more processor cores 104 and a cache memory 106 that provides low-latency access to instructions and operands that are likely to be read and/or written by processor core 104 . Processors 102 are coupled for communication via a system interconnect 110 , which in various implementations may include one or more buses, switches, bridges, and/or hybrid interconnects.

Data processing system 100 may additionally include several other components coupled to system interconnect 110. For example, these components may include a memory controller 112 that controls access to system memory 114 by processor 102 and other components of data processing system 100. Additionally, data processing system 100 may include an input/output (I/O) adapter 116 for coupling one or more I/O devices to system interconnect 110 , a non-volatile storage system 118 , and a network adapter 120 for coupling data processing system 100 to a communications network (e.g., a wired or wireless local area network and/or the Internet).

Those skilled in the art will also appreciate that the data processing system 100 shown in FIG1 may include many additional components not shown. Because these additional components are not necessary for understanding the described embodiments, they are not shown in FIG1 or discussed further herein. However, it should also be understood that the enhancements described herein are applicable to data processing systems and processors of various architectures and are in no way limited to the generalized data processing system architecture shown in FIG1 .

2 , a high-level block diagram of an exemplary processor core 200 is shown according to one embodiment. The processor core 200 may be used to implement any of the processor cores 104 of FIG. 1 .

In the depicted example, processor core 200 includes an instruction fetch unit 202 for fetching instructions within one or more instruction streams from memory 230 (which may include, for example, cache 106 and/or system memory 114 of FIG. 1 ). In a typical implementation, each instruction has a format defined by the instruction set architecture of processor core 200 and includes at least an operation code (opcode) field that specifies an operation to be performed by processor core 200 (e.g., fixed-point or floating-point arithmetic operations, vector operations, matrix operations, logical operations, branch operations, memory access operations, cryptographic operations, etc.). Some instructions may also include one or more operand fields that directly specify operands or implicitly or explicitly reference one or more registers storing source operands to be used in instruction execution and one or more registers storing destination operands generated by instruction execution. In some embodiments, the instruction decode unit 204 , which may be combined with the instruction fetch unit 202 , decodes instructions fetched from the register 230 by the instruction fetch unit 202 and forwards branch instructions that control the execution flow to the branch processing unit 206. In some embodiments, the processing of branch instructions by the branch processing unit 206 may include speculating the outcome of a conditional branch instruction. The results of branch processing (both speculative and non-speculative) by the branch processing unit 206 may then be used to redirect one or more streams of instruction fetches performed by the instruction fetch unit 202 .

Instruction decode unit 204 forwards instructions that are not branch instructions (often referred to as "in-order instructions") to mapper circuitry 210. Mapper circuitry 210 is responsible for assigning physical registers within the processor core 200 's register file to instructions as needed to support instruction execution. Mapper circuitry 210 preferably implements register renaming. Thus, for at least some classes of instructions, mapper circuitry 210 creates a temporary mapping between the set of logical (or architected) registers referenced by the instruction and a larger set of physical registers within the processor core 200 's register file. As a result, the processor core 200 may avoid unnecessary serialization of non-data-dependent instructions, which may otherwise occur due to nearby instructions in program order reusing the limited set of architected registers.

Still referring to FIG2 , processor core 200 further includes a dispatch circuit 216 configured to ensure that any data dependencies between instructions are observed and to dispatch sequential instructions as they become ready for execution. Instructions dispatched by dispatch circuit 216 are temporarily buffered in issue queue 218 until the execution units of processor core 200 have resources available to execute the dispatched instructions. When appropriate execution resources become available, issue queue 218 opportunistically issues instructions from issue queue 218 to the execution units of processor core 200 , potentially out of order relative to the original program order of the instructions.

In the depicted example, processor core 200 includes several different types of execution units for executing various classes of instructions. In this example, the execution units include one or more fixed-point units 220 for executing instructions that access fixed-point operands; one or more floating-point units 222 for executing instructions that access floating-point operands; one or more load-store units 224 for loading data from and storing data to memory 230 ; and one or more vector-scalar units 226 for executing instructions that access vector and/or scalar operands. In a typical embodiment, each execution unit is implemented as a multi-stage pipeline, in which multiple instructions can be processed simultaneously at different execution stages. Each execution unit preferably includes or is coupled to access at least one register file, the at least one register file including a plurality of physical registers for temporarily buffering operands accessed during or generated by instruction execution.

Those skilled in the art will appreciate that processor core 200 may include additional components not shown, such as logic configured to manage the completion and retirement of instructions targeted by the completion of execution by execution units 220 through 226. Because these additional components are not necessary for understanding the described embodiments, they are not shown in FIG . 2 or discussed further herein.

Referring now to FIG. 3 , a high-level block diagram of an exemplary execution unit of processor 102 is shown according to one embodiment. In this example, vector-scalar unit 226 of processor core 200 is shown in greater detail. In the embodiment of FIG . 3 , vector-scalar unit 226 is configured to perform operations on different types of operands and generate multiple different classes of instructions for different types of operands. For example, vector-scalar unit 226 is configured to perform a first class of instructions that operate on vector and scalar source operands and generate vector and scalar destination operands. The vector-scalar unit 226 executes instructions from this first category of instructions in functional units 302 through 312 , which in the depicted embodiment include an arithmetic logic unit/rotate unit 302 for performing addition, subtraction, and rotate operations, a multiplication unit 304 for performing binary multiplication, a division unit 306 for performing binary division, an encryption unit 308 for performing encryption functions, a permutation unit 310 for performing operand permutations, and a binary code decimal (BCD) unit 312 for performing decimal math operations. The vector and scalar source operators on which these operations are performed, and the vector and scalar destination operators generated by these operations, are buffered in physical registers of the architected register file 300 .

In this example, the vector-scalar unit 226 is additionally configured to execute a second class of instructions that result in the execution of hash functions. The vector-scalar unit 226 executes instructions from this second class of instructions in the accelerator unit 314. Operands on which these hash functions are executed and operands generated by these hash functions are buffered and accumulated in a wide vector register file 316 , which may include, for example, 1024-bit wide physical registers.

In operation, the vector-scalar unit 226 receives an instruction from the issue queue 218. If the instruction is a first-class instruction (e.g., a vector-scalar instruction), the associated source operands for the instruction are accessed in the architected register file 300 using the mapping between logical registers and physical registers established by the mapper circuit 210 and then transferred along with the instruction to the associated one of the functional units 302 to 312 for execution. The destination operands generated by the execution are then stored back into the physical registers of the architected register file 300 determined by the mapping established by the mapper circuit 210 . On the other hand, if the instruction is in the second category of instructions (e.g., a shuffle instruction), the instruction is forwarded to the accelerator unit 314 for execution on the operands buffered in the specified registers of the wide vector register file 316 .

Referring now to FIG. 4 , a more detailed block diagram of the accelerator unit 314 of FIG. 3 is depicted, according to one embodiment. The accelerator unit 314 includes circuitry for executing various hash functions in hardware, including, for example, one or more hash functions defined by the SHA family of standards. In the depicted example, the hash circuitry of the accelerator unit 314 includes at least a SHA3/SHAKE hash circuit 400, described in more detail below with reference to FIG . 11 , and a SHA2 hash circuit 402, described in more detail below with reference to FIG. 17 . The accelerator unit 314 also includes a single instruction, multiple data (SIMD) exclusive OR (XOR) circuit 404 for performing SHA3/SHAKE hashing of messages, as discussed further below. Finally, the accelerator unit 314 includes a data transfer circuit 406 for transferring data (e.g., messages to be hashed and message digests) between the memory system (e.g., cache 106 and system memory 114 ) and the wide vector register file 316 .

Referring now to FIG. 5 , there is a time-space diagram of a message hashing process 500 according to the SHA-3 standard. As is known in the art, the SHA-3 standard (i.e., FIPS 202) employs a sponge structure based on a wide random function or random permutation. According to this sponge structure, a message 502 of any arbitrary length (potentially many megabytes) is first processed in an input phase (referred to in sponge terminology as the SHA3 absorption phase 504 ). The SHA3 absorption phase 504 , described in more detail below with reference to FIG . 6 , is identical for both the SHA3 hash function and the SHAKE hash function. The SHA3 absorption phase 504 produces a 1600-bit final absorption state 610 , which is then processed in the output phase (referred to in sponge terms as the SHA3/SHAKE squeeze phase 506 ) to generate a message digest 508. The SHA3/SHAKE squeeze phase 506 , described in detail below with reference to FIG8 , operates differently for the SHA3 hash function and the SHAKE hash function. Specifically, the SHA3/SHAKE squeeze phase 506 generates a fixed-length message digest 508 for various SHA3 hash functions, but generates a variable-length message digest 508 for the SHAKE hash function.

Table 1 below summarizes the properties of the four SHA3 hash functions and the two SHAKE hash functions defined by the SHA-3 standard and listed in the first row. In Table 1, the second row summarizes the size ( r ) in bits of the message blocks into which the variable-length message 502 is subdivided by the SHA3 absorption phase 504. The message block size r is an integer multiple of the byte length, and the first message block of each message is byte-aligned. The third row of Table 1 summarizes the size ( d ) in bits of the message digest 508 output by the SHA3/SHAKE compression phase 506. Again, it should be noted that, unlike the SHA3 hash functions, SHAKE-128 and SHAKE-256 generate variable-length digests of length d ' . As mentioned in the fourth row of Table I, for each hash function specified by the SHA-3 standard, the length of the final absorbed state 610 is 1600 bits. The fifth row of Table I specifies different values of c , the number of lower-order bits that are passed between iterations of the SHA3 state permutation function during the SHA3/SHAKE squeeze phase 506 (see, e.g., FIG8 ). Finally, the sixth row of Table I specifies that each iteration of the SHA3 state permutation function employs 24 rounds of permutations per message block (see, e.g., FIG7A ). In updates to the SHA-3 standard or in non-standard implementations, the number of rounds of permutations may be varied, for example, by reducing the number of required permutations (e.g., to 12). Table I Message block size r (bits) Digest size d (bits) Status (bit) c = 1600 - r (bits) Per-block replacement rounds SHA3-224 1152 224 1600 448 twenty four SHA3-256 1088 256 1600 512 twenty four SHA3-384 832 384 1600 768 twenty four SHA3-512 576 512 1600 1024 twenty four SHAKE-128 1344 d' 1600 256 twenty four SHAKE-256 1088 d' 1600 512 twenty four

Referring now to FIG6 , a time-space diagram of the SHA3 absorption phase 504 depicted in FIG5 is depicted. As shown, the SHA3 absorption phase 504 receives as input a message 502 of any arbitrary length. As shown at block 600 , the message 502 is padded to obtain a length that is an integer multiple of r bits. In many prior art implementations, this padding is accomplished by a potentially time-consuming, computationally expensive memory-to-memory move of the entire message 502. In some other prior art implementations, the SHA hash software routine pads the message block after loading it into a SIMD register using a learned SIMD instruction sequence. While these prior art techniques may be used herein to perform padding, as described in detail below with reference to Figures 21A through 27 , such padding may alternatively be efficiently performed by hardware in accordance with the disclosed invention by executing pad instructions in processor registers (e.g., wide vector register file 316 ). Padding message 502 by executing pad instructions also allows padding to be applied to the end of message 502 in a manner that overlaps with the processing time of message blocks in SHA3 absorption phase 504 .

In the SHA3 absorption phase 504 , each of the n ( n is a positive integer) message blocks of length r that comprise the padded message is extracted and then zero-extended in the trailing low-order bits to form n 1600-bit extended message blocks 602. The first message block, message block 1 602 , forms the input to the SHA3 state permutation function 604 defined by the SHA- 3 standard. As described below with reference to Figures 9 and 11 , according to one aspect of the disclosed invention, the SHA3 state permutation function 604 is executed in hardware by executing a SHA3 hash instruction. The 1600-bit state output of SHA3 state permutation function 604 forms the first input to a 1600-bit bitwise XOR function 606 , which takes the next 1600-bit extended message block 602 of the padded message as its second input. The result of bitwise XOR function 606 forms the next iteration input of SHA3 state permutation function 604. As shown, this process continues repeatedly for each of message blocks 602 until the final iteration of SHA3 state permutation function 604 generates and outputs a 1600-bit final absorbed state 610 , as previously mentioned in the description of FIG. 5 .

Referring now to FIG. 7A , a time-space diagram of the SHA3 permutation function 604 shown in FIG . SHA3 permutation function 604 accepts a 1600-bit input and then processes the 1600-bit input in conjunction with the SHA-3 standard-specified round index 0 702 in the first of 24 rounds of SHA3 round function 704. This process continues repeatedly, with each subsequent round of processing in SHA3 round function 704 receiving as input the 1600-bit output of the previous SHA3 round function 704 and the associated SHA3 standard-specified round index 702 (which is a constant). After the 24 rounds of processing within the SHA3 state permutation function 604 are completed, the SHA3 state permutation function 604 outputs a 1600-bit state, which serves as input to the bitwise XOR function 606 or, in the case of the final iteration of the SHA3 state permutation function 604 within the SA3 absorption phase 504, constitutes the final absorbed state 610 that serves as input to the SHA3/SHAKE squeeze phase 506 .

Referring now to FIG. 7B , a time-space diagram of the SHA3 round function 704 depicted in FIG . 7A is depicted. As shown, the SHA3 round function 704 comprises a sequence of functions specified by the SHA-3 standard, including, in order, the five functions designated in the SHA-3 standard by the Greek letters θ (theta), ρ (rho), π (pi), χ (chi), and ϊ (iota). The θ function receives and processes the 1600-bit input to the round function 704 , and the output of each function except the ϊ function is fed to the next sequential function. Finally, the ϊ function processes the output of the χ function and the associated round index 702 to produce the 1600-bit output for a given iteration of the SHA3 round function 704 . In the prior art, executing round function 704 using two single instruction multiple data (SIMD) vector pipelines can take up to 80 cycles. According to one aspect of the invention disclosed herein, round function 704 can be completed in a single cycle of processor core 104 using SHA3/SHAKE hash circuit 400 described below in FIG. 11 .

Referring now to FIG. 8 , a time-space diagram of the SHA3/SHAKE squeeze phase 506 shown in FIG . 5 is shown. As previously described, the SHA3/SHAKE squeeze phase 506 receives as input the 1600-bit final absorbed state 610 generated by the SHA3 absorb phase 504. To generate a message digest 508 for use with any of the SHA3 functions defined by the SHA-3 standard, the SHA3/SHAKE squeeze phase 506 first extracts the r high-order bits preceding the final absorbed state 610 to form a result block 1 800. The truncation function 802 then truncates the r bits of the result block 1 800 to retain the d high-order bits that form the message digest 508 .

To generate a message digest for one of the SHAKE functions defined by the SHA-3 standard, the r bits of result block 1 800 form the r high-order bits of the input to a truncation function 804. These r high-order bits are concatenated with n -1 additional r -bit result blocks 800 , each of which is formed by the r high -order bits of the output of repeated SHA3 state permutation functions 604 as previously described with respect to FIG. 7A . Each SHA3 state permutation function 604 in the SHA3/SHAKE compression phase 506 receives a 1600-bit input (i.e., r + c = 1600) and generates a 1600-bit output. This 1600-bit output feeds all subsequent iterations of the SHA3 state permutation function 604 , except for the final iteration. The truncation function 804 truncates the r × n input bits to obtain a message digest 508 of a user-specified length of d ' bits.

9 and 10 , exemplary formats for a SHA3 hash instruction 900 and a bitwise exclusive OR (XOR) instruction 1000 , respectively, are shown according to one embodiment. In one exemplary embodiment, the accelerator unit 314 is configured to, in response to receiving the SHA3 hash instruction 900 , execute a SHA3/SHAKE state permutation function in hardware using the SHA3/SHAKE hash circuit 400 , and, in response to receiving the bitwise XOR instruction 1000 , execute a 1024-bit bitwise XOR of the specified operand using the SIMD XOR circuit 404 .

In the illustrated embodiment, the SHA3 hash instruction 900 includes an opcode field 902 that specifies a particular architecture-specific opcode for the SHA3/SHAKE permutation function. The SHA3 hash instruction 900 also includes one or more register fields 904 and 906 that specify registers within the wide vector register file 316 for the source and destination operands of the SHA3/SHAKE state permutation function. For example, in one implementation, the SHA3 hash instruction 900 includes a single register field 904 that specifies the first of a pair of adjacent 1024-bit registers that buffer a 1600-bit source operand and, after the SHA3/SHAKE permutation function completes, a 1600-bit destination operand (which overwrites the source operand). In an alternative implementation, the SHA3 hash instruction 900 includes two register fields 904 , 906 that specify separate pairs of 1024-bit source and destination registers (in which case the destination operand does not overwrite the source operand).

As mentioned above, in future updates to the SHA-3 standard or in non-standard implementations, it may be necessary to control the number of permutation rounds applied by the SHA3 state permutation function 604. In such embodiments, the SHA3 hash instruction 900 for the number of permutations may include directly setting the number of permutations or referencing a field in a register that specifies the number of permutations.

FIG10 illustrates an exemplary embodiment in which a bitwise XOR instruction includes an opcode field 1002 that specifies an architecture-specific opcode for a 1024-bit bitwise XOR function. Bitwise XOR instruction 1000 also includes three register fields 1004 , 1006 , and 1008 that are used to separately specify 1024-bit registers within wide vector register file 316 for buffering two 1024-bit source operands and one 1024-bit destination operand.

Now that the SHA3 and SHAKE hash functions and example instructions for implementing portions of these hash functions have been explained, pseudocode for executing an example SHA3 hash function in hardware is presented. In the following pseudocode, the following registers are referenced: Rr ß Block length in bytes RL ß Message length in bytes // Assume RL ≥ Rr and the first block is unpadded Ra ß Starting address of the message Rb ß Address of the message digest produced by the hash function Rd ß Message digest length in bytes Xs ß SHA3 state // Wide vector register pair Xm ß Message block // Wide vector register pair Given these registers, the pseudocode for any of the SHA3 (non-SHAKE) hash functions can be expressed as follows: Xs = loadlength(Ra, Rr) // Load the first message block of the message and initialize the state Xs = sha3hash(Xs) //Execute the SHA3 hash instruction to perform the permutation on the first message block RL - = Rr //Decrement the length of the unprocessed portion of the message Ra += Rr //Increment the pointer to the next message block in the message While (RL > = Rr) //Enter the loop for processing each remaining message block except the last message block { Xm = loadlength(Ra, Rr) //Load the next message block Xs = wide_xor(Xs, Xm) //Execute the bitwise XOR instruction to combine the state and the current message block Xs = sha3hash(Xs) //Execute the SHA3 hash instruction to perform the permutation on the current message block RL - = Rr //Decrement the length of the unprocessed portion of the message Ra += Rr //Increment to the pointer of the next message block} Xm = loadlength(Ra, RL) //Load the last message block (if it exists) (RL can be zero)  Xm = sha3_padding(Xm, RL, sha3-type) // Execute padding instructions to pad the message based on the remaining message length and the SHA3 function Xs = wide_xor(Xs, Xm) // Execute bitwise XOR instructions to combine the state and the last message block Xs = sha3hash(Xs) // Execute SHA3 hash instructions to permute the last message block and generate the final absorbed state Store_length(Xs, Rb, Rd) // During the SHA3 squeeze phase, truncate the final absorbed state by storing the leading Rd bytes of Xs to memory at address Rb to form the message digest

11 , a high-level block diagram of an exemplary SHA3/SHAKE hash circuit 400 suitable for executing the SHA3 hash instruction 900 is shown, according to one embodiment. As shown, the SHA3/SHAKE hash circuit 400 includes two 1024-bit two-input multiplexers 1100 a , 1100 b , two 1024-bit state registers 1102 a, 1102 b , a SHA3 round circuit 1106 , and a control circuit 1110 that controls the operation of the SHA3/SHAKE hash circuit 400 in response to the SHA3 hash instruction 900 .

Input multiplexer 1100a has a first input coupled to receive the high-order 1024 bits of the 1600-bit input state from the first register of the register pair in the wide vector register file 316 identified by the SHA3 hash instruction 900 , and a second input coupled to receive the high-order 1024 bits of the 1600-bit round feedback from the SHA3 round circuit 1106 . Input multiplexer 1100b is similarly structured, having a first input coupled to receive a 1024-bit value comprising the low-order 576 bits of the 1600-bit input state from the second register of the register pair specified by the instruction in width vector register file 316 ; and a second input coupled to SHA3 round circuit 1106 to receive a 1024-bit value comprising the low-order 576 bits of the 1600-bit round feedback. Control logic 1110 within SHA3/SHAKE hash circuit 400 provides select signals (not shown) to input multiplexers 1100a and 1100b, causing input multiplexers 1100a and 1100b to select the value present at their first inputs before SHA3 round 0 and the value present at their second inputs after each of SHA3 rounds 0 through SHA3 round 23. The values output by input multiplexers 1100a and 1100b , respectively, and buffered in state registers 1102a and 1102b, collectively form the 1600-bit round input value for SHA3 round circuit 1106 , which is configured to perform SHA3 round function 704 on the round input value, as previously described with reference to FIG . 7A and FIG .

Control circuit 1110 is further configured to sequence SHA3 round circuit 1106 through each of the 24 rounds required by the SHA-3 standard using the correct round index specified by the SHA-3 standard. After the 23rd round, state registers 1102a and 1102b will hold the high-order 1024 bits and low-order 576 bits of the 1600-bit output state, respectively. The control circuit 1110 is further configured to assert a select signal (not shown) once the output state is obtained, causing the output multiplexer 1108 to write the high-order bits and low-order bits of the 1600-bit output state from the state registers 1102a , 1102b to the instruction-specified register pair in the wide vector register file 316 (assuming the wide vector register file 316 has a single write port) in two consecutive cycles.

12 , a high-level logic flow diagram of an exemplary process for executing the SHA3 hash instruction 900 according to one embodiment is depicted. For ease of understanding, the process of FIG . 12 is described with reference to the exemplary SHA3/SHAKE hash circuit 400 of FIG. 11 .

The process of Figure 12 begins at block 1200 and then continues to block 1202 , which shows the SHA3/SHAKE hash circuit 400 receiving the SHA3 hash instruction 900 specifying an operand register pair within the wide vector register file 316. In response to receiving the SHA3 hash instruction 900 , the control circuit 1110 causes the contents of the operand register pair to be read from the wide vector register file 316 and loaded into the state registers 1102a and 1102b via the input multiplexers 1100a and 1100b (block 1204 ). Control circuit 1110 also initializes the internal round counter to 0 (block 1206 ).

The process then proceeds from block 1206 to block 1208 , which shows control circuit 1110 directing SHA3 round circuit 1106 to perform iterations of SHA3 round function 704 using the round inputs buffered in state registers 1102a and 1102b and the appropriate round index specified by the SHA- 3 standard. Control circuit 1110 also increments the round counter (block 1208 ). The results of SHA3 round circuit 1106 's processing are returned to state registers 1102a and 1102b via input multiplexers 1100a and 1100b . As indicated at block 1210 , control logic 1110 causes SHA3 round circuitry 1106 to perform the 24 rounds of processing specified by the SHA-3 standard using the appropriate round index. When the 24 rounds of processing are complete, control circuitry 1110 asserts the appropriate select signal to cause output multiplexer 1108 to store the 1600-bit state buffered in state registers 1102 a and 1102 b (zero-extended in the low-order bits to form two 1024-bit values) into the operand register pair within wide vector register file 316 specified by SHA3 hash instruction 900 (block 1214 ). The process of FIG. 12 then terminates at block 1216 .

Referring now to FIG. 13 , a time-space diagram of message hashing according to the SHA-2 standard (FIPS 180-4) is shown, which is performed by the SHA2 hashing circuit 402 in the embodiment of FIG . Table II below summarizes the properties of the six SHA2 hashing functions defined by the SHA-2 standard and listed in the first row. In Table II , the second row summarizes the message block size ( r ) in bits. The message block size r is an integer multiple of the byte length, and the first message block of the message is byte aligned. The third row of Table II summarizes the fixed size ( d ) in bits of the message digest produced by each SHA2 hashing function. The fourth row of Table II specifies the size of the state of each SHA2 hash function in bits, and the fifth row of Table II indicates the number of rounds of processing employed in each SHA2 hash function (i.e., 64 or 80) (see, for example, FIG. 14 ). Finally, the sixth row of Table II specifies the word size used for each SHA2 hash function in bits. Note that for all variants, the state size is 8 times the word size (i.e., contains 8 words), and the message block size is 16 times the word size (i.e., contains 16 words). As described below, according to one aspect of the disclosed invention, a SHA2 hash function using a 32-bit word size and a SHA2 hash function using a 64-bit word size are processed along the same data stream by means of message expansion applied to the words of the SHA2-224 and SHA2-256 hash functions, as described below with reference to FIG . 15 . Table II Message block size r (bits) Digest size d (bits) Status (bit) round Word size w (bits) SHA2-224 512 224 256 64 32 SHA2-256 512 256 256 64 32 SHA2-384 1024 384 512 80 64 SHA2-512 1024 512 512 80 64 SHA2-512/224 1024 224 512 80 64 SHA2-512/256 1024 256 512 80 64

As shown in FIG13 , SHA2 hash function 1300 receives as an input a message 1302 of any arbitrary length (e.g., a length of millions of bytes ) . As shown at block 1304 , message 1302 is padded to obtain a length that is an integer multiple of r bits. As discussed above with reference to FIG6 , this padding can be performed efficiently by hardware in processor registers (e.g., wide vector register file 316 ) rather than by executing a pad instruction and performing a memory move. Message 1302 is padded by executing the padding instruction, and specifically the last message block of message 1302 , allowing the padding to be applied to the end of message 1302 in a manner that overlaps in time with the processing of the message blocks by SHA2 hash function 1300. Each of the n ( n is a positive integer) message blocks of length r (where r = 16× w ) that make up the padded message generated by block 1304 is extracted to form one of n 16× w bit message blocks 1306 .

In addition to message 1302 , SHA2 hash function 1300 also receives as input an 8× w- bit SHA-2-specified constant value. As is known in the art, this constant value, accessible from architected register file 300 , varies between SHA2 hash functions and forms an 8× w -bit initial state 1308. Initial state 1308 and the first message block (i.e., message block 1 1306 ) form the two inputs to SHA2 block hash function 1 1310 as defined by the SHA-2 standard. As described below with reference to Figures 16 and 17 , according to one aspect of the disclosed invention, SHA2 block hash function 1310 is executed in hardware by executing a SHA2 hash instruction. The 8× w -bit state output by SHA2 block hash function 1 1310 forms the first input of SHA2 block hash function 2 1310. SHA2 block hash function 2 1310 then treats the next 16× w -bit message block 2 1306 as its second input . The result of SHA2 block hash function 2 1310 forms the next repeated input of SHA2 block hash function 1310 . As shown, this process continues repeatedly for each of the message blocks 602 until the final n- th iteration of the SHA2 block hash function 1310 generates and outputs an 8× w - bit final state, which is truncated by the truncation function 1312 to produce a message digest 1314 having d bits.

Referring now to FIG. 14 , a time-space diagram of SHA2 block hash function 1310 shown in FIG . SHA2 block hash function 1310 accepts a 16× w -bit message block 1306 and, as shown at block 1420 , initializes a 16× w -bit message schedule for message block 1306 . SHA2 block hash function 1310 then processes the 16× w -bit message schedule via n rounds of message schedule round function 1400 , where the 16× w -bit output of each of rounds 1 through n-2 serves as the input to the next round of message schedule processing.

As shown, SHA2 block hash function 1310 also receives as input the 8× w -bit current hash state (i.e., initial state 1308 or the output of a previous SHA2 block hash function 1310 ). As indicated at block 1406 , SHA2 block hash function 1310 partitions this 8× w- bit current hash state into 8w - bit variables a through h . SHA2 block hash function 1310 then processes the current hash state by updating round function 1404 through n rounds of processing. Initial update round 0 1404 takes as additional input the w -bit SHA-2-specified round key 0 1402 and the w high-order bits of the 16× w -bit message scheduling initialization 1420. Each subsequent iteration of update round function 1404 takes as input the state generated by the previous iteration of update round function 1404 , the w high-order bits of the 16× w -bit output of the corresponding iteration of message scheduling round function 1400 , and the w- bit SHA-2-specified round key 1402. The hash state output by update round function n -1 1404 is added to the input hash state by an 8× w -bit carry-propagation addition function 1410 to generate the next hash state.

Referring now to FIG. 15 , a diagram illustrates message expansion for a SHA2 hash function according to an exemplary embodiment. As mentioned above with reference to Table II and FIG . 13 , embodiments of the present invention preferably support processing SHA2 hash functions of different word sizes w along a common data path by expanding the message word and initial hash state of those SHA2 hash functions employing smaller word sizes. This expansion can be performed, for example, at blocks 1304 and 1308 of FIG. 13 . 15 illustrates a specific example in which each of the sixteen 32-bit words 1502 of a SHA2-224 or SHA2-256 input message 1500 is expanded to form a corresponding one of the sixteen 64-bit doublewords 1506 of an output message 1504. In this example, each 64-bit doubleword 1506 is formed by concatenating the 32-bit word of the input message 1500 in the high-order half of the 64-bit doubleword 1506 with the 32-bit zero word 1508 in the low-order half of the doubleword 1506. The resulting output message 1504 can then be processed by the SHA2 hash circuit in the same manner as a message using 64-bit words.

16 , an exemplary format for a SHA2 hash instruction 1600 according to one embodiment is depicted. In one exemplary embodiment, the accelerator unit 314 is configured to execute the SHA2 block hash function 1310 in hardware using the SHA2 hash circuit 402 in response to receiving the SHA2 hash instruction 1600 .

In the illustrated embodiment, the SHA2 hash instruction 1600 includes an opcode field 1602 that specifies a particular architecture-specific opcode for the SHA2 block hash function. The SHA2 hash instruction 1600 also includes one or more operand register fields 1604 and 1606 that specify operand registers within the wide vector register file 316 for the source and destination operands of the SHA2 block hash function. For example, in one implementation, SHA2 hash instruction 1600 includes a register field 1604 that specifies a 1024-bit register that buffers the current hash state as input and outputs the current hash state after the SHA2 block hash function completes (overwriting the input current hash state). Additionally, SHA2 hash instruction 1600 includes a register field 1606 that buffers the current message block to be processed. The SHA2 hash instruction 1600 further includes a mode field 1608 that indicates whether the SHA2 hash function to be performed uses 32-bit words or 64-bit words.

Now that the SHA2 hash function and example instructions for implementing a portion of the SHA2 hash function have been explained, a pseudocode for executing an example SHA2 hash function (i.e., SHA2-512) in hardware is presented. In the SHA2-512 hash function, each message block is 1024 bits long, and the hash state and message digest are each 512 bits long. In the following pseudocode, the following registers are referenced: Rl ßMessage length in bytes RL ßMessage length in bytes; assumed ≥ 128 bytes, so the first message block is unpadded Ra ßStarting address of the message Ri ßAddress of the initial state Rb ßAddress of the message digest generated by the hash function Rd ßMessage digest length in bytes Xs ßSHA2 state                    //Wide vector register Xm ßCurrent message block      //Wide vector register

Given these registers, the pseudocode for executing the SHA2-512 hash function can be expressed as follows: Xs = load(Ri, 64)                     //Load 64-byte initial state Xm = load(Ra, 128)                      //Load the first (complete) message block Xs  = sha2hash(Xs, Xm, 64-bit)  //Execute the SHA2 hash instruction to perform the block hash function RL - = 128                         //Decrement the length of the message to be processed Ra += 128                         //Advance the pointer to the next message block While (RL >= 128) //Through the remaining message block loop, except for the last message block {   Xm = load(Ra, 128)             //Load the next message block (full size)     Xs  = sha2hash(Xs, Xm, 64-bit)     //Execute SHA2 hash instruction to execute the block hash function     RL - = 128                          //Decrement the length of the message to be processed    Ra += 128                            //Advance pointer to the next message block } Xm = loadlength(Ra, RL)   //Load the last message block (if any) (RL can be zero) Xm = sha2_EOM_pad(Xm, RL)  //Append the SHA2 EOM bytes to the end of the message block If (RL > 111) then                      //If the padding spans two message blocks, then {  Xs  = sha2hash(Xs, Xm, 64-bit)      //Execute SHA2 hash instruction to execute the block    Xm = force-to-zero                //Hash function and set the last message block to zero } Xm = sha2_EOB_pad(Xm, RI)    //Insert EOB in the last block of padded message Xs  = sha2hash(Xs, Xm, 64-bit)  //Execute SHA2 hash instruction to execute the block hash function on the last message block Store(Xs, Rb, 64) //Truncate the state to the leading 64 bytes of Xs to obtain the message digest and store it in memory at address Rb

Referring now to FIG. 17 , a high-level block diagram of an exemplary embodiment of the SHA2 hash circuit 402 of FIG. 4 is shown, suitable for executing the SHA2 hash instruction 1600. As shown, the SHA2 hash circuit 402 includes a 512-bit two-input state multiplexer 1702 a , a 1024-bit two-input message multiplexer 1702 b , a 512-bit state register 1704 a , a 1024-bit message block register 1704 b , an update working status circuit 1708 , a message scheduling circuit 1710 , and a control circuit 1720 that controls the operation of the SHA2 hash circuit 402 in response to the SHA2 hash instruction 1600 .

In this example, a first input of state multiplexer 1702a is coupled to receive the current hash state held in the 512 high-order bits of the register specified by register field 1604 of SHA2 hash instruction 1600 in width vector register file 316. A second input of state multiplexer 1702a is coupled to the output of update working state circuit 1708 . Message multiplexer 1702b is similarly configured, having a first input coupled to receive a message block from the register specified by register field 1606 of SHA2 hash instruction 1600 in width vector register file 316 , and a second input coupled to receive a 1024-bit round feedback from message scheduling round circuit 1710 . Control logic 1720 within SHA2 hash circuit 400 provides select signals (not shown) to multiplexers 1702a and 1702b , causing multiplexers 1702a and 1702b to select the value present at the first input before the update round 0 function 1404 and the value present at the second input after each of the update round 0 function and the SHA2 block hash n function. The values output by multiplexers 1702a and 1702b are temporarily buffered in state register 1704a and message block register 1704b, respectively. The message blocks buffered in message block register 1704b form the inputs of message scheduling round circuit 1710 , which implements message scheduling round function 1400 of FIG . 14 . The 64 high-order bits from message block register 1704b and the 512-bit state in state register 1704a form the two inputs of update work state circuit 1708 , which is configured to execute update round function 1404 as previously described with reference to FIG .

The control circuit 1720 is further configured to sequence the update of the working state circuit 1708 through each of the n rounds using the correct round index specified by the SHA-2 standard. After the last round n -1 is completed, the state register 1704a will hold the 512-bit hash state. The control circuit 1720 is further configured to cause the single instruction multiple data (SIMD) adder 1712 to add the hash state from the state register 1704a to the input hash state read from the wide vector register field 316 upon obtaining the output hash state, and to store the result back to the wide vector register file 316 as the next hash state, as described above with respect to the add function 1410 of FIG. 14 . Those skilled in the art will appreciate that, in various implementations, the SIMD adder 1712 may be implemented as a dedicated component of the SHA2 hash circuit 402 or as a separate pipeline that may be shared by, for example, multiple hash circuits.

Referring now to FIG18 , a more detailed block diagram of the exemplary update operating state circuit 1708 from FIG17 is depicted according to one embodiment. In this embodiment, the 512-bit state buffered in state register 1704 a received as one input to the update operating state circuit 1708 is split into eight 64-bit variables, referred to as variables a through h in the SHA-2 standard, as shown at block 1800 . Update working state circuit 1708 includes two sigma function circuits, SHA2 Sigma 0 circuit 1802 and SHA2 Sigma 1 circuit 1806 , as well as SHA2 MA circuit 1804 and SHA2 CH circuit 1808 , each of which performs a function defined by the SHA-2 standard. Update working state circuit 1708 also includes three 64-bit adders 1810 , 1812 , and 1814. SHA2 Sigma 0 circuit 1802 applies a sigma function with n (n1, n2, n3) = (28, 34, 39) and m (m1, m2, m3) = (2, 13, 22) to variable a to generate the first input of adder 1812 . Variables a , b, and c are processed by SHA2 MA circuit 1804 to generate the second input of adder 1812. SHA2 Sigma 1 circuit 1806 applies a sigma function with n (n1, n2, n3) = (14, 18, 41) and m (m1, m2, m3) = (6, 13, 22) to variable e to generate the first of five inputs to adder 1810. Variables e , f, and g are processed by SHA2 CH circuit 1808 to generate the second input of adder 1810. Adder 1810 adds the associated round key, round message block, and variable d to these two inputs to generate the sum that forms the first input of adder 1814 and the third input of adder 1812 .

Updated working state circuit 1708 generates a 512-bit result state 1816 consisting of eight 64-bit variables a ' through h ' . Variable a ' of result state 1816 is formed by the output of adder 1812 , variables b ' , c ' , and d ' are formed by variables a , b , and c, respectively, from input state 1800 , and variables f ' , g ', and h ' are formed by variables e , f, and g , respectively, from input state 1800. Remainder variable e ' is formed by the sum of the output of adder 1810 and variable d from input state 1800 .

It should be noted that the 32-bit to 64-bit expansion of the SHA-2 message word described above with reference to FIG15 does not affect (is transparent to) the design of SHA2 MA circuit 1804 , SHA2 CH circuit 1808 , and modular adders 1812 and 1814. Trailing zero expansion of the SHA2 message using 32-bit words only affects SHA2 sigma circuits 1802 and 1806 , as described in more detail below with reference to FIG19 .

FIG19 is a more detailed block diagram of an exemplary embodiment of a SHA2 Sigma circuit 1900 , which may be used to implement the SHA2 Sigma 0 circuit 1802 and the SHA2 Sigma 1 circuit 1806 of FIG18 . The SHA2 Sigma circuit 1900 receives a 64-bit input variable 1902 comprising 32 high-order bits (bits 0 to 31) and 32 low-order bits (bits 32 to 63).

SHA2 sigma circuit 1900 includes a 64-bit rotate circuit 1904a that rotates the 64-bit input variable 1902 by n1 bits (i.e., 28 bits for SHA2 sigma 0 circuit 1802 and 14 bits for SHA2 sigma 1 circuit 1806 ) to obtain a first 64-bit input to multiplexer 1910a . SHA2 sigma circuit 1900 further includes a 32-bit rotate circuit 1906a that rotates the 32 high-order bits of input variable 1902 by m1 bits (i.e., 2 bits for SHA2 sigma 0 circuit 1802 and 6 bits for SHA2 sigma 1 circuit 1806 ) to obtain a second 64-bit input to multiplexer 1910a when concatenated with the 32 low-order bits of input variable 1902. Multiplexer 1910a selects between its first and second inputs based on a mode signal determined by mode field 1608 of the associated SHA2 hash instruction 1600 . That is, if the mode signal indicates that the mode field 1608 is set to indicate the SHA2 hash function using 64-bit words, the multiplexer 1910a selects the first input, and if the mode signal indicates that the mode field 1608 is set to indicate the SHA2 hash function using 32-bit words, the multiplexer 1910a selects the second input.

SHA2 sigma circuit 1900 further includes a 64-bit rotate circuit 1904b that rotates the 64-bit input variable 1902 by n2 bits (i.e., 34 bits for SHA2 sigma 0 circuit 1802 and 18 bits for SHA2 sigma 1 circuit 1806 ) to obtain a first 64-bit input to multiplexer 1910b . SHA2 sigma circuit 1900 also includes a 32-bit rotate circuit 1906b that rotates the 32 high-order bits of input variable 1902 by m2 bits (i.e., 13 bits for both SHA2 sigma 0 circuit 1802 and SHA2 sigma 1 circuit 1806 ) to provide a second 64-bit input to multiplexer 1910b when concatenated with the 32 low-order bits of input variable 1902. Multiplexer 1910b selects between its first and second inputs based on the mode signal. Specifically, if the mode signal indicates that the mode field 1608 is set to indicate the SHA2 hash function using 64-bit words, the multiplexer 1910b selects the first input, and if the mode signal indicates that the mode field 1608 is set to indicate the SHA2 hash function using 32-bit words, the multiplexer 1910b selects the second input.

SHA2 sigma circuit 1900 also includes a 64-bit rotate/shift circuit 1908a that rotates and shifts the 64-bit input variable by n3 bits (i.e., 39 bits for SHA2 sigma 0 circuit 1802 and 41 bits for SHA2 sigma 1 circuit 1806 ) to obtain a first 64-bit input to multiplexer 1910c . SHA2 sigma circuit 1900 further includes a 32-bit rotate/shift circuit 1908b that rotates and shifts the 32 high-order bits of input variable 1902 by m3 bits (i.e., 22 bits for both SHA2 sigma 0 circuit 1802 and SHA2 sigma 1 circuit 1806 ) to provide a second 64-bit input to multiplexer 1910c when concatenated with the 32 low-order bits of input variable 1902. Multiplexer 1910c selects between its first and second inputs based on the mode signal. Like multiplexers 1910a and 1910b , multiplexer 1910c selects the first input if the mode signal indicates that mode field 1608 is set to indicate the SHA2 hash function using 64-bit words, and selects the second input if the mode signal indicates that mode field 1608 is set to indicate the SHA2 hash function using 32-bit words.

The 64-bit outputs of multiplexers 1910a , 1910b , and 1910c form the inputs of a three-input 64-bit bit-by-bit XOR circuit 1912 , which performs a bit-by-bit XOR on its three inputs to generate a 64-bit output 1914 . Those skilled in the art will appreciate that in some embodiments of the SHA2 sigma circuit 1900 , the functionality of the rotate circuits 1904a - 1904b and 1906a - 1906b , as well as the rotate/shift circuits 1908a - 1908b , can be implemented by appropriate routing, thereby allowing the SHA2 sigma circuit 1900 to be implemented by three multiplexers 1910a - 1910c and a 3-way bitwise XOR circuit 1912 without the need for explicit rotate and shift circuitry.

20 , a high-level logic flow diagram is depicted of an exemplary process for executing the SHA2 hash instruction 1600 according to one embodiment. For ease of understanding, the process of FIG . 20 is described with reference to the exemplary embodiment of the SHA2 hash circuit 402 shown in FIG . 17 through FIG. 19 .

The process of FIG. 20 begins at block 2000 and then continues to block 2002 , which illustrates the SHA2 hash circuit 402 receiving the SHA2 hash instruction 1600 specifying a particular SHA2 mode (i.e., 32-bit or 64-bit word size) and the state registers and message block registers within the wide vector register file 316 . In response to receiving SHA2 hash instruction 1600 , control circuit 1720 reads the 512-bit state and 1024-bit message blocks from the width vector register file 316 and loads them into state register 1704a and message block register 1704b via multiplexers 1702a and 1702b , respectively (block 2002 ). Control circuit 1720 also initializes the internal round counter to 0 (block 2004 ).

The process then proceeds from block 2004 to block 2006 , which shows that control circuit 1720 directs message scheduling round circuit 1710 to execute iterations of message scheduling round function 1400 using the message blocks buffered in message block register 1704b . Additionally, control circuit 1720 directs update work status circuit 1708 to execute iterations of update round function 1404 based on the appropriate round index, the 64 high-order bits of message block register 1704b , and the input hash state from status register 1704a . The processing results of the update work status circuit 1708 and the message scheduling round circuit 1710 are returned by multiplexers 1702a and 1702b to registers 1704a and 1704b , respectively. Control circuit 1110 also advances the round counter. At block 2010 , control logic 1720 determines whether SHA2 hash circuit 402 has performed the last round specified by the SHA-2 standard by referencing the round counter. As mentioned in Table II, SHA2 hash circuit 402 performs 64 rounds of processing for a SHA2 hash function using 32-bit words and 80 rounds of processing for a SHA2 hash function using 64-bit words. If control circuit 1720 determines at block 2010 that at least one additional round of processing remains to be performed, the program returns to block 2006 , which has already been described. However, in response to determining at block 2010 that all rounds of processing are complete, control circuit 1720 causes the previous state to be read again from wide vector register file 316 and added to the final state buffered in state register 1704a by SIMD adder 1712 (block 2012 ). Control circuit 1720 then directs the storage of the resulting next state back to wide vector register file 316 (block 2014 ). Thereafter, the program of FIG. 20 ends at block 2016 .

As discussed above with reference to block 600 of FIG. 6 and block 1304 of FIG. 13 , messages processed by the SHA2 and SHA3 hash functions are padded to produce messages with a length that is an even multiple of the block length r bits. FIG. 21A depicts an exemplary unpadded message 2100 having a total length of L bits and comprising n message blocks. The first n -1 message blocks comprise r bits, but the final message block n comprises k bits, where k < r . As shown in FIG . 21B , in the general case, message 2100 is padded by appending r - k padding bits to the end of message block n , resulting in n message blocks each having a length of r bits.

The content of the padding bits appended to obtain a padded message can vary depending on the hash function being considered. For example, in the SHA2 and SHA3/SHAKE hashing algorithms discussed herein, the padding bits will include bytes marking both the end of the unpadded portion of the message (i.e., the end-of-message (EOM) marker) and the end of the last block of the padded message (i.e., the end-of-block (EOB) marker). As explained further below, in some cases, the padding bits, including the EOM and EOB markers, may all be included in the message block containing the final message bytes; in other cases, the addition of padding bits may require appending an additional message block to the message. In either case, the disclosed invention preferably performs message filling in a processor register by executing one or more instructions rather than by a high-latency memory move operation that transfers the message between two locations in memory.

In at least some architectures, the load storage unit 224 , memory controller 112 , and/or system interconnect 110 are not configured to support the transfer of lengthy data objects (e.g., complete r- bit SHA3/SHAKE and SHA2 message blocks) between the system memory 114 and the wide vector register file 116. In such architectures, the message blocks are transferred in smaller chunks to a narrower register file, and then from the narrower register file to one or more wide vector registers in the wide vector register file 316 . 22A illustrates an example of assembling SHA3/SHAKE message block n into an architected register file 300 comprising 256-bit registers r0 through r5 301. In this example, a load length instruction is executed, for example by the load store unit 224 of FIG . 2 , to load five 256-byte chunks of the 1152-bit SHA3-224 message block n into registers r0 through r7 and to set any register bytes that do not contain message data to zero. Given a message block length of 1152 bits in SHA3-224, the message bytes in message block n will at most completely fill registers r0 through r3 plus the leading 128 bits of register r4 (of course, the final unpadded message block may contain fewer than r bits). At least the remaining 128 bits of register r4 and all of registers r5 through r7 are zeroed by either automatically executing a load length instruction or by executing a standard load instruction. (Registers r6 and r7 need only be zeroed for the generic SHA3 function for any of the supported message block lengths). Additional data transfer instructions may then be executed by data transfer circuitry 406 or transfer unit 320 to transfer the contents of registers r0 through r7 to registers R0 and R1 317 of wide vector register file 316 , which includes registers R0 through RT, each having an exemplary width of 1024 bits as discussed above. In an alternative implementation, the same result may be achieved by loading four registers 301 within architected register file 300 to buffer blocks n1 through n4 and then reusing the same registers 301 on a subsequent loop to buffer blocks n5 through n8.

22B depicts a similar example, showing the 1024-bit SHA2 message block n being transferred to wide vector register 317 in wide vector register file 316 after the message blocks are assembled in register 301 of architected register file 300. In this example, a load length instruction is executed, for example by load store unit 224 of FIG . 2 , to load four 256-byte blocks of SHA2 message block n into registers r2 through r5 of architected register file 300 and to set any register bytes that do not contain message data to zero. Additional data transfer instructions may then be executed by data transfer circuitry 406 to transfer the contents of registers r2-r5 to register R0 317 of wide vector register file 316. In an alternative implementation, the same result may be achieved by loading two registers 301 within architected register file 300 to buffer chunks n1 and n2, and then reusing the same registers 301 on a subsequent loop to buffer chunks n3-n4.

In at least some preferred embodiments, the process for loading message blocks into the wide vector register file 316 shown in Figures 22A - 22B is executed for all message blocks of the SHA3/SHAKE or SHA2 message, including message block n , which is the last message block that has not been filled with messages. As explained below, the end of the message in the wide vector register file 316 can then be at least partially filled by executing one or more instructions.

Figures 23A through 23D illustrate various padding configurations for SHA3/SHAKE messages of various lengths. According to the SHA-3 standard, every message must include an EOM padding byte, which marks the end of the message. Under the SHA3 standard, EOM padding has a fixed value of x06 for the SHA3 hash function and a fixed value of x1F for the SHAKE hash function. The location of the EOM padding within the padded message varies depending on the message length, which is often unknown at compile time. The SHA-3 standard further mandates that the last byte of each padded message be a fixed-value EOB padding byte.

As shown in FIG23A , if the last message block 2300 of the SHA3/SHAKE message includes more than two bytes that do not contain message data, then the EOM padding byte 2302 is inserted into the zeroed bytes of the associated wide vector register 317 immediately following the last message byte 2306 , and the EOB padding byte 2304 is inserted into the set bytes of the wide vector register 317 as the last byte of the padded message block.

23B illustrates a similar second scenario, where the last message block 2300 ′ of the SHA3/SHAKE message includes exactly two zeroed bytes that do not contain message data. In this scenario, the last two zeroed bytes of the last message block 2300 ′ are replaced with EOM padding bytes 2302 , followed by EOB padding bytes 2304 .

FIG23C depicts a third case, in which the last message block 2300 ″ of the SHA3/SHAKE message includes only a single zeroed message byte following the last message byte 2306. In this case, execution of the padding instruction described below causes the EOM and EOB padding values to be ORed together and inserted into the final byte of padded message block 2300 ″ as EOM/EOB padding byte 2308 .

23D shows the final state, where the last message byte 2306 of the SHA3/SHAKE message is the last byte of message block 2310. Because message block 2310 does not include the required EOM and EOB padding in this state, an additional zeroed message block 2312 is appended to the message (e.g., by executing a load length instruction). EOM padding byte 2302 is inserted as the first byte into this zeroed message block 2312 , and EOB padding byte 2304 is inserted as the last byte into this zeroed message block 2312 . It should be noted that in each of the four cases depicted in Figures 23A to 23D , both EOM padding and EOB padding can be advantageously applied using a single padding instruction because both EOM padding and EOB padding always belong to the same message block. It should also be understood that although Figures 23A to 23D depict padding being applied to messages that include an integer number of message bytes, padding can similarly be applied to byte messages that do not include an integer number of bytes.

In one embodiment, three instructions can be used to implement padding of SHA3/SHAKE messages of arbitrary length as shown in Figures 23A to 23D . These instructions include: (1) a load length instruction that stages the final message block of the padded message into a specified register 301 in the architected register file 300 ; (2) a transfer instruction that transfers the message block from register 301 in the architected register file 300 to one or more wide vector registers 317 in the wide vector register file 316 as shown in Figure 22A ; and (3) a pad instruction that inserts EOM and EOB padding at appropriate byte positions in the final message block of the padded SHA3/SHAKE message held in the wide vector register 317 . Of course, in an alternative implementation, it is possible to use two different instructions to insert EOM padding and EOB padding into the final message block. However, for single-block messages, such as those commonly used in post-quantum encryption schemes, adding additional padding instructions increases latency and undesirably reduces hashing performance.

Figures 24A to 24D illustrate various padding scenarios for SHA2 messages of various lengths. According to the SHA-2 standard, every message must include an EOM padding byte with the value x80 in the byte immediately following the last message byte. The position of the EOM padding byte within the padded message therefore varies depending on the message length. The SHA-2 standard further mandates that the last two words (i.e., two 32-bit words or two 64-bit words, depending on the SHA2 hash function in question (see Table II)) contain the EOB padding that specifies the length of the unpadded message in bits.

In the first case shown in Figure 24A , the last message block 2400 of the SHA2 message includes more than two words plus one byte that do not contain message data. In this case, the last message block 2400 is padded by inserting the EOM pad byte 2402 into the zero bytes of the associated width vector register 317 immediately after the last message byte 2406 and by inserting two EOB pad words 2404 as the last two words of the last message block 2400 .

24B illustrates a similar second situation, where the last message block 2400 ′ of the SHA2 message includes exactly two words plus one byte that do not contain message data. In this situation, the last message block 2400 ′ is padded by inserting an EOM pad byte 2402 into the zeroed bytes of the associated width vector register 317 immediately following the last message byte 2406 and inserting two EOB pad words 2404 as the last two words of the last message block 2400 .

FIG24C depicts a third case, in which the last message block 2400 ″ of the unpadded SHA2 message includes too few bytes without message data to accommodate EOM padding byte 2402 and two EOB padding words 2404. In this case, the SHA2 message is padded by inserting EOM padding byte 2402 into the zeroed bytes of the associated wide vector register 317 immediately after the last message byte 2406. Because EOB padding word 2404 does not fit within message block 2400 ″ , an additional zeroed message block 2408 is appended to the message (e.g., by executing a load length instruction). EOB padding words 2404 are then inserted as the last two words of message block 2408 .

FIG24D illustrates a fourth scenario, in which the last message byte 2406 of the SHA2 message forms the last byte of a complete message block 2410. Because message block 2410 does not include space for EOM or EOB padding, an additional zeroed message block 2412 is appended to the SHA2 message. Additional message block 2412 includes EOM padding byte 2402 as the first byte of message block 2412 , followed by a number of zeroed bytes, and finally , two EOB padding words 2404 at the end of message block 2412 .

In one embodiment, padding of SHA2 messages of arbitrary length can be implemented using as few as four instructions. These instructions include: (1) a load length instruction that places the final message block of the SHA2 message in a specified register 301 in the architected register file 300 and sets any register bytes that do not contain message bytes to zero; (2) an insert word instruction that places two EOB padding words 2404 in the appropriate bytes of register 301 in the architected register file 300 to mark the end of the padded message; (3) a transfer instruction that transfers the contents of register 301 of a buffered message block from the architected register file 300 to wide vector register 317 in the wide vector register file 316 . and (4) a padding instruction that inserts EOM padding bytes 2402 into the appropriate location in wide vector register 317. In this embodiment, execution of the padding instruction inserts EOM padding bytes 2402 but not EOB padding words 2404 because (1) EOM padding bytes 2402 and EOB padding words 2404 can be located in different message blocks, and (2) EOB padding words 2404 can be efficiently located in the appropriate register 301 within the architected register file 300 using existing insert word instructions. Of course, in an alternative embodiment, both EOM padding bytes 2402 and EOB padding words 2404 can be applied to the SHA2 message block in register 301 of the architected register file 300 .

25 , an exemplary fill instruction 2500 is shown according to one embodiment. In at least one embodiment, the exemplary fill instruction 2500 may be executed by the accelerator unit 314 within the data transfer circuit 406 to perform fill on both SHA3/SHAKE message blocks and SHA2 message blocks.

In the illustrated example, the fill instruction 2500 includes an operation code field 2502 that specifies the architecture-specific operation code for the message fill instruction. The fill instruction also includes two register fields 2504 and 2506 that specify the storage locations of the source and destination operands of the fill operation. For example, register 1 field 2504 may identify the destination wide vector register 317 within wide vector register file 316 that buffers the message block to be filled, and register 2 field 2506 may specify register 301 within architected register file 300 that holds the remaining message length in bytes.

The padding instruction 2500 further includes a mode field 2508 that provides information for padding the message. In one exemplary embodiment, the mode field 2508 includes at least three subfields, including a hash identifier (HID) subfield 2510 , a block length (BL) subfield 2512 , and an extension (E) subfield 2514. The HID subfield 2510 indicates the type of hash function to be applied to the message block. For example, in one implementation, the HID subfield 2510 may include two bits that specify one of the following hash types: SHA3, SHAKE, SHA2 (64-bit word), and SHA2 (32-bit word). BL subfield 2512 indicates the length of the message block in bytes (possibly when interpreted together with HID subfield 2510 ). E subfield 2514 indicates whether the width vector register 317 specified by register 1 field 2504 holds the leading segment S0 or the trailing segment S1 of the message block. For example, in an embodiment where the wide vector register 317 is 1024 bits wide, if the wide vector register 317 specified by the register 1 field 2504 does not hold the trailing segment of the message block, then the E subfield 2514 may have a value of b0, and if the wide vector register 317 is specified to hold the trailing segment of the message block, then the E subfield 2514 may have a value of b1. Of course, in other embodiments where the wide vector register 317 has a different width (e.g., 512 bits), the E subfield 2514 may include additional bits to specify additional register segments.

Referring now to FIG. 26 , an exemplary fill circuit 2600 is shown according to one embodiment. Fill circuit 2600 , which may be implemented as part of data transfer circuit 406 of accelerator unit 314 , for example, fills message segment S1 held in a target wide vector register in response to execution of fill instruction 2500 as shown in FIG . 25 . The illustrated example assumes that wide vector register file 316 has 1024-bit wide vector registers 317 .

In this exemplary embodiment, fill circuit 2600 includes a select EOM circuit 2602 that selects the value of EOM pad byte 2302 or 2402 (i.e., eom_byte) based on the hash function specified by HID subfield 2510 of fill instruction 2500. Fill circuit 2600 also includes a select EOB circuit 2604 that similarly selects the value of the EOB pad byte (i.e., eob_byte) to be inserted by fill instruction 2500 based on HID subfield 2510 . In the depicted embodiment, for the SHA3/SHAKE hash function, select EOB circuit 2604 selects a fixed eob_byte value specified by the SHA-3 standard, which is contained in the register indicated by register 2 field 2506. For the SHA2 hash function, select EOB circuit 2604 selects a zero eob_byte because EOB padding word 2404 is inserted by a separate instruction in this embodiment. Padding circuit 2600 further includes select BL size circuit 2606 , which selects and outputs an 8-bit block length value based on HID field 2510 and BL field 2512 of padding instruction 2500 .

The 8-bit block length value output by the select BL size circuit 2606 is received by the EOB enable circuit 2608 , which includes a comparator 2610 , a decoder 2612 , and a bitwise AND circuit 2614. The high-order bit of the 8-bit block length value indicates whether the length of the message block exceeds the width of the 1024-bit wide vector register 317 (as would be the case, for example, for SHA3-224, SHAKE-128, and SHAKE 256). The low-order 7 bits of the block length form the block length size (bl_size), which indicates the number of bytes contained in the segment of the message block buffered in the target width vector register 317 identified by register 1 field 2504. The decoder 2612 decodes the 7-bit bl_size value to obtain a 128-bit representation of the position of the end of the message block in the target width vector register 317 . Comparator 2610 compares the high-order bits of the 8-bit block length with the E subfield 2514 of the pad instruction 2500 to form a 1-bit indication of whether EOB padding is added to the segment of the message block buffered in the destination width vector register (i.e., whether the destination width vector register 317 buffers the trailing segment S1 of the message block). This 1-bit indication is then logically combined by a bit-wise AND circuit 2614 to generate a 128-bit EOB enable signal (eob_en(0:127)) that identifies the byte of the message segment buffered in the target width vector register 317 into which the EOB padding is to be inserted (if any).

Still referring to FIG26 , padding circuit 2600 further includes EOM enable circuit 2620 , which includes selection circuit 2620 , comparator 2622 , decoder 2624 , and bitwise AND circuit 2626. In the depicted example, selection circuit 2620 is implemented by a two-input multiplexer having a first input coupled to receive an 8-bit indication of the message length and a second input coupled to receive an extended message length for a SHA-2 hash function using 32-bit words. The extended message length value at the second input doubles the original message length by inserting b0 between bits 5 and 6 of the original length according to the equation EX_LEN = 4*(LEN/4) + LEN. This technique preserves the bit positions of the original bits 6:7, which indicate the byte positions within the 32 high-order bits of the extended message block of the final message byte (if any). If HID subfield 2510 indicates that the hash function is a SHA3/SHAKE hash function or a SHA2 hash function that uses 64-bit words, then selection circuit 2620 selects the first of its two 8-bit inputs, and if HID subfield 2510 indicates that the hash function is a SHA2 hash function that uses 32-bit words, then selection circuit 2620 selects the second of its two inputs instead.

The 8-bit length value output by select circuit 2620 includes a high-order bit indicating whether the block length exceeds the width of the 1024-bit width vector register file 316 , and seven low-order bits indicating the number of bytes contained in the segment of the message block buffered in the target width vector register 317 identified by register 1 field 2504. Decoder 2624 decodes the seven low-order bits to obtain a 128-bit representation of the byte position (if any) at which the end of the message byte is to be inserted in the target width vector register 317 . Comparator 2622 compares the high-order bits of the length value output by select circuit 2620 with E subfield 2514 of pad instruction 2500 to form a 1-bit indication of whether EOM padding is to be added to the segment of the message block buffered in target width vector register 317. This 1-bit indication is then logically combined by bitwise AND circuit 2626 to generate a 128-bit EOM enable signal (eom_en(0:127)), which identifies the bytes of the message segment buffered in target width vector register 317 into which EOM padding is to be inserted (if any).

The EOB enable signal eob_en (0:127), the EOM enable signal eom_en (0:127), the eom_byte, the eob_byte, and the message segment from the target width vector register 317 are all passed to the conditional OR circuit 2630. This conditional OR circuit conditionally inserts EOM and/or EOB padding into the message segment to obtain the padded message segment Sp. The padded message segment Sp is then stored back into the target width vector register 317 specified in register 1 field 2504 .

Referring now to FIG. 27 , an exemplary embodiment of the conditional OR circuit 2630 of FIG. 26 is shown. In this example, each of the 128 bytes of the message segment has a respective associated OR gate 2700 having three 8-bit inputs. The first input of OR gate 2700 is coupled to receive the respective byte of message segment S. The second input of OR gate 2700 is coupled to the output of a two-input AND gate 2702 , which qualifies the eom_byte for a given bit packet of message segment S using eom_en(). The third input of OR gate 2700 is coupled to the output of a two-input AND gate 2704 , which qualifies eob_byte with eob_en() for a given bit packet of message segment S. OR gate 2700 performs a logical OR operation on these three inputs and writes the resulting bytes of the padded message segment Sp to the destination wide vector register 317 in wide vector register file 316. Therefore, if neither eom_en() nor eob_en() is asserted for a given bit packet of message segment S, the associated OR gate 2700 simply writes the bytes of the input message segment S to the corresponding bytes of the padded message segment Sp. However, if either or both eom_en() or eob_en() are asserted for a given bit tuple of message segment S, then the associated OR gate 2700 writes eom_byte, eob_byte, or a logical combination thereof, into the corresponding bytes of the padded message segment Sp, as indicated by the enable signals eom_en() and eob_en().

Referring now to FIG. 28 , a high-level logic flow diagram is depicted illustrating an exemplary process for filling a message block according to one embodiment. The depicted process may be executed by the accelerator unit 314 in response to receiving a fill instruction 2500. For ease of understanding, the process is described below with reference to the exemplary fill circuits depicted in FIG. 26 and FIG. 27 .

28 begins at block 2800 and then proceeds to block 2802 , which shows the accelerator unit 314 receiving the fill instruction 2500 for execution . In response to receiving the fill instruction 2500 , the accelerator unit 314 first accesses the source operand specified by the register fields 2504 and 2506 of the fill instruction 2500 (block 2804 ). Specifically, the accelerator unit 314 reads the message segment S from the target width vector register 317 specified by the register 1 field 2504 in the width vector register file 316 , and reads the unfilled message length from the register 301 specified by the register 2 field 2506 in the architected register file 300 , and passes these operands to the fill circuit 2600 of FIG . 26 , which, as mentioned above, may be implemented within the data transfer circuit 406. At block 2806 , the fill circuit 2600 uses the mode field 2508 of the fill instruction 2500 to select parameters for the fill operation. Specifically, select EOM circuit 2602 selects the value of EOM pad byte (eom_byte) 2302 or 2402 based on the hash function specified by mode field 2508 , select EOB circuit 2604 selects the value of the EOB pad byte (eob_byte) to be inserted by pad instruction 2500 (i.e., a fixed value for SHA3/SHAKE and a zero byte for SHA2, since EOB pad word 2404 is applied by a separate instruction for SHA2), and select BL size circuit 2606 selects the block length based on HID subfield 2510 and BL subfield 2512 . The eom_byte selected by the select EOM circuit 2602 and the eob_byte selected by the select EOB circuit 2604 form the input to the conditional OR circuit 2630 .

At block 2808 , selection circuit 2620 determines whether the hash function applied to the message is one of the SHA2-224 or SHA2-256 hash functions using 32-bit words based on the HID subfield of mode field 2508. If not, selection circuit 2620 selects and outputs the message length read from register 301 identified by free register 2 field 2506 as the message length, and the process of Figure 28 continues to block 2812 , which is described below. However, if selection circuit 2620 determines at block 2808 that HID subfield 2510 of fill instruction 2500 indicates the use of a 32-bit word SHA2 hash function, selection circuit 2620 selects and outputs a double length for the SHA2 message to account for the message expansion described above with reference to FIG. 15 . In one implementation, the expanded SHA2 message length can be conveniently calculated as: 4 * (LEN / 4) + LEN. The process then continues from block 2810 to block 2812 .

Block 2812 shows the determination by the EOM enable circuit 2620 of whether EOM padding is to be placed in the current message segment. If not, the EOM enable vector eom_en(0:127) generated by the EOM enable circuit 2620 is all zeros, and no EOM padding is inserted into the message segment S. Therefore, the process proceeds to block 2816 , which is described below. However, if the EOM enable circuit 2620 determines at block 2812 that EOM padding is to be inserted into the message segment S, the EOM enable circuit 2620 generates an EOM enable vector eom_en(0:127) that identifies the byte of the message segment S where the EOM padding byte is to be inserted, and the EOM padding byte is inserted into the specified byte of the padded message segment Sp via the conditional OR circuit 2630 (block 2814 ). The process continues from block 2814 to block 2816 .

At block 2816 , the BL size selection circuit 2606 and the EOB enable circuit 2608 determine whether the hash function specified by the mode field 2508 of the hash instruction 2500 is a SHA3 or SHAKE hash function and EOB padding bytes are to be inserted into the message segment S. If not, the EOB enable vector eob_en (0:127) generated by the EOB enable circuit 2608 is all zeros, and no EOB padding is inserted into the message segment S. Therefore, the program jumps from block 2816 to block 2820 , which is described below. However, if the BL size circuit 2606 and the EOB enable circuit 2620 determine at block 2816 that the hash function specified by the mode field 2508 is the SHA3 or SHAKE hash function and that EOB padding is to be inserted into the message segment S, the EOB enable circuit 2608 generates an EOB enable vector eob_en(0:127) that identifies the byte of the message segment S into which the EOB padding byte is to be inserted, and the EOB padding byte is inserted into the specified byte of the padded message segment Sp via the conditional OR circuit 2630 (block 2818 ). The program then proceeds to block 2820 .

Block 2820 shows the data transfer circuit 406 writing the resulting padded message segment Sp into the target width vector register 317 specified by register 1 field 2504. Thereafter, the process of FIG. 28 ends at block 2822 .

Referring now to FIG. 29 , a block diagram of an exemplary design flow 2900 used, for example, in semiconductor IC logic design, simulation, testing, layout, and manufacturing is shown. Design flow 2900 includes procedures, machines, and/or mechanisms for processing a design structure or device to generate a logically or otherwise functionally equivalent representation of the design structure and/or device described above and illustrated herein. The design structure processed and/or generated by design flow 2900 may be encoded on a machine-readable transmission or storage medium to include data and/or instructions that, when executed or otherwise processed on a data processing system, generate a logically, structurally, mechanically, or otherwise functionally equivalent representation of a hardware component, circuit, device, or system. A machine includes, but is not limited to, any machine used in an IC design process, such as designing, manufacturing, or simulating a circuit, component, device, or system. For example, a machine may include a lithography machine, a machine and/or equipment for generating masks (e.g., an electron beam writer), a computer or equipment for simulating a design structure, any equipment used in a manufacturing or testing process, or any machine for programming a functionally equivalent representation of a design structure into any medium (e.g., a machine for programming a programmable gate array).

The design flow 2900 may vary depending on the type of representation being designed. For example, the design flow 2900 for building an application-specific IC (ASIC) may differ from the design flow 2900 for designing a standard component or from the design flow 2900 for materializing the design into a programmable array, such as a programmable gate array (PGA) or a field programmable gate array (FPGA) provided by Altera® or Xilinx®.

FIG29 illustrates a plurality of such design structures, including an input design structure 2920 , preferably processed by a design program 2910. Design structure 2920 may be a logical simulation design structure generated by design program 2910 and processed to produce a logically equivalent functional representation of a hardware device. Design structure 2920 may also or alternatively include data and/or program instructions that, when processed by design program 2910, generate a functional representation of the physical structure of the hardware device. Whether representing functional and/or structural design features, design structure 2920 may be generated using, for example, electronic computer-aided design (ECAD) implemented by a core developer/designer. When encoded on a machine-readable data transmission, gate array, or storage medium, design structure 2920 can be accessed and processed by one or more hardware and/or software modules within design program 2910 to simulate or otherwise functionally represent an electronic component, circuit, electronic or logical module, apparatus, device, or system, such as those shown herein. Thus, design structure 2920 may include files or other data structures including human and/or machine readable source code, compiled structures, and computer executable code structures that, when processed by a design or simulation data processing system, functionally simulate or otherwise represent circuits or other levels of a hardware logic design. Such data structures may include hardware description language (HDL) design entities or other data structures that conform to lower-level HDL design languages (such as Verilog and VHDL) and/or higher-level design languages (such as C or C++) and/or are compatible with lower-level HDL design languages and/or higher-level design languages.

Design program 2910 preferably employs and incorporates hardware and/or software modules for synthesizing, translating, or otherwise processing design/simulation functional equivalents of components, circuits, devices, or logic structures presented herein to generate a wiring lookup table 2980 that may include design structures such as design structure 2920. Wiring lookup table 2980 may include, for example, a compiled or otherwise processed data structure representing a list of wires, discrete components, logic gates, control circuits, I/O devices, models, etc., that describe connections to other components and circuits in an integrated circuit design. Wiring lookup table 2980 can be synthesized using an iterative process, wherein wiring lookup table 2980 is resynthesized one or more times depending on the design specifications and parameters for the device. As with other design structure types described herein, wiring lookup table 2980 can be recorded on a machine-readable storage medium or programmed into a programmable gate array. The medium can be a non-volatile storage medium such as a magnetic or optical disk drive, a programmable gate array, a CF card, or other flash memory. Additionally or alternatively, the medium can be system or cache memory or buffer space.

Design program 2910 may include hardware and software modules for processing various input data structure types, including lookup tables 2980. Such data structure types may reside, for example, in library components 2930 and include a collection of commonly used components, circuits, and devices for a given manufacturing technology (e.g., different technology nodes: 32 nm, 45 nm, 290 nm, etc.), including models, layouts, and symbolic representations. Data structure types may further include design specifications 2940 , characterization data 2950 , verification data 2960 , design rules 2990 , and test data files 2985 , which may include input test patterns, output test results, and other test information. Design process 2910 may further include, for example, standard mechanical design processes such as stress analysis, thermal analysis, mechanical event simulation, and process simulation for operations such as casting, molding, and press forming. Those skilled in the art of mechanical design will appreciate the range of possible mechanical design tools and applications that may be used in design process 2910 without departing from the scope and spirit of the present invention. Design process 2910 may also include modules for performing standard circuit design process operations such as timing analysis, verification, design rule checking, placement, and routing.

The design program 2910 employs and incorporates logical and physical design tools such as HDL compilers and simulation model building tools to process the design structure 2920 along with some or all of the depicted supporting data structures and any additional mechanical design or data, if applicable, to generate a second design structure 2990. The design structure 2990 resides on a storage medium or programmable gate array in a data format for exchanging data of mechanical devices and structures (e.g., information stored in IGES, DXF, Parasolid XT, JT, DRG, or any other suitable format for storing or representing such mechanical design structures). Similar to design structure 2920 , design structure 2990 preferably comprises one or more files, data structures, or other computer-encoded data or instructions that reside on a transmission or data storage medium and, when processed by an ECAD system, generate a logically or otherwise functionally equivalent form of one or more of the embodiments of the present invention presented herein. In one embodiment, design structure 2990 may comprise a compiled, executable HDL simulation model that functionally simulates a device presented herein.

Design structure 2990 may also employ a data format and/or symbol data format for exchanging layout data of integrated circuits (e.g., information stored in GDSII (GDS2), GL1, OASIS, a map file, or any other suitable format for storing such design data structures). Design structure 2990 may include information such as, for example, symbol data, map files, test data files, design content files, manufacturing data, layout parameters, wires, metal levels, vias, shapes, data for routing through fabricated lines, and any other data required by a manufacturer or other designer/developer to produce devices or structures as described above and shown herein. The design structure 2990 may then proceed to stage 2995 , where, for example, the design structure 2990 : proceeds to tape-out, is released to manufacturing, is released to a mask room, is sent to another design house, is sent back to the customer, etc.

As described, in at least one embodiment, a processor includes an instruction fetch unit that fetches instructions to be executed, a register file that includes a plurality of registers for storing source and destination operands, and an execution unit that executes a fill instruction. The fill instruction includes an operand field and a mode field, the operand field indicating one of the plurality of registers that buffers a message block segment of a message block to be filled, and the mode field indicating which of a plurality of different hash functions to apply to the message block. The execution unit includes a fill circuit configured to receive a message block segment from one of the plurality of registers indicated by the operand field of the message fill instruction based on the message fill instruction, wherein the message block spans multiple registers in the register file. Based on which of the plurality of different hash functions is indicated by the mode field of the message fill instruction, the fill circuit selects a byte position in the message block segment at which to insert at least one padding byte and inserts the at least one padding byte at the byte position within the message block segment. The message block segment filled with the at least one padding byte is then written back to the register file.

In one embodiment, a data processing method includes fetching, by an instruction fetch unit of a processor, instructions to be executed by the processor, wherein the instructions include a fill instruction, the fill instruction including an operand field and a mode field, the operand field indicating one of a plurality of registers of a message block segment of a buffer to be filled with a message block, and the mode field indicating which of a plurality of different hash functions to apply to the message block. Upon receiving the fill instruction, an execution unit of the processor executes the fill instruction. Executing the message fill instruction includes receiving a message block segment from one of the plurality of registers indicated by the operand field of the message fill instruction from a register file, wherein the message block spans multiple registers in the register file. Based on which of the plurality of different hash functions is indicated by the mode field of the message fill instruction, selecting a byte position in the message block segment at which to insert at least one padding byte, and inserting the at least one padding byte at the byte position within the message block segment. The message block segment filled with the at least one padding byte is written back to the register file.

In one embodiment, the message block includes a plurality of message block segments, and the execution unit is configured to detect which of the plurality of message block segments the message block segment is based on an indication in the mode field.

In one embodiment, the plurality of different hash functions include a first hash function and a second hash function, and the execution unit is configured to insert both end-of-message (EOM) padding and end-of-block (EOB) padding in the message block segment based on the mode field indicating the first hash function, and is configured to insert EOM padding but not EOB padding in the message block segment based on the mode field indicating the second hash function.

In one embodiment, the operand field of the message fill instruction indicates a length parameter of one of the plurality of registers buffering the message segment, and the execution unit is configured to interpret the length parameter differently based on which of the plurality of hash functions is indicated by the mode field.

In one embodiment, the at least one padding byte includes an end-of-message (EOM) padding byte, selecting the byte position includes generating an EOM enable vector having a length corresponding to the message block segment, and inserting the at least one padding byte includes inserting the EOM padding byte at the byte position in the message block segment based on the EOM enable vector.

In one embodiment, the fill circuit includes a selection circuit configured to select a value of the EOM fill byte based on which of the plurality of different hash functions is indicated by the mode field of the fill instruction.

In one embodiment, the register file is a first register file including a first plurality of registers; the processor includes a second register file including a second plurality of registers, each of which has a length less than a length of the first plurality of registers; and the execution unit is further configured to combine multiple blocks of the message block segment into multiple registers among the second plurality of registers, and transfer all of the multiple blocks to one of the first plurality of registers to form the message block segment. In one embodiment, the processor is further configured to insert end-of-block (EOB) padding into one of the plurality of registers in the second plurality of registers before transferring the plurality of blocks to the one of the first plurality of registers.

In one embodiment, the at least one padding byte includes an end-of-block (EOB) padding byte, selecting the byte position includes generating an EOB enable vector having a length corresponding to the message block segment, and inserting the at least one padding byte includes inserting the EOB padding byte at the byte position in the message block segment based on the EOB enable vector.

In one embodiment, inserting the at least one pad byte includes logically combining the EOB pad byte with an end-of-message (EOM) pad byte.

In one embodiment, the execution unit includes a hash circuit configured to apply a hash function from the SHA family of hash functions to a padded message block including the padded message block segment based on a hash instruction.

In one embodiment, the message block segment is a portion of a message including a plurality of message blocks having a same length of r bits, the padded message blocks include r bits; and each of the plurality of registers has a length less than r bits.

While various embodiments have been particularly shown and described, those skilled in the art will understand that various changes in form and details may be made therein without departing from the spirit and scope of the appended claims, and that such alternative implementations are intended to be within the scope of the appended claims. For example, while the present invention has been described with specific reference to the SHA family of standards, those skilled in the art will understand that the disclosed invention is also applicable to other hashing algorithms (e.g., the generalized Keccak function, among others). Additionally, although illustrative numbers of bits and bytes have been discussed herein for ease of understanding, it should be understood that the specific numbers of bits and bytes used in hashing algorithms can and have changed over time, and that the principles of the disclosed invention apply to encryption algorithms regardless of the specific numbers of bits and bytes in a given implementation.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of an instruction set that includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions mentioned in the blocks may not occur in the order mentioned in the figures. For example, depending on the functionality involved, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order. It should also be noted that each block of the block diagrams and/or flowcharts, and combinations of blocks in the block diagrams and/or flowcharts, can be implemented by a special-purpose hardware-based system that performs the specified functions or actions or executes a combination of special-purpose hardware and computer instructions.

Furthermore, although aspects have been described with respect to a computer system executing program code that directs the functions of the present invention, it should be understood that the present invention may alternatively be implemented as a program product including a computer-readable storage device storing program code that can be processed by a data processing system. The computer-readable storage device may include volatile or non-volatile memory, an optical or magnetic disk, or the like. However, as used herein, "storage device" is specifically defined to include only legal products and excludes the signal medium itself, the transient propagating signal itself, and the energy itself.

Program products may include data and/or instructions that, when executed or otherwise processed on a data processing system, generate a logically, structurally, or otherwise functionally equivalent representation (including simulation models) of the hardware components, circuits, devices, or systems disclosed herein. Such data and/or instructions may include hardware description language (HDL) design entities or data structures compatible with lower-level HDL design languages (such as Verilog and VHDL) and/or higher-level design languages (such as C or C++) and/or other data structures compatible with lower-level HDL design languages and/or higher-level design languages. Additionally, the data and/or instructions may be in a data format and/or symbolic data format for exchanging layout data of an integrated circuit (e.g., information stored in GDSII (GDS2), GL1, OASIS, a map file, or any other suitable format for storing such design data structures).

100: Data processing system 102: Processor 104: Processor core 106: Cache 110: System interconnect 112: Memory controller 114: System memory 116: Input/output (I/O) adapter 118: Non-volatile storage system 120: Network adapter 200: Processor core 202: Instruction fetch unit 204: Instruction decoding unit 206: Branch processing unit 210: Mapper circuit 216: Dispatch circuit 218: Issue queue 220: Fixed point unit 222: Floating point unit 224: Load-store unit 226: Vector-scalar unit 230: Register 300: Architected register file 301: 256-bit registers r0 to rS 302: Functional Unit/Arithmetic Logic Unit/Rotation Unit 304: Functional Unit/Multiplication Unit 306: Functional Unit/Division Unit 308: Functional Unit/Encryption Unit 310: Functional Unit/Permutation Unit 312: Functional Unit/Binary Coded Decimal (BCD) Unit 314: Accelerator Unit 316: Wide Vector Register File 317: Registers R0 and R1 320: Transmission unit 400: SHA3/SHAKE hash circuit 402: SHA2 hash circuit 404: Single instruction, multiple data (SIMD) exclusive OR (XOR) circuit 406: Data transmission circuit 500: Process 502: Message 504: SHA3 absorption phase 506: SHA3/SHAKE compression phase 508: Message digest 600: Block 602: 1600-bit extended message block 604: SHA3 state permutation function 606: 1600-bit bitwise XOR function 610: 1600-bit final absorbed state 702: Round index 0 specified by the SHA-3 standard 704: SHA3 round function 800: Result block 1 802: Truncation function 804: Truncation function 900: SHA3 hash instruction 902: Operation code field 904: Register field 906: Register field 1000: Bitwise XOR instruction 1002: Operation code field 1004: Register field 1006: Register field 1008: Register field 1100a: 1024-bit dual-input multiplexer 1100b: 1024-bit dual-input multiplexer 1102a: 102 4-bit status register 1102b: 1024-bit status register 1106: SHA3 round circuit 1108: output multiplexer 1110: control circuit/control logic 1200: block 1202: block 1204: block 1206: block 1208: block 1210: block 1214: block 1216: block 1300: SHA2 hash function 1302: message 1304: block 1306: 16× w -bit message block/message block 1 1308: 8× w -bit initial state 1310: SHA2 block hash function 1312: Truncation function 1314: Message digest 1400: Message scheduling round function 1402: w -bit round key 1404: Round function/initial update round 1406: Block 1410: 8× w- bit carry propagation addition function 1420: Block/16× w bit initialization 1500: SHA2-224 or SHA2-256 input message 1502: 32-bit word 1504: output message 1506: 64-bit double word 1508: 32-bit zero word 1600: SHA2 hash instruction 1602: operation code field 1604: operand register field 1606: operand register field 1608: mode field 1702a: 512-bit double input status Multiplexer 1702b: 1024-bit dual-input message multiplexer 1704a: 512-bit status register 1704b: 1024-bit message block register 1708: Update work status circuit 1710: Message scheduling circuit 1712: Single instruction multiple data (SIMD) adder 1720: Control circuit 1800: Block/input status 1802: SHA2 Sigma 0 circuit 1804: SHA2 MA circuit 1806: SHA2 Sigma 1 circuit 1808: SHA2 CH circuit 1810: 64-bit adder 1812: 64-bit adder/modular adder 1814: 64-bit adder/modular adder 1816: Result status 1900: SHA2 sigma circuit 1902: 64-bit input variable 1904a: 64-bit rotate circuit 1904b: 64-bit rotate circuit 1906a: 32-bit rotate circuit 1906b: 32-bit rotate circuit 1908a: 64-bit rotate/shift circuit 1908b: 32-bit rotate/shift circuit 1910a: Multiplexer 1910b: Multiplexer 1910c: Multiplexer 1912: Three-input 64-bit bitwise XOR circuit/3-way bitwise XOR circuit 1914: 64-bit Meta output 2000: Block 2002: Block 2004: Block 2006: Block 2010: Block 2012: Block 2014: Block 2016: Block 2100: Unfilled message 2300: Last message block 2300': Last message block 2300'': Last message block 2302: EOM fill byte 2304: EO B padding byte 2306: Last message byte 2308: EOM/EOB padding byte 2310: Message block 2312: Extra zero message block 2400: Last message block 2400': Last message block 2400'': Last message block 2402: EOM padding byte 2404: EOB padding byte 2406: Last message byte 2408: Message block 2410: Complete message block 2412: Message block 2500: Fill instruction 2502: Operation code field 2504: Register 1 field 2506: Register 2 field 2508: Mode field 2510: Hash identifier (HID) subfield 2512: Block length (BL) subfield 2514: Extension (E) subfield 2 600: Fill circuit 2602: EOM selection circuit 2604: EOB selection circuit 2606: BL size selection circuit 2608: EOB enable circuit 2610: Comparator 2612: Decoder 2614: Bitwise AND circuit 2620: EOM enable circuit/selection circuit 2622: Comparator 2624: Decoder 2626 :Bitwise AND circuit 2630:Conditional OR circuit 2700:OR gate 2702:Dual input AND gate 2704:Dual input AND gate 2800:Block 2802:Block 2804:Block 2806:Block 2808:Block 2810:Block 2812:Block 2814:Block 2816:Block 2818:Block Block 2820: Block 2822: Block 2900: Design Flow 2910: Design Procedure 2920: Design Structure 2930: Library Components 2940: Design Specifications 2950: Characterization Data 2960: Verification Data 2980: Wiring Comparison Table 2985: Test Data File 2990: Design Rules/Second Design Structure 2995: Phase

FIG1 is a high-level block diagram of a data processing system including a processor according to one embodiment ;

FIG2 is a high-level block diagram of a processor core according to one embodiment ;

FIG3 is a high-level block diagram of an exemplary execution unit of a processor core according to one embodiment ;

FIG4 is a more detailed block diagram of an accelerator unit within a processor core according to one embodiment ;

Figure 5 shows the time-space diagram of message hashing according to the SHA-3 standard;

FIG6 is a time-space diagram of the absorption phase depicted in FIG5 ;

FIG7A is a time-space diagram of the SHA3 permutation function shown in FIG6 ;

FIG7B is a time-space diagram of the SHA3 round function depicted in FIG7A ;

Figure 8 is a time-space diagram of the SHA3/SHAKE squeeze phase shown in Figure 5 ;

9 and 10 illustrate exemplary formats for a SHA3 hash instruction and a bitwise exclusive OR (XOR) instruction, respectively, according to one embodiment ;

FIG11 is a high-level block diagram of an exemplary SHA3 / SHAKE hashing circuit according to one embodiment;

FIG12 is a high-level logical flow chart of an exemplary process by which a processor executes a SHA3 hash instruction according to one embodiment;

Figure 13 depicts the time-space diagram of message hashing according to the SHA-2 standard;

FIG14 is a time-space diagram of the SHA2 block hash function shown in FIG13 ;

FIG15 illustrates message expansion of a SHA2 hash function with 32-bit words according to an exemplary embodiment ;

FIG16 depicts an exemplary format for a SHA2 hash instruction according to one embodiment ;

FIG17 is a high-level block diagram of an exemplary SHA2 hashing circuit according to one embodiment;

FIG18 is a high-level block diagram of the exemplary update operating status circuit from FIG17 according to one embodiment;

FIG19 is a high-level block diagram of an exemplary embodiment of the SHA2 sigma circuit shown in FIG18 ;

FIG20 is a high-level logical flow chart of an exemplary process by which a processor executes a SHA2 hash instruction according to one embodiment;

FIG21A depicts an exemplary unpopulated message;

FIG21B depicts an exemplary populated message;

22A - 22B illustrate grouping blocks of message blocks in a narrower first register file and transferring the message blocks to a wider second register file;

Figures 23A to 23D illustrate various padding scenarios for SHA3 /SHAKE messages;

Figures 24A to 24D illustrate various padding scenarios for SHA2 messages ;

FIG25 illustrates an exemplary fill instruction according to one embodiment ;

FIG26 depicts an exemplary fill circuit according to one embodiment ;

FIG27 illustrates an exemplary circuit for combining end-of-block (EOB) and end-of-message (EOM) bytes and messages according to one embodiment ;

FIG28 is a high-level logic flow diagram of an exemplary process for filling a message block according to one embodiment; and

FIG29 depicts an exemplary design process according to one embodiment.

2800: Block 2802: Block 2804: Block 2806: Block 2808: Block 2810: Block 2812: Block 2814: Block 2816: Block 2818: Block 2820: Block 2822: Block

Claims (20)

A processor includes: an instruction fetch unit that fetches instructions to be executed; a register file comprising a plurality of registers for storing source and destination operands; and an execution unit for executing a message fill instruction, wherein the message fill instruction includes an operand field and a mode field, the operand field indicating one of the plurality of registers that buffers a message block segment of a message block to be filled, and the mode field indicating which of a plurality of different hash functions is to be applied to the message block, wherein the execution unit includes a fill circuit configured to perform the following operations based on the message fill instruction: receiving a message block segment from one of the plurality of registers indicated by the operand field of the message stuff instruction, wherein the message block spans a plurality of registers in the register file; determining whether to insert at least one padding byte into the message block segment based on which of the plurality of different hash functions is indicated by the mode field of the message stuff instruction; selecting a byte position in the message block segment into which to insert the at least one padding byte based on which of the plurality of different hash functions is indicated by the mode field, based on determining that the at least one padding byte is to be inserted into the message block segment, and inserting the at least one padding byte at the selected byte position in the message block segment; Based on determining that the at least one padding byte is not inserted into the message block segment, avoid inserting the at least one padding byte into the message block segment; and write the message block segment filled by the at least one padding byte back to the register file, wherein the padding circuit includes: at least one enable circuit, the enable circuit being configured to generate an enable vector to select a byte position; and an OR circuit, the OR circuit being coupled to receive the enable vector and the message block segment, and being configured to insert the at least one padding byte at the selected byte position in the message block segment based on the enable vector. The processor of claim 1, wherein the plurality of different hash functions include SHA3, SHAKE, and SHA2 hash functions. The processor of claim 1, wherein: the message block includes a plurality of message block segments; and the execution unit is configured to detect which of the plurality of message block segments the message block segment is based on an indication in the mode field. A processor as claimed in claim 1, wherein: the plurality of different hash functions include a first hash function and a second hash function; and the execution unit is configured to insert both end-of-message (EOM) padding and end-of-block (EOB) padding in the message block segment based on the mode field indicating the first hash function, and is configured to insert EOM padding but not EOB padding in the message block segment based on the mode field indicating the second hash function. The processor of claim 1, wherein: the plurality of hash functions include a first hash function and a second hash function; the selecting includes selecting the byte position based on a length parameter indicated by the operand field of the message fill instruction; and the execution unit is configured to insert the at least one padding byte at a first byte position based on the length parameter when the mode field indicates the first hash function, and to insert the at least one padding byte at a different second byte position based on the length parameter when the mode field indicates the second hash function. The processor of claim 1, wherein: the fill circuit includes a selection circuit configured to select a value of the at least one fill byte based on which of the plurality of different hash functions is indicated by the mode field of the fill instruction. A processor as in claim 1, wherein: the register file is a first register file; the plurality of registers are a first plurality of registers; the processor includes a second register file, the second register file including a second plurality of registers, each having a length less than a length of the first plurality of registers; the execution unit is further configured to combine multiple blocks of the message block segment into multiple registers among the second plurality of registers, and transfer all of the multiple blocks to one of the first plurality of registers to form the message block segment. The processor of claim 7, wherein the processor is further configured to insert end-of-block (EOB) padding into one of the plurality of registers in the second plurality of registers before transferring the plurality of chunks to the one of the first plurality of registers. The processor of claim 1, wherein: selecting the byte position comprises generating an enable vector having a length corresponding to the message block segment; and inserting the at least one padding byte comprises inserting the at least one padding byte at the byte position in the message block segment based on the enable vector. The processor of claim 1, wherein: inserting the at least one pad byte comprises logically combining an end-of-block (EOB) pad byte with an end-of-message (EOM) pad byte and inserting a resulting combined pad byte. The processor of claim 1, wherein: the execution unit includes a hash circuit configured to apply a hash function from the SHA family of hash functions to a padded message block including the padded message block segment based on a hash instruction. The processor of claim 1, wherein: the message block segment is part of a message comprising a plurality of message blocks having a same length of r bits; the padded message block includes r bits; and each of the plurality of registers has a length less than r bits. A method for performing data processing in a processor including a register file, the method comprising: fetching, by an instruction fetch unit of the processor, instructions to be executed by the processor, wherein the instructions include a fill instruction, the fill instruction including an operand field and a mode field, the operand field indicating one of a plurality of registers of a message block segment of a buffer to be filled with a message block, and the mode field indicating which of a plurality of different hash functions is to be applied to the message block; and executing, by an execution unit of the processor, the fill instruction upon receiving the fill instruction, wherein executing the fill instruction comprises: receiving, from the register file, a message block segment from one of the plurality of registers indicated by the operand field of the message stuff instruction, wherein the message block spans a plurality of registers in the register file; determining whether to insert at least one padding byte into the message block segment based on which of the plurality of different hash functions is indicated by the mode field of the message stuff instruction; Based on determining that the at least one padding byte is to be inserted into the message block segment, selecting a byte position in the message block segment at which to insert the at least one padding byte based on which of the plurality of different hash functions is indicated by the mode field, and inserting the at least one padding byte at the selected byte position in the message block segment, wherein the selecting comprises generating an enable vector specifying the byte position by an enable circuit; and inserting the at least one padding byte at the selected byte position in the message block segment based on the enable vector by one or more circuits coupled to receive the enable vector and the message block segment; Based on determining that the at least one stuffing byte is not inserted into the message block segment, refraining from inserting the at least one stuffing byte into the message block segment; and writing the message block segment filled with the at least one stuffing byte back to the register file. A method as claimed in claim 13, wherein: the message block includes multiple message block segments; and the method further includes detecting which of the multiple message block segments the message block segment is based on an indication in the mode field. The method of claim 13, wherein: the plurality of different hash functions include a first hash function and a second hash function; and the execution includes inserting both end-of-message (EOM) padding and end-of-block (EOB) padding in the message block segment based on the mode field indicating the first hash function, and is configured to insert EOM padding but not EOB padding in the message block segment based on the mode field indicating the second hash function. The method of claim 13, wherein: the plurality of hash functions include a first hash function and a second hash function; the selecting includes selecting the byte position based on a length parameter indicated by the operand field of the message fill instruction; and the inserting includes inserting the at least one padding byte at a first byte position based on the length parameter when the mode field indicates the first hash function, and inserting the at least one padding byte at a different second byte position based on the length parameter when the mode field indicates the second hash function. The method of claim 13, further comprising: selecting, by the execution unit, a value of the at least one pad byte based on a hash function indicated by the mode field of the pad instruction. A method as claimed in claim 13, wherein: the register file of the processor is a first register file; the plurality of registers are a first plurality of registers; the processor includes a second register file, the second register file including a second plurality of registers, each having a length less than a length of the first plurality of registers; the method further includes combining multiple chunks of the message block segment in multiple registers among the second plurality of registers, and transferring all of the multiple chunks to one of the first plurality of registers to form the message block segment. The method of claim 18, further comprising inserting end-of-block (EOB) padding into one of the plurality of registers in the second plurality of registers before transferring the plurality of chunks to the one of the first plurality of registers. The method of claim 13, further comprising: based on a hash instruction, applying, by a hash circuit of the processor, a hash function from the SHA family of hash functions to a padded message block including the padded message block segment.