Eric Rescorla <[EMAIL PROTECTED]> 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
