Secure data processing method and processor using hash

Abstract

A method and a processor for secure data processing using hashing are provided. The processor includes a register file and an execution unit. The execution unit includes a hash circuit including at least a state register, a state update circuit coupled to the state register, and a control circuit. Based on a hash instruction, the hash circuit receives the current state of the message to be hashed from the register file and the buffer in the state register. The state update circuit performs a state update function on the contents of the state register, where performing the state update function includes performing multiple iterative rounds of processing on the contents of the state register and returning the results of each of the multiple iterative rounds of processing to the state register. Following completion of all of the multiple iterative rounds of processing, the execution unit stores the contents of the state register in the register file as the updated state of the message. (Figure 2)

Description

[Background technology]

[0001] The present invention relates generally to data processing, and in particular to efficiently implementing secure hash algorithms in hardware.

[0002] An important aspect of data security is the protection of data at rest (e.g., while stored on a data storage device) or in motion (e.g., during transmission) through encryption. Generally, encryption involves using a cryptographic function to transform unencrypted data (called plaintext) into encrypted data (called ciphertext) through a combination of plaintext and one or more encryption keys. To recover the plaintext from the ciphertext, the ciphertext is processed by a decryption function using one or more decryption keys. Thus, encryption provides data security by requiring a party to know an additional secret (i.e., a decryption key) before they can access the protected plaintext.

[0003] In many implementations, data encryption is performed using software running on a general-purpose processor. While implementing encryption in software offers the advantage of being able to select different encryption algorithms and easily adapting the selected encryption algorithm to use with various data lengths, implementing encryption in software also has the disadvantage of relatively low performance. As the volume of data sets continues to increase dramatically in the era of "big data," the performance achieved by software-implemented encryption may not be acceptable when encrypting large messages and / or data sets. Concerns about encryption performance also arise due to the increasing need to run enterprise applications that utilize encrypted data to mitigate the consequences of "hacking" and other cyber-attacks and to ensure regulatory compliance. Accordingly, it is often desirable to provide support for encryption in hardware to achieve improved performance. Summary of the Invention

[0004] This disclosure recognizes that one class of cryptographic algorithms for which it may be desirable to provide hardware support are hash functions, including but not limited to hash functions belonging to the Secure Hash Algorithm (SHA) family of standards. As known in the art, the SHA family of standards defines hash algorithms approved by the National Institute for Standards and Technology (NIST) for generating condensed 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 "SHA3 Standard: Permutation-Based Hashing and Extensible Output Function," which are incorporated herein by reference. FIPS 180-4 specifies seven hash algorithms: SHA-1 (Secure Hash Algorithm-1) and the SHA-2 family of hash algorithms, including SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, and SHA-512 / 256. FIPS 202 additionally specifies four SHA3 hash algorithms with fixed-length outputs (i.e., SHA3-224, SHA3-256, SHA3-384, and SHA3-512), and two closely related "extensible 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., stream ciphers, authenticated encryption systems, or tree hashing methods) have not yet been adopted as NIST standards.

[0005] Given the wide variety of hash functions and data sizes for hash functions (even within the standard SHA family), widespread support in hardware for hash functions can result in a large area in a processor floorplan being consumed by circuits implementing the hash function. As a result, some hardware solutions choose to implement such circuits separately from the processor core, for example, in a bus-attached application-specific integrated circuit (ASIC) or accelerator. While the use of these additional circuits offers the potential for better performance than some software solutions, they still suffer from bus and memory access latency and messaging overhead, again limiting performance compared to what is achievable within a high-performance processor core. This performance penalty is particularly significant for relatively small messages (e.g., messages conforming within a single message block), which represent the majority of SHA messages processed in enterprise servers. The present disclosure addresses these and other design considerations by efficiently implementing hash functions in a processor.

[0006] In one embodiment, the processor includes an instruction fetch unit, a register file, and an execution unit. The instruction fetch unit fetches instructions for execution. The register file includes a plurality of registers for storing source and destination operands. The execution unit includes a hash circuit including at least a state register, a state update circuit coupled to the state register, and control circuitry. Based on a hash instruction, the hash circuit receives a current state of the message to be hashed from the register file and the buffer in the state register. The state update circuit performs a state update function on the contents of the state register, where performing the state update function includes performing multiple iterative rounds of processing on the contents of the state register and returning results of each of the multiple iterative rounds of processing to the state register. Following completion of all of the multiple iterative rounds of processing, the execution unit stores the contents of the state register in the register file as an updated state of the message.

[0007] Such a processor may be incorporated into a data processing system that includes multiple processors, a shared memory, and a system interconnect that communicatively couples the shared memory and the multiple processors.

[0008] Such a processor may also be tangibly embodied in a design structure in a machine-readable storage device for designing, manufacturing, or testing integrated circuits.

[0009] In one embodiment, a method for processing data in a processor includes fetching, by an instruction fetch unit, an instruction for execution by the processor. The instruction includes a hash instruction. Upon receiving the hash instruction, an execution unit of the processor, including a hash circuit including at least a state register, a state update circuit coupled to the state register, and control circuitry, executes the hash instruction. Executing the hash instruction includes receiving a current state of the message to be hashed from the register file and the buffer in the state register of the execution unit. Executing the hash instruction also includes performing, in the state update circuit, a state update function on the contents of the state register, where executing the state update function includes performing multiple iterative rounds of processing on the contents of the state register and returning a result of each of the multiple iterative rounds of processing to the state register. Following completion of all of the multiple iterative rounds of processing, the contents of the state register are stored in the register file as an updated state of the message.

[0010] In at least some embodiments, the state update function includes a Secure Hash Algorithm 3 (SHA3) state permutation function, and the state update circuit performs 24 rounds of processing, each of which utilizes a respective one of the 24 round indexes as an input.

[0011] In one embodiment, the execution unit executes hash instructions during the squeezing phase of the Secure Hash Algorithm and the Keccak (SHAKE) hash algorithm.

[0012] In at least some embodiments, the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function. In at least some embodiments, the hash circuit further includes an adder configured to add the contents of the state register to the current state and return the resulting sum to the register file.

[0013] In some embodiments, the execution unit further includes a message block register for buffering message blocks of the message, and a message schedule round circuit coupled to the message block register, the message schedule round circuit performing multiple iterative rounds of processing on the contents of the message block register and returning a result of each of the multiple iterative rounds of processing to the message block register.

[0014] In some embodiments, the state update circuit includes a data path for data words having a first data width, and the execution unit is configured based on the hash instruction indicating a second data width narrower than the first data width to expand data words of a message block of the message to the first data width before processing the data words of the message in the state update circuit. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a high-level block diagram of a data processing system including a processor according to one embodiment;

[0016] [Figure 2] FIG. 2 is a high-level block diagram of a processor core according to one embodiment.

[0017] [Figure 3]FIG. 2 is a high-level block diagram of an exemplary execution unit of a processor core in accordance with one embodiment.

[0018] [Figure 4] FIG. 2 is a more detailed block diagram of an accelerator unit within a processor core according to one embodiment.

[0019] [Figure 5] A time-space diagram of message hashing according to the SHA3 standard.

[0020] [Figure 6] FIG. 6 is a time-space diagram of the absorption phase depicted in FIG.

[0021] [Figure 7A] FIG. 7 is a time-space diagram of the SHA3 permutation function illustrated in FIG. 6.

[0022] [Figure 7B] FIG. 7B is a time-space diagram of the SHA3 round function depicted in FIG. 7A.

[0023] [Figure 8] FIG. 6 is a time-space diagram of the SHA3 / SHAKE squeezing phase illustrated in FIG. 5.

[0024] [Figure 9] 1 illustrates an exemplary format of a SHA3 hash instruction, according to one embodiment. [Figure 10] 1 illustrates an exemplary format of a bitwise exclusive OR (XOR) instruction, according to one embodiment.

[0025] [Figure 11] FIG. 2 is a high-level block diagram of an exemplary SHA3 / SHAKE hashing circuit, according to one embodiment.

[0026] [Figure 12]1 is a high-level logical flowchart of an exemplary process by which a processor executes a SHA3 hash instruction, according to one embodiment.

[0027] [Figure 13] Depicts the time-space diagram of message hashing according to the SHA2 standard.

[0028] [Figure 14] FIG. 14 is a time-space diagram of the SHA2 block hash function illustrated in FIG. 13.

[0029] [Figure 15] 1 illustrates message expansion for a SHA2 hash function with 32-bit words, according to an example embodiment.

[0030] [Figure 16] 1 depicts an exemplary format for a SHA2 hash instruction, according to one embodiment.

[0031] [Figure 17] FIG. 2 is a high-level block diagram of an exemplary SHA2 hashing circuit, according to one embodiment.

[0032] [Figure 18] FIG. 18 is a high-level block diagram of the exemplary operating state update circuit from FIG. 17, according to one embodiment.

[0033] [Figure 19] FIG. 19 is a high-level block diagram of an exemplary embodiment of the SHA2 sigma circuit shown in FIG. 18.

[0034] [Figure 20] 1 is a high-level logical flowchart of an exemplary process by which a processor executes a SHA2 hash instruction, according to one embodiment.

[0035] [Figure 21A]1 depicts an exemplary unpadded message.

[0036] [Figure 21B] 1 illustrates an exemplary padded message.

[0037] [Figure 22A] 1 depicts the assembly of chunks of a message block in a narrower first register file and the transfer of the message block to a wider second register file. [Figure 22B] 1 depicts the assembly of chunks of a message block in a narrower first register file and the transfer of the message block to a wider second register file.

[0038] [Figure 23A] Illustrates various padding scenarios for SHA3 / SHAKE messages. [Figure 23B] Illustrates various padding scenarios for SHA3 / SHAKE messages. [Figure 23C] Illustrates various padding scenarios for SHA3 / SHAKE messages. [Figure 23D] Illustrates various padding scenarios for SHA3 / SHAKE messages.

[0039] [Figure 24A] Depict various padding scenarios for SHA2 messages. [Figure 24B] Depict various padding scenarios for SHA2 messages. [Figure 24C] Depict various padding scenarios for SHA2 messages. [Figure 24D] Depict various padding scenarios for SHA2 messages.

[0040] [Figure 25] 1 illustrates an exemplary padding instruction, according to one embodiment.

[0041] [Figure 26] 1 depicts an exemplary padding circuit, according to one embodiment.

