It's great that people enjoy this-- but I've never seen explanations that centered on the group law as actually being especially useful for building insight pro

It's great that people enjoy this-- but I've never seen explanations that centered on the group law as actually being especially useful for building insight producing understandings complex cryptosystems. I think it's a lot more useful to start from a generic group: e.g. you have some group G generated by g, and a group operator ... plus a way to (de)serialize members, a method to identify the additive identity, maybe a hash function and not much else. From that point you can build a pretty solid understanding of real cryptosystems. Knowledge of how to implement a particular group law is necessary to build one from scratch-- which people should almost never be doing, esp as it requires a serious amount of number theory to do well-- but it doesn't give any real insight into the cryptography, not even any intuition as to why the DL problem in some groups is believed to be hard. I think that understanding ECC starting at group law is kind of like understanding quick sort by studying CMOS logic: you can't implement quicksort in practice without (someone) building some digital logic, but if you're down in the trees it's not particularly easy to see the forest. When I've trained people on the subject I've enjoyed using a sequence that goes like: 1. Generic group, how we can construct efficient 'multiplication' from only addition (I prefer to call the group operator addition, but I talk about both notations and how both are equally valid). General intuition about how algebra essentially JustWorks(tm) in finite fields. 2. CDH and Diffe-hellman, the fact that the hardness of the DL problem (in particular groups) is a strong assumption. 3. Constructing a pedersen commitment using the additive homomorphism 'in the exponent', establishing the security assumption in pedersen commitments that the two generators have an unknown DL between them. 4. Constructing a chameleon hash function-- a trap-door hash function where someone knowing a secret can freely construct collisions at will-- by violating the pedersen security assumption. 5. Constructing a schnorr digital signature by feeding the output of a chameleon hash back into itself, creating an impossible causal loop that can only be resolved using the trapdoor. 6. Extending the causal loop: creating an OR proof (A signature that shows I know at least one of two secrets). [FWIW, we cover 4,5,6 in this paper https://pdfs.semanticscholar.org/4160/470c7f6cf05ffc81a98e8fd67fb0c84836ea.pdf https://pdfs.semanticscholar.org/4160/470c7f6cf05ffc81a98e8f... for the purpose of describing a more efficient than typical OR proof.] 7. From there extending into other more elaborate protocols like range proofs (built from OR proofs of related secrets), private set-intersection (built from polynomial evaluation in-the-exponent), etc. 8. And critically, interesting attacks on these systems, with a particular focus on how fragile they can be: 8a. Linearly related nonce attacks against signatures. (unfortunately, these attacks are easier taught if the signature algorithm is understood as a hidden linear system, then the attack is just a 'as many knows as unknowns attack', but I strongly prefer the causal loop understanding of signatures for the intuition it creates for more complex protocols). 8b. Random-modular-subset sum attacks on naive blind signatures and naive multi-signature. 8c. At least one attack that break the generic group abstraction. I'm fond of invalid key attacks on DH with twist-insecure curves. (This is probably the only example that I think is important to teach that requires some group law understanding). If I do get into group law, I think it's interesting to talk about optimizations. Particularly, projective coordinates, precomputation, addition/subtraction ladders and signed digit representations, doubling sharing for multi-exp. Bos-coster for sum-of-many products is an especially fun and easy algorithm to implement (similar kind of fun as implementing the peeling algorithm for decoding sparse linear codes in F(2)). I'd like to have a 9 on that list that goes into the building blocks of proof techniques for these systems e.g. programmable oracles/forking lemma... but that is enough out of my area of expertise that I don't know how to teach it effectively.