In a more general sense I'd agree, but in this instance, the ML-KEM draft specification (FIPS 203) uses the exact same greek symbols.
This code will be read many more times than it is written, and anyone auditing its correctness will be comparing against the spec.
If the variables are spelt out, then you have to do the mental (or otherwise) translation before you can compare the two, adding overhead. For comparing the symbols visually, you don't even need to know their names.
> For comparing the symbols visually, you don't even need to know their names.
Well, no, this was the main issue with homograph attacks in domain names [1] that brought us to the use of punycode in browsers [2]
In particular for a cryptographic library, I wouldn't want to constantly have to watch out for sneaky malicious variables put in the right place (e.g. try to compare visually the Cyrillic а, с, е, о, р, х, у with the ascii a, c, e, o, p, x, y (no, they're not the same characters).
EDIT: I realize that many programming languages today allow the use of unicode variables and I like that it's a possibility, it's just not the best when you need to be paranoid about the code
Preventing/detecting homoglyph attacks is a feature of competent text editors, and not a feature of the source code itself. If the source spelt out the variable names using latin characters, it would be no more or less susceptible to being backdoored in this way.
> the ML-KEM draft specification (FIPS 203) uses the exact same greek symbols
I'm as proud of my heritage as the next Greek-American, but just because mathematicians use unintelligible symbols in their manuscripts doesn't mean we have do the same thing in code. Let's prioritize comprehensibility and give variables meaningful names, instead.
FIPS 203 is not a math paper, it's a specification, giving concrete algorithms that use aforementioned variable names. Maybe they should use more descriptive variable names in the spec (you could tell them about it - they accept and respond to feedback from the public), but in the meantime, I think it's more useful for an implementation to use the same variable names as the spec.
This code will be read many more times than it is written, and anyone auditing its correctness will be comparing against the spec.
If the variables are spelt out, then you have to do the mental (or otherwise) translation before you can compare the two, adding overhead. For comparing the symbols visually, you don't even need to know their names.