Eric Rescorla <ekr(_at_)networkresonance(_dot_)com> writes:
All popular of digital signature algorithms are subject to a variety of
side channel attacks. The most well-known of these are timing channels
[0], power analysis [2], and cache timing analysis [3]. Most of these
attacks require either physical access to the machine or the ability to
run processes directly on the target machine. Defending against these
attacks is out of scope for DKIM.
However, remote timing analysis (at least on local area networks) is
known to be feasible [1], particularly in server-type platforms where
the attacker can inject traffic which will immediately subject to the
cryptographic operation in question. With enough samples, these
techniques can be used to extract private keys even in the face of
modest amounts of noise in the timing measurements.
The three commonly proposed countermeasures against timing analysis are:
1. To make the operation run in constant time. This turns out in
practice to be rather difficult.
2. To make the time independent of the input data. This can be
difficult but see [1] for more details.
3. To use blinding. This is generally considered the best current
practice countermeasure, and while not proved generally secure is a
countermeasure against known timing attacks. It adds about 2-10% to the
cost of the operation and is implemented in many common cryptographic
libraries. Unfortunately, ECDSA and DSA do not have standard methods
though some defenses may exist. [4]
Note that adding random delays to the operation is only a partial
countermeasure. Because the noise is generally uniformly distributed,
a large enough number of samples can be used to average it out and
extract an accurate timing signal.
I guess it wasn't clear from my text that none of these
countermeasures affect the bits on the wire so there's no
compatibility issue here. They only affect the signer's
implementation. Signers don't HAVE to do them any more
than they HAVE to have a strong RNG. It's just good
security practice.
The only reason to mention this in the DKIM RFC at all is that unlike
(say) S/MIME, the fact that it's done under a server in semi-real-time
means that there's a potential risk.
-Ekr
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html