Suppose there's a programming bug that trivially exposes user passwords,
long-term SSL keys, and maybe some RNG state to attackers. Do we respond
to this by dribbling fresh entropy into the RNG?
Arnold Reinhold writes, regarding side-channel attacks:
> The argument seems to be that component A need not be resistant to attack X
> because critical component B is even more susceptible to X than A is. A counter
> position is that we should make component A as resistant to X as it can safely
> be, with reasonable effort, and also try to improve the resistance of component
> B to X.
Let's try this again slowly.
The attacker is stealing your long-term PGP key, your long-term SSH key,
and your long-term SSL key through side-channel attacks. What exactly do
you think you're accomplishing by dribbling fresh entropy into your RNG?
You say that your strategy is
(1) to make the RNG as "resistant" to these attacks as it can "safely
be" and then
(2) to "try" to similarly protect the rest of the system.
You claim that the first step is what's accomplished by the recent
dribbling paper http://eprint.iacr.org/2014/167
The simple fact, however, is that dribbling fresh entropy into an RNG
doesn't make the RNG resistant to side-channel attacks. Proper
side-channel defenses directly and comprehensively address the
problem---they stop the attacker from seeing the secret data in the
first place---whereas dribbling fresh entropy into the RNG does not.
So you're not even following the first step of your own strategy.
Furthermore, proper side-channel defenses also apply to the rest of the
system (and in particular the long-term keys), whereas I have no idea
how you think dribbling fresh entropy into an RNG is a step towards
protecting the rest of the system.