Deprecate old specs and update SHA3 API

[marsella]

#142 introduces a new API for SHA-3 that handles bit ordering conversions. However, there are several algorithms that use the old API for both hash functions and extendable output functions, including:

• several old versions of Dilithium (round 1, round 2, final draft (probably the IPD of FIPS 204, but I'm not sure)
• an old version of Kyber (3.1)
• the latest ML-KEM (FIPS 203)
• "DSA" -- not sure what spec this is (Primitive/Asymmetric/Signature/DSA/p2048_q224.cry) deleted in Delete more ecdsa! #174
• Falcon 1.2
• SPHINCS+ 3.1

Some of these old versions do not have working tests or KATs, which makes it hard to modify the SHA3 API and still have confidence that the specs work as intended. For the outdated specs, we should remove the old versions (Dilithium Round 1 and 2, Kyber 3.01). I don't know what to do about Falcon (new NIST spec is supposed to be released later this year) or SPHINCS+.

• For anything testable, update to the new SHA-3 API and modify as necessary to get the tests running again (if this becomes a huge task, separate into issues)
• For anything not testable: if the spec is not the latest version, delete it. If it is the latest version, I guess keep it as-is for now and make a note in this issue.
• If all the calls to toBytes and fromBytes and the old sha3 APIs have been removed, delete those APIs from SHA3. Otherwise make sure they're marked as deprecated.

[sauclovian-g]

In principle even without tests it ought to be possible to add the updated version in parallel with the existing one, have Cryptol show that they're equivalent, then remove the old one :-)

In practice it may not be trivial, you might need to set it up in SAW, etc. And it'll probably work if and only if the tooling recognizes (or can be made to recognize) that the underlying SHA3 is the same in both cases instead of trying to explore it. But if any of these are specs we actually want to keep, it might be worth looking into.

[marsella]

Yeah. I could also track down the old KATs for some of these (e.g. by combing through the history of the repo where I sourced the new ones).

There's a question of how much effort to put in now vs later. I have ML-DSA (the standardized version of Dilithium) on the roadmap and I'm working on ML-KEM (the standardized version of Kyber), so all the old versions of those two can go away. SPHINCS+ was also finalized in August, and Falcon is supposed to be standardized later this year (see the NIST announcement). Given general resource constraints and priorities and so on, it does not seem worthwhile (to me) to iterate a bunch on the outdated versions of these if they're going to be replaced in the next ~year by the latest n greatest versions. Easier I think to let the old SHA3 API linger a little bit longer.

So the main question is around that mysterious DSA, which I just haven't looked into yet.

[sauclovian-g]

If they aren't specs we want to keep then all of that is definitely not worthwhile :-)