Patent Description:
Recently, there has been an explosion in the number of devices that are connected to computer networks. For example, Internet connectivity is expanding beyond computing devices such as desktop and laptop computers to embedded systems within everyday objects such as motor vehicles, lightbulbs, fridges, medical devices, thermostats and surveillance systems. Telecommunications links allow many low-cost computing devices to report sensor data, and/or be controlled, across the world. One issue with these connected devices is that they are often vulnerable to attack and malicious control. For example, hundreds or thousands of embedded devices may be compromised by malicious parties and used to enact distributed denial of services attacks. In many cases, control of these devices is easily obtained due to poor or limited implementations of cryptographic protocols. As these connected devices grow in number and popularity, there is an open question as to how to secure them.

Another consideration when securing connected computing devices is the possibility of a future attack using quantum computing. For many years, quantum computers were of mainly theoretical interest. However, research implementations of quantum computers are developing rapidly. Quantum computers having <NUM> and <NUM> qubits are currently available, and there are many research groups actively working on higher qubit machines. Given the possible future reality of quantum computing, recent work has shown that many well-known public key cryptographic systems can be broken by a sufficiently strong quantum computer.

When implementing cryptographic functions, especially those that are "post quantum" secure, there is the challenge that many of these functions are resource intensive. For example, many cryptographic functions involve complex mathematical functions using values with long bit lengths. These typically consume a large number of processor cycles and present difficulties for implementations within low-resource embedded devices. Additionally, as end-to-end encryption of both data and communications becomes common, these cryptographic functions also have to be performed repeatedly at high speeds. To be secure is to be slow.

<CIT> describes an apparatus to process the KECCAK secure hashing algorithm. In the apparatus of <CIT>, an instruction decoder receives an instruction to process a KECCAK state cube of data representing a KECCAK state of a KECCAK hash algorithm. The instruction instructs the partition of the KECCAK state cube into a plurality of subcubes, and the storage of the subcubes in a plurality of registers, respectively. An execution unit coupled to the instruction decoder performs the KECCAK hash algorithm on the plurality of subcubes respectively stored in the plurality of registers in a vector manner. The apparatus of <CIT> is a processor such as a Complex Instruction Set Computing (CISC) or Reduced Instruction Set Computing (RISC) processor. The methods described in <CIT> are implemented by the processor. The methods may be implemented with eight instructions per round of the KECCAK algorithm, where each round is performed on a slice (the subcube) of the total data.

It is desirable to provide efficient implementations of cryptographic operations. For example, it is desired to provide implementations that may be used within low-resource embedded systems and/or in high-speed data processing operations, while offering resistance to attack in a post-quantum environment.

<CIT> describes a hash value generating device for generating a hash value based on the KECCAK algorithm.

<CIT> describes a digital signal processor (DSP) co-processor according to a clustered architecture with local memories.

<CIT> describes an embedded-DRAM (dynamic random access memory) processor architecture.

<CIT> describes a cryptographic engine that includes a scalable cryptographic coprocessor that is controlled by, and separate from, a main engine processor.

<CIT> describes an efficient implementation of a cryptographic processor that dynamically updates the encryption state.

Aspects of the present invention are set out in the appended independent claims. Certain variations of the invention are then set out in the appended dependent claims.

Examples of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:.

Certain examples described herein provide a cryptographic architecture that allows a processing unit to efficiently perform a cryptographic permutation. The cryptographic architecture provides a processor interface that enables the processing unit to effectively communicate with a cryptographic permutation unit to perform a cryptographic permutation. As such, the processing unit may effectively off-load computation of the permutation to a dedicated module and then access the results of the permutation via the processor interface. The cryptographic architecture may provide atomic low-level operations that allow many advanced cryptographic functions to be rapidly computed, including those that are "post-quantum" secure. The cryptographic architecture may perform rapid cryptographic base functions on behalf of a processor or microprocessor, and as such provides benefits for both low-power embedded devices and high-throughput server devices.

<FIG> shows an example <NUM> of a cryptographic architecture <NUM>. In <FIG>, the cryptographic architecture <NUM> comprises a processor interface <NUM> that enables the cryptographic architecture <NUM> to communicate with a processing unit <NUM>. The processing unit <NUM> is shown with a dot-dash outline as it may not form part of the cryptographic architecture <NUM>. The cryptographic architecture <NUM> also comprises a cryptographic permutation unit <NUM>. The cryptographic permutation unit <NUM> comprises circuitry to perform a cryptographic permutation. As shown in <FIG>, in use, the processing unit <NUM> instructs the cryptographic permutation and accesses a result of the cryptographic permutation using the processor interface <NUM>.

In one example, the processor interface <NUM> comprises a set of cryptographic registers. The cryptographic registers may be accessible to the processing unit <NUM>, e.g. certain cryptographic registers may be readable and/or writable by the processing unit <NUM>. In use, the processing unit <NUM> may access a result of the cryptographic permutation, as performed by the cryptographic permutation unit <NUM>, via the set of cryptographic registers, i.e. using data stored within the set of cryptographic registers. The set of cryptographic registers may be used for exchanging data and control information between the cryptographic permutation unit <NUM> and the processing unit <NUM>. The cryptographic registers may be accessed one or more of memory mapped registers and as a part of named Single Instruction, Multiple Data (SIMD) or vector register set of the processing unit <NUM>.

In certain examples, the processing unit <NUM> comprises a microprocessor having one or more processing cores, e.g. the processing unit <NUM> may be a processing unit for an embedded device. In other examples, the processing unit may comprise a central processing unit of a computing device that has one or more processing cores, e.g. the processing unit <NUM> may be a processing unit for mobile computing device, desktop computer and/or server computing device.

The cryptographic architecture <NUM> may be implemented in a number of different ways (and combinations of approaches are possible). In one case, the cryptographic architecture <NUM> may be implemented using one or more Application Specific Integrated Circuits (ASICs). In another case, the cryptographic architecture <NUM> may be implemented using one or more Field Programmable Gate Arrays (FPGAs). In yet another case, the cryptographic architecture <NUM> may be implemented using firmware for the processing unit <NUM>. In certain cases, different components of the cryptographic architecture <NUM> may be implemented using a combination of two or more of ASICs, FPGAs and firmware instructions. In one case, the functionality of the cryptographic architecture <NUM> may be provided via one or more of a microcode and firmware update. In this case, authentication of the code may be required to ensure security. The cryptographic permutation unit <NUM> may be implemented in a similar manner.

