Well, ML-KEM has zero assembly and was written entirely from scratch, for example, so it must be more than you'd think if you think we "reuse the same machine code for this that you'd find in everybody else's implementation." In fact, almost everyone else's was found to be producing a variable-time DIV instruction, while ours was unaffected.
Porting the assembly to higher-level generators has nothing to do with lawyers (??), the goals are stated in https://go.dev/wiki/AssemblyPolicy.
The idea that one day we'll write All Of The Cryptography Code Once And For All In The Perfect Language and reuse that across languages comes up pretty regularly, and has never panned out.
ML-KEM? How did you get from ChaCha20 to ML-KEM? Is it just that you skimmed the original comment and are focused on a different topic altogether? I was trying to understand what constitutes "Soup-to-nuts" here because I think Thomas is putting the distinction in the wrong place.
Still, now we're here:
It's foolish to wait for a "perfect language" but it's not foolish to look for a way to improve the status quo, and I don't buy that just because it so happens it "never panned out" previously that won't ever change.
Which actually gets me back to that DIV instruction. What ensured Go couldn't have this problem? Just luck? The IRA's warning to Thatcher seems very applicable.
Thomas and I are both talking about the Go cryptographic library overall, not about the ChaCha20 implementation in particular. Anyway, I don’t find arguing semantics around the “soup-to-nuts” expression particularly productive.
We avoided the DIV by deliberately not using a modulus operation and doing Barrett reduction instead.
Porting the assembly to higher-level generators has nothing to do with lawyers (??), the goals are stated in https://go.dev/wiki/AssemblyPolicy.
The idea that one day we'll write All Of The Cryptography Code Once And For All In The Perfect Language and reuse that across languages comes up pretty regularly, and has never panned out.