Nah, I'm pretty sure there's exactly as much (assembly) as I'd think because I spent some time prodding it before writing the question in the first place.
You likely understand what it does much better than me, but I'm under no illusion that there's a lot of this code, nor indeed that it's problematic to use this code.
However I'm not at all convinced that porting "hand written assembler to higher level generators" is a good strategy for this specific code. It serves to launder the creativity, so that maybe some day one lawyer can convince another lawyer that A and B are distinct works despite every actual process along the convoluted path from A to B being mechanical... but it doesn't seem like it gets us closer to having a sustainable alternative.
And that's what I actually am interested in here, I think we want a Special Purpose language focused on emitting guaranteed constant time machine code for an algorithm. So that actually gets to the same Readability and Correctness goals you state, but rather than hoping to get away with writing Go (or any GP language) we accept that it's never going to make sense for a General Purpose language to prioritise this. IMO We're more or less guaranteeing one day we accidentally ship an Oracle.
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.
Nah, I'm pretty sure there's exactly as much (assembly) as I'd think because I spent some time prodding it before writing the question in the first place.
You likely understand what it does much better than me, but I'm under no illusion that there's a lot of this code, nor indeed that it's problematic to use this code.
However I'm not at all convinced that porting "hand written assembler to higher level generators" is a good strategy for this specific code. It serves to launder the creativity, so that maybe some day one lawyer can convince another lawyer that A and B are distinct works despite every actual process along the convoluted path from A to B being mechanical... but it doesn't seem like it gets us closer to having a sustainable alternative.
And that's what I actually am interested in here, I think we want a Special Purpose language focused on emitting guaranteed constant time machine code for an algorithm. So that actually gets to the same Readability and Correctness goals you state, but rather than hoping to get away with writing Go (or any GP language) we accept that it's never going to make sense for a General Purpose language to prioritise this. IMO We're more or less guaranteeing one day we accidentally ship an Oracle.