In an example, one or more of the cryptographic architecture <NUM> and the cryptographic permutation unit <NUM> may be provided (e.g. packaged) as a discrete unit. For example, the discrete unit may be a self-contained security microcontroller (e.g. supplied as a smart card, a Universal Serial Bus - USB - device and/or a Radio Frequency Identification - RFID - device), a cryptographic coprocessor or accelerator, a cryptographic Trusted Platform Module (TPM) or a Hardware Security Module (HSM). The discrete unit may be coupled to the processing unit <NUM> via one or more communications buses or interfaces and/or co-located on a circuit board. Hence, the cryptographic architecture <NUM> may be provided as a single chip that is easily added to a computing board for a wide variety of computing devices.

<FIG> shows a processor interface <NUM> where the cryptographic registers comprise a first set of data registers <NUM> and a second set of control registers <NUM>. The cryptographic permutation unit <NUM> is able to read and/or write data to both sets of registers <NUM>, <NUM>. Likewise, the processing unit <NUM> is also communicatively coupled to the cryptographic registers and is able to read and/or write data to registers within the first and second sets <NUM>, <NUM>. The first and second sets of registers <NUM>, <NUM> thus provide an interface between the processing unit <NUM> and the cryptographic permutation unit <NUM>.

According to the invention, the cryptographic registers of the processor interface <NUM> are memory mapped to the address space of the processing unit <NUM>. This may be achieved either directly, e.g. via a bus of the processing unit <NUM>, and/or via a Memory Management Unit (MMU). Different cryptographic registers may be accessed in different manners if desired. If a given cryptographic register is memory-mapped, then a read or write to a specific address in memory by the processing unit <NUM> may be mapped to a read or write to the given cryptographic register (or a portion of said register). In a Reduced Instruction Set Computing (RISC) Instruction Set Architecture (ISA), such as RISC-V, the cryptographic registers of the processor interface <NUM> may be implemented as one or more Control and Status Registers (CSRs) and/or one or more vector extensions, e.g. in the latter case, a cryptographic register may be viewed as one or more vector registers.

In certain examples, the processor interface <NUM> may be implemented using one or more auxiliary processor interface mechanisms such as processor interrupts, Direct Memory Access (DMA), and ISA Extensions. For example, the processor interface <NUM> may enable the cryptographic permutation unit <NUM> to invoke interrupts on the processing unit <NUM> and/or perform DMA operations on a bus associated with the processing unit <NUM> (e.g. a bus of the processing unit <NUM> or a bus the processing unit <NUM> is coupled to). Alternatively, or additionally, control interactions performed by way of the processor interface <NUM> may be implemented as an Instruction Set Architecture extension.

In certain examples, a command to perform a specific cryptographic permutation operation may be encoded as a single machine code instruction, e.g. a single instruction executed by the processing unit <NUM> acts to perform the cryptographic permutation. For example, the single machine code instruction may, by way of the processor interface <NUM>, activate the cryptographic permutation unit <NUM>, which performs the permutation and returns the result to the processing unit <NUM> by way of the processor interface <NUM>. In one case, the cryptographic permutation unit <NUM> may set a control flag within the second set of control registers <NUM>, which may be checked by the processing unit <NUM> to determine when the cryptographic permutation is complete, at which point the result of the cryptographic permutation may be read by the processing unit <NUM> from the first set of data registers <NUM>. In one case, the cryptographic permutation unit <NUM> may trigger, via the processor interface <NUM>, an interrupt that is received by the processing unit <NUM> to indicate that the cryptographic permutation is complete. On receipt of the interrupt, the processing unit <NUM> may again access a result of the cryptographic permutation from the first set of data registers <NUM>. Implementing control interactions of the processor interface <NUM> using an ISA Extension may provide one way of allowing the cryptographic permutation to be encoded as a single machine code instruction for the processing unit <NUM>.

In certain examples, the cryptographic permutation unit <NUM> performs a cryptographic permutation on data stored within at least one of the cryptographic registers, e.g. one of the first set of data registers <NUM>. In one case, the cryptographic permutation unit <NUM> performs a cryptographic permutation in accordance with control data stored within the second set of control registers <NUM>. The cryptographic permutation may involve one or more operations that are performed on a cryptographic state. This cryptographic state may comprise a collection of bits, e.g. a sequence of <NUM>, <NUM> or <NUM> binary values. The cryptographic permutation may be used to update the cryptographic state. The updating of the cryptographic state may then provide a framework for a variety of cryptographic functions, such as hashes, encryption and decryption functions and number generators. In a case where the cryptographic permutation is performed on a set of bits of size b (e.g. <NUM>, <NUM> or <NUM>), then the processor interface <NUM> may comprise a plurality of cryptographic registers that are b bits in length. In certain cases, data may be loaded in and out of the cryptographic registers in words of length w (e.g. where w < b), where w may correspond to a word size of the processing unit <NUM>.

In one case, the cryptographic permutation unit <NUM> implements cryptographic permutation that provides a "random-like function" on a block of data. The cryptographic permutation may be performed for a plurality of "rounds", where each round or a set of rounds also constitutes a cryptographic permutation. The cryptographic permutation may be a keyless permutation, e.g. may not involve a cryptographic key. For example, the cryptographic permutation may be distinct from a block cipher in that it is not controlled by an explicit secret encryption key (although a part of a permutation state may be designated as secret "capacity"). Also, there is rarely a need to compute the inverse of the permutation, unlike with block ciphers. Each round may be similar to other rounds. In certain cases, rounds may be differentiated via the use of a round constant and/or domain separator parameters. A round constant may be a plurality of bits that varies in value across a plurality of rounds. The use of a varying round constant may help to cryptographically "separate" rounds. Domain separation parameters may also comprise a plurality of bits and may be used in a similar manner to the round constants to separate different domains of use (e.g. encryption vs decryption or hashing vs random number generation). Round constants may be used together with, or independently from, separation parameters. Further details of an example cryptographic permutation are described in <CIT>, which is incorporated by reference herein.