[0042] [Figure 27] 1 illustrates an exemplary circuit for combining end-of-block (EOB) and end-of-message (EOM) bytes with a message, according to one embodiment.

[0043] [Figure 28] 1 is a high-level logical flowchart of an exemplary process for padding a message block, according to one embodiment.

[0044] [Figure 29] 1 depicts an exemplary design process, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0045] 1, there is depicted a high-level block diagram of a data processing system 100 according to one embodiment. In some implementations, data processing system 100 may be, for example, a server computer system (such as one of the POWER series of servers available from International Business Machines Corporation), a mainframe computer system, a mobile computing device (such as a smartphone or tablet), a laptop or desktop personal computer system, or an embedded processor system.

[0046] As shown, data processing system 100 includes one or more processors 102 that process instructions and data. Each processor 102 may be implemented as a respective integrated circuit having a semiconductor substrate on which the integrated circuit is formed, as is known in the art. In at least some embodiments, processor 102 may generally implement any one of several 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 cache memory 106 that provides low-latency access to instructions and operands likely to be read and / or written by processor cores 104. Processors 102 are coupled for communication by a system interconnect 110, which, in various implementations, may include one or more buses, switches, bridges, and / or hybrid interconnects.

[0047] Data processing system 100 may additionally include several other components coupled to system interconnect 110. These components may include, for example, a memory controller 112 that controls access to system memory 114 by processor 102 and other components of data processing system 100. In addition, 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).

[0048] Additionally, those skilled in the art will appreciate that data processing system 100 shown in Figure 1 may include many additional, not-shown, components. Because such additional components are not necessary to an understanding of the described embodiments, they are not shown in Figure 1 or further described herein. However, it should also be understood that the enhancements described herein are applicable to data processing systems and processors of a variety of architectures and are in no way limited to the general-purpose data processing system architecture illustrated in Figure 1.

[0049] 2, a high-level block diagram of an exemplary processor core 200 is depicted, according to one embodiment. Processor core 200 may be utilized to implement any of processor cores 104 of FIG.

[0050] In the depicted example, processor core 200 includes an instruction fetch unit 202 for fetching instructions in one or more streams of instructions from storage 230 (which may include, for example, cache memory 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 the operation to be performed by processor core 200 (e.g., fixed-point or floating-point arithmetic operation, vector operation, matrix operation, logical operation, branch operation, memory access operation, cryptographic operation, etc.). Particular instructions may additionally include one or more operand fields that directly specify operands or that implicitly or explicitly reference one or more registers that store source operands used in executing the instruction and one or more registers for storing destination operands produced by execution of the instruction. In some embodiments, an instruction decode unit 204 integrated with instruction fetch unit 202 decodes instructions retrieved from storage 230 by instruction fetch unit 202 and forwards branch instructions that control the flow of execution to branch processing unit 206. In some embodiments, the processing of branch instructions performed by branch processing unit 206 may include speculating on the outcome of conditional branch instructions. The outcome of branch processing by branch processing unit 206 (both speculative and non-speculative) may then be used to redirect one or more streams of instruction fetches by instruction fetch unit 202.

[0051] Instruction decode unit 204 forwards non-branch instructions (often referred to as "sequential instructions") to mapper circuit 210. Mapper circuit 210 is responsible for allocating physical registers in processor core 200's register file to instructions as necessary to support instruction execution. Mapper circuit 210 preferably implements register renaming. Thus, for at least some classes of instructions, mapper circuit 210 establishes a temporary mapping between the set of logical (or architected) registers referenced by the instruction and a larger set of physical registers in processor core 200's register file. As a result, processor core 200 may avoid unnecessary serialization of non-data-dependent instructions that might otherwise occur due to reuse of a limited set of architected registers by instructions that are closest in program order.

[0052] 2, processor core 200 additionally includes dispatch circuitry 216 configured to ensure that any data dependencies between instructions are observed and to dispatch sequential instructions when ready for execution. Instructions dispatched by dispatch circuitry 216 are temporarily buffered in issue queue 218 until an execution unit of processor core 200 has available resources to execute the dispatched instructions. When appropriate execution resources become available, issue queue 218 opportunistically issues instructions from issue queue 218 to an execution unit of processor core 200, possibly in an order different from the original program order of the instructions.

[0053] In the depicted example, processor core 200 includes multiple different types of execution units for executing respective different 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 storage 230, and one or more vector-scalar units 226 for executing instructions that access vector and / or scalar operands. In an exemplary embodiment, each execution unit is implemented as a multi-stage pipeline in which multiple instructions are processed simultaneously at different stages of execution. Each execution unit preferably includes, or is coupled to have access to, at least one register file containing multiple physical registers for temporarily buffering operands accessed or generated by instruction execution.

[0054] 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 whose execution by execution units 220-226 is completed. Because these additional components are not necessary to an understanding of the described embodiments, they are not shown in FIG. 2 or further described herein.

[0055] 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 more detail. In the embodiment of FIG. 3, vector-scalar unit 226 is configured to execute multiple different classes of instructions that operate on and produce different types of operands. For example, vector-scalar unit 226 is configured to execute a first class of instructions that operate on vector and scalar source operands and produce vector and scalar destination operands. Vector-scalar unit 226 executes instructions in this first class of instructions in functional units 302-312, which, in the depicted embodiment, include an arithmetic logic unit / rotate unit 302 for performing addition, subtraction, and rotate operations, a multiply unit 304 for performing binary multiplication, a divide unit 306 for performing binary division, a cipher unit 308 for performing cryptographic functions, a permutation unit 310 for performing operand permutations, and a binary-coded decimal (BCD) unit 312 for performing decimal-point mathematical operations. The vector and scalar source operands on which these operations are performed, and the vector and scalar destination operands produced by these operations, are buffered in physical registers of architected register file 300.

[0056] In this example, vector-scalar unit 226 is additionally configured to execute a second class of instructions that perform hash functions. Vector-scalar unit 226 executes instructions in this second class of instructions in accelerator unit 314. Operands on which these hash functions are performed and operands generated by these hash functions are buffered and stored in wide vector register file 316, which may include, for example, 1024-bit wide physical registers.

[0057] During operation, an instruction is received from issue queue 218 by vector-scalar unit 226. If the instruction is of a first class of instruction (e.g., a vector-scalar instruction), associated source operands for the instruction are accessed in architected register file 300 using the mapping between logical and physical registers established by mapper circuit 210 and then forwarded along with the instruction to the associated one of functional units 302-312 for execution. Destination operands produced by that execution are then stored back into physical registers in architected register file 300 as determined by the mapping established by mapper circuit 210. On the other hand, if the instruction is of a second class of instruction (e.g., a hash instruction), the instruction is forwarded to accelerator unit 314 for execution with operands buffered in designated registers in wide vector register file 316.

[0058] Referring now to FIG. 4, a more detailed block diagram of accelerator unit 314 of FIG. 3 is depicted, according to one embodiment. Accelerator unit 314 includes circuitry for implementing 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 accelerator unit 314 includes at least a SHA3 / SHAKE hash circuit 400, as described in more detail below with reference to FIG. 11, and a SHA2 hash circuit 402, as described in more detail below with reference to FIG. 17. Accelerator unit 314 further includes a single instruction multiple data (SIMD) exclusive OR (XOR) circuit 404 that is utilized in performing SHA3 / SHAKE hashes of messages, as described below. Finally, accelerator unit 314 includes a data transfer circuit 406 that transfers data (e.g., messages to be hashed and message digests) between the memory system (e.g., cache memory 106 and system memory 114) and wide vector register file 316.

[0059] Referring now to FIG. 5, there is a time-space diagram of a message hashing process 500 according to the SHA3 standard. As known in the art, the SHA3 standard (i.e., FIPS202) utilizes 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 several megabytes) is first processed in an input phase, referred to in sponge terminology as the SHA3 absorption phase 504. As described in more detail below with reference to FIG. 6, the SHA3 absorption phase 504 is identical for both the SHA3 and SHAKE hash functions. The SHA3 absorption phase 504 produces a 1600-bit final absorption state 610, which is then processed in an output phase (referred to in sponge terminology as the SHA3 / SHAKE squeezing phase 506) to produce a message digest 508. The SHA3 / SHAKE squeezing phase 506, described in more detail below with reference to FIG. 8, operates differently for the SHA3 hash function and the SHAKE hash function. In particular, the SHA3 / SHAKE squeezing phase 506 produces a fixed-length message digest 508 for various SHA3 hash functions, but produces a variable-length message digest 508 for SHAKE hash functions.

[0060] Table I below summarizes the attributes of the four SHA3 hash functions and two SHAKE hash functions defined by the SHA3 standard, listed in the first column. In Table I, the second column summarizes the size in bits (r) of the message blocks obtained by the SHA3 absorption phase 504 by breaking down the variable-length message 502. The message block size r is an integer multiple of bytes in length, and the first message block of each message is byte-aligned. The third column of Table I summarizes the size in bits (d) of the message digest 508 output by the SHA3 / SHAKE squeezing phase 506. It should again be noted that SHAKE-128 and SHAKE-256, unlike the SHA3 hash function, produce a variable-length digest of length d'. As listed in the fourth column of Table I, for each hash function specified by the SHA3 standard, the length of the final absorption state 610 is 1600 bits. The fifth column of Table I specifies different values ​​of c, the number of low-order bits passed between iterations of the SHA3 state permutation function during the SHA3 / SHAKE squeezing phase 506 (see, e.g., FIG. 8). Finally, the sixth column of Table I specifies that each iteration of the SHA3 state permutation function utilizes 24 rounds of permutation per message block (see, e.g., FIG. 7A). In updates to the SHA3 standard, or in non-standard implementations, the number of rounds of permutation may be varied, for example, by reducing the required number of permutations (e.g., to 12). Table I [Table 1]

[0061] Referring now to FIG. 6, a time-space diagram of the SHA3 absorption phase 504 depicted in FIG. 5 is depicted. As shown, the SHA3 absorption phase 504 receives as input a message 502 of any arbitrary length. As shown in 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 achieved through a high-latency, computationally expensive memory-to-memory move of the entire message 502. In some other prior art implementations, the SHA hashing software routine pads the message block after loading it into a SIMD register using a sequence of conventional SIMD instructions. As described in detail below with reference to FIGS. 21A through 27, these prior art techniques are utilized herein to perform the padding; however, this padding can instead be efficiently performed by hardware in a processor register (e.g., wide vector register file 316) in accordance with the disclosed invention through the execution of padding instructions. The padded message 502 through execution of the padding instructions also allows padding to be applied to the end of the message 502 in a time-overlapping manner with the processing of the message blocks in the SHA3 absorption phase 504.

