What are Hardware Private Cubic Circuits?

Recently, my first ever paper has been published on the IACR ePrint server: https://eprint.iacr.org/2026/1351. If you’re into hardware side-channel security and know what the d-probing model is, you should probably read the paper. Otherwise, here’s a small intro to what I spent my last ~year working on.

Seemingly secure cryptography, like AES, can fail catastrophically when implemented naively on hardware. Theoretical cryptography usually reasons about adversaries with access to the plaintext and ciphertext, and show that it is somehow difficult to recover the secret key from this information. In hardware security however, an adversary might have physical access to the device (such as a credit card) and is able to obtain measurements of the device while the cryptographic algorithm is running. This additional measurable information, such as power consumption, is not considered by the underlying cryptographic algorithm and can be used to recover the secret key, even when the algorithm is secure.

We call such attacks “side-channel attacks” and the goal is to design circuits in such a way that the additionally measurable information does not give any hints about the secret key. We use the d-probing model to assess the security of a circuit against side-channel attacks, where the parameter d is a positive integer called the “security order”. Making a circuit secure in a higher security order costs more overhead, in terms of area and latency, but we can show that the overhead in the implementation grows only polynomially while the difficulty to recover secret information grows exponentially.

So how do we design such a side-channel secure circuit, such as a secure implementation of AES for instance? One way would be to design the entire circuit “at once” in a side-channel secure manner and prove that it is secure. This is notoriously hard, as these proofs can get really complex really fast. Additionally, even if we manage to prove our design as secure, any change to the implementation, such as changing the key size, or even just applying any optimization to the implementation, invalidates the entire security proof and we have to essentially start from scratch. This means such designs are inherently fragile and prone to errors.

Instead, we use the “PINI” notion to our advantage. A circuit secure in this notion is not only secure against side-channel attacks in the d-probing model, we can also show that composing such circuits to make any larger circuit preserves the security of the circuit. We can therefore create small, elementary circuits secure in such a notion, and then create any complex circuit by just plugging these elementary circuits, called “gadgets” together. This allows us to design the implementation of AES completely separately from the gadgets that we use to implement the design, as we can take an unsecured AES implementation and simply “find and replace” all elementary gates, like AND, XOR, OR, …, by a PINI gadget which implements such a gate in a secure manner. The final circuit is secure by the composability of the underlying gadgets.

This makes the implementation of complex circuits in a side-channel secure manner practical. Optimizations on the algorithm-level can be applied without considering security implementations, and optimizations on the gadget level immediately give improvements in all designs using these gadgets. However, this also means that any overhead in the gadgets themselves is amplified massively when they are duplicated hundreds of times into the unsecure circuit.

We have essentially two costs associated with each gadget: Area and Latency ¹. The area of a circuit is self-explanatory and measures exactly what is says on the tin. The latency is a measure of how many clock cycles it takes to produce a valid result. It turns out it’s trivial to implement the XOR and NOT gates in a secure-manner, but the AND gate is challenging. The best possible 2-input PINI AND gate is implemented with one cycle of latency, which enables us to implement the AES round function with three cycles. However, we know that a 3-input PINI AND gate with one cycle of latency would enable a AES round function with only two cycles of latency, decreasing the latency by 33%.

This brings us finally to the contribution of the paper. A 3-input AND gate with one cycle of latency already exists in the 1-probing model, but not for d > 1, i.e. not for higher security orders. We present “HPCC”, a d-probing PINI gadget with only one cycle of latency that computes a 3-input AND gate and use it to implement the AES S-Box with two cycles of latency. We provide pen-and-paper proofs for the security of the gadget, as well as simulations and experimental analysis that validate the security guarantees of the gadget.

In the table below, we compare HPCC to some other designs. You can see that, for d > 1, there are no designs that also implement the AND gate with a single cycle. For d =1, although some other designs exist, we actually beat the previous lowest area.

There’s an extra neat feature of HPCC, which allows it to compute not just one 3-input AND gate, but actually an arbitrary number of AND gates as long as two of the operands are shared between all the AND gates. The cost of the extra AND gates is far lower than implementing each AND gate by its own gadget. This trick allows us to really optimize the implementation of AES. Additionally, HPCC, like many other AND gate gadgets, is actually capable of multiplying three values from arbitrary finite fields and AND is just represented as the multiplication of two values in F₂.

An implementation of HPCC and application to the AES S-Box is available on GitHub: https://github.com/ChairImpSec/HPCC.

Lastly, I want to sincerely thank Amir Moradi for supervising and helping me so much along the way with this work!