Document some side channel stuff in README.md.

README.md

@@ -18,6 +18,59 @@ discouraging you from using it applies to *ring*:
 
 
 
+Side Channels
+-------------
+
+*ring* uses coding patterns that attempt to reduce the risk that the compiler
+will generate machine code that will leak secrets through timing side channels.
+*ring* uses similar mitigations as BoringSSL, but they are not exactly the same,
+they are not used in exactly the same way. BoringSSL seems to have some ways of
+validating that its mitigations work with specific versions of specific C/C++
+compilers. *ring* relies heavily on BoringSSL's testing, but for many reasons,
+that tactic doesn't work well. *ring* needs to develop and deploy new tactics
+for this.
+
+There are some targets where trying to be "constant-time" just isn't going to
+work.
+
+For WebAssembly and WebAssembly-like targets, where there is a JIT, virtual
+machine, or similar intermediary involved, the runtime is likely to undo
+whatever we do to mitigate timing side channels. Even with the introduction of
+blinding, there is a big risk for these targets. WebAssembly itself needs to
+develop solutions for solving these problems.
+
+There are "native" targets that have similar issues. BoringSSL will refuse to
+compile for some of them because of its allowlist of targets. *ring* doesn't
+use that allowlist, and also the allowlist doesn't completely avoid the
+problem.
+
+*ring* doesn't use any randomizing mitigations like blinding.
+
+Over time, as compiler evolved, BoringSSL's mitigations for compiler-introduced
+side channels have had to evolve. What worked years ago with version X of the
+C compiler doesn't necessarily work now with version X+1, or even with the same
+version of the compiler shipped by a different vendor or configured in a
+different way.
+
+Over time *ring* and BoringSSL have diverged in various areas. In some cases
+*ring* was ahead of BoringSSL regarding mitigations for timing side channels
+using our own code. For example, there was a time when we replaced much of the
+ECC code and RSA code that was using variable-length `BIGNUM` arithmetic with
+similar fixed-length bigint arithmetic. However, in the meantime, BoringSSL has
+come up with its own similar but different solution. Accordingly, *ring* should
+probably try to minimize the divergence with BoringSSL here.
+
+Recently, BoringSSL has converted most of its code from C to C++, whereas
+*ring* still uses the C variant of that code. This will naturally make sharing
+code hard unless we also switch to requiring a C++ compiler for *ring*. And of
+course this even further reduces the validity of relying on BoringSSL's
+validation results for *ring*.
+
+Besides all of the above, there are many other things to consider regarding
+timing side channels and other kinds of side channels.
+
+
+
 Documentation
 -------------