[0062] In the SHA3 absorption phase 504, each of the n message blocks of length r (n is a positive integer) that make up the padded message is extracted and then zero-extended in its last, least significant bits to form n 1600-bit extended message blocks 602. The first message block, i.e., message block 1 602, forms the input of a SHA3 state permutation function 604 defined by the SHA3 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 implemented in hardware through execution of a SHA3 hash instruction. The 1600-bit state output of the SHA3 state permutation function 604 forms the first input of a 1600-bit bitwise XOR function 606, which takes as its second input the next 1600-bit extended message block 602 of the padded message. The result of the bitwise XOR function 606 forms the input of the next iteration of the SHA3 state permutation function 604. As shown, this process continues iteratively for each of the message blocks 602 until the final iteration of the SHA3 state permutation function 604 generates and outputs a final absorbing state 610 of 1600 bits, as previously described in the description of Figure 5.

[0063] 7A, there is illustrated a time-space diagram of the SHA3 permutation function 604 illustrated in FIG. 6. The SHA3 permutation function 604 receives a 1600-bit input and then processes the 1600-bit input in conjunction with round index 0 702 specified by the SHA3 standard in the first of 24 rounds of the SHA3 round function 704. This process continues iteratively, with each subsequent round of processing in the SHA3 round function 704 receiving as input the 1600-bit output of the previous SHA3 round function 704 and the round index 702 (which is a constant) specified by the associated SHA3 standard. After 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 SHA3 absorption phase 504, constitutes the final absorption state 610 which serves as input to the SHA3 / SHAKE squeezing phase 506.

[0064] Referring now to Figure 7B, a time-space diagram of the SHA3 round function 704 depicted in Figure 7A is depicted. As shown, the SHA3 round function 704 includes a sequence of SHA3 standard-specified functions, including, in order, five functions referred to in the SHA3 standard as the Greek letters θ (theta), ρ (rho), π (pi), χ (chi), and ι (iota). The theta functions receive and process the 1600-bit input to the round function 704, feeding the output of each function, except for the iota function, into the next function in the sequence. Finally, the iota function processes the output of the chi function and the associated round index 702 to generate the 1600-bit output for a given iteration of the SHA3 round function 704. In the prior art, execution of the round function 704 can take up to 80 cycles utilizing two single instruction multiple data (SIMD) vector pipelines. According to one aspect of the invention disclosed herein, the round function 704 may be completed in a single cycle of the processor core 104 using the SHA3 / SHAKE hash circuit 400 of FIG. 11, described below.

[0065] 8, a time-space diagram of the SHA3 / SHAKE squeezing phase 506 illustrated in FIG. 5 is shown. As previously described, the SHA3 / SHAKE squeezing phase 506 receives as input the 1600-bit final absorption state 610 produced by the SHA3 absorption phase 504. To generate a message digest 508 for any of the SHA3 functions defined by the SHA3 standard, the SHA3 / SHAKE squeezing phase 506 first extracts the first r most significant bits of the final absorption state 610 to form a result block 1 800. A truncation function 802 then truncates r bits of the result block 1 800, keeping the most significant d bits to form the message digest 508.

[0066] To generate a message digest for one of the SHAKE functions defined by the SHA3 standard, the r bits of result block 1 800 form the r most significant bits of the input to a truncation function 804. These r most significant bits are concatenated with n-1 additional r-bit result blocks 800, each formed from the r most significant bits of the output of an iteration of the SHA3 state permutation function 604, as previously described with respect to FIG. 7A. Each SHA3 state permutation function 604 in the SHA3 / SHAKE squeezing phase 506 receives a 1600-bit input (i.e., r+c=1600) and produces a 1600-bit output, which feeds the subsequent iteration of the SHA3 state permutation function 604, except for the last iteration of the SHA3 state permutation function 604. The truncation function 804 truncates r×n input bits to obtain a message digest 508 having a user-specified length of d′ bits.

[0067] 9-10, exemplary formats are illustrated for a SHA3 hash instruction 900 and a bitwise exclusive OR (XOR) instruction 1000, respectively, according to one embodiment. In an exemplary embodiment, accelerator unit 314 is configured to, in response to receiving SHA3 hash instruction 900, utilize SHA3 / SHAKE hash circuitry 400 to perform a SHA3 / SHAKE state permutation function in hardware, and, in response to receiving bitwise XOR instruction 1000, utilize SIMD XOR circuitry 404 to perform a 1024-bit bitwise XOR of the specified operands.

[0068] In the illustrated embodiment, the SHA3 hash instruction 900 includes an opcode field 902 that specifies a particular architecture-specific operation code for the SHA3 / SHAKE permutation function. The SHA3 hash instruction 900 additionally includes one or more register fields 904, 906 to 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 the 1600-bit source operand and the 1600-bit destination operand (which overwrites the source operand) following completion of the SHA3 / SHAKE permutation function. In an alternative implementation, the SHA3 hash instruction 900 includes two register fields 904, 906 that specify a separate pair of 1024-bit source and destination registers (in which case the destination operand does not overwrite the source operand).

[0069] As noted above, in future updates to the SHA3 standard or non-standard implementations, it may be desirable to control the number of rounds of permutation applied by the SHA3 state permutation function 604. In such an embodiment, the number of rounds SHA3 hash instruction 900 may include a field that either directly sets the number of rounds of permutation or references a register that specifies the number of rounds of permutation.

[0070] 10 depicts an exemplary embodiment in which a bitwise XOR instruction includes an opcode field 1002 that specifies a particular architecture-specific operation code for a 1024-bit bitwise XOR function. The bitwise XOR instruction 1000 additionally includes three register fields 1004, 1006, and 1008 that separately specify 1024-bit registers within the wide vector register file 316 for buffering two 1024-bit source operands and one 1024-bit destination operand.

[0071] Now that the SHA3 and SHAKE hash functions and example instructions for implementing some of these hash functions have been described, pseudocode for executing an example SHA3 hash function in hardware is presented. In the pseudocode below, the following registers are referenced: Rr ← Block length in bytes RL ← message length in bytes / / Assume RL ≥ Rr and the first block is not padded Ra ← start address of message Rb ← Address of the message digest resulting from the hash function Rd ← message digest length in bytes Xs ← SHA3 state / / wide vector register pair Xm ← message block / / wide vector register pair Considering these registers, the pseudocode for any of the SHA3 (non-SHAKE) hash functions can be expressed as follows: Xs=loadlength(Ra,Rr) / / Loads the first message block of the message and initializes the state Xs = sha3hash(Xs) / / Executes the SHA3 hash command and performs substitutions on the first message block RL-=Rr / / Decrement length of outstanding message Ra+=Rr / / Increment pointer to the next message block in the message While(RL>=Rr) / / Enter a loop to process each remaining message block except the last one in the message. {Xm=loadlength(Ra, Rr) / / Load the next message block Xs = wide_xor(Xs,Xm) / / Perform a bitwise XOR operation to combine the state and the current message block Xs = sha3hash(Xs) / / Executes the SHA3 hash instruction and performs substitutions on the current message block RL-=Rr / / Decrement length of outstanding message Ra+=Rr / / Increment pointer to next message block } Xm = loadlength(Ra,RL) / / Load the last message block, if present (RL can be zero) Xm=sha3_padding(Xm,RL,sha3-type) / / Executes the padding command to pad the message based on the remaining message length and the SHA3 function. Xs = wide_xor(Xs,Xm) / / Performs a bitwise XOR operation to combine the state and the last message block Xs = sha3hash(Xs) / / Executes the SHA3 hash instruction, performs a substitution on the last message block, and generates the final absorbing state Store_length(Xs,Rb,Rd) / / During the SHA3 squeezing phase, form a message digest by truncating the last absorbing state and storing the first Rd bytes of Xs in memory at address Rb

[0072] 11 , there is shown a high-level block diagram of an exemplary SHA3 / SHAKE hash circuit 400 suitable for executing the SHA3 hash instruction 900, according to one embodiment. As shown, the SHA3 / SHAKE hash circuit 400 includes two 1024-bit 2-input multiplexers 1100 a, 1100 b, two 1024-bit status 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.

[0073] Input multiplexer 1100a has a first input coupled to receive the most significant 1024 bits of the 1600-bit input state from a first register of a register pair in wide vector register file 316 identified by SHA3 hash instruction 900, and a second input coupled to receive the most significant 1024 bits of the 1600-bit round feedback from SHA3 round circuitry 1106. Input multiplexer 1100b is similarly structured, with a first input coupled to receive a 1024-bit value comprising the least significant 576 bits of the 1600-bit input state from a second register of an instruction-specified register pair in wide vector register file 316, and a second input coupled to SHA3 round circuitry 1106 to receive a 1024-bit value comprising the least significant 576 bits of the 1600-bit round feedback. Control logic 1110 within SHA3 / SHAKE hash circuit 400 provides selection signals, not shown, to input multiplexers 1100a, 1100b, causing input multiplexers 1100a, 1100b to select the value present at their first inputs before SHA3 round 0 and to select the value present at their second inputs following each of SHA3 rounds 0 through 23. The values ​​output by input multiplexers 1100a, 1100b, which are buffered in state registers 1102a, 1102b, respectively, together form 1600-bit round input values ​​for SHA3 round circuit 1106, which is configured to perform SHA3 round function 704 on the round input values, as previously described with reference to Figures 7A-7B.

[0074] The control circuitry 1110 is further configured to sequence the SHA3 round circuitry 1106 through each of the 24 rounds required by the SHA3 standard, utilizing the correct round index specified by the SHA3 standard. Following the conclusion of round 23, the status registers 1102a, 1102b hold the upper 1024 bits and the lower 576 bits of the 1600-bit output state, respectively. The control circuitry 1110 is further configured, once the output state is obtained, to assert a select signal (not shown) to cause the output multiplexer 1108 to write, in two consecutive cycles, the upper and lower bits of the 1600-bit output state from the status registers 1102a, 1102b to an instruction-specified register pair in the wide vector register file 316 (assuming the wide vector register file 316 has a single write port).

