Mastodon Feed
Boosted by soatok@furry.engineer ("Soatok Dreamseeker"):
senil@gts.social.senil.me ("Senil") wrote:
@NohatCoder @soatok Oh yeah, I agree, there aren't many use cases where you'd need that kind of thing. Buuuut it just seems weird to me that, for the rare cases where you'd need one (and the dev is insistent on using Monocypher for... reasons), they refuse to consider implementing a variant that at least ships the absolute basics that tries to remain mostly-compatible - or that they even "consider" that something worth exploring now, two-ish years later, even though their current portable version is still too heavy for the truly low-power devices while still risking not being secured on those architectures.
It seems like they're very aware that some folks do use Monocypher in that way (whether they should or shouldn't on hardware as limited as the Cortex M0's is a different debate, but I do agree that one should really use something much more specific), but also don't want to actually implement it in a way that ensures it'd work securely.
IDK, it just seems weird to me that Loup-Vaillant acknowledges that embedded devices are something some folks try to use this tool for, is open to trying to implement some version of it, but also refuses to do the one thing that would make it marginally more viable (whether it should actually be done or not) in the form of breaking direct API compatibility with the normal versions. Either implementing a more embedded-device-friendly version is on the table, which means breaking existing API compatibility to focus on the lowest common denominator in terms of what preserves constant-time behavior; or it shouldn't be considered, the issue closed, and discouraged from use on certain ISA's.
Just feels like a weird spec choice to have this question in the air.