5 ms·

I think STROBE is quite a bit smaller than TweetNaCl once deployed, in gates or bytes, both ROM and RAM. More generally, there are lots of off-list recommendati

by lvh 9y ago

I think STROBE is quite a bit smaller than TweetNaCl once deployed, in gates or bytes, both ROM and RAM. More generally, there are lots of off-list recommendations that are still fine. The list doesn’t have AESCBCHMAC anymore but I’m unlikely to tell you Fernet is busted. 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.

bsder 9y ago
The real question is which of these have actually been vetted. 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.
- lvh 9y ago
  My argument was specific to embedded crypto. If I don’t have to care about size constraints then yes, I’m going to make a better-understood recommendation than STROBE. Re “I trust DJB”: if you’re going to trust individual implentors, I suggest that the median cryptographer is going to suggest you can do a lot worse than “literally Mike Hamburg” here. I certainly will. 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.
- tptacek 9y ago
  Why do you trust Bernstein more than you trust Mike Hamburg?
  - bsder 9y ago
    I suspect its lingering litigation distrust of RAMBUS and association with Stanford connections. 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.

by lvh 9y ago

bsder 9y ago

The real question is which of these have actually been vetted. 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.

lvh 9y ago
My argument was specific to embedded crypto. If I don’t have to care about size constraints then yes, I’m going to make a better-understood recommendation than STROBE. Re “I trust DJB”: if you’re going to trust individual implentors, I suggest that the median cryptographer is going to suggest you can do a lot worse than “literally Mike Hamburg” here. I certainly will. 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.
tptacek 9y ago
Why do you trust Bernstein more than you trust Mike Hamburg?
- bsder 9y ago
  I suspect its lingering litigation distrust of RAMBUS and association with Stanford connections. 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.