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 _______________________________________________ Curves mailing list Curves@moderncrypto.org https://moderncrypto.org/mailman/listinfo/curves