I trust NaCl and, specifically, DJB-associated implementations thereunto. Lots of people have looked at it. I trust DJB and his cohorts to think about and mitigate footguns as much as practical.
STROBE is right about a year old. Maybe it's awesome, but it almost certainly hasn't been vetted sufficiently.
I seem to recall that most PAKE's relied on one of the nice properties that modular exponentiation has that doesn't work for ECC. IIRC, quite a few of the PAKE's tried to use ECC and fell into the trap and created a breakable PAKE.
The patent situation around PAKE's didn't help. Fortunately, those patents just expired.
> If you’re doing embedded you need a security person around.
Apple couldn't even get it right. They implemented an 3072-bit SRP that takes almost 15-20 seconds on Cortex M0/M3 series processors unless you have an exponentiation accelerator (Cortex-M4).
If Apple can't get it right, what chance do those with far less resource have?
A list like the parent article but tailored to embedded would be quite welcome.
Re: PAKEs: yes, some PAKEs and related protocols are hard to port to ECC. For example, SRP doesn’t port cleanly from FF to an elliptic curve group because it actually needs a field. But I called out SPAKE2 for a reason: porting SPAKE2 to ECC is easy.
RAMBUS got shafted by the DRAM manufacturers, but they pulled a LOT of shady crap of their own and Stanford was in the thick of it.
While I have no belief that Mike Hamburg was ever in the middle of that, I have some concerns about what might or might not be patented once RAMBUS's lawyers get done with it.
We could do an elaborate embedded post but the answers diverge a lot more because constraints are tighter. If you’re doing embedded you need a security person around.
Also I <3 SPAKE2. More than I ought to.