1. 39
  1.  

  2. 4

    This is fantastic. Crypto can be complicated enough because of important subtle properties that need to be preserved, but I’m a big fan of anything that makes a working implementation mentally tractable.

    Crypto is too important to only be understood by the small group of (understands complicated math) ∩ (understands low level programming). I still want that group verifying, but they can’t add crypto to all the places it should by themselves.

    1. 4

      Excellent. Made me feel like I almost understand crypto primitives.

      1. 2

        I was reading the Elligator paper last night, and it really does look like magic. Lots of algebraic manipulation without much conceptual motivation describing how it was derived.

        1. 10

          Curve25519 and Poly1305 are even worse. The bit clamping masks are presented as foregone conclusions, with no explanation of why they are as they are. I’ve watched a team of outstanding cryptographers spend days reverse engineering what exactly clamping accomplishes in Curve25519. At the end, they came up with something better, Ristretto! Now you have to wonder how quicker that improvement could have come if only Curve25519 was documented.

          1. 1

            Sadly, people learned two different lessons from “you are not expected to understand this.”

        2. 2

          If you find this interesting, you may also find @Loup-Vaillant’s “The Design of Poly1305” a worthwhile read.

          1. 2

            It has always seemed to me that a literate programming(ish) style works very well for crypto, and non-trivial algorithms in general.

            1. 2

              Thanks for sharing, Filippo, and greetings from Kigali! It’s great to see some of the work you’ve been up to since joining the Go team.