[HN Gopher] An Illustrated Guide to Elliptic Curve Cryptography ...
       ___________________________________________________________________
        
       An Illustrated Guide to Elliptic Curve Cryptography Validation
        
       Author : alanfranz
       Score  : 62 points
       Date   : 2021-11-30 20:45 UTC (2 hours ago)
        
 (HTM) web link (research.nccgroup.com)
 (TXT) w3m dump (research.nccgroup.com)
        
       | dan-robertson wrote:
       | I was worried this would be a silly visualisation where you draw
       | an elliptic curve and talk about tangents, which maybe describes
       | an elliptic curve group, but not the right one, and it doesn't
       | really give any intuition about what ECC is.
       | 
       | But this article is not that at all, and I like that.
        
       | loup-vaillant wrote:
       | Excellent essay, highly recommended.
       | 
       | > _With the popularity of Curve25519 and the desire for
       | cryptographers to design more exotic protocols with it, the
       | cofactor value of 8 resurfaced as a potential source of problems.
       | Ristretto was designed as a solution to the cofactor pitfalls._
       | 
       | I'm a bit two face about this: on the one hand, if you don't want
       | to think and just want a prime order group to work with,
       | Ristretto is a Blessing from the Heavens: fast validation, fast
       | curve operations (thanks to the underlying curve), and no pesky
       | cofactor death trap. Thanks Mike Hamburg, may you live long and
       | happy.
       | 
       | On the other hand, if we know our way around cyclic groups1,
       | there are almost always very simple (implementation-wise) ways to
       | deal with the cofactor, which lessens the need for Ristretto on
       | carefully crafted protocols--though Ristretto would still
       | simplify those protocols, making them easier to audit.
       | 
       | [1]: https://loup-vaillant.fr/tutorials/cofactor
       | 
       | > _Recently, we also uncovered a critical vulnerability in a
       | number of open-source ECDSA libraries, in which the verification
       | function failed to check that the signature was non-zero,
       | allowing attackers to forge signatures on arbitrary messages_
       | 
       | Oh. That explains a lot.
       | 
       | See, I made _one_ significant mistake in all my time as a
       | cryptographic implementer2. The effect was, all-zero signatures
       | were accepted half the time, with any public key. Sounds
       | familiar?
       | 
       | In any case, some people were quick to assume I was a drooling
       | incompetent for failing to perform such a basic check as
       | rejecting the all-zero signature. If I was implementing ECDSA,
       | they'd have been right. Except I was implementing _EdDSA_ , which
       | _already_ rejects all-zero signatures with its main algorithm. An
       | explicit all-zero check is not needed at all. DJB himself for
       | instance omits it in TweetNaCl. My bug was more subtle: I didn't
       | failed to check a standard edge case any decent specification
       | would mention. I _introduced_ an edge case by doing a less-than-
       | safe conversion with a less-than-perfect understanding of the
       | maths involved.
       | 
       |  _(To those who wonder why I even tried, I asked around before
       | attempting this, and no one warned me. And to those who are
       | wondering why I didn't use Whycheproof right away, that's because
       | I thought it didn't support EdDSA: to this day, its front page
       | lists neither EdDSA nor Ed251519, despite my pull request from
       | nearly 2 years ago.3 If someone from Google hears this,
       | please...)_
       | 
       | In any case, I now understand the mockery better. Those people
       | likely pattern matched my vulnerability with the corresponding
       | ECDSA beginner error, and shot me down without checking what was
       | actually going on. I guess they too were busy.
       | 
       | [2]: https://monocypher.org/quality-assurance/disclosures
       | 
       | [3]: https://github.com/google/wycheproof/pull/79
        
       | throwaway81523 wrote:
       | It is very easy to make mistakes in ECC implementation. If you
       | really want to code it yourself, there's a book by Menezes,
       | Vanstone et al ("Guide to Elliptic Curve Cryptography, I think)
       | that gives very explicit instructions about how to do everything.
       | I used to hack on a P256 implementation. But, it is a bit out of
       | date by now, and IIRC it doesn't say anything about Curve25519.
        
       ___________________________________________________________________
       (page generated 2021-11-30 23:00 UTC)