Keccak-operation-specifying instruction

Abstract

Instruction decoding circuitry 13 is configured to decode instructions according to an instruction set architecture; and processing circuitry 6 is configured to perform data processing in response to

Description

The present technique relates to the field of data processing. The Keccak function is a primitive which is used in the SHA3 family of cryptographic hashes. SHA3 was standardized as a potential drop-in replacement for SHA2, in case SHA2’s security got compromised. The algorithm was not widely adopted since then, mostly due to SHA2 not having been compromised and SHA3 hardware acceleration being more costly to implement - especially when provided in addition to existing SHA2 hardware. However, SHA3 forms an integral part in post quantum algorithms and is therefore expected to become increasingly relevant in the near future. At least some examples of the present technique provide an apparatus comprising: instruction decoding circuitry configured to decode instructions according to an instruction set architecture; and processing circuitry configured to perform data processing in response to the instructions decoded by the instruction decoding circuitry; in which: the processing circuitry comprises Keccak round computation circuitry configured to perform, in response to the instruction decoding circuitry decoding a Keccak-operation-specifying instruction, an atomic operation comprising at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array; and in a given round of the Keccak function, the Keccak round computation circuitry is configured to update at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction. At least some examples of the present technique provide computer-readable code for fabrication of an apparatus comprising: instruction decoding circuitry configured to decode instructions according to an instruction set architecture; and processing circuitry configured to perform data processing in response to the instructions decoded by the instruction decoding circuitry; in which: the processing circuitry comprises Keccak round computation circuitry configured to perform, in response to the instruction decoding circuitry decoding a Keccak-operation-specifying instruction, an atomic operation comprising at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array; and in a given round of the Keccak function, the Keccak round computation circuitry is configured to update at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction. At least some examples of the present technique provide a method comprising: decoding instructions according to an instruction set architecture, using instruction decoding circuitry; and performing data processing, using processing circuitry, in response to the instructions decoded by the instruction decoding circuitry; in which: in response to the instruction decoding circuitry decoding a Keccak-operation-specifying instruction, Keccak round computation circuitry of the processing circuitry performs an atomic operation comprising at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array; and in a given round of the Keccak function, the Keccak round computation circuitry updates at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction. At least some examples provide a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: instruction decoding program logic to decode instructions according to an instruction set architecture and control the host data processing apparatus to perform data processing in response to the instructions decoded by the instruction decoding circuitry; and Keccak round computation program logic to control the host data processing apparatus perform, in response to the instruction decoding program logic decoding a Keccak-operation-specifying instruction, at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array, said Keccak-operation-specifying instruction comprising an atomic instruction for controlling performance of said at least one round of the Keccak function, where in a given round of the Keccak function, at least one working state data element of the array is updated based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction. Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which: Figure 1 illustrates an example of an apparatus comprising Keccak round computation circuitry; Figure 2 illustrates an example system comprising a central processing unit (CPU) comprising the Keccak round computation circuitry; Figure 3 illustrates an example of a sponge function used for the SHA3 cryptographic algorithm, which includes a number of instances of absorbing a portion of a message into Keccak state information and a number of instances of squeezing a portion of the digest out of it (the underlying function f applies multiple rounds of the Keccak function to the Keccak state information); Figure 4 illustrates an example of Keccak state information; Figure 5 illustrates an example of one round of the Keccak function; Figure 6 illustrates an example of an atomic operation comprising one round of the Keccak function, with Keccak state information and round information referenced as a single logical register; Figure 7 illustrates an example apparatus in which the Keccak round computation circuitry comprises a functional unit of a CPU; Figure 8 illustrates another example in which the Keccak round computation circuitry is implemented within threadlet processing circuitry providing extension functionality to be processed asynchronously with respect to other operations performed by the CPU; Figure 9 illustrates a second example implementation of threadlet processing circuitry comprising the Keccak round computation circuitry; Figure 10 illustrates a method for processing a Keccak-operation-specifying instruction; Figure 11 illustrates a more detailed example of steps performed in response to a Keccak-operation-specifying instruction; Figure 12 illustrates fusion of Keccak-operation-specifying instructions; and Figure 13 illustrates a simulation example. An apparatus comprises instruction decoding circuitry configured to decode instructions according to an instruction set architecture (ISA); and processing circuitry configured to perform data processing in response to the instructions decoded by the instruction decoding circuitry. Current instruction set architectures offer little support for Keccak functions, and rely on implementing a round of the Keccak function using separate instructions for different parts of the Keccak round (e.g. XOR instructions, shift instructions, and register move or permute instructions). However, performance has been restricted due to the large size of the Keccak state information manipulated in a round of the Keccak function. The Keccak state information comprises an array of working state data elements, and the Keccak function includes elementwidth permutation operations to swap positions of the elements within the array. This makes it difficult to apply vectorization (single-instruction-multiple-data (SIMD) techniques) to accelerate the hash function by computing operations on multiple elements of the array in parallel, as it is difficult for vector (SIMD) instructions to implement the swapping of elements efficiently while allowing other parts of the Keccak function to complete in parallel. Therefore, typical processor architectures are restricted to using scalar operations which operate on a single element at a time, and implement individual steps of the hash function (e.g. an XOR of an element with a second value, or a shift to rotate the bits within a given element) as a sequence of distinct scalar instructions each processing a single element. This limits processing performance. In future, it is expected that SHA3, a class of cryptographic hashes which makes use of the Keccak function, will become increasingly prominent, because of its role in post quantum cryptography (PQC). PQC addresses the increasing risk of upcoming quantum computers severely weakening the security provided by signature and key exchange algorithms, such as RSA and ECC (Elliptic Curve Cryptography) that are widely used today. Three of the four PQC algorithms currently being standardized by NIST, i.e. Kyber, Dilithium and Sphincs+, heavily rely on SHA3. Those algorithms may serve as the basis for TLS or other secure internet protocols and so acceleration of SHA3 processing performance may be important for ensuring good internet browsing experience. In the examples discussed below, the ISA supported by the processing circuitry and the instruction decoding circuitry supports a Keccak-operation-specifying instruction. The processing circuitry comprises Keccak round computation circuitry which is configured to perform, in response to the instruction decoding circuitry decoding a Keccak-operation-specifying instruction, an atomic operation comprising at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array. In a given round of the Keccak function, the Keccak round computation circuitry is configured to update at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction Hence, a single instruction implements at least one complete round of the Keccak function as an atomic operation. Here, an atomic operation refers to a single operation scheduled as a single non-divisible action, rather than being implemented as a series of separately scheduled steps performed in response to separate ISA instructions. It may be considered surprising that it would be practical to implement a complete Keccak round as an atomic operation performed in response to a single program instruction. The Keccak working state is very large in comparison to operation operands used by most ISA instructions (e.g. the working state comprises 1600 bits for the variant of Keccak used in SHA3). Also, the Keccak function includes 5 stages of intraelement and inter-element operations applied to the Keccak state information, which would appear to be challenging to implement in a single ISA instruction, given pressures on meeting circuit timings. However, the inventors have recognised that, with the development of processor architectures supporting larger registers (e.g. tile registers for supporting processing of large matrix structures that are offered as part of architectures such as the Scalable Matrix Extension (SME) provided by Arm® Limited), it is becoming feasible to implement the register capacity for holding the complete Keccak working state such that it can be accessed by a single instruction. Also, while the Keccak function involves many steps of operations, most of these steps (intraelement shifts or XORs applied separately per element) are quick and cheap to implement in hardware, and the main challenge is the element-sized data movements to swap element positions in an inter-element permutation stage. By implementing a single instruction of the ISA which can trigger a complete Keccak round to be performed as an atomic operation, this means dedicated hardware can perform the element-sized data movements, rather than relying on generic permutation logic to extract and permute elements of various vector registers in response to a series of smaller generic permutation instructions. This dedicated hardware can be much faster at performing the required permutations. Therefore, support for a Keccak-operation-specifying instruction as mentioned above can greatly accelerate performance for the Keccak round to the point where it can be performed in a single clock cycle even at the high operating frequencies generally supported by modern processors. Hence, by offering in the ISA of a processor an instruction for triggering performance of at least one round of the Keccak function as an atomic (non-divisible) operation, this enables acceleration of the Keccak round computations, which can support much more performanceefficient implementations of cryptographic algorithms such as SHA3. Also, by specifying, in association with the instruction, a round constant specifying value used to select a round constant to be applied in a given round for updating at least one working state data element of the array, this provides architectural support for implementations which perform relatively few rounds of the Keccak function in one instruction (e.g. as few as 1 or 2 rounds, say). In contrast, an instruction lacking the round constant specifying value might be limited to causing the full set of Keccak rounds (e.g. 24 rounds) according to SHA3 to be performed in one instruction, as there would be no mechanism to identify for a given instance of the instruction how many previous rounds have already been performed, which is relevant for determining the round constant for the next round(s). Hence, by supporting the round constant specifying value, it becomes feasible to implement circuit logic to perform a single round of the Keccak function (or a relatively small number of rounds) per instruction, which can make it much more feasible to integrate the Keccak round computation circuitry into a CPU pipeline while meeting timing constraints associated with processing of other instructions of the ISA. In some examples, the Keccak-operation-specifying instruction references the Keccak state information as a single logical register. This contrasts with typical implementations of Keccak which would rely on instructions referencing individual portions of the Keccak state information using separate logical register identifiers. A problem with splitting the Keccak state information across multiple separate logical registers is that the so-called “pi” stage of the Keccak function, which involves shuffling of the positions of working state elements according to a fixed pattern, would be very hard to vectorise if portions of the array are split across multiple logical vector registers, as a given logical vector register representing a portion of the array would need to receive elements selected from multiple other vectors of the array, and most permutation instructions can only take a limited number of vector inputs as permutation source operands (typically, the hardware for supporting general purpose vector permute instructions would not support enough register read ports to read the register storage corresponding to many logical vector registers in a single instruction). This means that vectorised implementations of Keccak using separate logical registers for the Keccak working state information would be unlikely to offer any performance benefit compared to pure scalar implementations which implement each working state data element as a separate logical scalar register and can rename registers (to adjust mappings between logical registers and physical registers) without any actual data movement between physical registers. However such scalar implementations would greatly restrict performance for the other stages of the Keccak function which apply intra-element operations within each working state element. In contrast, by providing an instruction which references the entire array of Keccak working state as a single logical register (even when the working state is as large as 1600 bits as required for SHA3 implementations of Keccak), this gives flexibility for hardware to implement the required permutations of an entire Keccak round as an atomic operation. By being able to access the complete Keccak state at once as a single logical register, hardware can parallelize computations within a Keccak round and simply hardwire the data movements (rather than relying on software direction of the element data movements required), so that processing performance can be greatly accelerated for implementations of algorithms involving the Keccak function. As mentioned earlier, in a given round of the Keccak function, the Keccak round computation circuitry updates at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction. In some cases, a single working state data element of the array may be updated based on the round constant in a given round of the Keccak function. The round constant specifying value can be identified as an operand of the Keccak-operation-specifying instruction (e.g. as a register operand or as an immediate value). The round constant specifying value can be implemented in different ways. In some examples, the round constant specifying value comprises a round index indicative of which of a plurality of rounds of the Keccak function is to be performed in response the Keccak-operation-specifying instruction. In some examples, the round index may correspond to the number of rounds already processed (e.g. if the round index indicates 1 then this indicates that the next round constant to be selected is the round constant for the second round of the Keccak function - this enables a more efficient encoding as the round index for the first round is “0” and so the “0” encoding is not wasted). However, other encodings are also possible. A round index can be more efficient to specify as an instruction operand or using register state, as, say, a 5-bit round index can be sufficient to identify the number of rounds likely to be required for typical cryptographic algorithms using Keccak (e.g. most SHA3 implementations apply 24 rounds of the Keccak function for each instance of calling the Keccak algorithm). A round index can be mapped to a specific round constant, e.g. by looking up a lookup table structure based on the round index, or by simply hardwiring logic gates to provide the required round constants for each index (in some examples, hardwired logic may be more efficient, as the round constants may typically include a lot of bits equal to 0 for which no actual logic gates would be required to be implemented in hardware). In other examples, the round constant specifying value may explicitly specify the round constant itself. Although this may require some extra operand bits in comparison to a round index, in practice there may be spare space available in the logical register holding the Keccak state information (since the Keccak state information may not correspond to an exact power of 2 number of bits and typically it can be most efficient to implement register storage in blocks sized to an exact power of 2 number of bits). The Keccak round constants can be computable at runtime by using a linear feedback shift register, so that it is not necessary to maintain a lookup structure for looking up stored round constants, so it would be practical to use the round constant itself as an operand or variable associated with the Keccak instruction and use hardware to compute the round constant for the next round based on the round constant for the previous round. In some examples, in response to the Keccak-operation-specifying instruction, the Keccak round computation circuitry is configured to update the round constant specifying value based on how many rounds of the Keccak function have been performed by the Keccak round computation circuitry. The updated round constant specifying value can be provided as an output of the Keccak-operation-specifying instruction (e.g. written to a destination register of the instruction, which may be the same single logical register as the source register used to provide the round constant specifying value), or can be maintained internally by hardware without necessarily exposing it to software as an output of the instruction. If the instruction triggers a single round of the Keccak function to be applied, then the round constant specifying value can be advanced to the value corresponding to the next round to be performed (e.g. incremented and / or set to the round constant value for the next round). Some implementations of the instruction may trigger more than one round of the Keccak function (or multiple instances of the instruction may become fused in some processor hardware implementations as discussed below), so if two or more rounds are performed then the round constant specifying value can be advanced by two or more steps, based on the number of rounds actually performed, so that the round constant specifying value becomes set to the value indicating the round to be performed next if a further instance of the Keccak-operation-specifying instruction is executed. In this way, the round constant specifying value tracks progress made through multiple rounds of the Keccak function, so that the required number of rounds can be processed by calling multiple instances of the Keccak-operation-specifying instructions with the hardware causing the progress made so far to be tracked. In some examples, the Keccak round computation circuitry is configured to reset the round constant specifying value to an initial value in response to the number of completed rounds of the Keccak function reaching a maximum number of rounds. In some examples, the maximum number of rounds could be fixed by design (hardwired). For example, the SHA3 variants standardized in FIPS 202 require 24 rounds, and so once the 24th round is performed then it would be expected that the next instance of a Keccak-operation-specifying instruction would be starting a new set of 24 rounds (e.g. applied to a different portion of a message being hashed). Other variants of cryptographic algorithms involving Keccak (e.g. TurboSHAKE) may require fewer rounds, so some implementations of the Keccak-operation-specifying instruction may take an operand which defines the maximum number of rounds to perform, so the maximum number of rounds used to determine when to reset the round constant specifying value could depend on that operand of the instruction. The initial value for the round constant specifying value could for example be 0 (in the example where the round constant specifying value is a round index) or could be the actual round constant value used for round 0 (e.g. 0x0000_0000_0000_0001 as defined in the Keccak algorithm). In some examples, the Keccak-operation-specifying instruction is associated with a reset parameter indicative of whether the round constant specifying value is to be reset in response to the Keccak-operation-specifying instruction. This could be an operand (e.g. no_rounds parameter described below) which defines the maximum number of rounds to perform as mentioned above, or could be a flag simply indicating whether or not a reset of the round constant specifying value should occur in the current iteration of applying the Keccak-operation-specifying instruction. In response to the reset parameter indicating that a reset is required, the Keccak round computation circuitry may reset the round constant specifying value to its initial value as discussed above. In some examples, the round constant specifying value and the Keccak state information are specified using a single logical register providing both the round constant specifying value and the Keccak state information. This can be efficient as the logical register providing the Keccak state information may have spare bits available (due to padding the Keccak state information to provide a power-of-2 sized register), which can be reused to provide the round constant specifying value. In other examples, the round constant specifying value could be specified as a separate logical register from the logical register providing the Keccak state information, or (at least in the case where the round constant specifying value is a round index rather than the round constant itself) could be specified as an immediate operand directly encoded in the instruction encoding of the Keccak-operation-specifying instruction. It is possible to specify additional information in spare bits of the logical register that provides the Keccak state information. For example, these bits could be used to provide additional information such as: • the round constant specifying value as mentioned earlier; • progress information tracking progress of hashing a message using an algorithm involving the Keccak function (e.g. the progress information could specify a pointer to a memory system location providing the next portion of the message to be hashed); • zero-status information associated with the Keccak state information, which indicates whether the Keccak state information is currently zero. In implementations where the Keccak-operation-specifying instruction also triggers loading of the Keccak state information from memory, as well as processing of the Keccak state information by applying at least one round of the Keccak function, the zero-status information specified by the logical register can be used by the hardware to determine whether the load of the Keccak state information can be suppressed. In some examples, the Keccak-operation-specifying instruction comprises a CPU instruction comprising an opcode indicating that the instruction is a Keccak-operation-specifying instruction. Hence, the ISA supported by a CPU may have a dedicated instruction for triggering Keccak processing, with a particular opcode allocated for representing that instruction. Where a dedicated Keccak CPU instruction is provided, that instruction may architecturally be defined as triggering performance of a single round of the Keccak function in response to that instruction, or could trigger a variable number of rounds depending on a number of rounds parameter specified by the instruction. In some examples, the Keccak-operation-specifying instruction comprises a threadlet start instruction to control offloading of a threadlet operation to be performed by threadlet processing circuitry asynchronously with respect to other operations performed by the processing circuitry; the threadlet processing circuitry comprises the Keccak round computation circuitry; and the threadlet start instruction specifies a threadlet operation identifier which, for the Keccak-operation-specifying instruction, specifies that the threadlet operation comprises said at least one round of the Keccak function. Threadlet processing circuitry (which operates asynchronously with respect to other portions of the processing pipeline) can be useful for supporting acceleration of certain processing functions using dedicated hardware which may be faster at performing the function compared to the same functions being performed in multiple instructions using general purpose synchronous processing logic. An instruction may be provided in the ISA of a CPU to control offloading of such threadlet operations to the associated threadlet processing circuitry. The threadlet processing circuitry can be tightly coupled to the main CPU pipeline (e.g. having direct access to CPU registers and sharing some resources such as address translation circuitry and / or private caches with the CPU). Some implementations may provide support for optional extension using two or more distinct threadlet types, and so the threadlet start instruction may specify a threadlet operation identifier identifying which threadlet operation is required. Hence, in implementations supporting such threadlet processing, at least one threadlet accelerator may support the Keccak function (either as a standalone operation, or as part of a wider cryptographic function such as SHA3), and the Keccak-operation-specifying instruction may be a threadlet start instruction which specifies a threadlet operation identifier having a value indicating that the threadlet operation includes at least one round of the Keccak function. In a threadlet implementation, the single logical register mentioned above may be an internal register of the threadlet processing circuitry. The round constant specifying value could be passed as a parameter to the threadlet processing circuitry at the time of offloading the Keccak operation to the threadlet processing circuitry, or could be read from a memory location identified based on an address passed as a parameter to the threadlet processing circuitry. In some examples, the Keccak-operation-specifying instruction is associated with a number-of-rounds parameter specifying a maximum number of rounds of the Keccak function to be performed in response to the Keccak-operation-specifying instruction, and the Keccak round computation circuitry is configured to limit a number of rounds of the Keccak function performed in response to the Keccak-operation-specifying instruction to not exceed the maximum number. By supporting a parameter indicating the number of rounds to be performed at maximum, this provides flexibility for supporting different variants of SHA3 or other cryptographic algorithms which apply different numbers of Keccak rounds as a basic unit of processing within the algorithm. The parameter value may be capped to a certain maximum (e.g. 24, corresponding to the maximum number of rounds specified by the SHA3 algorithm), either by restricting the number of bits used to encode the parameter value, or by triggering error handling mechanisms (e.g. an exception) if the number-of-rounds parameter is set to a value greater than the allowed maximum. It is not essential to necessarily perform all of the rounds specified by the number-of-rounds parameter in response to a single instruction - some implementations may limit how many rounds can be performed in hardware and so may perform only the number of rounds supported by hardware, even if less than the specified maximum number indicated by the parameter. However, in general based on the number-of-rounds parameter (optionally in combination with the round index or other value which tracks the number of already completed rounds), the hardware of the Keccak round computation circuitry can determine whether the final round to be performed has been reached and prevent additional rounds being performed. The Keccak round computation circuitry can also reset the round constant specifying value in response to determining that the indicated maximum number of rounds have been completed. In some examples, the instruction decoding circuitry is configured to fuse a group of at least two Keccak-operation-specifying instructions detected by the instruction decoding circuitry, to control the Keccak round computation circuitry to perform at least two rounds of the Keccak function in response to a single fused micro-operation. For example, the Keccak-operation-specifying instruction may, according to its architectural definition in the ISA, specify that a single round (or a greater number of rounds) is to be performed, but typically it may be expected that multiple such instructions may be included in succession to implement the total number of rounds required by a given cryptographic algorithm (e.g. 12 rounds forTurboSHAKE or 24 rounds for the SHA3 variants). The inventors have recognised that the critical path timing delay for a single Keccak round can be relatively short in comparison with typical clock cycle periods for modern processors, so for some implementations it can be feasible to compute multiple rounds per cycle. Therefore, it can be helpful for the instruction decoding circuitry to be provided with instruction fusion logic to detect groups of multiple Keccak-operation-specifying instructions and fuse them into a single micro-operation which can be processed by hardware as a single atomic operation. By reducing the number of micro-operation slots occupied in issue queues and other structures to free up slots for other operations, and improving the throughput of Keccak rounds, this can further improve processing performance. Nevertheless, other examples may not support fusion to retain a simpler hardware design, and may process each Keccak-operation-specifying instruction individually as a separate microoperation. Hence, in some examples at least two rounds of the Keccak function are performed in response to a micro-operation generated based on at least one Keccak-operation-specifying instruction. This could be either because the Keccak-operation-specifying instruction itself requires multiple rounds due to its architectural instruction definition in the ISA, or because the Keccak-operation-specifying instruction triggers offloading of a threadlet operation which is implemented asynchronously on a particular processor implementation that chooses to implement multiple rounds per threadlet offload, or because while the Keccak-operation-specifying instruction architecturally requires only a single round, the instruction decoding circuitry supports instruction fusion as described above. In any of these cases, in cases where at least two rounds of the Keccak function are performed in response to a micro-operation generated based on at least one Keccak-operation-specifying instruction, some implementations may update the register state with the updated values of the Keccak state information only after completion of the last of those at least two rounds. However, other implementations may support, in cases where multiple rounds are processed in response to a single micro-operation, the Keccak round computation circuitry updating register state with the updated values for the array of working state data elements in response to completion of each individual round of the Keccak function, to enable resumption of one or more uncompleted rounds of the Keccak function following an interruption without repeating one or more earlier completed rounds of the Keccak function. With this approach, there can be greater tolerance of interruptions part way through, so that on resumption the state information has already been updated to account for earlier completed rounds even if not all the rounds intended to be processed in absence of the interruption were done at the time of the interruption. This approach can be particularly useful for the threadlet example where the rounds may be performed asynchronously with respect to other operations performed by the processing circuitry, which is more vulnerable to being interrupted part way through (e.g. if the threadlet processing circuitry needs to be assigned to another thread). That is, while each round may performed as an atomic operation so that it is indivisible within a round, the threadlet may be interrupted between rounds, e.g. if the threadlet accelerator is to be reassigned to a different software process. Hence, by updating register state with the Keccak state information following each completed round (rather than only on completion of the final round being performed), and exposing that updated register state from the partially completed operation so that it can be read by other instructions, this can enable forward progress to be made when resuming processing after the interruption, without requiring the already-completed rounds to be repeated after the interruption. In some examples, the size of the Keccak state information could be variable. The Keccak function may be generalizable to different sized arrays of working state data elements. For other examples, the Keccak round computation circuitry may operate according to a single fixed size for the Keccak state information. For example, it can be particularly useful for the Keccak state information to comprise a 5x5 array of working state data elements, as this is the array dimension specified when Keccak is to be used to support the SHA3 family of cryptographic algorithms. In some examples, the Keccak state information comprises 1600 bits of working state information (e.g. a 5x5 array of 64-bit working state data elements, giving 1600 bits of working state in total). Again, this helps support SHA3 implementations. Given the 1600 bits of working state, there can be a real challenge in marshalling the 64-bit wide element swapping for the “pi” phase of a Keccak round, but provision of an atomic instruction that implements a complete round, with a single logical register being used to reference the entire working state, can be helpful in improving processing performance. However, other implementations of the Keccak-operation-specifying instruction could support more general application of the Keccak function when applied to different array dimensions or differently sized working state data elements, to enable use in cryptographic algorithms other than SHA3. A given round of the Keccak function may comprise an inter-element permutation function (e.g. the pi phase mentioned above) to swap positions of working state data elements within the array and at least one intra-element permutation function (e.g. theta, rho, chi and iota stages mentioned further below) to apply permutations within each working state data element of the array. In some examples, the instruction decoding circuitry, processing circuitry and Keccak round computation circuitry are implemented within a central processing unit (CPU). Hence, acceleration of Keccak functions is provided local to the CPU, rather than relying on a remote hardware accelerator. This can help make it feasible to intersperse short periods of Keccak processing with other operations, for which the configuration overhead of configuring a remote hardware accelerator via memory buses can be prohibitive if the length of time for which the Keccak processing is required is too short to justify the overhead. In some examples, the instruction decoding circuitry comprises shared decoding circuitry configured to decode arithmetic / logical instructions, branch instructions and load / store instructions of the instruction set architecture, as well as being configured to decode the Keccak-operation-specifying instruction. Hence, the Keccak-operation-specifying instruction (e.g. a dedicated Keccak CPU instruction, or a threadlet start instruction) can be supported within a general purpose instruction decoder that is also used for decoding standard CPU instructions such as load / store instructions, branch instructions and arithmetic / logical instructions. The Keccak-operation-specifying instruction may be an instruction other than a load / store instruction. In some examples, the apparatus may comprise a configuration signal path configured to convey control signals to the Keccak round computation circuitry in response to decoding of the Keccak-operation-specifying instruction by the instruction decoding circuitry. The configuration signal path may be separate from a load / store data path used by the processing circuitry to issue load / store memory access requests to a memory system. By providing a dedicated configuration signal path, separate from the memory access path by which load / store accesses to memory are performed, the acceleration of Keccak functions can be integrated more tightly into a CPU, avoiding the relatively slow configuration overhead of configuring a remote accelerator via memory-based communication (which may incur delays due to synchronisation of control structures in memory, for example). In some examples, the Keccak round computation circuitry is configured to perform the at least one round of the Keccak function in a single clock cycle. Hence, fast processing performance can be achieved for the Keccak function. In some examples, the Keccak round computation circuitry has direct access to state in architectural CPU registers defined by the instruction set architecture. For example, the Keccak round computation circuitry may be a functional unit of the CPU which accesses registers in a similar way to other functional units such as ALUs (arithmetic / logical units), vector execution units, etc. Alternatively, the Keccak round computation circuitry may comprise threadlet processing circuitry which, at least at the point of handing over a new threadlet operation to the threadlet processing circuitry, has access to CPU registers for passing parameters to the threadlet processing circuitry. Specific examples are now described with reference to the drawings. Figure 1 illustrates an example of an apparatus 10 for processing data, which comprises instruction decoding circuitry 13 for decoding instructions fetched from a data store, and based on the decoded instructions, controlling processing circuitry 6 to perform data processing operations in response to those instructions. The processing circuitry 6 has access to registers 8, used to store instructions operands and processing results for the instructions processed by the processing circuitry 6. The instruction decoding circuitry 13 and processing circuitry 6 support decoding and execution of instructions from at least one instruction set as defined by a particular instruction set architecture (ISA). The ISA defines the encodings and functions of instructions supported in the instruction set, as well as the register state which software can expect to be supported by the registers 8, and other rules governing how the apparatus 10 should behave in response to architecturally-defined actions such as execution of instructions, updates to register state and exceptions. As shown in Figure 1, the processing circuitry 6 includes Keccak round computation circuitry 9 used to perform at least one round of a Keccak function in response to a Keccak-operation-specifying instruction being decoded by the instruction decoding circuitry 13. The Keccak-operation-specifying instruction is an instruction defined in the ISA supported by the instruction decoding circuitry 13 and processing circuitry 6, which software can choose to execute to trigger the Keccak round computation circuitry 9 to perform at least one round of a Keccak function on Keccak working state information. For a given round, a round constant applied to at least one element of a working state array is selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction. Figure 2 shows another example in which the apparatus 10 of Figure 1 is a central processing unit (CPU) 10 provided as part of a processing system 2, such as a system on chip or collection of chiplets making up a computing device. The system 2 includes a number of processing elements (PE) capable of instruction execution, such as one or more CPUs 10, one or more graphics processing units (GPUs) 100, and optionally other kinds of processing element (not shown in the specific example of Figure 2), such as neural processing units (NPUs) which provide acceleration of machine learning functions such as neural network processing. The system 2 also includes non-PE memory access requesters 102, 104 which are not themselves capable of instruction execution but which have direct access to the memory system 110 shared with the PEs 10, 100, and can be configurable by software executing on the CPUs 10 to perform processing functions on behalf of the PEs 10, 100. For example, the non-PE memory access requesters may include one or more input / output (I / O) devices 102 (such as a user interface device, display controller, network controller, external storage controller, etc.) and / or one or more hardware accelerators 104 for providing hardware acceleration of certain dedicated processing functions which can be performed more efficiently by the hardware accelerator 104 than when implemented using general purpose instructions executed by a CPU 10. Control of the I / O devices 102 and hardware accelerators 104 may be provided by using memory communication mechanisms, such as interaction between the CPU 10 and hardware accelerator 104 using shared command queues or other memory-based control data structures stored in the memory system 110, which when configured by software on the CPU 10 by issuing store requests to write data to the control data structures, can be read by the hardware accelerator 104 to control which operations are performed by the hardware accelerator 104. Hence, the control mechanism for controlling a hardware accelerator 104 is typically by implementation-specific memory access patterns defined by specific software drivers, rather than being offered by particular instructions defined according to the ISA supported by the CPU 10. The memory access requesters (including both PEs and non-PE requesters) 10,100,102, 104 access shared memory 110 via a system interconnect 106, which may control routing of memory access requests and responses to / from memory. The interconnect 106 may also implement a coherency protocol to ensure that data from memory cached in private caches of particular requesters is accessed coherently to ensure that updates to shared data made by one requester are observed by another requester accessing the same address in memory. It will be appreciated that the examples of Figures 1 and 2 are schematic and simplified and that the apparatus 10 and system 2 can include many other features not shown for conciseness. The SHA3 secure hash algorithm was originally standardized as a potential drop-in replacement for SHA2. It deliberately operates differently to SHA2, so that if either algorithm’s security got compromised in the future, the other would not be affected. The adoption of SHA3 has been very limited. SHA2 had been standardized 14 years prior, and as its security had not been compromised, code bases saw little reason to change. Also, the smaller state of SHA2 makes it cheaper to accelerate in hardware, so its performance on existing platforms tends to be superior to SHA3. However, the advent of quantum computing brought the long-term security of common public key exchange schemes into question. The concern is that attackers might collect encrypted messages now and break their encryption once quantum computers sufficiently weaken their security. At risk algorithms include RSA and especially ECC (Elliptic Curve Cryptography). NIST (U.S. National Institute of Standards and Technology) recently announced a set of post quantum ciphers (PQCs) to address this and similar use cases . The two most prevalent algorithms Kyber and Dilithium currently spent around 50% of their cycles on SHA3. SHINCS+ is an alternative provided to Dilithium, providing different trade-offs between compute complexity, and required bandwidth, for certain applications. It is based on a hash tree, thereby spending >=95% of its cycles on SHA3. Given the potentially significant performance overheads for PQC over current ciphers we consider it important to provide strong hardware acceleration of the underlying SHA3 algorithm. In particular the use within the TLS (Transport Layer Security) protocol could significantly impact Internet browsing experiences on client systems, and overheads on networking equipment and cloud services. SHA3 is a subset of the Keccak family of mathematical permutations. The SHA3 standard specifies the use of a 1,600-bit Keccak state and a set of 24 round constants. As shown in Figure 3, to hash an input block using SHA3, the working state is initially zeroed, and then an r-bit portion of the message data is XOR’ed into the state (the remaining c bits of the working state remain as zero). Different variants of SHA3 trade off processing speed against security by choosing different values for “r” (referred to as a “rate” parameter which controls the rate at which the input message is processed). After hashing in a portion of the message, the working state is updated by applying a number of rounds of a Keccak function (for SHA3, the number of rounds is 24). In Figure 3, each block “f” represents a complete set of 24 rounds of applying the Keccak function to the 1600-bit working state information to generate an updated value (i.e. each instance of the ‘T block represents a separate set of 24 rounds, rather than representing one individual round of Keccak). Once the 24 rounds are complete, further input blocks of data from the message are processed in the same way, by hashing in another r bits of the message into the working data resulting from the previous application of the set of 24 Keccak rounds. Each instance of hashing in another chunk of the message and performing one set of 24 Keccak rounds can be referred to as an “absorbing” cycle and the number of absorbing cycles required to process the message depends on the ratio between the message size of the message M and the rate r. Once all blocks to be processed for the message have been processed, a digest can be retrieved from the working state, by performing one or more “squeezing” cycles, each squeezing cycle comprising retrieving a certain number of bits of the working state. If more than one squeezing cycle is performed (e.g. for the SHAKE variants of SHA3 mentioned below), then a further instance of the set of 24 Keccak rounds is applied between successive squeezing cycles and the overall digest Z can be obtained by concatenating or otherwise combining values obtained in each squeezing cycle. The SHA3 algorithm can therefore be referred to as a “sponge” function since the absorption of message blocks into the working state and squeezing of digest information from the working state can be seen as analogous to a sponge absorbing water and then water being squeezed out of the sponge. The SHA3 standard defines a number of variants of the algorithm, which may all use the same underlying Keccak function, but define different rates r and digest sizes d. They process an input message M at a rate r to produce a digest d. The higher the rate, the faster the message is processed, but also the lower the offered security. Similarly, the longer the digest, the higher the security it provides. The SHAKE variants allow for arbitrary length digests by computing further Keccak rounds after processing all input blocks. Type Description Rate r Digest d Hash SHA3-224(M) = KECCAK

