I should think on the contrary that timing attacks would be almost impossible in managed code, because the jitter due to GC at upredictable times would overwhelm all other considerations. Indeed, timing simple loops in C has become an excellent way of generating entropy quickly, because no two CPUs, however similar otherwise, have exactly the same timing, and the more modern the CPU, the more true this is. See <https://arxiv.org/ftp/arxiv/papers/1810/1810.00567.pdf>.

On Sat, Sep 14, 2019 at 11:59 AM Lassi Kortela <xxxxxx@lassi.io> wrote:

> [Discussion of how to erase secret data in a garbage collected language.]

Another problem that always plagues crypto implementations is timing
attacks. Once again, OpenBSD has timingsafe_memcmp()
<http://man.openbsd.org/timingsafe_memcmp>.

I expect it would be quite difficult to guarantee predictable timing in
Scheme code, especially in portable code. Perhaps so difficult that it'd
be best to write the core transforms in assembler and simply call out to
them using the FFI.

The alternative would be to pick a particular implementation and
religiously read (disassemble my-procedure) output until it looks right,
praying that relevant implementation details don't change...