Using per-operation randomness is a popular and effective way to protect cryptographic implementations against side-channel attacks, e.g. using Shuffling (randomizing the processing order eg for AES bytes) and Masking (aka blinding).

Now I wondered about where symmetric cryptographic implementations, e.g. a 4-shared masked and shuffled AES implementation, get their randomness from given that "proper" cryptographic randomness strategies would require computing (something like) AES again which gives us a circular dependency (?).

So my question is:
What quality of randomness is needed to secure a proper randomized cryptographic implementation and how is that randomness generated (usually)?

An optional follow-up (if not answered I will simply ask a new question): Does the randomness generator need to have the same level of protection as the main protected implementation (and thus also requires per-run randomness)?


1 Answer 1


What quality of randomness is needed to secure a proper randomized cryptographic implementation?

  1. It is essential that the random source used is unpredictable, including under attack. If it could be predicted, or made predictable (e.g. by pouring some liquefied gaz literally freezing the random source) the countermeasure could be neutralized or even become counterproductive.
  2. It is important that the values produced are at least about uniform and independent. A marked bias could enable an attack. How uniform and independent depends on circumstances and attacker's skill.
  3. It is important that the source is fast, because customers hate to wait, and a lot of randomness is typically used.

How is that randomness generated (usually)?

In modern security devices, by a physical True Random Number Generator complemented by some level of monitoring and/or post-conditioning. For a typical general description of what that hardware does, see e.g. items 151 and 152 in this public Target Of Evaluation. Details are usually secret, because knowing them could help attacks. More generally, resistance to side channels is a hide and seek game, and competitive practitioners of such game don't reveals their hides. I am told that in Common Criteria evaluation schemes, there are points for how tightly the code is kept secret.

  • 1
    $\begingroup$ If the true random number generator is too slow, one has to "stretch" it somehow. A serious way to do this is described in the EuroCrypt'20 paper Side-channel Masking with Pseudo-Random Generator. Real world implementations might be more ad hoc. $\endgroup$
    – j.p.
    Jul 28, 2020 at 6:31

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.