[448] (M || 01, 224) 1,600-448= 1,152 bit 224-bit Hash SHA3-256(M) = KECCAK

[512] (M || 01, 256) 1,600-512= 1,088 bit 256-bit Hash SHA3-384(M) = KECCAK

[768] (M || 01, 384) 1,600-768 = 832 bit 384-bit Hash SHA3-512(M) = KECCAK

[1024] (M || 01, 512) 1,600-1,024 = 576 bit 512-bit Extendable-output function SHAKE 128(M, d) = KECCAK

[256] (M || 1111, d) 1,600-256= 1,344 bit Flexible Extendable-output function SHAKE256(M, d) = KECCAK

[512] (M || 1111, d) 1,600-512= 1,088 bit Flexible Figure 4 illustrates the Keccak state information, which for the SHA3 implementations represents a 5x5 array (matrix) of 64-bit data elements. Note that the Keccak function itself can be defined over arbitrary matrix dimensions other than 5x5 and arbitrary data element sizes other than 64 bits, but for SHA3 this has been standardized as a 5x5 matrix and 64 bit elements, giving 1600 bits of Keccak state information. In the Keccak function algorithm, particular elements of the Keccak state information can be referenced based on their (x, y) position in the array. The Keccak algorithm uses a convention where the position (0, 0) is at the central position of the 5x5 array and index values are processed according to modulo 5 arithmetic, so in ascending position from left to right or top-to-bottom, the x and y position indices following the sequence 3, 4, 0, 1, 2. Figure 5 illustrates functionality of one round of the Keccak function, which is applied to the Keccak state matrix as shown in Figure 4 to generate updated values for each working state element of the matrix. Each Keccak round consists of 5 stages: Theta: Compute the parity of each column, and XOR that into the two nearby columns in a regular pattern - Rho: Bitwise rotate each of the 25 words by a different number 0, 1,3, 6, 10, 15, etc. - Pi: Permute the 25 words in a fixed pattern (transpose + intra column shuffle) Chi: Bitwise combine along rows, using x <— x XOR (NOT(y) AND z) lota: XOR a round constant into the word at (x, y) = (0,0), with the round constant being different for each of the 24 rounds. More particularly, some pseudocode representing the operations of one round of the Keccak function is as follows: Keccak-f[b](A) { for i in 0...n-l A = Round[b](A, RC[i]) return A Round[b](A,RC) { # theta step C[x] = A[x,0] xor A[x,l] xor A[x,2] xor A[x,3] xor A[x,4], for x=0...4 D[x] = C[x-1] xor rot (C [x+1],1), for x=0...4 A[x,y] = A[x,y] xor D[x], for (x,y) in (0...4,0...4) # rho and pi steps (rho providing rotation and pi providing element position swapping) B[y,2*x+3*y] = rot(A[x,y], r[x,y]), for (x,y) in (0...4,0...4) # chi step A[x,y] = B[x,y] xor ((not B[x+l,y]) and B[x+2,y]), for (x,y) in (0...4,0...4) # iota step A [0,0] = A[0,0] xor RC return A } Here, all the index operations are performed according to modulo 5 arithmetic. For example, x+1 when x=4 would return 0 (as 5 modulo 5 is 0), and 2*x when x = 4 would return 3 as 2*4 = 8 and 8 modulo 5 is 3). Note that given the convention shown in Figure 4, x=2 is on the extreme right of the matrix and x=3 is on the extreme left of the matrix). For the rho rotation step, the rotation offsets r[x,y] defining the number of bits by which each element A[x,y] is rotated is defined as follows: x=3 x=4 x=0 x=1 x=2 y=2 25 39 3 10 43 y=1 55 20 36 44 6 y=0 28 27 0 1 62 y=4 56 14 18 2 61 y=3 21 8 41 45 15 For the iota step, the round constants are defined as follows (all constant values expressed in hexadecimal). Note that many bits are 0 for each round constant. Round Index Round Constant Round Index Round Constant 0 0x0000000000000001 12 0x000000008000808B 1 0x0000000000008082 13 0x800000000000008B 2 0x800000000000808A 14 0x8000000000008089 3 0x8000000080008000 15 0x8000000000008003 4 0x000000000000808B 16 0x8000000000008002 5 0x0000000080000001 17 0x8000000000000080 6 0x8000000080008081 18 0x000000000000800A 7 0x8000000000008009 19 0x800000008000000A 8 0x000000000000008A 20 0x8000000080008081 9 0x0000000000000088 21 0x8000000000008080 10 0x0000000080008009 22 0x0000000080000001 11 0x000000008000000A 23 0x8000000080008008 While Figure 5 shows the 5 stages of one Keccak round sequentially, it will be appreciated that hardware may implement these stages in any way which provides the same end result, so some of these stages may be fused to perform a combined function which generates the same result. It is not essential to perform each stage sequentially in the order shown, provided the result is the same as a sequential implementation. TurboSHAKE is a recently proposed SHA3 variant that is identical to the above-mentioned SHAKE variants but reduces the number of Keccak rounds to 12 to improve performance for the cost of reduced security. Hence, it is not essential to apply the full set of 24 Keccak rounds each time. Aside from a few data movement instructions, SHA3 is dominated by the Keccak round updates. The mathematical function for defining the Keccak round updates is well defined in the Keccak specification, but there is considerable design flexibility for instruction set designers to decide how to implement instructions for performing Keccak round updates in a CPU architecture. A problem to be addressed is that accelerating the Keccak round updates has proven difficult due to the large state, i.e. 1,600-bit representing a 5x5 matrix of 64-bit elements. While the shifts and XORs involved in the theta, rho, chi and iota stages are relatively cheap to implement in hardware, the element-sized data movements for the pi stage are not. As part of each Keccak round, elements are combined with their row- and column neighbours and the whole state is transposed and shuffled (see details of pi stage above). Given that the Keccak state information is defined as an array of elements and most of the steps of the Keccak function are defined independently per element, one might think it would be feasible to provide, in the ISA of a CPU, vector instructions (i.e. SIMD - single instruction multiple data - instructions) which apply the element updates to multiple independent data elements in response to a single instruction. However, the inventors have found that, surprisingly, even a 512-bit SIMD unit holding one row or column (5x64-bit elements) of the matrix per vector (SIMD) register would provide little to no performance benefit over a scalar implementation (which processes a single 64-bit element per scalar instruction), which could avoid the permutes by “mentally renaming” the 25 registers holding one element each. This is because each “pi” permutation applied to one of the 5x64-bit SIMD registers would need to take inputs from the other 4 SIMD registers providing the other rows / columns (and possibly also need to use further SIMD registers as temporary registers to hold values overwritten in one column / row which still need to be written to another column / row), and most SIMD permute units are not able to accept as inputs such a large number of separate logical vector registers in one instruction. Hence, the performance reduction in transferring individual elements between element positions across 5 or more SIMD registers would be such that the performance cost of the Keccak round is dominated by the very slow performance for the pi step, negating any gains in performance from vectorising the other theta, rho, chi and iota steps. Hence, previous SIMD implementations, relying on instructions which process subportions of the Keccak state with the round function decomposed into separate sub-instructions, so that the round is not performed atomically, effectively replicated scalar operations while allowing multiple independent input streams to be processed in parallel (one per 64-bit lane). This would only provide a performance gain over a scalar implementation if there were multiple independent messages M to hash independently, in which case a given SIMD instruction could be processing working state elements for the same element position (x, y) for each independent message M in parallel. However, in practice, the number of opportunities to generate SHA3 hashes of multiple messages at the same time may be limited, and often software may only require a single message to be hashed, preventing any performance gains being achieved from SIMD processing with conventional approaches. In the examples discussed below, to accelerate the generation of individual SHA3 hashes (not just hashes of multiple independent streams), a CPU instruction is proposed that, when decoded, causes the Keccak round computation circuitry 9 to perform the entire functionality of at least one round of a Keccak function, including the required updates to the whole of the 1600-bit Keccak state information, as a single atomic operation (an indivisible operation which is not split into multiple sub-instructions). This enables opportunities for much greater hardware acceleration of Keccak round updates within SHA3 or other cryptographic algorithms making use of Keccak, which would not be feasible in systems implementing a CPU ISA not supporting such a Keccak-operation-specifying instruction. More particularly, as shown in Figure 6, the Keccak state is referenced as a single logical register holding the whole of the 1600-bit state information. In addition, for some examples where the Keccak state information is held in a logical register with greater than 1600bits (e.g. a 2048-bit register to use an exact power-of-2 number of bits), there is space to hold additional information in the same register. For example, the additional information may comprise a round index value (or other round-constant-specifying value - see example below), which identifies which of the 24 round constants for SHA3 implementation of Keccak is to be used for the next round. By specifying a round constant specifying value associated with the instruction, this means one instance of the instruction can perform a subset of the rounds of Keccak required for a given SHA3 message hashing round, rather than being limited to doing a complete set of 24 rounds, because the round constant specifying value may be used to track how many rounds have already been completed and select the round constant to be used on a particular instance of the instruction. Execution of the instruction may cause the round constant specifying value to be updated to reflect the number of rounds of Keccak performed in response to the instruction, so that a subsequent instruction may continue progress by performing further rounds. Hence, compared to an instruction encoding not supporting the round constant specifying value (which might be limited to performing the full set of 24 Keccak rounds by default, hence having a relatively slow latency making it harder to meet timing requirements in designing a processing pipeline), this makes it more feasible to build a Keccak functional unit as part of a CPU pipeline while meeting timing requirements. Figure 6 shows the computation of one Keccak round update performed in response to the Keccak-operation-specifying instruction. The current state is read from register storage 8 corresponding to the single logical register referenced by the instruction, and processed based on the Keccak algorithm (details above). In parallel, the round index is read, decoded into the corresponding 64-bit round constant, and incremented. The constants are the same for all SHA3 variants and may be obtained by hardwiring a decoder for the index values. A simple lookup structure would also be possible but given the large number of 0s within the constants, a hardwiring would likely be more efficient. Also, the Keccak standard describes the use of a linear-feedback shift register (LFSR) to compute the constants at runtime, which could be an option for some variants. The constant is XORed into the 64-bit of the state representing element (0, 0) in the final step of the round update. The updated state and round index are written back in-place. The round index overflows to 0 once it exceeds 23, representing the 24 round constants. The single logical register (referred to as ZK below) referenced by the instruction could be implicit in the instruction definition, so may not necessarily need an explicit register identifier field to point to the register. Alternatively, the single logical register could be a register identified by a register identifier field of the instruction. A logical register is a register as referenced by instructions, for which there is flexibility in mapping the logical register onto physical register storage in a variety of different ways. Logical registers refer to those referenced by software, while physical registers are those implemented in hardware. One logical register can be mapped to one physical register or to several physical registers. Multiple independent instructions referencing the same logical register can be parallelized, by mapping their operands to different physical registers. This mapping, also known as renaming, step is software transparent, allowing the same code to run on hardware independent of the number of physical registers implemented. A technical advantage of defining instructions such that the whole of the Keccak state information is referenced as a single logical register is that this frees up opportunities for hardware designers, if they wish, to map this onto physical storage which does not necessarily need to be made accessible by other instructions independently referencing sub-portions of the single register. In contrast, ISAs which do not support a Keccak-operation-specifying instruction accessing the Keccak state as a single logical register would be limited to referencing subportions of the state using different logical register identifiers, which may imply that portions of that state need to be accessible if those same logical registers were specified by other non-Keccak-related instructions. This will tend to mean that the hardware designer is forced to introduce multiplexing arrangements which allow arbitrary software-specified accesses to individual parts of the registers used to provide the Keccak state, which will tend to reduce performance for the Keccak round updates themselves as in practice that hardware is likely to be shared with other more generic operations. In contrast, an ISA instruction which references the whole Keccak state as a single logical register gives the hardware designer the freedom to ignore whether other instructions should be able to reference sub-parts of the state, and simply implement the hardwired circuit logic that can implement the required data movements for the “pi” phase as a single atomic operation, rather than implementing selection logic for a programmable selection of specific permutations from a wider set of supported options. It may seem surprising that, given the complexity of the Keccak round update function, it is feasible to perform a Keccak round update as a single atomic instruction. However, the inventors have found that, being able to access the complete Keccak state at once within a single logical register, hardware may parallelize most computations within each stage and simply hardwire data movements. As the critical path is only around a dozen gates deep, it is feasible to compute one or more Keccak rounds within a single cycle, even at the relatively high operating frequencies supported by modern processors. When in use within a wider program instruction sequence implementing SHA3, the Keccak-operation-specifying instruction (referred to as “Keccak instruction” for conciseness below) can be included in the instruction sequence as follows, with successive instructions implementing the following functions: - Zero the Keccak state information register o E.g. “Zero ZK” instruction with ZK referencing the register - XOR the first input block into the state o E.g. one or more “XOR ZK[index], Zs” instructions, with Zs specifying an n-bit source register and index the region within ZK to XOR it to (n-bit wide starting at “index * n-bit”) Compute 24 Keccak rounds o E.g. 24 Keccak instructions, which implicitly operate on ZK, performing 1 round update each - XOR the next input block into the state, then compute 24 more Keccak rounds ... repeat for any other message blocks Retrieve the digest from the state o E.g. “MOV Zd, ZK[index]”, with Zd specifying an n-bit destination register The Keccak-operation-specifying instruction, and the corresponding Keccak-round-computation circuitry 9, can be implemented in different ways. The support for XOR / MOV instructions shown above as accessing a specified portion of the ZK register may be limited to instructions which access the portion of the Keccak state information corresponding to the “r” bits into which input message data is absorbed or the bits from which the digest is squeezed in the SHA3 functions, so it is not essential to support general purpose instructions capable of accessing any arbitrary bits of the Keccak working state data corresponding to the ZK register. Figure 7 shows a first example of a data processing apparatus, e.g. a CPU 10, comprising the Keccak round computation circuitry 9. The data processing apparatus 10 is schematically shown to have a pipelined configuration, which for the purposes of brevity and clarity is shown in a conceptual representation here. The illustrated pipeline stages comprise an instruction cache 11, a fetch stage 12, a decode stage 13, a micro-op cache 14, an issue stage 15, and a register access stage 16. A sequence of instructions is retrieved from memory (not shown) and cached in the instruction cache 11. The fetch stage 12 controls which instructions are retrieved as the sequence of instructions and these instructions are then decoded in the decode stage 13. This decoding identifies the type of each instruction, as well as any further operands specified by the instruction, and generates control signals to control the remainder of the apparatus to perform the data processing operation(s) defined by the instruction. Decoding the instructions may comprise splitting an instruction into one or more micro-ops, and these micro-ops can be cached in the micro-op cache 14. The final stage of the pipeline before execution is the issue stage 15, where instructions (or micro-ops) are queued pending the availability of the register values they specify as operands and the corresponding functional unit of the data processing pipeline which will carry out the defined operation. Generally the data processing operation(s) defined by the instructions are carried out by the functional units that form part of the data processing pipeline, namely the load / store unit 17, one or more execute units 18 (which may for example include arithmetic logic units (ALUs), floating point units (FPUs), and so on), and, for this example supporting the Keccak-operation-specifying instruction, the Keccak round computation circuitry 9, which is implemented as a further functional unit (either in isolation or as a combined functional unit which also supports operations other than the Keccak round update operation). The functional units that form part of the data processing pipeline perform their data processing operations on data values which are provided from a set of registers (conceptually represented by the register access stage 16 in the figure) and result values of those data processing operations are returned to the set of registers. The load / store unit 17 is provided for the purpose of storing values from the set of registers to the memory system, of which only a level 1 cache 21 and a level 2 cache 22 are shown in the figure. The L1 cache 21 is private to the data processing apparatus 10 and the L2 cache 22 may be shared with another data processing apparatus, when part of a wider data processing system. The data processing apparatus 10 is also shown to comprise a branch unit 20, which monitors execution flow of the sequence of instructions and seeks to predict, based on previous execution history, whether a given branch will be taken or not. The predictions from the branch unit 20 inform the sequence of instructions caused to be fetched by the fetch stage 12. It will be appreciated that Figure 7 shows one particular example, but not all features of Figure 7 are essential (e.g. some examples may omit the micro-operation cache 14) and additional features can also be provided (e.g. an out-of-order processor may include a further rename pipeline stage for performing register renaming). Hence, Keccak round computation circuitry 9 can be built into a CPU hardware design as a standalone functional unit (or part of a functional unit shared with other operations). The Keccak round computation circuitry 9 has direct access to processor registers 16 and is controlled to perform at least one round of the Keccak function in response to decoding of the Keccak-operation-specifying instruction. While Figure 7 shows the Keccak round computation circuitry 9 as a parallel functional unit to other functional units 17, 18, 20 of the CPU 10, and accessing a common set of registers 16 shared with those other functional units 17, 18, 20, other examples could implement the Keccak round computation circuitry 9 as part of a co-processor which shares a common front end portion of the pipeline (e.g. fetch 12 and decode 13 stages) with the main CPU functional units 17, 18, 20, but which has separate register files, issue logic and execution logic from the register file(s), issue and execution stages 15, 17, 18, 20 used for other CPU instructions. For example, the co-processor could implement functionality corresponding to the “Scalable Matrix Extension” (SME) architecture extension provided by Arm® Limited, which provides registers and instruction execution support for performing operations on very long registers, which is particularly helpful for processing of matrix data structures. Hence, in some examples the physical register mapped to the logical register referenced by the Keccak-operation-specifying instruction could for instance be part of the circuitry supporting the Scalable Matrix Extensions (SME). SME already provides a fixed-size 512-bit ZT0 register to handle data transformations. The architecture allows for up to 4 ZT registers, so the above mentioned ZK could map onto a fixed-size 2,048-bit ZT1. A power of two size would simplify data movement instructions, but the physical register could be implemented with just 1,600 bits (or 1605-bit if a 5-bit round constant index is included), and even if the logical register is defined as 2048 bits, if the hardware only implements fewer bits then writes to the unsupported bits of the logical register can ignored and the hardware can return 0 for reads of bits beyond the limit of the hardware-implemented storage. A status register could indicate if the Keccak state logical register ZT1 is present and enabled, so not all designs would need to implement it, and software could ignore it for fill / spill on context switches (on implementations not supporting the Keccak logical register, the Keccak instruction can be treated as undefined and emulated in software using conventional scalar operations). The status register could also indicate the physical sizes of ZT1. In practice, padding the round constant index to a power of 2 (using 64 instead of 5 bits) to represent the index might simplify this representation (26*64-bit size) and also reads / writes of the index value. Figure 8 illustrates another possible implementation of a CPU 10 supporting Keccak round computation circuitry 9 as discussed above. The features of Figure 8 shown with the same numbers as in Figure 7 are the same as discussed earlier. However, the example of Figure 8 also comprises extension processing circuitry 23, which is provided to support efficient performance of one or more defined functions, which have been established to be impactful and ubiquitous for the data processing operations which this data processing apparatus 10 carries out. While Figure 8 shows a single extension processing unit 23, other examples may have more than one extension processing unit 23 directed to different defined functions. The extension processing circuitry is closely associated with the data processing pipeline and is configured to perform the defined function (also referred to as a delegated task) in response to a delegation signal received from the data processing pipeline. The extension processing circuitry 23 is an example of a threadlet extension (TE). The sequence of operations it carries out to perform the defined function is referred to as a threadlet. The extension processing circuitry 23, although closely associated with the data processing pipeline, is configured to perform the delegated task asynchronously with respect to the data processing operations performed by the main data processing pipeline 11-20 of the CPU 10. Threadlets are functions or collections of operations that can be executed asynchronously relative to other CPU activity once launched. The directive or command sent to the extension processing circuitry 23 to initiate the delegated task is generated in response to an extension start instruction defined for this purpose in the ISA of the CPU 10. Thus, an extension start instruction progresses along the data processing pipeline in the manner that any other CPU instruction would, but when the decoding circuitry 13 identifies the extension start instruction it can signal directly to the extension processing circuitry 23. As the extension task triggered by the extension start instruction is performed asynchronously by the extension processing circuitry 23, the extension start instruction can be committed by the main CPU pipeline without waiting for completion of the extension task by the extension processing circuitry 23. The close integration of the extension processing circuitry 23 with data processing pipeline is illustrated by the fact that the extension processing circuitry 23 has direct access to the load / store unit 17, and thus it shares the data processing pipeline’s path to memory. The extension processing circuitry 23 also has access to the set of registers 16, such that for example, the extension start instruction can specify one or more registers as operands, and the values from these registers are then passed directly to the extension processing circuitry 23 in association with the command sent to initiate the delegated task (hence, for the Keccak operation threadlet, the parameters passed from the registers may include the round constant specifying value mentioned earlier). Upon completion of the task, results of the delegated task can be returned to the register values via an extension synchronisation instruction, which provides a barrier that ensures that subsequent instructions referencing those registers await completion of the delegated task by the extension processing circuitry 23 (in the absence of the extension synchronisation instruction being decoded, there is no need for any non-extension instructions executing on the CPU to await outputs from the extension processing circuitry 23, and as such further processing using conventional CPU instructions may continue in the background of extension processing being performed asynchronously on the extension processing unit 23). In examples which support more than one extension processing unit 23, a parameter of the extension start instruction and extension synchronisation instruction may identify which of the extension processing units 23 is targeted by that instruction. Figure 9 schematically illustrates a further example of the apparatus 10 supporting extension processing circuitry, which is provided as a comparison to the example of Figure 8. In the example of Figure 8, the extension processing circuitry was more closely embedded with the data processing pipeline. However, in the example of Figure 9, the main processing logic 51 of the CPU 10 and the extension processing circuitry (threadlet extension) 52 are less closely integrated (but still much more closely integrated than if the corresponding extension functions were executed by a remote accelerator 104 accessed via the memory system interconnect 106 as shown in Figure 2). For example, this is illustrated by the fact that both the main CPU logic 51 and the threadlet extension circuitry 52 each has its own path to memory, with an L1 cache 53 private to the main CPU logic 51 and an L1 cache 54 private to the threadlet extension 52. They share the L2 cache 55. Nevertheless, the threadlet extension 52 remains tightly coupled to the main CPU logic 51, and can be launched quickly when an extension start instruction is encountered in the CPU pipeline specifying the function this threadlet extension 52 performs. The threadlet extension 52 can get data directly from CPU registers at the start of its execution. Upon completion, it can return values via an extension synchronisation instruction. Figure 9 also shows the threadlet extension 52 as having its own private TLB 56, in which it can cache currently used address translations. As a preparatory step before or associated with the delegation signal, content from the TLB 57 in the CPU 51 can be copied into the private TLB 56 in order to prewarm this cache before the threadlet begins operation. In either of the examples of Figures 8 and 9, where extension processing circuitry 23, 52 is provided for implementing dedicated delegated tasks or functions asynchronously with respect to other CPU operations, the Keccak round computation circuitry 9 mentioned earlier can be implemented as part of the threadlet extension processing circuitry 23, 52, and the single logical register referenced by the Keccak round computation circuitry 9 may be an internal register of the threadlet extension processing circuitry 23, 52. Alternatively, the Keccak state information could be held in a region of memory referenced by the threadlet extension processing circuitry 23, 52 when processing the delegated threadlet function including the Keccak function. The Keccak-operation-specifying instruction in this example may be an extension (threadlet) start instruction which specifies an operation identifier which identifies that, from among a set of supported threadlet functions, the particular threadlet function to be performed asynchronously by the threadlet extension processing circuitry 23, 52 is an operation comprising at least one Keccak round update. Figures 7 to 9 show that, while a variety of implementations are possible, in general it is useful to implement the Keccak round computation circuitry 9 tightly coupled to the main CPU. In all these examples, the configuration signal path used to convey control signals to the Keccak round computation circuitry in response to decoding of the Keccak-operation-specifying instruction by the instruction decoding circuitry (e.g. the path from issue stage 15 to the Keccak functional unit 9 in Figure 7, or the path from the decode stage 13 to the extension processing unit 23 in Figure 8, or the path by which the main CPU logic 51 instructs the threadlet extension circuitry 52 in response to an extension start instruction in Figure 9) is separate from the load / store signal path by which the CPU 10 / main CPU logic 51 accesses memory 110. This is different from implementations relying on remote hardware accelerators 104 for acceleration of cryptographic functions. Such remote hardware accelerators 104 are complex and slow to program and read out results for further processing on a CPU 10. As there is a certain amount of overhead associated with offloading work to the remote accelerators, it becomes infeasible to offload very short tasks to the remote accelerator 104 and then process the results of those tasks using the CPU 10. In practice, hashing a message using SHA3 may be a short task for which the performance cost of offloading to a hardware accelerator 104 would be prohibitive. Hence, by providing Keccak round computation circuitry 9 which can accelerate the Keccak round updates much closer to the CPU itself, this can be extremely beneficial to processing performance for functions such as TLS and other secure browsing protocols which are expected in future to make use of SHA3. A number of further variation options for the Keccak-operation-specifying instruction are set out below, which could be combined in any combination. a) Fusion to Process more than one Keccak round per cycle As mentioned above, the critical path of a Keccak round is relatively short. Depending on underlying process and timing constraints it is possible to compute more than one round per cycle. For instance, the instruction decoding circuitry 13 could recognize sequences of multiple “Keccak” instructions and fuse them. The hardware may then use the Keccak round computation circuitry 9 to compute two or more rounds together. The number of rounds per cycle does not have to be an integer but can match the expected 12 or 24 rounds for TurboSHAKE and SHA3, respectively. This would for example allow for implementations processing 2 rounds in 1 cycle or 3 rounds in 2 cycles. The latter would process a full set of 24 Keccak rounds in 16 cycles. The same instructions may be executed on other implementations not supporting fusion in 24 cycles, with one round per cycle. b) Status Information in Upper Register Bits A logical 1,600+-bit register can be mapped to physical registers larger than that, e.g. 1,664- or 2,048-bit to better match existing circuitry to move, load, and store data. The remaining bits could either be ignored (write ignore / read zero) or used for additional status information. For instance, it can be useful to record in the unused bits a “working state hint value” used to indicate whether the 1,600-bit state is all 0. This could drastically speed up the time to load it from the stack in cases where no round updates have been applied yet. Also, a threadlet might use those additional bits of storage to store recovery information. Assuming that the threadlet interface is provided with a pointer and length to the data in memory to be hashed, it could store updated pointer values with the Keccak state. This might simplify its recover in case of an interrupt and / or migration of the underlying thread to a different CPU. c) Status Information in separate Configuration / Status Register Status and configuration registers may be provided to indicate if ZK exists (set by hardware) - that is whether the Keccak-operation-specifying instruction is supported at all. This can be polled by software to determine whether to call an alternative fallback code path which implements the Keccak functionality using separate non-atomic scalar or vector instructions. ZK is enabled (set by software) - i.e. whether the Keccak-operation-specifying instruction is currently enabled. For example, in an implementation using the threadlet extension, even if supported the Keccak-operation-specifying instruction may not currently be enabled for one thread if the threadlet extension circuitry 23, 52 is currently in use for another thread. d) “Keccak num_rounds” The basic “Keccak” instruction discussed above does not require any operands. It implicitly uses the proposed logical register (e.g. ZK I ZT1) to compute 1 Keccak round, while implicitly updating the corresponding round index. However, an operand (e.g. an immediate operand or additional information specified in the logical register ZK or in a further register) may be used to indicate the number of rounds to be processed. For instance, a 2-bit value to indicate: Compute 1 round; increment index by 1 (reset if value == 24) Compute up to 12 rounds (TurboSHAKE); increment index after each round, stop computation and reset index if value == 12 Compute up to 24 rounds; increment index after each round, stop computation and reset index if value == 24 Alternatively, a 5-bit instead of a 2-bit value could indicate an arbitrary number of rounds between 1 and 24. If the current round index is considered when determining how many rounds to compute, it might be easiest to block the functional unit for the max. # of cycles required to compute 1,12, or 24 rounds. This would simplify the decoder as it wouldn’t need to read the round index prior to issue. While this might leave some performance on the table in case of a round index >0 reducing the number of cycles required, it would be up to software to avoid those cases. e) Preserve Progress throughout Interrupts The basic concept - processing 1 Keccak round per cycle - does not require special interrupt recovery mechanisms. However, when implemented as a threadlet, recovery mechanisms might benefit from storing progress information in the upper register bits as outlined above. The “Keccak num_rounds” instruction variant outlined above may take 24 or more cycles to complete, depending on the hardware implementation. For most systems this should be unproblematic as interrupts are relatively rare and hardware could just squash the in-flight instruction and re-issue it after handling the interrupt. However, certain systems - slow Keccak hardware and frequent interrupts - may be interested in ensuring that some progress is made on such long-running instructions. One approach would be to update ZK after each completed round I set of rounds if hardware computes multiple per cycle, instead of only after the whole “Keccak num_rounds” instruction completes. The instruction would not be retired until it fully completes; hence, it would be re-issued after the interrupt is handled and the round index and the num_rounds operand could be used to determine how many rounds still need to be computed before the instruction may retire. This approach may be compatible with some interrupt models that support the partial completion of instructions. f) “Keccak round_index” In the example of Figure 6, the round index is stored within ZK. Alternatively, the index may be provided as an immediate operand by the instruction. This would slightly reduce the physical size of the register and may speed up fill / spill operation on context switch. The operand may either be a register or 5-bit immediate. The register would allow for higher code density as it may be updated within a loop, rather than requiring up to 24 separate instructions with immediate values 0 to 23. The immediate variant would not require the use and update of a scalar register to hold the index value. g) Store Round Constant instead of Round Index The example of Figure 6 assumes that the round index held in ZK is decoded using hardwired circuitry to obtain the corresponding 64-bit round constant. Alternatively, a 24-entry lookup table may be used. An alternative to storing the round index with ZK would be to directly store the current round constant. The SHA standard describes how a linear-feedback shift register (LFSR) may compute the constants at runtime. Hence, the next constant could be computed from the current constant at runtime. Hence, in general, the Keccak instruction may be associated with a round constant specifying value, which could either be a round index as discussed above or could be a value indicating the round constant itself. Figure 10 illustrates steps for processing a Keccak-operation-specifying instruction. At step 200, a Keccak-operation-specifying instruction is decoded using instruction decoding circuitry 13. For example, the Keccak-operation-specifying instruction could be a dedicated CPU instruction indicating that the Keccak function is to be performed, or could be an extension (threadlet) start instruction as discussed above. At step 202, in response to the Keccak-operation-specifying instruction being decoded, the Keccak round computation circuitry 9 performs at least one round of the Keccak function applied to Keccak state information representing an array of working state elements, to generate updated values for each working state data element of the array. The Keccak state information is referenced as a single logical register by the instruction. At least one complete round of the Keccak function is performed as an atomic (non-divisible) operation by the Keccak round computation circuitry 9. The round constant to be used for a given round to be performed in response to the Keccak-operation-specifying instruction is selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction. The round constant specifying value may be updated in response to the Keccak-operation-specifying instruction, based on the In some examples, the element-width data movements in the pi phase of the Keccak round update are performed by hardwired circuitry, without requiring explicit software designation of the positions from which I to which elements are copied in source / destination registers. Figure 11 illustrates in more detail an example of the Keccak round computation processing performed by the Keccak round computation circuitry 9. At step 210, a round constant for the current round is selected based on a round constant specifying value. For example, the round constant can be decoded from a round index or read directly from the round constant specifying value provided in the logical register shared with the Keccak state information. At step 212, the Keccak function is applied to an array of working state elements based on the selected round constant. For example, the circuitry applies the theta, rho, pi, chi and iota stages of the Keccak function to the elements of the working state matrix as mentioned earlier. The selected round constant is applied to element (0, 0) during the iota stage. At step 214, the round constant specifying value is updated to account for the completed round of the Keccak function. For example, if the round constant specifying value is a round index, the round index is incremented (one or more times, depending on the number of rounds performed), or if it has already reached the maximum number of rounds required (24 for SHA3 implementations, 12 for TurboSHAKE implementations, or an arbitrary maximum number of rounds if the “num_rounds” operand is supported), then the round constant specifying value is reset to an initial value (e.g. to 0 or to the round constant for round 0). At step 216, the stored register state is updated with updated values for the array of working state elements and the round constant specifying value. At step 218, it is determined whether there are further rounds to compute (either because the Keccak-operation-specifying instruction itself triggers multiple rounds, e.g. because it triggers a threadlet extension function involving multiple rounds, or because multiple Keccak-operation-specifying instructions have been fused to perform multiple rounds in one micro-operation). If there are further rounds to compute, then the method returns to step 210 to perform another round of the Keccak function. If there are no more rounds to compute, then at step 220 the next instruction to process is awaited. Figure 11 shows an example where, if there are multiple rounds to compute in one instruction, at step 216 the register state is updated after each individual completed round, so that forward progress can be made even if the instruction operation is interrupted before completing all the rounds it was scheduled to complete. However, this is not essential and in other examples the register state update step at step 216 can be deferred until after step 218 so that the register state is only updated after the final round is complete. In this case, it is possible that if the instruction’s operation is interrupted between rounds before completing the final round, on resumption after the interrupt all the rounds corresponding to that instruction I micro-operation may need to be repeated even if some rounds were already done prior to the interruption. Figure 12 illustrates steps for controlling instruction fusion, in an implementation where the instruction decoding circuitry 13 supports instruction fusion. At step 240, the instruction decoding circuitry 13 detects a Keccak-operation-specifying instruction. At step 242, the instruction decoding circuitry 13 detects whether the Keccak-operation-specifying instruction can be fused with at least one preceding Keccak-operation-specifying instruction already detected. If not, then the Keccak-operation-specifying instruction is decoded to a non-fused Keccak microoperation which triggers performance of a single round of the Keccak function. If the instruction can be fused with earlier Keccak-operation-specifying instruction(s), then at step 246 the instruction decoding circuitry 13 decodes the Keccak-operation-specifying instruction to a fused Keccak micro-operation which controls the Keccak round computation circuitry to perform at least two rounds of the Keccak function. Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein. For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, System Verilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using system-level modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts. Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly. The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated. Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept. Figure 13 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 IISENIX Conference, Pages 53 - 63. To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 described above, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features. Hence, the simulator code 710 may include instruction decoding program logic 712 and Keccak round computation program logic 714 which emulates functionality of the instruction decoding circuitry 13 and Keccak round computation circuitry 9 from the earlier examples. For example, the instruction decoding program logic 712 may include if / then / else-type conditional logic to parse the instructions of the target code 700 and identify specific instruction types which are to be mapped to corresponding subroutines defined in the native instruction set of the host hardware 730. The Keccak round computation program logic 714 comprises one of those subroutines which is selected by the instruction decoding program logic 712 when a Keccak-operation-specifying instruction is detected in the target code 700. Although the Keccak-operation-specifying instruction is defined in the ISA supported by the simulator 710 as an atomic instruction referencing a single logical register, in the simulated embodiment of Figure 13 the instruction may be mapped to multiple non-atomic instructions referencing the Keccak state information as separate logical registers according to the native ISA supported by the host hardware 730, as the host hardware 730 may not itself support a single atomic Keccak operation. Providing a simulator embodiment which enables target code 700 written for an apparatus 10 as in the earlier examples to be emulated on host hardware 730 not supporting the Keccak instruction can be helpful for enabling development of software including the Keccak instruction to start even before hardware supporting that instruction is ready. Such software can then be tested by executing it within the simulated instruction execution environment provided by the simulator program 710 executing on host hardware not supporting the Keccak instruction. In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. In the present application, lists of features preceded with the phrase “at least one of’ mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination. Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. An apparatus comprising:instruction decoding circuitry configured to decode instructions according to an instruction set architecture; andprocessing circuitry configured to perform data processing in response to the instructions decoded by the instruction decoding circuitry; in which:the processing circuitry comprises Keccak round computation circuitry configured to perform, in response to the instruction decoding circuitry decoding a Keccak-operation-specifying instruction, an atomic operation comprising at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array; andin a given round of the Keccak function, the Keccak round computation circuitry is configured to update at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction.

2. The apparatus according to claim 1, in which the Keccak-operation-specifying instruction references the Keccak state information as a single logical register.

3. The apparatus according to any preceding claim, in which the round constant specifying value comprises a round index indicative of which of a plurality of rounds of the Keccak function is to be performed in response the Keccak-operation-specifying instruction.

4. The apparatus according to any of claims 1 and 2, in which the round constant specifying value explicitly specifies the round constant itself.

5. The apparatus according to any preceding claim, in which, in response to the Keccak-operation-specifying instruction, the Keccak round computation circuitry is configured to update the round constant specifying value based on how many rounds of the Keccak function have been performed by the Keccak round computation circuitry.

6. The apparatus according to claim 5, in which the Keccak round computation circuitry is configured to reset the round constant specifying value to an initial value in response to the number of completed rounds of the Keccak function reaching a maximum number of rounds.

7. The apparatus according to any preceding claim, in which the Keccak-operation-specifying instruction is associated with a reset parameter indicative of whether the roundconstant specifying value is to be reset in response to the Keccak-operation-specifying instruction.

8. The apparatus according to any preceding claim, in which the round constant specifying value and the Keccak state information are specified using a single logical register providing both the round constant specifying value and the Keccak state information.

9. The apparatus according to any preceding claim, in which the Keccak-operation-specifying instruction comprises a CPU instruction comprising an opcode indicating that the instruction is a Keccak-operation-specifying instruction.

10. The apparatus according to any of claims 1 to 8, in which the Keccak-operation-specifying instruction comprises a threadlet start instruction to control offloading of a threadlet operation to be performed by threadlet processing circuitry asynchronously with respect to other operations performed by the processing circuitry;the threadlet processing circuitry comprises the Keccak round computation circuitry; and the threadlet start instruction specifies a threadlet operation identifier which, for the Keccak-operation-specifying instruction, specifies that the threadlet operation comprises said at least one round of the Keccak function.

11. The apparatus according to any preceding claim, in which the Keccak-operation-specifying instruction is associated with a number-of-rounds parameter specifying a maximum number of rounds of the Keccak function to be performed in response to the Keccak-operation-specifying instruction, and the Keccak round computation circuitry is configured to limit a number of rounds of the Keccak function performed in response to the Keccak-operation-specifying instruction to not exceed the maximum number.

12. The apparatus according to any preceding claim, in which the instruction decoding circuitry is configured to fuse a group of at least two Keccak-operation-specifying instructions detected by the instruction decoding circuitry, to control the Keccak round computation circuitry to perform at least two rounds of the Keccak function in response to a single fused micro-operation.

13. The apparatus according to any preceding claim, in which, when at least two rounds of the Keccak function are performed in response to a micro-operation generated based on at least one Keccak-operation-specifying instruction, the Keccak round computation circuitry is configured to update register state with the updated values for the array of working state data elements in response to completion of each individual round of the Keccak function, to enable resumption ofone or more uncompleted rounds of the Keccak function following an interruption without repeating one or more earlier completed rounds of the Keccak function.

14. The apparatus according to any preceding claim, in which the Keccak state information comprises 1600 bits of working state information.

15. The apparatus according to any preceding claim, in which a given round of the Keccak function comprises an inter-element permutation function to swap positions of working state data elements within the array and at least one intra-element permutation function to apply permutations within each working state data element of the array.

16. The apparatus according to any preceding claim, comprising a central processing unit (CPU) comprising the instruction decoding circuitry, the processing circuitry and the Keccak round computation circuitry.

17. The apparatus according to any preceding claim, in which the instruction decoding circuitry comprises shared decoding circuitry configured to decode arithmetic / logical instructions, branch instructions and load / store instructions of the instruction set architecture, as well as being configured to decode the Keccak-operation-specifying instruction.

18. The apparatus according to any preceding claim, comprising a configuration signal path configured to convey control signals to the Keccak round computation circuitry in response to decoding of the Keccak-operation-specifying instruction by the instruction decoding circuitry;wherein the configuration signal path is separate from a load / store data path used by the processing circuitry to issue load / store memory access requests to a memory system.

19. The apparatus according to any preceding claim, in which the Keccak round computation circuitry is configured to perform said at least one round of the Keccak function in a single clock cycle.

20. The apparatus according to any preceding claim, in which the Keccak round computation circuitry has direct access to state in architectural CPU registers defined by the instruction set architecture.

21. Computer-readable code for fabrication of an apparatus comprising:instruction decoding circuitry configured to decode instructions according to an instruction set architecture; andprocessing circuitry configured to perform data processing in response to the instructions decoded by the instruction decoding circuitry; in which:the processing circuitry comprises Keccak round computation circuitry configured to perform, in response to the instruction decoding circuitry decoding a Keccak-operation-specifying instruction, an atomic operation comprising at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array; andin a given round of the Keccak function, the Keccak round computation circuitry is configured to update at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction.

22. A method comprising:decoding instructions according to an instruction set architecture, using instruction decoding circuitry; andperforming data processing, using processing circuitry, in response to the instructions decoded by the instruction decoding circuitry; in which:in response to the instruction decoding circuitry decoding a Keccak-operation-specifying instruction, Keccak round computation circuitry of the processing circuitry performs an atomic operation comprising at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array; andin a given round of the Keccak function, the Keccak round computation circuitry updates at least one working state data element of the array based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction.

23. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: instruction decoding program logic to decode instructions according to an instruction set architecture and control the host data processing apparatus to perform data processing in response to the instructions decoded by the instruction decoding circuitry; andKeccak round computation program logic to control the host data processing apparatus perform, in response to the instruction decoding program logic decoding a Keccak-operation-specifying instruction, at least one round of a Keccak function applied to Keccak state information representing an array of working state data elements, to generate updated values for each working state data element of the array, said Keccak-operation-specifying instruction comprising an atomic instruction for controlling performance of said at least one round of the Keccak function,where in a given round of the Keccak function, at least one working state data element of the array is updated based on a round constant selected based on a round constant specifying value associated with the Keccak-operation-specifying instruction.40

Images