[0075] 12, there is depicted a high-level logical flowchart of an exemplary process for executing the SHA3 hash instruction 900, according to one embodiment. For ease of understanding, the process of FIG. 12 will be described with reference to the exemplary SHA3 / SHAKE hash circuit 400 of FIG.

[0076] 12 begins at block 1200 and then proceeds to block 1202, which illustrates the SHA3 / SHAKE hash circuitry 400 receiving a SHA3 hash instruction 900 that specifies an operand register pair in the wide vector register file 316. In response to receiving the SHA3 hash instruction 900, the control circuitry 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, 1102b via the input multiplexers 1100a, 1100b (block 1204). The control circuitry 1110 additionally initializes an internal round counter to 0 (block 1206).

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

[0078] Referring now to FIG. 13, a time-space diagram of message hashing according to the SHA2 standard (FIPS 180-4) performed by the SHA2 hash circuit 402 in the embodiment of FIG. 4 is illustrated. Table II below summarizes the attributes of the six SHA2 hash functions defined by the SHA2 standard and listed in the first column. In Table II, the second column summarizes the message block size (r) in bits. The length of the message block size r is an integer multiple of bytes, and the first message block of a message is byte-aligned. The third column of Table II summarizes the fixed size (d) in bits of the message digest resulting from each SHA2 hash function. The fourth column of Table II specifies the size in bits of the state for each SHA2 hash function, and the fifth column of Table II indicates the number of rounds of processing (i.e., 64 or 80) used in each SHA2 hash function (see, e.g., FIG. 14). Finally, the sixth column of Table II specifies the word size in bits used for each SHA2 hash function. 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 explained below, in accordance with one aspect of the disclosed invention, SHA2 hash functions utilizing 32-bit word sizes and SHA2 hash functions utilizing 64-bit word sizes are processed along the same data flow, with message expansion applied to words for the SHA2-224 and SHA2-256 hash functions, as explained below with reference to Figure 15. Table II [Table 2]

