This section contains an incomplete list of security considerations.
Random secret inputs: XEdDSA and VXEdDSA signatures are randomized, they are not deterministic in the sense of [1] or [14]. The caller must pass in a new secret and random 64 byte value each time the signing function is called.
Deterministic signatures are designed to prevent reuse of the same nonce r with different messages, as this reveals the private key a. Consider two XEdDSA signatures (R || s_1) and (R || s_2) such that:
s_1 = r + h_1*a (mod q)
s_2 = r + h_2*a (mod q)
The private key a can be calculated as a = (s_1 - s_2)/(h_1 - h_2) (mod q).
A deterministic signing scheme hashes M with a long-term secret to calculate r, instead of taking r from a random number generator. Because M is also hashed to calculate h the probability that different h get the same r is small. However, if the same message is signed repeatedly, a glitch that affects the calculation of h could cause this to happen (an observation due to Benedikt Schmidt). Also, repeated use of the same r might make it easier to recover information about r through side-channel analysis.
So XEdDSA and VXEdDSA preserve the idea of calculating r by hashing a long-term secret key and the message, but add a random value into the calculation for greater resilience.
Constant time. The signing algorithms must not perform different memory accesses or take different amounts of time depending on secret information. This is typically achieved by "constant time" implementations that execute a fixed sequence of instructions and memory accesses, regardless of secret keys or message contents.
Particular care should be taken with the calculate_key_pair function due to its use of conditional branching. The hash_to_point function also uses conditional branching (within elligator2) and should be made constant time, even though it only handles the message, not secret keys.
Key reuse: It is safe to use the same key pair to produce XEdDSA and VXEdDSA signatures.
In theory, under some circumstances it is safe to use a key pair to produce signatures and also use the same key pair within certain Diffie-Hellman based protocols [15]. In practice this is a complicated topic requiring careful analysis, and is outside the scope of the current document.