The cryptographic permutation unit <NUM> may be configured to perform many different cryptographic permutations. For example, a set of FPGAs may be programmed for a particular use case, and/or the cryptographic permutation may be defined within updatable firmware. As one example, the cryptographic permutation unit <NUM> may be configured to perform a KECCAK-p permutation, e.g. as described in the Federal Information Processing Standards (FIPS) <NUM> (or Secure Hash Algorithm <NUM> - "SHA-<NUM>" - standard) - "SHA-<NUM> Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB <NUM>, National Institute of Standards and Technology (NIST), August <NUM>, which is incorporated herein by reference. As described in Section <NUM> of the FIPS <NUM> standard, each round of a cryptographic permutation may comprise a composition of five individual (permutation) steps: theta: θ(A), rho: ρ(A), pi: π(A), chi: χ(A), and iota <IMG>(A, ir). The last step takes in round-constant parameter ir. The composite round function in this standard may thus be defined as: <MAT> In this example, the cryptographic permutation unit <NUM> may be configured to perform this composite round function - Rnd, e.g. either for one round or for a plurality of rounds. When the size of permutation input A is <NUM> bits, a composition of twenty-four of these round functions (with specific round constants ir) constitutes KECCAK-p[<NUM>, <NUM>]. This then provides a basic building block of SHA-<NUM> / SHAKE hash functions as described in the FIPS <NUM> standard. It also provides a basic building block for many other derivative primitives. Beyond KECCAK-p, other examples of cryptographic permutations include the <NUM>-bit permutation of ASCON, described by Christoph Dobraunig, Maria Eichlseder, Florian Mendel and Martin Schläffer, in "Ascon v1. <NUM>" Proposal to NIST LWC standardization effort, March <NUM> and the <NUM>-bit SNEIK permutation, described by Markku-Juhani O. Saarinen in "SNEIKEN and SNEIKHA: The SNEIK Family of Lightweight Cryptographic Algorithms", Proposal to NIST LWC standardization effort, March <NUM>, both of which are incorporated by reference herein.

<FIG> shows one example of a set of cryptographic registers <NUM> that may form part of the processor interface <NUM>. In this example, the set of cryptographic registers <NUM> form part of the first set of data registers <NUM> shown in <FIG>, but in other cases may form part of a single common set of data and control registers. In <FIG>, the set of cryptographic registers <NUM> comprise a permutation state register <NUM> to store a permutation state (S); a permutation input register <NUM> to store permutation input data (X); and a permutation output register <NUM> to store output data (O). These registers may all be b bits in length (or capable of storing b bits). In this example, the permutation input register <NUM> is writable by the processing unit <NUM> and the permutation output register <NUM> is readable by the processing unit <NUM>. The processing unit <NUM> may thus instruct the loading of data for the cryptographic permutation into the permutation input register <NUM> and also instruct the loading of data resulting from the cryptographic permutation from the permutation output register <NUM>.

In <FIG>, the cryptographic permutation unit <NUM> is able to read data from, and write data to, the permutation state register <NUM>. For example, the cryptographic permutation unit <NUM> may read a current permutation state value (e.g. of b bits) from the permutation state register <NUM> prior to a cryptographic permutation and then write an updated permutation state value (e.g. following the cryptographic permutation of the state) back to the permutation state register <NUM>. In other cases, the input and output state values may be read from and written to different registers. The permutation state register <NUM> may not be visible to (e.g. readable or writable by) the processing unit <NUM>. If the permutation state register <NUM> is not visible, this may increase security (as the state cannot be directly manipulated by the processing unit <NUM>) and encapsulate functionality in a manner that simplifies application of the cryptographic permutation (e.g. the manufacturer of the processing unit <NUM> need not know how the permutation is performed on the state).

In <FIG>, the cryptographic permutation unit <NUM> is able to read data from the permutation input register <NUM>. The data read from the permutation input register <NUM> may be combined with the permutation state read from the permutation state register <NUM>. In one case, data from the permutation input register <NUM> may be combined with the permutation state read from the permutation state register <NUM> using an XOR operation. The cryptographic permutation unit <NUM> may perform the cryptographic permutation on a result of the combination. In <FIG>, the cryptographic permutation unit <NUM> is able to write data to the permutation output register <NUM>. This data may comprise an output of the cryptographic permutation, e.g. as performed as described above.

<FIG> shows another example of a set of cryptographic registers <NUM>. The example of <FIG> extends the example of <FIG>, e.g. may be provided where more functionality is desired. The set of cryptographic registers <NUM> includes the permutation state register <NUM>, the permutation input register <NUM> and the permutation output register <NUM> (S, X and O respectively). These may operate in a similar manner to the example of <FIG>.

In <FIG>, the set of cryptographic registers <NUM> also includes a mask input register <NUM> to store an input mask (M) and a combination output register <NUM> to store a result (Y) of combining data in the permutation state register <NUM> and data in the permutation input register <NUM>. In one case, the combination output register <NUM> comprises an XOR output register, e.g. where the combination is an XOR operation. In <FIG>, the mask input register <NUM> is writable by the processing unit <NUM> and the combination output register <NUM> is readable by the processing unit <NUM>. The cryptographic permutation unit <NUM> is able to read data from the mask input register <NUM> and to use this data to perform a masking operation, e.g. as part of, or prior to, the cryptographic permutation. The cryptographic permutation unit <NUM> is also able to write an output of the combination to the combination output register <NUM>; the processing unit <NUM> may then read the output of the combination from the combination output register <NUM>, e.g. the processing unit <NUM> may use the output of the combination as well as the permutation output register <NUM> in a higher level cryptographic operation.

In one example, a cryptographic architecture <NUM>, e.g. with components as set out in one or more of <FIG>, further comprises circuitry to apply an input XOR operation. For example, this circuitry may receive data derived from the permutation input data from the permutation input register <NUM> and data derived from the permutation state from the permutation state register <NUM> and apply the input XOR operation to this data.

In one case, the circuitry may apply the input XOR operation to the permutation input data and the permutation state and a result of the input XOR operation may be written to the combination output register <NUM>. In another case, the circuitry may apply the input XOR operation to the permutation input data and a modified version of the permutation state; in this case, the circuitry to apply an input XOR operation may be communicatively coupled to, or form part of, the cryptographic permutation unit <NUM>. In this latter case, the circuitry may provide the result of the input XOR operation to the cryptographic permutation unit <NUM>, such that the cryptographic permutation may be performed on this result. In certain examples, two sets of circuitry may be used to provide each use case.

In one example, a cryptographic architecture <NUM>, e.g. with components as set out in one or more of <FIG>, further comprises permutation masking circuitry to apply a masking operation to the permutation state, e.g. as read from the permutation state register <NUM>. This may be one implementation of the above described circuitry to apply an XOR operation. The permutation masking circuitry may be communicatively coupled to the mask input register <NUM> and the permutation state register <NUM>. The masking operation may apply a mask from the mask input register <NUM> to the permutation state. In one case, the mask may be applied using an AND operation.