[0079] As shown in FIG. 13, SHA2 hash function 1300 receives as one input a message 1302 of any arbitrary length (e.g., possibly megabytes in length). As shown in block 1304, message 1302 is padded to obtain a length that is an integer multiple of r bits. As described above with reference to FIG. 6, this padding can be efficiently performed by hardware in processor registers (e.g., wide vector register file 316) rather than by memory movement through execution of a padding instruction. Padding message 1302, specifically the last message block of message 1302, through execution of a padding instruction also allows 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 (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.

[0080] In addition to the message 1302, the SHA2 hash function 1300 also receives as an input an 8×w-bit SHA-2-specified constant value. This constant value, which may be accessed from the architected register file 300 as known in the art, varies between SHA2 hash functions to form an 8×w-bit initial state 1308. The initial state 1308 and the first message block, i.e., message block 1 1306, form two inputs of the SHA2 block hash function 1 1310 defined by the SHA2 standard. As described below with reference to Figures 16 and 17, according to one aspect of the disclosed invention, the SHA2 block hash function 1310 is implemented in hardware through execution of a SHA2 hash instruction. The 8×w-bit state output by the SHA2 block hash 1 function 1310 forms the first input of the SHA2 block hash function 2 1310, which receives the next 16×w-bit message block 2 1306 as a second input. The result of SHA2 block hash function 2 130 forms the input for the next iteration of SHA2 block hash function 1310. As shown, this process continues iteratively for each of the message blocks 602 until the final nth iteration of SHA2 block hash function 1310 generates and outputs a final state of 8×w bits, which is truncated by truncation function 1312 to produce a d-bit message digest 1314.

[0081] Referring now to Figure 14, there is depicted a time-space diagram of the SHA2 block hash function 1310 shown in Figure 13. The SHA2 block hash function 1310 receives the 16xw bit message block 1306 and initializes a 16xw bit message schedule for the message block 1306, as shown in block 1420. The SHA2 block hash function 1310 then processes the 16xw bit message schedule through n rounds of processing in the message schedule round function 1400, with the 16xw bit output of each of rounds 1 through n-2 serving as input to the next round of message schedule processing.

[0082] As shown, the SHA2 block hash function 1310 also receives as input an 8×w-bit current hash state (i.e., either the initial state 1308 or the output of a previous SHA2 block hash function 1310). As shown in block 1406, the SHA2 block hash function 1310 divides this 8×w-bit current hash state into eight w-bit variables a through h. The SHA2 block hash function 1310 then processes the current hash state through n rounds of processing by an update round function 1404. The first update round 0 1404 receives as additional inputs a SHA-2 specific w-bit round key 0 1402 and the w most significant bits of the 16×w-bit initialization of the message schedule 1420. Each subsequent iteration of the update round function 1404 receives as input the state produced by the previous iteration of the update round function 1404, the w most significant bits of the 16×w bit output of the corresponding iteration of the message schedule round function 1400, and the SHA-2 specified w bit round key 1402. The hash state output by the update round function n−1 1404 is added to the input hash state by an 8×w bit carry propagate addition function 1410 to produce the next hash state.

[0083] Referring now to FIG. 15, message expansion for a SHA2 hash function according to an exemplary embodiment is illustrated. As described above with reference to Table II and FIG. 13, embodiments of the disclosed invention preferably support processing SHA2 hash functions of different word sizes w along a common data path by expanding the message words and initial hash states of those SHA2 hash functions to utilize smaller word sizes. This expansion may be performed, for example, in blocks 1304 and 1308 of FIG. 13. FIG. 15 illustrates a specific example in which each of sixteen 32-bit words 1502 of a SHA2-224 or SHA2-256 input message 1500 is expanded to form a corresponding one of sixteen 64-bit double words 1506 of an output message 1504. In this example, each 64-bit double word 1506 is formed by concatenating a 32-bit word of the input message 1500 in the most significant half of the 64-bit double word 1506 with a 32-bit zero word 1508 in the least significant half of the double word 1506. The resulting output message 1504 can then be processed by a SHA2 hash circuit in the same manner as a message utilizing a 64-bit word.

[0084] 16, an exemplary format for a SHA2 hash instruction 1600 is depicted according to one embodiment. In an exemplary embodiment, the accelerator unit 314 is configured to, in response to receiving the SHA2 hash instruction 1600, utilize the SHA2 hash circuitry 402 to perform the SHA2 block hash function 1310 in hardware.

[0085] In the illustrated embodiment, the SHA2 hash instruction 1600 includes an opcode field 1602 that specifies a particular architecture-specific operation code for the SHA2 block hash function. The SHA2 hash instruction 1600 additionally includes one or more operand register fields 1604, 1606 for specifying 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, the SHA2 hash instruction 1600 includes a register field 1604 that specifies a 1024-bit register for buffering the current hash input state and for buffering the output current hash state (overwriting the current hash input state) following completion of the SHA2 block hash function. In addition, the SHA2 hash instruction 1600 includes a register field 1606 for buffering the current message block being processed. The SHA2 hash instruction 1600 further includes a mode field 1608 that indicates whether the SHA2 hash function being performed utilizes 32-bit or 64-bit words.

[0086] Having now described the SHA2 hash function and exemplary instructions for implementing portions of the SHA2 hash function, pseudocode for implementing an exemplary 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. The following registers are referenced in the pseudocode below: Rl ← message length in bits RL ← message length in bytes; assume 128 bytes or more to avoid padding in the first message block Ra ← start address of message Ri←Initial state address Rb ← Address of the message digest resulting from the hash function Rd ← message digest length in bytes Xs ← SHA2 state / / wide vector register Xm ← current message block / / wide vector register

[0087] Taking these registers into account, the pseudocode for performing the SHA2-512 hash function can be expressed as follows: Xs = load(Ri, 64) / / Load 64 bytes of initial state Xm = load(Ra, 128) / / Load the first (complete) message block Xs = sha2hash(Xs, Xm, 64-bit) / / Executes the SHA2 hash command to perform the block hash function RL-=128 / / Decrement the message length to be processed Ra+=128 / / Advance the pointer to the next message block While(RL>=128) / / Loop through the remaining message blocks except for the last one {Xm=load(Ra,128) / / Load the next message block (full size) Xs = sha2hash(Xs, Xm, 64-bit) / / Executes the SHA2 hash command to perform the block hash function RL-=128 / / Decrement the message length to be processed Ra+=128 / / Advance the pointer to the next message block Xm = loadlength(Ra,RL) / / Load the last message block, if present (RL can be zero) Xm=sha2_EOM_pad(Xm,RL) / / Appends a SHA2 EOM byte to the end of the message block If (RL>111) then / / If the padding spans two message blocks, {Xs = sha2hash(Xs,Xm,64bit) / / Execute the SHA2 hash command to perform the block hash function, Xm=force-to-zero / / Force the last message block to zero} Xm=sha2_EOB_pad(Xm,RI) / / Insert EOB into the last block of the padded message Xs = sha2hash(Xs, Xm, 64-bit) / / Executes the SHA2 hash command to perform a block hash function on the last message block Store(Xs,Rb,64) / / Truncate the state to the first 64 bytes of Xs, get the message digest, and store it in memory at address Rb

[0088] 17, there is shown a high-level block diagram of an exemplary embodiment of the SHA2 hash circuit 402 of FIG. 4 that is suitable for executing the SHA2 hash instruction 1600. As shown, the SHA2 hash circuit 402 includes a 512-bit two-input state multiplexer 1702a, a 1024-bit two-input message multiplexer 1702b, a 512-bit state register 1704a, a 1024-bit message block register 1704b, an operation state update circuit 1708, a message schedule round 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.

[0089] In this example, a first input of state multiplexer 1702a is coupled to receive the current hash state, held in the 512 most significant bits of the register, from a register in wide vector register file 316 specified by register field 1604 of SHA2 hash instruction 1600. A second input of state multiplexer 1702a is coupled to the output of operation state update circuit 1708. Message multiplexer 1702b is similarly configured, having a first input coupled to receive a message block from a register in wide vector register file 316 specified by register field 1606 of SHA2 hash instruction 1600, and a second input coupled to receive 1024-bit round feedback from message schedule round circuit 1710. Control logic 1720 within SHA2 hash circuit 400 provides select signals (not shown) to multiplexers 1702a, 1702b, causing multiplexers 1702a, 1702b to select the value present at their first input before update round 0 function 1404 and the value present at their second input following each of the update round 0 functions through the SHA2 block hash n functions. The values ​​output by multiplexers 1702a, 1702b are temporarily buffered in status and message block registers 1704a, 1704b, respectively. The message blocks buffered in message block register 1704b form the input to message schedule round circuit 1710, which implements message schedule round function 1400 of FIG. 14. The 64 most significant bits from the message block register 1704b and the 512-bit state in the status register 1704a form two inputs to an operational state update circuit 1708 that is configured to perform the update round function 1404, as previously described with reference to FIG. 14.

[0090] The control circuitry 1720 is further configured to sequence the operational state update circuitry 1708 through each of the n rounds using the correct round index specified by the SHA2 standard. Following the conclusion of the final round n-1, the state register 1704a holds the 512-bit hash state. As described above with respect to the addition function 1410 of FIG. 14, once the output hash state is obtained, the control circuitry 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 file 316 and store the result, which is the next hash state, back into the wide vector register file 316. Those skilled in the art will appreciate that in different implementations, the SIMD adder 1712 may be implemented as a dedicated component of the SHA2 hash circuitry 402 or as a separate pipeline shared, for example, by multiple hash circuits.

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

[0092] The operational state update circuit 1708 generates a 512-bit result state 1816 composed of eight 64-bit variables a'-h'. Variable a' of the result state 1816 is formed by the output of adder 1812, variables b', c', and d' are formed from variables a, b, and c, respectively, of the input state 1800, and variables f', g', and h' are formed from variables e, f, and g, respectively, of the input state 1800. The remaining variable e' is formed by the sum of the output of adder 1810 and variable d of the input state 1800.

[0093] Note that the 32-bit to 64-bit extension of the words of the SHA-2 message, described above with reference to Figure 15, does not affect (is transparent to) the design of the SHA2 MA circuit 1804, the SHA2 CH circuit 1808, and the modular adders 1812, 1814. The trailing zero extension of the SHA2 messages utilizing 32-bit words only affects the SHA2 sigma circuits 1802, 1806, as will be described in more detail below with reference to Figure 19.

[0094] Figure 19 is a more detailed block diagram of an exemplary embodiment of a SHA2 sigma circuit 1900 that may be utilized to implement the SHA2 sigma 0 circuit 1802 and the SHA2 sigma 1 circuit 1806 of Figure 18. The SHA2 sigma circuit 1900 receives a 64-bit input variable 1902 that includes 32 most significant bits (bits 0-31) and 32 least significant bits (bits 32-63).

[0095] The SHA2 sigma circuit 1900 includes a 64-bit rotate circuit 1904a that rotates a 64-bit input variable 1902 by n1 bits (i.e., 28 bits for the SHA2 sigma 0 circuit 1802 and 14 bits for the SHA2 sigma 1 circuit 1806) to obtain a first 64-bit input for multiplexer 1910a. The SHA2 sigma circuit 1900 additionally includes a 32-bit rotate circuit 1906a that rotates the 32 most significant bits of the input variable 1902 by m1 bits (i.e., 2 bits for the SHA2 sigma 0 circuit 1802 and 6 bits for the SHA2 sigma 1 circuit 1806) to obtain a second 64-bit input for multiplexer 1910a when concatenated with the 32 least significant bits of the 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 mode field 1608 is set to indicate a SHA2 hash function that uses 64-bit words, multiplexer 1910a selects the first input, and if the mode signal indicates that mode field 1608 is set to indicate a SHA2 hash function that uses 32-bit words, multiplexer 1910a selects the second input.

[0096] SHA2 sigma circuit 1900 additionally includes a 64-bit rotate circuit 1904b that rotates 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 for multiplexer 1910b. SHA2 sigma circuit 1900 also includes a 32-bit rotate circuit 1906b that rotates the 32 most significant 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 obtain a second 64-bit input for multiplexer 1910b when concatenated with the 32 least significant bits of input variable 1902. Multiplexer 1910b selects between its first and second inputs based on a mode signal. In particular, multiplexer 1910b selects the first input when the mode signal indicates that mode field 1608 is set to indicate a SHA2 hash function that uses 64-bit words, and selects the second input when the mode signal indicates that mode field 1608 is set to indicate a SHA2 hash function that uses 32-bit words.

[0097] 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 for multiplexer 1910c. SHA2 sigma circuit 1900 additionally includes a 32-bit rotate / shift circuit 1908b that rotates and shifts the 32 most significant 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 obtain a second 64-bit input for multiplexer 1910c when concatenated with the 32 least significant bits of input variable 1902. Multiplexer 1910c selects between its first and second inputs based on a mode signal. Similar to multiplexers 1910a and 1910b, multiplexer 1910c selects its first input when the mode signal indicates that mode field 1608 is set to indicate a SHA2 hash function using 64-bit words, and selects its second input when the mode signal indicates that mode field 1608 is set to indicate a SHA2 hash function using 32-bit words.

[0098] The 64-bit outputs of multiplexers 1910a, 1910b, and 1910c form the inputs of a 3-input 64-bit bitwise XOR circuit 1912, which performs a bitwise XOR on its three inputs to produce a 64-bit output 1914. Those skilled in the art will appreciate that in some embodiments of SHA2 sigma circuit 1900, the functions of rotate circuits 1904a-1904b and 1906a-1906b and rotate / shift circuits 1908a-1908b are implemented with appropriate wiring, allowing SHA2 sigma circuit 1900 to be realized using three multiplexers 1910a-1910c and 3-way bitwise XOR circuit 1912 without explicit rotate and shift circuits.

[0099] 20, there is depicted a high-level logical flowchart of an exemplary process for executing a SHA2 hash instruction 1600, according to one embodiment. For ease of understanding, the process of FIG. 20 will be described with reference to the exemplary embodiment of the SHA2 hash circuit 402 illustrated in FIGS.

[0100] The process of Figure 20 begins at block 2000 and then proceeds to block 2002, which illustrates the SHA2 hash circuitry 402 receiving a SHA2 hash instruction 1600 specifying a particular SHA2 mode (i.e., 32-bit or 64-bit word size), as well as the status and message block registers within the wide vector register file 316. In response to receiving the SHA2 hash instruction 1600, the control circuitry 1720 causes a 512-bit status and a 1024-bit message block to be read from the wide vector register file 316 and loaded into the status register 1704a and the message block register 1704b via multiplexers 1702a and 1702b, respectively (block 2002). The control circuitry 1720 additionally initializes an internal round counter to 0 (block 2004).

[0101] The process then proceeds from block 2004 to block 2006, which illustrates control circuitry 1720 instructing message schedule round circuitry 1710 to perform an iteration of message schedule round function 1400 using the message block buffered in message block register 1704b. Additionally, control circuitry 1720 instructs operational state update circuitry 1708 to perform an iteration of update round function 1404 based on the appropriate round index, the 64 most significant bits of message block register 1704b, and the input hash state from status register 1704a. The results of the operations of operational state update circuitry 1708 and message schedule round circuitry 1710 are returned to registers 1704a and 1704b by multiplexers 1702a and 1702b, respectively. Control circuitry 1110 additionally advances a round counter. In block 2010, control logic 1720 references the round counter to determine whether SHA2 hash circuitry 402 has performed the last round of processing specified by the SHA2 standard. Note that, as shown in Table II, the SHA2 hash circuit 402 performs 64 rounds of processing for the SHA2 hash function using 32-bit words and 80 rounds of processing for the SHA2 hash function using 64-bit words. If the control circuit 1720 determines in block 2010 that at least one additional round of processing remains to be performed, the process returns to block 2006, as described. However, in response to determining in block 2010 that all rounds of processing have been completed, the control circuit 1720 again causes the previous state to be read from the wide vector register file 316 and added by the SIMD adder 1712 to the final state buffered in the state register 1704a (block 2012). The control circuit 1720 then directs the resulting next state to be saved back to the wide vector register file 316 (block 2014). The process of FIG. 20 then ends in block 2016.

[0102] As described above with reference to block 600 of FIG. 6 and block 1304 of FIG. 13, a message processed by the SHA2 and SHA3 hash functions is padded to create a message having 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 including n message blocks. Of these, the first n - 1 message blocks include r bits, but the final message block n includes k bits, where k < r. As shown in FIG. 21B, in the general case, message 2100 is padded by adding r - k padding bits at the end of message block n, resulting in n message blocks all of length r bits.

[0103] The content of the padding bits added to obtain the padded message can vary depending on the hash function being considered. For example, in the SHA2 and SHA3 / SHAKE hash algorithms described herein, the padding bits include bytes that mark 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 further described below, in some cases, all of the padding bits including the EOM and EOB markers are included within the message block containing the final message byte; in other cases, the addition of padding bits may require adding additional message blocks to the message. In any case, the disclosed invention preferably performs message padding in a processor register through the execution of one or more instructions, rather than a high-latency memory move operation that transfers the message between two locations in memory.

[0104] In at least some architectures, the load-store unit 224, memory controller 112, and / or system interconnect 110 are not configured to support data transfers of long data objects (e.g., complete r-bit SHA3 / SHAKE and SHA2 message blocks) between system memory 114 and wide vector register file 116. In such architectures, the message blocks are transferred in multiple smaller chunks into a narrower register file, and then transferred from the narrower register file into one or more wide vector registers of wide vector register file 316. For example, FIG. 22A illustrates an example in which a SHA3 / SHAKE message block n is assembled in an architected register file 300 that includes 256-bit registers r0 through rS 301. In this example, a load long instruction, for example, executed by load-store unit 224 of FIG. 2, loads five 256-bit chunks of the 1152-bit SHA3-224 message block n into registers r0 through r7, zeroing any register bytes that do not contain message data. Given the 1152-bit length of message blocks in SHA3-224, the message bytes in message block n will, at most, completely fill registers r0 through r3 and the first 128 bits of register r4 (of course, the final message block of an unpadded message may contain fewer than r bits). At least the remaining 128 bits of register r4 and all of registers r5 through r7 can be zeroed automatically by executing a load length instruction or by executing a standard load instruction. (The zeroing of registers r6 and r7 is only required for the general SHA3 function applicable to any of the supported message block lengths.) Additional data transfer instructions are then executed by data transfer circuit 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 described above.In an alternative implementation, the same result can be achieved by loading four registers 301 in architected register file 300 to buffer chunks n1 through n4, and then reusing the same registers 301 in the following cycle to buffer chunks n5 through n8.

[0105] FIG. 22B depicts a similar example showing the transfer of 1024-bit SHA2 message block n to wide vector register 317 in wide vector register file 316, followed by assembly of the message block in register 301 of architected register file 300. In this example, a load length instruction is executed, e.g., by load-store unit 224 of FIG. 2, to load four 256-bit chunks of SHA2 message block n into registers r2 through r5 of architected register file 300, zeroing any register bytes that do not contain message data. An additional data transfer instruction is then executed by data transfer circuit 406 to transfer the contents of registers r2 through r5 into register R0 317 of wide vector register file 316. In an alternative implementation, the same result could be achieved by loading two registers 301 in architected register file 300 to buffer chunks n1 and n2, and then reusing the same register 301 to buffer chunks n3 through n4 on a subsequent cycle.

[0106] 22A-22B into wide vector register file 316 is performed for all message blocks of a SHA3 / SHAKE or SHA2 message, including message block n, which is the last message block of the unpadded message. As described below, the end of the message may then be padded, at least in part, in wide vector register file 316 through execution of one or more instructions.

[0107] 23A-23D depict various padding cases for various lengths of SHA3 / SHAKE messages. According to the SHA3 standard, each message must include EOM padding to mark the EOM. In 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 SHA3 standard also requires that the last byte of each padded message be a fixed-value EOB padding byte.

[0108] As shown in FIG. 23A, if the last message block 2300 of a SHA3 / SHAKE message contains more than two bytes that do not contain message data, an 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 an EOB padding byte 2304 is inserted into the zeroed bytes of the wide vector register 317 as the last byte of the padded message block.

[0109] 23B illustrates a similar second case, where the last message block 2300′ of the SHA3 / SHAKE message contains exactly two zeroed bytes that contain no message data. In this case, the last two zeroed bytes of the last message block 2300′ are replaced with EOM padding bytes 2302 followed by EOB padding bytes 2304.

[0110] FIG. 23C depicts a third case, in which the last message block 2300" of the SHA3 / SHAKE message contains 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 last byte of the padded message block 2300" as EOM / EOB padding byte 2308.

[0111] Figure 23D illustrates the last case, where the last message byte 2306 of the SHA3 / SHAKE message is the last byte of a message block 2310. Because the message block 2310 does not contain capacity for the required EOM and EOB padding in this case, an additional zeroed message block 2312 is appended to the message (e.g., through execution of a load length instruction). Within this zeroed message block 2312, an EOM padding byte 2302 is inserted as the first byte, and an EOB padding byte 2304 is inserted as the last byte. Note that in each of the four cases depicted in Figures 23A-23D, both EOM padding and EOB padding are advantageously applied with a single padding instruction, since both padding always reside within the same message block. While Figures 23A-23D depict the application of padding to a message containing an integer number of message bytes, it should also be understood that padding is similarly applied to bit messages that do not contain an integer number of bytes.

[0112] In one embodiment, padding of an arbitrary-length SHA3 / SHAKE message, as shown in Figures 23A-23D, can be implemented using three instructions. 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 padding instruction that inserts EOM and EOB padding into 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 insert EOM and EOB padding into the final message block using two different instructions. However, for single-block messages, such as those commonly used in post-quantum cryptography, adding an extra padding instruction increases latency and adversely reduces hash performance.

[0113] 24A-24D depict various padding cases for various lengths of SHA2 messages. According to the SHA2 standard, each message must contain one EOM padding byte of value x80 in the byte immediately following the last message byte. Thus, the location of the EOM padding byte within a padded message varies depending on the message length. The SHA2 standard further requires that the last two words (i.e., either two 32-bit or two 64-bit words, depending on the SHA2 hash function in question (see Table II)) contain EOB padding, which specifies the length of the unpadded message in bits.

[0114] 24A, the last message block 2400 of the SHA2 message contains more than two words and one byte that do not contain message data. In this case, the last message block 2400 is padded by inserting an EOM padding byte 2302 immediately following the last message byte 2406 into the zeroed bytes of the associated wide vector register 317, and by inserting two EOB padding words 2404 as the last two words of the last message block 2400.

[0115] 24B illustrates a similar second case, where the last message block 2400' of the SHA2 message contains exactly two words and one byte, with no message data. In this case, the last message block 2400' is padded by inserting an EOM padding byte 2402 immediately following the last message byte 2406 into the zeroed bytes of the associated wide vector register 317, and by inserting two EOB padding words 2404 as the last two words of the last message block 2400.

[0116] FIG. 24C depicts a third case, in which the last message block 2400″ of the unpadded SHA2 message contains too few bytes not containing message data to accommodate both the EOM padding byte 2402 and the two EOB padding words 2404. In this case, the SHA2 message is padded by inserting the EOM padding byte 2402 immediately following the last message byte 2406 into the zeroed bytes of the associated wide vector register 317. Because the EOB padding word 2404 will not fit within the message block 2400″, an additional zeroed message block 2408 is appended to the message (e.g., through execution of a load length instruction). The EOB padding word 2404 is then inserted as the last two words of the message block 2408.

[0117] 24D illustrates a fourth case, where the last message byte 2406 of the SHA2 message forms the last byte of a complete message block 2410. Because the message block 2410 does not include capacity for EOM or EOB padding, an additional zeroed message block 2412 is appended to the SHA2 message. The additional message block 2412 includes the EOM padding byte 2302 as the first byte of the message block 2412, followed by multiple zeroed bytes, and finally, two EOB padding words 2404 at the end of the message block 2412.

[0118] In one embodiment, padding of an arbitrary length SHA2 message can be implemented using only four instructions. These instructions include: (1) a load length instruction that places the final message block of the SHA2 message into a specified register 301 in architected register file 300 and zeroes any register bytes that do not contain message bytes; (2) an insert word instruction that places two EOB padding words 2404 into the appropriate bytes of register 301 in architected register file 300 to mark the end of the padded message; (3) a transfer instruction that transfers the contents of register 301 buffering the message block from architected register file 300 to wide vector register 317 in wide vector register file 316; and (4) a pad instruction that inserts EOM padding bytes 2402 into the appropriate locations within wide vector register 317. In this embodiment, execution of the padding instructions inserts EOM padding bytes 2402 but does not insert EOB padding words 2404. This is because (1) EOM padding bytes 2402 and EOB padding word 2404 may be located in different message blocks, and (2) EOB padding word 2404 is efficiently placed in the appropriate register 301 in architected register file 300 using existing word insertion instructions. Of course, in alternative embodiments, both EOM padding bytes 2402 and EOB padding word 2404 may be applied to a SHA2 message block in register 301 of architected register file 300.

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

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

[0121] The padding instruction 2500 further includes a mode field 2508 that provides information utilized to pad 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 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). The BL subfield 2512 (possibly when interpreted together with the HID subfield 2510) indicates the length of the message block in bytes. The E subfield 2514 indicates whether the wide vector register 317 specified by the register 1 field 2504 holds the leading segment SO or the trailing segment SI of the message block. For example, in an embodiment in which the wide vector registers 317 are 1024 bits wide, the E subfield 2514 may have a value of b0 if the wide vector register 317 specified by the register 1 field 2504 does not hold the trailing segment of a message block, and may have a value of b1 if the specified wide vector register 317 holds the trailing segment of a message block. Of course, in other embodiments in which the wide vector registers 317 have a different width (e.g., 512 bits), the E subfield 2514 may include additional bits to specify additional register segments.

[0122] 26, an exemplary padding circuit 2600 according to one embodiment is illustrated. The padding circuit 2600, implemented as part of the data transfer circuit 406 of the accelerator unit 314, pads a message segment S1 held in a target wide vector register in response to execution of a padding instruction 2500, as shown in FIG. 25. The illustrated example assumes a wide vector register file 316 having a 1024-bit wide vector register 317.

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

[0124] The 8-bit block length value output by the BL size select circuit 2606 is received by an EOB enable circuit 2608, which includes a comparator 2610, a decoder 2612, and a bitwise AND circuit 2614. The most significant 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 (e.g., this is the case for SHA3-224, SHAKE-128, and SHAKE256). The least significant 7 bits of the block length form the block length size (bl_size), which indicates the number of bytes comprising the segment of the message block to be buffered in the target wide vector register 317 identified by the register 1 field 2504. The decoder 2612 decodes the 7-bit bl_size value to obtain a 128-bit representation of the end of the message block in the target wide vector register 317. A comparator 2610 compares the most significant bit of the 8-bit block length with the E subfield 2514 of the padding instruction 2500 to form a one-bit indication of whether EOB padding is to be added to the segment of the message block buffered in the target wide vector register (i.e., whether the target wide vector register 317 buffers the trailing segment S1 of the message block). This one-bit indication is then logically combined by a bitwise AND circuit 2614 to generate a 128-bit EOB enable signal (eob_en(0:127)) that identifies the bytes (if any) of the message segment buffered in the target wide vector register 317 into which EOB padding should be inserted.

[0125] 26, padding circuit 2600 further includes an EOM enable circuit 2620, which includes a selection circuit 2620, a comparator 2610, a decoder 2612, and a bitwise AND circuit 2614. In the depicted example, selection circuit 2620 is implemented using 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 applicable to a SHA-2 hash function utilizing 32-bit words. The extended message length value in the second input doubles the original length of the message according to the formula EX_LEN = 4 × (LEN / 4) + LEN by inserting b0 between bits 5 and 6 of the original length. This technique preserves the bit position of original bits 6:7, which, if present, indicate the byte position within the 32 most significant bits of the extended message block of the last message byte. Selection circuit 2620 selects the first of the two 8-bit inputs if HID subfield 2510 indicates that the hash function is a SHA3 / SHAKE hash function or a SHA2 hash function using 64-bit words, or alternatively selects the second of the two inputs if HID subfield 2510 indicates that the hash function is a SHA2 hash function using 32-bit words.

[0126] The 8-bit length value output by the selection circuit 2620 includes a high-order bit indicating whether the block length exceeds the 1024-bit width of the wide vector register file 316, and 7 low-order bits indicating the number of bytes that comprise the segment of the message block to be buffered in the target wide vector register 317 identified by the register 1 field 2504. The decoder 2612 decodes the 7 low-order bits to obtain a 128-bit representation of the byte position, if any, at which the last of the message bytes will be inserted in the target wide vector register 317. The comparator 2622 compares the high-order bits of the length value output by the selection circuit 2620 with the E subfield 2514 of the padding instruction 2500 to form a 1-bit indication of whether EOM padding will be added to the segment of the message block to be buffered in the target wide vector register 317. This 1-bit indication is then logically combined by a bitwise AND circuit 2626 to generate a 128-bit EOM enable signal (eom_en(0:127)) that identifies the bytes (if any) of the message segment buffered in the target wide vector register 317 where EOM padding is inserted.

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

[0128] 27, an exemplary embodiment of the conditional OR circuit 2630 of FIG. 26 is illustrated. In this example, each of the 128 bytes of the message segment has a respective associated OR gate 2700 with three 8-bit inputs. A first input of OR gate 2700 is coupled to receive a respective byte of message segment S. A second input of OR gate 2700 is coupled to the output of a two-input AND gate 2702 that modifies eom_byte using eom_en() for a given byte of message segment S. A third input of OR gate 2700 is coupled to the output of a two-input AND gate 2704 that modifies eob_byte using eob_en() for a given byte of message segment S. OR gate 2700 performs a logical OR operation on these three inputs and writes the resulting bytes of padded message segment Sp to a target wide vector register 317 in wide vector register file 316. Thus, if neither eom_en() nor eob_en() is asserted for a given byte of message segment S, the associated OR gate 2700 simply writes the byte of the input message segment S to the corresponding byte of the padded message segment Sp. However, if one or both of eom_en() or eob_en() are asserted for a given byte of message segment S, the associated OR gate 2700 writes eom_byte, eob_byte, or a logical combination thereof, to the corresponding byte of the padded message segment Sp, as indicated by the enable signals eom_en() and eob_en().

[0129] 28, a high-level logical flowchart of an exemplary process for padding a message block is depicted, according to one embodiment. The illustrated process may be performed by accelerator unit 314 in response to receiving a padding instruction 2500. For ease of understanding, the process is described below with reference to the exemplary padding circuitry depicted in FIGS. 26-27.

[0130] The process of Figure 28 begins at block 2800 and then proceeds to block 2802, which illustrates accelerator unit 314 receiving padding instruction 2500 for execution. In response to receiving padding instruction 2500, accelerator unit 314 first accesses the source operands specified by register fields 2504, 2506 of padding instruction 2500 (block 2804). In particular, accelerator unit 314 reads message segment S from target wide vector register 317 in wide vector register file 316 specified by register 1 field 2504, reads the unpadded message length from register 301 in architected register file 300 specified by register 2 field 2506, and forwards these operands to padding circuit 2600 of Figure 26, which is implemented within data transfer circuit 406 as described above. In block 2806, the padding circuit 2600 utilizes the mode field 2508 of the padding instruction 2500 to select parameters for the padding operation. In particular, the EOM selection circuit 2602 selects the value of the EOM padding byte (eom_byte) 2302 or 2402 based on the hash function specified by the mode field 2508, the EOB selection circuit 2604 selects the value of the EOB padding byte (eob_byte) to be inserted by the padding instruction 2500 (i.e., the SHA3 / SHAKE fixed value and the SHA2 zero byte after the EOB padding word 2404 is applied by a separate instruction for SHA2), and the BL size selection circuit 2606 selects the block length based on the HID subfield 2510 and the BL subfield 2512. The eom_byte selected by the EOM selection circuit 2602 and the eob_byte selected by the selected EOB circuit 2604 form inputs to a conditional OR circuit 2630.

[0131] In block 2808, the selection circuit 2620 determines, based on the HID subfield of the mode field 2508, whether the hash function applied to the message is one of the SHA2-224 or SHA2-256 hash functions that utilize 32-bit words. If not, the selection circuit 2620 selects and outputs the message length read from the register 301 identified by the register 2 field 2506 as the length of the message, and the process of FIG. 28 proceeds to block 2812, described below. However, if the selection circuit 2620 determines in block 2808 that the HID subfield 2510 of the padding instruction 2500 indicates a SHA2 hash function that utilizes 32-bit words, the selection circuit 2620 selects and outputs a double length for the SHA2 message to account for the message extension described above with reference to FIG. 15. In one implementation, the extended SHA2 message length may conveniently be calculated as 4×(LEN / 4)+LEN. The process then proceeds from block 2810 to block 2812.

[0132] Block 2812 illustrates a determination by the EOM enable circuit 2620 as to 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. In response, the process moves to block 2816, 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 bytes of the message segment S into which EOM padding bytes are to be inserted, and the EOM padding bytes are inserted into the specified bytes of the padded message segment Sp by the conditional OR circuit 2630 (block 2814). The process proceeds from block 2814 to block 2816.

[0133] In 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 either the SHA3 or SHAKE hash function and whether EOB padding bytes are 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. In response, the process from block 2816 moves to block 2820, described below. However, if the BL size circuit 2606 and the EOB enable circuit 2620 determine in block 2816 that the hash function specified by the mode field 2508 is either the SHA3 or SHAKE hash function and EOB padding is to be inserted into the message segment S, then the EOB enable circuit 2608 generates an EOB enable vector eob_en(0:127) that identifies the bytes of the message segment S into which the EOB padding bytes are to be inserted, and the EOB padding bytes are inserted into the specified bytes of the padded message segment Sp by the conditional OR circuit 2630 (block 2818). The process then passes to block 2820.

[0134] Block 2820 illustrates the data transfer circuit 406 writing the resulting padded message segment Sp to the target wide vector register 317 specified by the register 1 field 2504. The process of Figure 28 then ends at block 2822.

[0135] 29, a block diagram of an exemplary design flow 2900 used, for example, in semiconductor IC logic design, simulation, testing, layout, and manufacturing is illustrated. The design flow 2900 includes processes, machines, and / or mechanisms for processing design structures or devices to generate logically or otherwise functionally equivalent representations of the design structures and / or devices described above and shown herein. The design structures processed and / or generated by the 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 logically, structurally, mechanically, or otherwise functionally equivalent representations of hardware components, circuits, devices, or systems. The 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, the machine may include a lithography machine, a machine and / or equipment for generating a mask (e.g., an electron beam writer), a computer or equipment for simulating a design structure, any apparatus 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).

