[curves] EdDSA specification

[Tim Ruffing]

On Sun, 2016-10-23 at 22:55 +0000, Gregory Maxwell wrote:
> All things equal it's preferable for cryptographic constructs to not
> have surprising features which less cryptographically experienced
> system integrators would not expect.
Indeed. There are a lot of ways to shoot yourself in the foot if you
use crypto -- but we should at least try to avoid them when possible. 

Sure, the malleable variant is a little simpler to implement, but only
a little. The checks really don't add much complexity.

Actually, omitting the checks may be more complex depending on the
application. If the developer wants to compute a hash of some data
structure containing the signature for example (Greg gave two specific
cases), then he can take extra care to handle malleability, e.g., by
first removing the signature from the data structure or by normalizing
the signature. However that adds a lot of complexity and is easy to
miss.

(I didn't read it carefully enough, so I assumed you went for non-
malleability.)


---

On Sat, 2016-10-22 at 09:53 -0400, Trevor Perrin wrote:
> We could add more discussion about const-time implementation though,
> e.g. discuss how to do a const-time "conditional move" of byte
> sequences, and how that could be used here.
I think discussing this case would be a good idea, because it's
required here. You could also refer to
https://cryptocoding.net/index.php/Coding_rules#Avoid_branchings_contro
lled_by_secret_data


Tim