<FIG> shows an example implementation <NUM> of the circuitry described above. In the example of <FIG>, the circuitry is implemented as part of the cryptographic permutation unit <NUM>; in other examples, the circuitry may be implemented outside of the cryptographic permutation unit <NUM>, e.g. between the data registers <NUM> and the cryptographic permutation unit <NUM>. Similar functionality and connectivity applies in both cases. <FIG> shows the permutation state register <NUM>-A, the permutation input register <NUM>, and the mask input register <NUM> communicatively coupled as inputs to the cryptographic permutation unit <NUM>. In this example, the cryptographic permutation unit <NUM> also outputs data to the permutation state register <NUM>-B, the permutation output register <NUM> and the combination output register <NUM>. The permutation state register is shown dashed as component <NUM>-B, as this may be the same component as <NUM>-A, however, it is easier to understand the operation of the cryptographic permutation unit <NUM> by denoting these separately. For example, in one case, the cryptographic permutation unit <NUM> may output an updated permutation state that may be written to the permutation state register, effectively overwriting the previous permutation state that is accessed as the input. In other cases, different registers or different portions of a common register may alternatively be used to store an input and output permutation state.

The cryptographic permutation unit <NUM> comprises first XOR circuitry <NUM>, AND circuitry <NUM>, second XOR circuitry <NUM> and permutation circuitry <NUM>. The first XOR circuitry <NUM> may implement one case of the circuitry to apply an input XOR operation as described above; the AND circuitry <NUM> may implement the permutation masking circuitry as described above; and the second XOR circuitry <NUM> may implement the input application circuitry (or the other case of the circuitry to apply an input XOR operation) as described above. In <FIG>, black circles illustrate a communicative coupling; crossing of connections without a black circle are not communicatively coupled. In <FIG>, the first XOR circuitry <NUM> is communicatively coupled to the permutation state register <NUM>-A and the permutation input register <NUM>. The first XOR circuitry <NUM> applies a logical XOR operation and provides the output to the combination output register <NUM>. The AND circuitry <NUM> applies a logical AND operation to data read from the mask input register <NUM> (i.e. a mask) and data read from the permutation state register <NUM>-A (i.e. the permutation state). The AND circuitry <NUM> is communicatively coupled to the second XOR circuitry <NUM>. The second XOR circuitry <NUM> applies a logical XOR operation to data read from the permutation input register <NUM> (e.g. an XOR input) and the output of the AND circuitry <NUM> (e.g. a modified or masked permutation state). The second XOR circuitry <NUM> is communicatively coupled to the permutation circuitry <NUM>. The permutation circuitry <NUM> is configured to apply the cryptographic permutation to the output of the second XOR circuitry <NUM> and to supply the result of the cryptographic permutation to the permutation state register <NUM>-B and the permutation output register <NUM>. The processing unit <NUM> may read the result of the cryptographic permutation from the permutation output register <NUM>. The permutation state originally stored in the permutation state register <NUM>-A may be overwritten by the result (e.g. permutation state register <NUM>-B may be the same register storing a different value S' at a different point in time). In one case, the result of the cryptographic permutation may be copied to each of the permutation state register <NUM>-A and the permutation output register <NUM>.

The example implementation <NUM> of <FIG> performs a number of operations that may be described using a vector notation. For example, the data within the permutation state register <NUM> at a start of a cryptographic permutation may be referred to as a vector S - a start state. The data within the permutation state register <NUM> following a cryptographic permutation may be referred to as a vector S' - an updated state. The state may have b bits as described above. The data within the permutation input register <NUM> may be referred to as a vector X and the data within the mask input register <NUM> may be referred to as a vector M. The logical AND and XOR operations may operate on vectors of b bits (e.g. having a width equal to the whole width of the permutation state). This may allow for rapid computation, as the state need not be decomposed into sub-vectors in order to perform the cryptographic permutation. If the size of each register (e.g. the available memory) is greater than b (e.g. selected as a value that covers a large family of cryptographic operations), then a subset of b bits (e.g. the first or last b bits) may be accessed in any one particular operation. Each vector of b bits may be a sequence of bits each having a value of <NUM> or <NUM>.

Given the notation described above, the operation of the cryptographic permutation unit <NUM> in <FIG> may be summarised as: <MAT> <MAT> Hence, in an update operation, S = S'. In other words, the permutation state S is first XORed with input X and the output is written to Y. In this example, the permutation state S is also masked with M, and the result is also XORed with input X and subjected to cryptographic permutation Perm(). The resulting new permutation state S' is written to the permutation output O. For the next operation, the permutation state S is set as S = S'.

In certain examples, the permutation state may be internally divided into a plurality of portions. These portions may comprise a predefined number of bits. In one case, the permutation state is divided into a "secret" set of c-bits known as the "capacity" and a "public" set of r-bits known as the "rate", wherein b = r + c. During cryptographic operations, the processing unit <NUM> may only access (e.g. interact with) the "rate" bits. For example, only the "rate" bits may be read and/or written to leaving the capacity bits untouched. The values of b, r and c may affect mask selection during encryption and decryption operations, and may be configured according to implementation specifications. The "capacity" bits may be associated with a scheme security while the "rate" bits may be associated with a speed of processing. For example, making c larger may increase the security of the scheme, while making r smaller may increase a speed of processing.

The processing unit <NUM> may use the cryptographic architecture <NUM> in a number of different ways. In one case, the processing unit <NUM> may use the cryptographic architecture <NUM> to perform one or more of the following cryptographic operations: an "absorb" cryptographic operation to mix input data with a permutation state; a "squeeze" cryptographic operation to obtain an output using the permutation state; an "encrypt" cryptographic operation to encrypt input data using the permutation state; and a "decrypt" cryptographic operation to decrypt input data using the permutation state. The "absorb" and "squeeze" operations may be used, for example, for cryptographic hashing. The "encrypt" and "decrypt" operations may be used, for example, for the construction of authenticated encryption and decryption modes. Examples of these cryptographic operations, and how they may use the cryptographic architecture <NUM> are set out below.

In an "absorb" operation input data is mixed with the permutation state. The input data may comprise data from the permutation input register <NUM>. An absorb operation may be used to initialize the permutation state or to operate the permutation directly. The absorb operation may follow the operation of the cryptographic permutation unit <NUM> described above with reference to <FIG>: <MAT> <MAT> In this example operation, the permutation state S is first masked with the mask input M (e.g. the contents of the mask input register <NUM>). Then an XOR operation is performed between the result and the permutation input X (e.g. the contents of the permutation input register <NUM>). This forms the input to the cryptographic permutation. The output is written back to permutation state register <NUM>. In one case, the Perm( ) function may comprise the KECCAK-p Rnd operation performed as an atomic operation. In this case, multiple iterations of the KECCAK-p Rnd operation may be performed as part of the cryptographic permutation, where the permutation is performed as a discrete single operation by the cryptographic permutation unit <NUM>.

In one operational case, the mask input M may be set to zero, i.e. M = <NUM>b (a vector of "b" zero bits), which results in the operation: <MAT> This may be used to initialize the system or set secret keys, amongst other functions. In another operational case, the mask input M may be set to one, i.e. M = <NUM>b (a vector of "b" one bits), which results in a "sponge" absorb operation: <MAT> By configuring the bits of the mask input M, different overwrite combinations may be enacted. This may also be used to construct secure hashes.

In a "squeeze" operation, output may be extracted from the permutation state. For example, if the input permutation state is S and the output permutation state is S' then: <MAT> <MAT> In the "squeeze" operation, the permutation state S is directly subjected to the cryptographic permutation and the result is written back to permutation state register <NUM>, which now has the new value S'. The output may also be written to O, where it can be read from by the processing unit <NUM>. In a hashing operation, a portion of the output O comprising the r "rate" bits may be used by the processing unit <NUM> as a hash operation output. It may also be seen how a "squeeze" operation is equivalent to an "absorb" with M = <NUM>b and X = <NUM>b.

An "encrypt" operation may be seen as an "absorb", with X representing the data to encrypt (i.e. plaintext data) as written to the permutation input register <NUM> by the processing unit <NUM> and the output state O being copied to the permutation output register <NUM> after the operation, where the "ciphertext" is read from the permutation output register <NUM> by the processing unit <NUM>: <MAT> <MAT> In this operation, M may be set to M = <NUM>b, X has the role of plaintext and O represents ciphertext. Again, only part of X and O, e.g. the r "rate" bits may be read and/or used by the processing unit <NUM>. The c "capacity" may be ignored by the processing unit <NUM>.

A "decrypt" operation may be seen as the inverse of an "encrypt" operation. In this case, X (e.g. the contents of the permutation input register <NUM>) may be seen as ciphertext and Y forms the decrypted plaintext (e.g. as read from the combination output register <NUM>). In this case: <MAT> <MAT> <MAT> If, for example, the r "rate" bits are taken as a left-hand-side portion of a permutation state S, with the c "capacity" bits taken as a right-hand-side portion of the permutation state S, then M may be set as M=<NUM>r<NUM>c. In this case, the ciphertext X is overwritten using the permutation state S, as the left r bits of X are assumed to be zeros. The corresponding plaintext may be read by the processing unit <NUM> by taking the right r bits of Y.

In the examples described herein, the cryptographic registers may be arranged in w-bit words, where the size of w is determined by the architecture of the processing unit <NUM>. For example, w may be <NUM> for systems with a <NUM>-bit datapath or w=<NUM> for systems with a <NUM>-bit datapath. If an input and output of the cryptographic permutation is b bits (e.g. for KECCAK-p and SHA-<NUM>, b=<NUM>), then the processing unit <NUM> may access the registers as a set of n=b/w words. For example, the permutation state S', e.g. as copied to the permutation output register <NUM> may be accessed as <NUM> words on a <NUM>-bit system. However, the cryptographic architecture <NUM> is configured so that the contents of the full registers may be accessed in a single cycle by the cryptographic permutation unit <NUM>. This arrangement may greatly speed up data processing. For example, the data registers <NUM>, including those shown in <FIG>, may each be b bits in size (or able to store b bits).

<FIG> shows another example of a set of cryptographic registers <NUM>. In this example, a set of control registers <NUM> are shown. These may be provided as well as the data registers <NUM> shown in one of <FIG>. <FIG> shows an example with seven control registers <NUM>; different examples and implementations may use different numbers of control registers, or a single register divided into portions, depending on requirements. In <FIG>, the control registers <NUM> comprise: an identifier (ID) register <NUM>; a start (GO) register <NUM>; a ready (RDY) register <NUM>; a set of round registers <NUM>, <NUM>, <NUM>; and an interrupt (IRQ) control register <NUM>.

The identifier register <NUM> is writable by the processing unit <NUM> and stores an identifier of a cryptographic operation to be performed. For example, the identifier register <NUM> may store one or more domain separator parameters as described above. The value of the identifier may be used to configure the cryptographic permutation according to a particular cryptographic operation, e.g. by ensuring that different values written to identifier register <NUM> produce different outputs, e.g. as read from the permutation output register <NUM>.

The start register <NUM> is writable by the processing unit <NUM> and stores a start (or restart) flag for a cryptographic operation. For example, the start register <NUM> may store a binary flag having values of <NUM> and <NUM>, wherein a value of <NUM> indicates that the cryptographic permutation unit <NUM> is to start a cryptographic operation (e.g. by performing a cryptographic permutation as described above). The start register <NUM> may be <NUM> by default and may be written to by the processing unit <NUM> (e.g. set to <NUM>) to instruct the cryptographic architecture <NUM> (and/or cryptographic permutation unit <NUM>) to perform a cryptographic operation on behalf on the processing unit <NUM>.

The ready register <NUM> is readable by the processing unit <NUM> and stores a ready flag indicating that the cryptographic architecture <NUM> (and/or cryptographic permutation unit <NUM>) is ready to start another cryptographic operation and/or that a result of a cryptographic permutation is ready to be read by the processing unit <NUM>. This, like the start flag, may be a binary flag where <NUM> indicates that the cryptographic architecture <NUM> is not ready (e.g. is in use or is busy) and where <NUM> indicates that the cryptographic architecture <NUM> is ready to start a cryptographic operation. The ready register <NUM> may be useful in computing devices with multiple processing units (e.g. multicore processors or microprocessors), where each of the multiple processing units may have access to the cryptographic architecture <NUM>, e.g. where they each are communicatively coupled to the processor interface <NUM>. This may be the case where the processor interface <NUM> is coupled to a systems bus that also couples the multiple processing units. In a case where the ready register <NUM> is used to indicate that a result of a cryptographic operation is ready for reading from the data registers <NUM>, a value of <NUM> may indicate to the processing unit <NUM> that a result of a cryptographic permutation is available from the permutation output register <NUM> and a value of <NUM> may indicate that an operation is still in progress.

The set of round registers <NUM>, <NUM>, <NUM> are writable by the processing unit <NUM> and store one or more flags relating to rounds of cryptographic permutation. In <FIG>, there are three round registers: a begin (BEG) round register <NUM>, an end (END) round register <NUM> and a round data (RND) register <NUM>. The begin round register <NUM> and the end round register <NUM> are writable by the processing unit <NUM> to respectively store a start round (a first round to be processed) and an end round (a last round to be processed). The start and end round may be indicated with integer values. The round data register <NUM> may or may not be writable or accessible by the processing unit <NUM>. In a case, where the round data register <NUM> stores a round count to keep track of a current round (e.g. as an integer value) then the round data register <NUM> may not be accessible by the processing unit <NUM>. In another case, the round data register <NUM> may store a round constant indicating a number of rounds to perform. Different implementations are possible depending on requirements.

The interrupt control register <NUM> is writable by the processing unit <NUM> and stores a flag indicating whether interrupts are enabled or disabled. For example, the interrupt control register <NUM> may store a binary flag where <NUM> indicates that interrupts are disabled and <NUM> indicates that interrupts are enabled. Interrupts, in this example, refer to interrupts for the processing unit <NUM> that interrupt a series of instructions being executed by the processing unit <NUM>. If interrupts are enabled, they may be used to indicate that a cryptographic operation (including a cryptographic permutation) is complete and/or that the cryptographic architecture <NUM> is ready to process input (e.g. if it has been in use by another processing unit). The processing unit <NUM> may set whether interrupts are used based on a current device configuration and/or for a particular cryptographic operation. If interrupts are not used (e.g. the flag is set to <NUM>), then a processing unit <NUM> may instead poll the ready register <NUM> to determine whether an event has occurred.

The example set of cryptographic registers <NUM> in <FIG> thus enable the processing unit (or multiple processing units) to control the operation of the cryptographic architecture <NUM> and the cryptographic permutation unit <NUM>. Having a unified and common processor interface <NUM> for control and data may help simplify integration of the cryptographic architecture <NUM>. It also enables a single coupling to a larger computing device, e.g. the cryptographic architecture <NUM> may be easily added to a mother or control board for a larger computing device. Although, the set of cryptographic registers <NUM> are shown as separate register in <FIG>, some or all of the contents of these registers may alternatively be grouped as fields in one or more control registers (e.g. the binary flags described above may comprise different bits of an <NUM>-bit register).

<FIG>, <FIG> and <FIG> illustrate certain methods of controlling a cryptographic architecture, such as that shown in <FIG>. The cryptographic architecture may be controlled to perform a cryptographic operation, e.g. at least one processing unit may control the cryptographic architecture via a processor interface. In certain cases, the cryptographic architecture may be used in a manner that facilitates input preparation and to allow output unloading to occur concurrently with permutation computation.

<FIG> shows a method <NUM> of performing a cryptographic operation according to an example. The method <NUM> may be performed by a cryptographic architecture such as the cryptographic architecture <NUM> of <FIG>. In one case, the method <NUM> may be performed by a cryptographic permutation unit within the cryptographic architecture, such as the cryptographic permutation unit <NUM> shown in <FIG>.

The method starts at block <NUM>, which comprises receiving an instruction to perform the cryptographic operation from a processing unit. This may comprise receiving a signal from the processing unit <NUM> via the processor interface <NUM> of <FIG>. In one case, the cryptographic permutation unit <NUM> may monitor the start register <NUM> in <FIG>, and block <NUM> may comprise loading a value from the start register <NUM> and determining whether it indicates a positive start signal (e.g. a value of <NUM>).

At block <NUM>, a permutation state is loaded from one of a set of cryptographic registers. This may comprise the cryptographic permutation unit <NUM> loading data from the permutation state register <NUM> as shown in <FIG>. The permutation state may not be accessible by the processing unit.

At block <NUM>, a cryptographic permutation is performed on data derived from the permutation state. The data may comprise the permutation state itself or, as shown in <FIG>, a number of logic operations may be applied to the permutation state before performing a cryptographic permutation. Block <NUM> may be performed by the cryptographic permutation unit <NUM> of <FIG>, using data stored in the cryptographic registers of the processor interface <NUM>. Block <NUM> may comprise reading data from multiple data registers <NUM> within processor interface <NUM>, such as is shown in <FIG>.

At block <NUM>, the method <NUM> comprises storing an output of the cryptographic permutation in one of the set of cryptographic registers. For example, this may comprise copying the output of the cryptographic permutation to the permutation output register <NUM>. It may also comprise storing the same output in the permutation state register <NUM>. Read/write operations on the data registers <NUM> may be performed by the cryptographic permutation unit <NUM>.

At block <NUM>, the method <NUM> comprises indicating to the processing unit that the permutation is complete. The processing unit is then able to access the output of the cryptographic permutation from the set of cryptographic registers, e.g. via the processor interface <NUM> of <FIG>. In one case, block <NUM> may comprise the cryptographic permutation unit <NUM> sending an interrupt to the processing unit (e.g. if an interrupt more is enabled). Alternatively, or additionally, block <NUM> may comprise writing a flag value to the ready register <NUM> (e.g. a value of <NUM>). The processing unit may read the output of the cryptographic permutation from the set of cryptographic registers, e.g. from permutation output register <NUM>.

In one case, the method may comprise indicating via one of the set of control registers that the cryptographic permutation unit is ready to begin processing. For example, this may be indicated by the ready register <NUM> as shown in <FIG>. In examples, the operation of the processing unit and the cryptographic permutation unit <NUM> may be synchronised based on one or more of an interrupt and a state of one of the set of control registers, e.g. a start of a process flow may be synchronised based on one or more of these.

In one case, the method may comprise loading, by the cryptographic permutation unit, a round count from a round control register, such as the round data register <NUM>. The round count may be used in the in the cryptographic permutation, e.g. as a round constant input. Following the cryptographic permutation, the round count in the round control register may be incremented. The loading, using and incrementing operations may be repeated based on a comparison of the round control register and an end control register, such as the end round register <NUM> in <FIG>.

In one case, the method may comprise loading permutation input data from a permutation input register, such as the permutation input register <NUM>. Mask input data may then be loaded from a mask input register, such as mask input register <NUM>. In this case, performing the cryptographic permutation at block <NUM> may comprise updating, by the cryptographic permutation unit, the permutation state in the permutation register by performing an XOR operation as a function of the permutation input data and a result of an AND operation performed on the mask input data and the permutation state. In this case, block <NUM> may comprise loading the updated permutation state into the permutation state register, e.g. permutation state register <NUM> in <FIG>. For example, this may comprise operations performed by an arrangement as shown in <FIG>.

<FIG> and <FIG> show two example modes of operation <NUM> of a cryptographic module, such as the cryptographic architecture <NUM> of <FIG> (e.g. as implemented by the cryptographic permutation unit <NUM>). The left-hand side <NUM> of <FIG> and <FIG> shows operations that are performed by the cryptographic module, such as the cryptographic permutation unit <NUM> of <FIG>. The right-hand side <NUM> of <FIG> and <FIG> shows corresponding operations that may be performed when executing a controlling program on a processing unit, such as processing unit <NUM> of <FIG>. The two sides of <FIG> and <FIG> show how the operations of the cryptographic module and the processing unit may be synchronised.

The left-hand side operations <NUM> begin when a ready (RDY) flag is set at block <NUM> to indicate that the cryptographic module is ready to perform a cryptographic operation. This may be performed via an interrupt and/or via the cryptographic module setting a ready register (such as ready register <NUM>) to have a particular value (e.g. <NUM>). In certain cases, setting the ready flag to one may also trigger a processing unit interrupt that informs the processing unit that the cryptographic module is ready. In other cases, the processing unit may periodically read the ready register to look for a particular of value (e.g. <NUM>) or a change in value (e.g. from <NUM> to <NUM>). The synchronisation based on the ready flag value is shown via arrow <NUM>, with the interfacing registers, e.g. as provided by the processor interface <NUM>, shown as <NUM>. At block <NUM> in <FIG>, the processing unit receives an interrupt based on the ready flag value (e.g. indicating that the ready flag has a value of <NUM> indicating that the cryptographic module is ready for processing). <FIG> shows a case where interrupts are enabled. <FIG> shows an alternative case where interrupts are not enabled; in <FIG>, at block <NUM>, the processing unit monitors a value of the ready flag (e.g. by periodically polling the ready register) and starts operations when this value is set to <NUM>.

Once the ready flag is set to <NUM>, and the cryptographic module is ready to perform processing at block <NUM>, the cryptographic module proceeds to block <NUM>, where it waits for a start flag to be set indicating a new cryptographic operation is to be performed (e.g. indicated by the start flag set to <NUM>). Block <NUM> may comprise the cryptographic permutation unit <NUM> monitoring a value stored in the start register <NUM> as shown in <FIG>.

While the cryptographic module is waiting for a start signal, the processing unit, following one of block <NUM> in <FIG> (e.g. an interrupt indicating ready =<NUM>) or block <NUM> in <FIG> (e.g. the processing unit reads the value of the ready register <NUM> and determines it is <NUM>), starts processing an old output of the cryptographic module at block <NUM>. For example, when the ready flag is seen to be <NUM>, the processing unit may start a new operation and read the contents of one or more of the permutation output and the combination output. This latter operation may comprise reading values respectively stored in the permutation output register <NUM> and the combination output register <NUM>.

Following block <NUM>, the processing unit performs a check at block <NUM> to determine if there is more data to process. As described in more detail below, for a new cryptographic operation the values read at block <NUM> may be ignored and there will be more data to process. If the processing unit is following up on a previously instructed cryptographic operation, e.g. where a result is now ready, there may not be further data to process. If there is more data to process, then the method proceeds to block <NUM>, where new input values are prepared by the processing unit. This may comprise writing new values for the permutation input (X) and/or the mask input (M) to the permutation input register <NUM> and the mask input register <NUM> respectively. Once the new values are written, the start flag is set to <NUM> to initiate a new cryptographic permutation. Again, the writing of new values and a value of <NUM> to the start register <NUM> may be performed at the same time, e.g. as part of one write cycle. The design of the processor interface <NUM> facilitates this operation.

If the processing unit sets the start flag, e.g. initially at block <NUM>, the cryptographic module proceeds from block <NUM> to block <NUM>. This may be performed in parallel with one or more of blocks <NUM>, <NUM> and <NUM> within the processing unit program flow. At block <NUM>, the cryptographic module performs an initialisation operation. This may comprise an atomic operation, e.g. a number of different events may take place simultaneously as a single operation on at least one clock cycle of the cryptographic module. Block <NUM> may comprise one or more of the following operations: setting the start flag to <NUM> (to indicate processing has started); setting the ready flag to <NUM> (to indicate that the cryptographic module is unable to process further cryptographic requests at this time); setting the permutation output (O) as the current permutation state (S); performing an XOR operation on the permutation input (X) and the permutation state (S) to set the value of the combination output (Y); loading the permutation state (S) as S = ((S AND M) XOR X); and setting a round count flag to a round beginning flag. Hence, block <NUM> may comprise storing a value of <NUM> in the start register <NUM> and the ready register <NUM>; copying the contents of the permutation state register <NUM> to the permutation output register <NUM>; storing the output of the first XOR circuitry <NUM> in the combination output register <NUM>; loading a value of the permutation state into temporary memory as the output of the second XOR circuitry <NUM>; and copying the value of the begin round register <NUM> into the round data register <NUM>. These components of the cryptographic architecture are configured such that the operations of block <NUM> may be performed in parallel. This enables them to be performed as an atomic operation and greatly increases the speed of the cryptographic operation.

Following initialisation at block <NUM>, the cryptographic module performs an iteration (i.e. a round) of a cryptographic permutation at block <NUM>. This may comprise activating the permutation circuitry <NUM> using the value of the initialised permutation state (S) loaded into (temporary memory) at block <NUM>. The permutation circuitry <NUM> may also access a round count or constant stored with the round data register <NUM> (e.g. S = Round(S, RND) - as referenced above when discussing the KECCAK-p implementation). In certain cases, the permutation circuitry <NUM> may also access a domain separation parameter stored in the identifier register <NUM>. The initialised permutation state (S), the round count or constant and the domain separation parameter may be supplied as the input to a permutation round (e.g. S = Round(S, RND, ID)). As part of block <NUM>, the value of the round count may be incremented within the round data register <NUM> (e.g. RND = RND + <NUM>).

At block <NUM>, in the left-hand side processing stream <NUM>, a check is made to determine whether the round count is less than an end round value (e.g. RND < END?). This may comprise comparing integer values in the round data register <NUM> and the end round register <NUM>. If the round count is less than the end round value then block <NUM> may be repeated. If the round count is not less than the end round value (e.g. is now equal to the end round value following the last increment at block <NUM>), then the cryptographic permutation is complete. The method proceeds to block <NUM>, where the ready flag is set to <NUM> indicating that a result of the permutation is ready, and that the cryptographic module is ready to perform a further cryptographic operation. The method then proceeds again to block <NUM>, where the cryptographic module waits for the start flag to be set to <NUM> by the processing unit.

In <FIG>, following the processing of input at block <NUM> the process flow for the processing unit ends at block <NUM>. The processing unit may thus execute different (e.g. unrelated) instructions while waiting for an interrupt to arrive indicating that a result of the cryptographic operation is ready. In this manner, the processing unit may be efficiently utilised. When the cryptographic module performs block <NUM>, e.g. via the cryptographic permutation unit <NUM> storing <NUM> in the ready register <NUM>, then it indicates that a result of the cryptographic operation is ready, and the processing unit starts another process flow at block <NUM>. The processing unit thus processes an output at block <NUM>, which may involve reading the values stored in the permutation output register <NUM> and the combination output register <NUM>. The result in the combination output register <NUM> may have been set by the previous execution of block <NUM> and the result in the permutation output register <NUM> may be stored as part of the iteration at block <NUM> (e.g. O = S' = Perm((S AND M) XOR X)). Once the outputs have been read by the processing unit at block <NUM>, then the check at block <NUM> is performed. If the cryptographic operation is complete (e.g. the result in the permutation output register <NUM> is all that is needed), then the processing unit ends its processing at block <NUM>. If there are additional cryptographic operations to perform, then block <NUM> is performed again and the process repeats. In one case, new values may be written to the permutation input register <NUM> and the mask input register <NUM>, while previous iterations are still being performed at block <NUM>.

<FIG> shows a similar process when interrupts are not enabled or configured. In this case, following block <NUM> the processing unit returns to block <NUM> and waits for a change in the state of the ready flag to indicate that a result of the cryptographic operation is ready. The processing unit need not solely perform block <NUM> but may perform this block intermittently as part of a monitoring or polling process.

Certain examples described herein provide a cryptographic architecture, and methods of operating such an architecture, that efficiently interface a cryptographic permutation unit with a processing unit such as a microprocessor. Certain examples described herein provide cryptographic methods that may be suitable for implementation on low-resource microcontrollers and embedded devices, as well as for implementation for high-speed secure data processing. The described cryptographic architecture is agnostic to the type of processing unit that is used, and a processor interface allows different processing units to be coupled to the cryptographic permutation unit, with options for different control procedures being available through a common set of control registers. The cryptographic architecture may be implemented using memory mapping and/or other approaches, thus providing easy or transparent data access to different types of processing unit. Described approaches may provide a tight coupling of a keyless cryptographic permutation with processor cores either via memory-mapped registers or vector registers and instructions, wherein the processor interface provides a buffer architecture to reduce power consumption and idle cycles.

Certain examples described herein may be implemented as ISA extensions, e.g. to a wide variety of processing units. The examples may directly and/or indirectly support secure implementation of quantum-resistant symmetric and asymmetric cryptography. The processor interface described herein may be controlled via a bus architecture of the processing unit or via other input/output mechanisms. Certain examples may be configured to provide constant time and emission-protected binary arithmetic.

Certain examples described herein may be used to enable efficient hardware and/or software implementations of higher-level algorithms that use the cryptographic permutation as a "building block" higher-level algorithms. Examples of algorithms that may benefit from such an efficient hardware-software co-design include: cryptographic hash functions and message digests (e.g. the previously discussed SHA3 and SHAKE standards, SNEIKHA that forms part of the previously described SNEIK approach and the Ascon-Hash from the previously described ASCON approach); SHA3-derived functions such as Message Authentication Codes (MACs) (e.g. as described by John Kelsey, Shu-Jen Chang and Ray Perlner in "SHA-<NUM> Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash. " NIST Special Publication <NUM>-<NUM>, National Institute of Standards and Technology - NIST, December <NUM>, which is incorporated by reference herein); authenticated encryption with associated data (AEAD) based on a cryptographic permutation (e.g. SNEIKEN and Ascon-AEAD as described in the previously reference SNEIK and ASCON approaches and the KEYAK approach described by Guido Bertoni, Joan Daemen, Seth Hoffert, Michaël Peeters, Gilles Van Assche, and Ronny Van Keer in "CAESAR submission: Keyak v2. " Keccak Team, September <NUM>, which is incorporated by reference herein); PseudoRandom Number Generation (PRNG) and Key Derivation Function (KDF) constructions based on cryptographic permutations; cryptographic modes based on cryptographic primitives such as those described in <NPL> and <NPL>, which are both incorporated by reference herein; traditional public-key cryptographic algorithms such as Rivest-Shamir-Adleman (RSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) that use permutation-based primitives as building blocks (e.g. as described in the FIPS standard <NUM>-<NUM>); and numerous post-quantum public-key cryptographic algorithms that use cryptographic permutations as building blocks (e.g. BIKE, "Classic McEliece", Dilithium, Falcon, FrodoKEM, GeMMS, Kyber, Luov, MQDSS, NewHope, NTRU, NTS-KEM, Picnic, qTESLA, Rounds, Saber, Sphincs+, and ThreeBears - as described in "<NPL>, which is also incorporated by reference herein.

Although certain examples refer to accessing data within a certain register, and reading and/or writing data from such a register, it will be understood that in practice intermediary data storage and/or data structures may be used in certain implementations, and that reference to "data in" may also apply to "data derived from", e.g. data that results from one or more intermediate processes in additional to those described. References to XOR and AND refer to logic operations that respectively perform a logical "exclusive-or" and a logical "and" operation. It shown also be understood that reference to circuitry coupled to certain components may be alternatively implemented as functionality within that component, e.g. whether via executed firmware code and/or dedicated hardware circuity. "Circuitry" as described herein may be implemented in hardware, e.g. using digital logic gates or programmable gates of an FPGA, and/or as computer program code that is loaded from memory and executed by a processor, such as a microprocessor. Certain system components and methods described herein may be implemented by way of computer program code, such as firmware or an instruction set, that is storable on a non-transitory storage medium, such as a read-only updatable firmware memory.

Claim 1:
A cryptographic architecture (<NUM>) comprising:
a processor interface (<NUM>) comprising a set of cryptographic registers (<NUM>, <NUM>), the processor interface (<NUM>) being accessible by at least one processing unit (<NUM>), the at least one processing unit (<NUM>) being separate from the cryptographic architecture (<NUM>); and
a cryptographic permutation unit (<NUM>) comprising circuitry to perform a cryptographic permutation using data stored within the set of cryptographic registers (<NUM>, <NUM>),
wherein the at least one processing unit (<NUM>) instructs the cryptographic permutation and accesses a result of the cryptographic permutation using the processor interface (<NUM>),
wherein the set of cryptographic registers (<NUM>, <NUM>) comprise one or more control registers (<NUM>) and one or more data registers (<NUM>) that are accessible to the at least one processing unit (<NUM>),
wherein the set of cryptographic registers (<NUM>, <NUM>) are memory mapped to the address space of the at least one processing unit (<NUM>),
wherein the cryptographic architecture (<NUM>) is configured to indicate a completion of the cryptographic permutation via one of:
setting a control flag within the control registers (<NUM>); and
triggering an interrupt via the processor interface (<NUM>) for the at least one processing unit (<NUM>).