[0136] Design flow 2900 may vary depending on the type of representation being designed. For example, a design flow 2900 for building an application-specific integrated circuit (ASIC) may differ from a design flow 2900 for designing a standard component, or from a design flow 2900 for instantiating a design into a programmable array, such as a programmable gate array (PGA) or field programmable gate array (FPGA) offered by Altera® Inc. or Xilinx® Inc.

[0137] FIG. 29 illustrates multiple such design structures, including input design structure 1020, preferably processed by design process 2910. Design structure 2920 may be a logic simulation design structure generated and processed by design process 2910 to generate 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 process 2910, generate a functional representation of the physical structure of a hardware device. Whether representing functional and / or structural design features, design structure 2920 may be generated using electronic computer-aided design (ECAD), such as implemented by a core developer / designer. When encoded on a machine-readable data transmission, gate array, or storage medium, design structure 2920 may be accessed and processed by one or more hardware and / or software modules in design process 2910 to simulate or otherwise functionally represent an electronic component, circuit, electronic or logic module, apparatus, device, or system, such as those described herein. Thus, design structure 2920 may include files or other data structures containing 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 a circuit or other level hardware logic design. Such data structures may include hardware description language (HDL) design entities or other data structures that conform to and / or are compatible with low-level HDL design languages, such as Verilog and VHDL, and / or high-level design languages, such as C or C++.

