> (against the designed-for threat model) Yeah, this is the really scary part. It's also the part not amenable proofs. I had to implement some crypto primitiv

> (against the designed-for threat model) Yeah, this is the really scary part. It's also the part not amenable proofs. I had to implement some crypto primitives at one point in my career (for a boring combination of legal and technical reasons). Yes, I was nervous, but you pay attention to details and take careful stock of the tools you available (e.g. what's my environment's constant-time comparison function? what's my CSPRNG?) and it's not really harder in the end than implementing lots of other algorithms, you just feel like it is because the stakes are higher. As mentioned many times in this thread, some of the primitives today are also really hard to mis-implement! But those were also part of a system that had to be secure. That was the terrifying part, because our threat models were relatively unique. But this is also the part that developers do all the time without thinking about it - any time you roll a middleware that looks directly at a JWT, or your own web session bootstrapping, or read a regexp from a user, you're committing the same kind of sin. Having a PhD in lattice reduction on-board for that isn't any help. Having security experts helps a lot for this, but when you have them they're not applying any complex math, they're just exceptionally good at getting into a Red Team mindset. tl;dr: If you're debating implementing your own ed25519, you're probably already way too far down the rabbit hole to instead grab libnacl and claim some pride that you didn't "roll your own crypto"; even if you take libnacl at that point you've already made most of the security decisions that will make or break you.