yeah, i've been working with these things for a long time

i built a thing in 2023 that uses sha256 and secp256k1 schnorr signatures as the MAC

in my cruddy initial version it could crunch through 8Mb/s/thread which was more than enough for a typical modern CPU to do a fully packed gigabit channel

and the amount of irrational bullshit about secp256k1 yet here we are, 2024, bitcoin still no problem with signatures, schnorr variant rolling out steadily

idk what to say

i routinely use SIMD code for my SHA256 hashing and it's fast as hell, like, more than 4x faster than it was before

i've seen how fast the secp256k1 C library is, and that's not even going SIMD yet, and it totally could, and if i had 3 months to tool up i could build something like this myself (in assembler)

ironically, the math of koblitz curves is actually on par with edwards, but unlike edwards, it's not possible to craft backdoors into the group

i think that BIP340 style EC signatures and SIMD sha256 allows you to do a perfectly adequate, and single-stack of crypto tooling free of legacy bullshit, and that it is very appealing to bitcoiners and nostr users... you can even find some amounts of commentary on nostr out there about fiatjaf's decision to go with the musig2/taproot BIP-340

when it comes to actually working it on hardware, 256 bit pubkeys versus 257 really makes a big difference, it's an alignment problem, you are talking 4 long words versus 5 long words to process the same data

i think this chacha/blake stuff is cool and all but if it's sufficient and bulletproof secure with a single crypto stack then why pollute your code or your memory with this?