[0138] Design process 2910 preferably utilizes and incorporates hardware and / or software modules for synthesizing, transforming, or otherwise manipulating design / simulation functional equivalents of components, circuits, devices, or logic structures shown herein to generate netlist 2980, which may include design structures such as design structure 2920. Netlist 2980 may include, for example, compiled or otherwise manipulated data structures representing a list of wires, discrete components, logic gates, control circuits, I / O devices, models, etc., describing connections with other elements and circuits in an integrated circuit design. Netlist 2980 may be synthesized using an iterative process in which netlist 2980 is resynthesized one or more times depending on design specifications and parameters for the device. As with the other design structure types described herein, netlist 2980 may be recorded on a machine-readable storage medium or programmed into a programmable gate array. The medium may be a non-volatile storage medium such as a magnetic or optical disk drive, a programmable gate array, a CompactFlash, or other flash memory. Additionally or alternatively, the medium may be system or cache memory, or buffer space.

[0139] Design process 2910 may include hardware and software modules for processing various input data structure types, including netlist 2980. Such data structure types may, for example, exist in library elements 2930 and may include sets of commonly used elements, circuits, and devices, including models, layouts, and symbolic representations, for a given manufacturing technology (e.g., different technology nodes, 32 nm, 45 nm, 290 nm, etc.). 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 also include standard mechanical design processes, such as stress analysis, thermal analysis, mechanical event simulation, process simulation of operations such as casting, molding, and die pressing, etc. Those skilled in the art of mechanical design will understand 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 invention. The design process 2910 may also include modules for performing standard circuit design processes such as timing analysis, verification, design rule checking, place and route operations, etc.

[0140] Design process 2910 utilizes and incorporates logical and physical design tools, such as HDL compilers and simulation model build tools, to process design structure 2920, along with some or all of the depicted supporting data structures, along with any additional mechanical design or data (if applicable), to generate second design structure 2990. Design structure 2990 resides on a storage medium or programmable gate array in a data format used for the exchange of mechanical device and structure data (e.g., information stored in IGES, DXF, Parasolid XT, JT, DRG, or any other suitable format for storing or rendering such mechanical design structures). Like design structure 2920, design structure 2990 preferably resides on a transmission or data and storage medium and includes one or more files, data structures, or other computer-encoded data or instructions that, when processed by an ECAD system, generate a logically or otherwise functionally equivalent form of one or more of the embodiments of the invention described herein. In one embodiment, design structure 2990 may include a compiled executable HDL simulation model that functionally simulates the devices described herein.

