2

I learned that some AES implementations are vulnerable to side-channel attacks due to how the SBOX structure is implemented. The output have to be nonlinear, therefore having low bit inputs results in high bit outputs, which can be seen on the oscilloscope and differentiated from the noise. How do Serpent implementations compare in regards to side-channel resistance? Is it easier to implement a side-channel resistant Serpent implementation than an AES implementation?

4
  • Low bit=Low hamming weight? Where did you read it? Reference and more details please.
    – kodlu
    Commented May 30 at 22:48
  • doesnt matter if high or low, the inputs to SBOX strongly differ from the outputs in terms of hamming weight, which helps with linearity but makes it visible on the scope
    – moju22
    Commented May 30 at 23:04
  • 5
    Ciphers are not vulnerable to side channel attacks; cipher implementations are. At best, you can say that "this particular cipher makes it easy/difficult to have a side channel resistant implementation" (and, of course, you would need to specify the type of side channel - there are several). Hence, your question might be better asked as "does Serpent lend itself to a side channel resistant implementation better than AES does?"
    – poncho
    Commented May 31 at 2:17
  • you are right @poncho , Im asking about implementation attacks, not cryptanalysis
    – moju22
    Commented May 31 at 9:35

1 Answer 1

5

As a rule, ciphers are not vulnerable to side channel attacks but implementations are, as was pointed out in the comments; however, as a someone who does semiconductors first, and then implements ciphers second, I would say that the nuances are in the S-box. I have personally never implemented Serpent, but I have looked extensively at the power requirements of ciphers and cryptographic primitives (AES/Blake2/ec25519) as my interest is passively-powered devices.

The AES S-box is large at 8-bits, and thereby it takes a long time to propagate, and you can see it settle in the current. This is especially common in FPGA implementations where "look up" tables are used because the designers of the HDL (implementation point here) just did logically mappings instead of designing the logic. How I make my S-boxes on AES is through pure logic, that I outline here: https://github.com/bpdegnan/aes/blob/master/aes-sbox/documentation/aessbox.pdf (one day, I'll release the complete circuit description, but that is work).

Serpent has a 4-bit S-boxes, which means it'd likely be more difficult for me to implement a timing or power attack. For this reason, I will say that Serpent is more side-channel robust just to the fact that the S-boxes are smaller, and there will be less power to leak out to tell me information regardless of the implementation. When you "stop the clock" to read the power, you're less likely to be able to see the changes.

Due to the above, if you read any paper in academia that doesn't have the actual implementation netlist of the circuit published somewhere, it's basically not reproducible.

3
  • is there anything else that makes Serpent more robust than just the 4bit SBOXes? are there more side-channel robust symmetric ciphers, which provide similar security level as AES?
    – moju22
    Commented Jun 5 at 16:46
  • @moju22 Regarding Serpent, it would be implementation dependent, but shorter paths create less to measure. Simon/Speck do not have S-Boxes and the current created by those is very small. My measured silicon results for Simon showed nothing above the noise floor created by the two-way shot noise of the device channels.
    – b degnan
    Commented Jun 5 at 20:15
  • you mentioned simon/speck and I researched further on the topic of ARX ciphers, they seem to be constant time therefore timing resistant. I looked further and found the chacha20poly1305, which also uses the same ARX approach, but is even more popular in use. Would it also be "better" than AES implementations when it comes to power analysis?
    – moju22
    Commented Jun 6 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.