# Is it possible to identify a Serpent encryption key in memory?

It has been shown that AES keys that are in use can be identified in memory. This identification relies on discovering expected round keys in memory that are contained within the key schedule.

My question is: can we, by extension, assume that the same technique, at least theoretically, can be used to extract Serpent and Twofish keys from memory since they both have a key schedule as well??

• Twofish keys would be much harder to identify – Richie Frame Oct 1 '19 at 5:01
• @RichieFrame Could you please elaborate on that? – learnerX Oct 1 '19 at 17:24

Yes, Serpent also does a deterministic well-known key expansion. So it should be possible to identify the sub keys in memory. You will want to know what implementation you are looking for since there is more than one sensible order for the key material to be in.

Yes, it would be possible to identify Serpent or Twofish keys from round keys in memory, which are likely to exist in a software-only implementation optimized for speed (but not in hypothetical hardware implementations, and not necessarily in implementations optimized for RAM or code size).

The Serpent round keys are 132 words of 32 bits, output by a function of the 256-bit (possibly padded) key. This is implies $$132\times32-256=3968$$ bits of redundancy in the subkeys. In general, the simpler the key expansion function and the more redundancy, the easier it is to identify the redundancy and to recover all keys bits (that have an influence; which is every, in any cipher not deliberately weakened). Essentially we need a fast distinguisher for the output of the function, and then invert it. That function is linear a linear expansion stage followed by S-boxes. It is simple enough to be attackable, but I can't tell at what speed.

That also applies to Twofish. Its key expansion produce S-boxes and round keys (both quite redundant) from separate bits of the main key. We can attack either to identify the expanded key if it is all in a block of memory with fixed layout; but we must distinguish both otherwise, and in any case need to invert both to recover the full key.

• Doesn't serpant apply s boxes on pre key to get round keys making them non linear? – Meir Maor Oct 1 '19 at 5:08
• @Meir Maor: Indeed. Thanks for correcting me. – fgrieu Oct 1 '19 at 5:31
• @fgrieu Thank you. Could expand your answer a bit to include why and how increased redundancy plays a role in identifying the keys? I've only ever seen discussions of treating 256-bits (for 256-bit key size) as master key and the next bytes as expected key schedule derived from this key. If next bytes in memory do actually resemble such expected round keys, then we've found our master key. I've never seen a discussion on redundancy. – learnerX Oct 4 '19 at 2:17