[0141] Design structure 2990 may also utilize data formats used for the exchange of integrated circuit layout data and / or symbolic data formats (e.g., GDSII (GDS2), GL1, OASIS, information stored in map files, or any other suitable format for storing such design data structures). Design structure 2990 may include information such as, for example, symbolic data, map files, test data files, design content files, manufacturing data, layout parameters, wire, metal levels, vias, shapes, data for manufacturing line routing, and any other data required by a manufacturer or other designer / developer to produce a device or structure as described above and shown herein. Design structure 2990 may then proceed to stage 2995, where, for example, design structure 2990 may proceed to tapeout, be released to manufacturing, be released to a mask house, be sent to other design houses, be returned to a customer, etc.

[0142] As described, in at least one embodiment, a processor includes a register file and an execution unit. The execution unit includes a hash circuit including at least a state register, a state update circuit coupled to the state register, and control circuitry. Based on a hash instruction, the hash circuit receives a current state of a message to be hashed from the register file and a buffer in the state register. The state update circuit performs a state update function on the contents of the state register, where performing the state update function includes performing multiple iterative rounds of processing on the contents of the state register and returning a result of each of the multiple iterative rounds of processing to the state register. Following completion of all of the multiple iterative rounds of processing, the execution unit stores the contents of the state register in the register file as an updated state of the message.

[0143] In at least some embodiments, the state update function includes a Secure Hash Algorithm 3 (SHA3) state permutation function, and the state update circuit performs 24 rounds of processing, each of which utilizes a respective one of the 24 round indexes as an input.

[0144] In one embodiment, the execution unit executes hash instructions during the squeezing phase of the Secure Hash Algorithm and the Keccak (SHAKE) hash algorithm.

[0145] In at least some embodiments, the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function. In at least some embodiments, the hash circuit further includes an adder configured to add the contents of the state register to the current state and return the resulting sum to the register file.

[0146] In some embodiments, the execution unit further includes a message block register for buffering message blocks of the message, and a message schedule round circuit coupled to the message block register, the message schedule round circuit performing multiple iterative rounds of processing on the contents of the message block register and returning a result of each of the multiple iterative rounds of processing to the message block register.

[0147] In some embodiments, the state update circuit includes a data path for data words having a first data width, and the execution unit is configured based on the hash instruction indicating a second data width narrower than the first data width to expand data words of a message block of the message to the first data width before processing the data words of the message in the state update circuit.

[0148] While various embodiments have been specifically shown and described, those skilled in the art will recognize that various changes in form and detail can be made therein without departing from the spirit and scope of the appended claims, and that all of these alternative implementations are within the scope of the appended claims. For example, while the invention has been described with specific reference to the SHA family of standards, those skilled in the art will recognize that the disclosed invention is also applicable to other hash algorithms (e.g., the general Keccak function, among others). Furthermore, while exemplary numbers of bits and bytes have been described herein for ease of understanding, it should be understood that the specific numbers of bits and bytes utilized in hash algorithms can and do change over time, and that the principles of the disclosed invention are applicable to cryptographic algorithms regardless of the specific numbers of bits and bytes in a given implementation.

[0149] 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 a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, are implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0150] Furthermore, while aspects have been described with reference to a computer system executing program code directing 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 that stores program code for processing by a data processing system. The computer-readable storage device may include volatile or non-volatile memory, optical or magnetic disks, or the like. However, "storage device" as used herein is specifically defined to include only legal articles of manufacture and to exclude the signal medium itself, the temporarily propagating signal itself, and the energy itself.

[0151] The program product may include data and / or instructions that, when executed or otherwise processed on a data processing system, generate a logical, structural, or otherwise functionally equivalent representation (including a simulation model) of a hardware component, circuit, device, or system disclosed herein. Such data and / or instructions may include Hardware Description Language (HDL) design entities or other data structures that conform to and / or are compatible with low-level HDL design languages, such as Verilog and VHDL, and / or high-level design languages, such as C or C++. Furthermore, the data and / or instructions may also utilize data formats used to exchange integrated circuit layout data and / or symbolic data formats (e.g., GDSII (GDS2), GL1, OASIS, information stored in map files, or any other suitable format for storing such design data structures).

Claims

1. an instruction fetch unit that fetches instructions to be executed; a register file including a plurality of registers for storing source and destination operands; and an execution unit for executing the hash instruction; wherein the execution unit includes a hashing circuit including at least a state register, a state update circuit coupled to the state register, and a control circuit, and the execution unit performs, based on the hash instruction: receiving from the register file a current state of the message to be hashed and buffering it in the state register; performing, in the state update circuit, a state update function on the contents of the state register, wherein performing the state update function includes performing multiple iterative rounds of processing on the contents of the state register and returning a result of each of the multiple iterative rounds of processing to the state register; and storing the contents of the state register in the register file as an updated state of the message following completion of all of the multiple iteration rounds of processing. configured to run Processor.

2. the state update function includes a Secure Hash Algorithm 3 (SHA3) state replacement function; performing multiple iterative rounds of processing includes performing 24 rounds of processing, where each round utilizes a respective one of the 24 round indexes as input; The processor of claim 1 .

3. the state update function includes a Secure Hash Algorithm 3 (SHA3) state replacement function; performing multiple iterative rounds of processing includes performing multiple rounds of processing indicated by the hash instruction; The processor of claim 1 .

4. The processor of claim 1 , wherein the execution unit executes the hash instruction during a squeezing phase of a Secure Hash Algorithm and a Keccak (SHAKE) hash algorithm.

5. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the hash circuit further comprising an adder configured to add the contents of the state register to the current state and return the resulting sum to the register file; A processor according to any one of claims 1 to 4.

6. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the execution unit further includes a message block register for buffering message blocks of the message, and a message schedule round circuit coupled to the message block register; performing a state update function includes performing, by the message schedule round circuitry, a plurality of iterative rounds of processing on the contents of the message block register and returning a result of each of the plurality of iterative rounds of processing to the message block register; A processor according to any one of claims 1 to 5.

7. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the state update circuit includes a data path for data words having a first data width; the execution unit is configured to, based on the hash instruction indicating a second data width narrower than the first data width, expand data words of a message block of the message to the first data width before processing the data words of the message in the state update circuit. A processor according to any one of claims 1 to 6.

8. A plurality of processors including the processor of any one of claims 1 to 7; shared memory; and a system interconnect communicatively coupling the shared memory and the plurality of processors; A data processing system comprising:

9. 1. A method of data processing in a processor, comprising: fetching, by an instruction fetch unit, instructions to be executed by the processor, wherein the instructions include hash instructions; and upon receiving the hash instruction, an execution unit of the processor executes the hash instruction, wherein the execution unit includes a hash circuit including at least a state register, a state update circuit coupled to the state register, and a control circuit; wherein said performing step comprises: receiving from a register file and buffering in said state register the current state of the message to be hashed; executing, in the state update circuit, a state update function on the contents of the state register, wherein executing the state update function includes performing multiple iterative rounds of processing on the contents of the state register and returning a result of each of the multiple iterative rounds of processing to the state register; and storing the contents of the state register in the register file as an updated state of the message following completion of all of the multiple iteration rounds of processing. A method comprising:

10. the state update function includes a Secure Hash Algorithm 3 (SHA3) state replacement function; performing multiple iterative rounds of processing includes performing 24 rounds of processing, where each round utilizes a respective one of the 24 round indexes as input; 10. The method of claim 9.

11. 11. The method of claim 9, wherein executing the hash instruction comprises executing the hash instruction in a squeezing phase of a Secure Hash Algorithm and a Keccak (SHAKE) hash algorithm.

12. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; 12. The method of claim 9, further comprising adding, by an adder, the contents of the state register to the current state and returning the resulting sum to the register file.

13. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the execution unit further includes a message block register for buffering message blocks of the message, and a message schedule round circuit coupled to the message block register; the step of executing a state update function includes the step of performing a plurality of iterative rounds of processing on the contents of the message block register in the message schedule round circuit, and returning a result of each of the plurality of iterative rounds of processing to the message block register.

13. The method according to any one of claims 9 to 12.

14. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the state update circuit includes a data path for a data word having a first data width; The method further comprises: expanding data words of a message block of the message to the first data width based on the hash command indicating a second data width narrower than the first data width prior to processing the data words of the message in the state update circuit.

14. The method of any one of claims 9 to 13, comprising:

15. A design structure tangibly embodied in a machine-readable storage device for designing, manufacturing, or testing an integrated circuit, comprising: an instruction fetch unit that fetches instructions to be executed; a register file including a plurality of registers for storing source and destination operands; and An execution unit for executing hash instructions a processor including: wherein the execution unit includes a hashing circuit including at least a state register, a state update circuit coupled to the state register, and a control circuit, wherein the execution unit performs, based on the hash instruction: receiving from said register file and buffering in said state register the current state of the message to be hashed; in the state update circuit, performing a state update function on the contents of the state register, wherein performing the state update function includes performing multiple iterative rounds of processing on the contents of the state register and returning a result of each of the multiple iterative rounds of processing to the state register; and storing the contents of the state register in the register file as an updated state of the message following completion of all of the multiple iteration rounds of processing. A design structure that is configured to perform

16. the state update function includes a Secure Hash Algorithm 3 (SHA3) state replacement function; performing multiple iterative rounds of processing includes performing 24 rounds of processing, where each round utilizes a respective one of the 24 round indexes as input; 16. The design structure of claim 15.

17. 17. The design structure of claim 15, wherein the execution unit executes the hash instructions during a squeezing phase of a Secure Hash Algorithm and a Keccak (SHAKE) hash algorithm.

18. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the hash circuit further comprising an adder configured to add the contents of the state register to the current state and return the resulting sum to the register file; 18. A design structure according to any one of claims 15 to 17.

19. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the execution unit further includes a message block register for buffering message blocks of the message, and a message schedule round circuit coupled to the message block register; performing a state update function includes performing, by the message schedule round circuitry, a plurality of iterative rounds of processing on the contents of the message block register and returning a result of each of the plurality of iterative rounds of processing to the message block register; 19. A design structure according to any one of claims 15 to 18.

20. the state update function includes a Secure Hash Algorithm 2 (SHA2) block hash function; the state update circuit includes a data path for data words having a first data width; the execution unit is configured to, based on the hash instruction indicating a second data width narrower than the first data width, expand data words of a message block of the message to the first data width before processing the data words of the message in the state update circuit.

20. A design structure according to any one of claims 15 to 19.

Images