Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> You may not think hardware support matters, but which is more likely: somebody breaking your private key remotely using a side-channel attack, or a trojan exfiltrating a key?

As a cryptography engineer, this is a good reason to urge Apple, et al. to support Ed25519, not to prioritize P-256.

(Of course, by all means, prioritize P-256 until we can succeed at getting these companies to correct their course on Ed25519 support. But long term? We want Ed25519 to become ubiquitous.)



Maybe it'll happen, but one thing to keep in mind is that canonical EdDSA signatures (i.e. PureEdDSA) require feeding the entire input stream, not simply a hash of the input. That can be problematic or even impossible for hardware tokens, as well as other scenarios--e.g. BearSSL's API has to be substantially refactored to support X.509 EdDSA signatures, a refactor which may never happen. So when devising and/or implementing a protocol one must consciously choose the supplemental HashEdDSA variant, if one even has the choice. But as long as people indulge make-perfect-the-enemy-of-good urges, that's yet one more hurdle many won't overcome. (And hesitancy is actually somewhat understandable in this case as DJB and others explicitly discounted the value or need for secure hardware scenarios; they were explicitly optimizing for the most common scenario in typical FOSS environments where the private key is local in software.)

Perhaps Ed448 might gather more momentum as it wouldn't be a direct replacement for P-256. And usage isn't quite as common so selection of the prehashed variant may be more practical. But it's entirely possible we won't see a shift in hardware support as widespread as RSA -> P-256 until quantum-resistant schemes are settled.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: