On the Matrix side we’re reading through the paper and seeing if/how it applies to Olm.

Why would you need to read through the paper to see if it applies? Are you deployed in settings where attackers can physically flip bits or not? That question, the only one that matters, is posed essentially in the abstract of the paper.

The article acknowledges RFC6979, which is the standard way to produce a deterministic r that doesn't have this problem intrinsically. It also refs RFC8032, which has EdDSA in it (both variants).

The fault attack acts after that deterministic generation, so tha fact that Olm doesn't reuse r values explicitly doesn't matter. You're not _erroneously_ reusing r: the attack involves you trying to sign the same message twice, with a fault occurring on the second signing.

When signing the same message, all EdDSA implementations are supposed to reuse the same `r`, as per RFC 8032, and thus to produce the same signature under the same key. For smartphone and instant messaging, I wouldn't be worried about fault attacks, there are probably easier ways around it.

It's a fault attack. It doesn't really matter what implementation you use; the attack is an interaction between the hardware (flipping bits in targeted memory at specific points in computation) and the algorithm itself.

You care about these kinds of attacks if you build or rely on a device that uses ECDSA for security and is in the physical custody of adversaries. It's not an attack that is especially relevant for client/server software or cloud cryptography (there are less theatrical ways your cloud provider can destroy your security).

It mostly does not matter for user-level software. Anything capable of creating faults on your system is almost certainly already able to read your private key and send it around.