wycheproof VS XKCP

I failed to notice the relevant Wycheproof test vectors because they weren’t listed on the front page (they still aren’t).

When I wrote the Monocypher cryptographic library, I didn't really know how to write serous tests. With some help, I eventually got something pretty good, with 100% code and path coverage, that test every possible input lengths as well as obscure corner cases I stole from various places (most notably Whycheproof).

"GitHub - google/wycheproof: Project Wycheproof tests crypto libraries against known attacks." https://github.com/google/wycheproof

Thankfully, Curve25519 is much easier to implement, with much fewer death traps than short Weierstraß curves. For X25519, just follow DJB’s advice from ECC Hacks https://www.youtube.com/watch?v=vEt-D8xZmgE and make sure your arithmetic is up to snuff (constant time arithmetic is actually the hard part, by default I strongly suggest you steal it from the ref10 implementation).

For EdDSA, just follow the relevant explicit formulas, avoid clever (but dangerous) tricks such as converting to Montgomery form and back, and test with Wycheproof’s Ed25519 test vectors. https://github.com/google/wycheproof/blob/master/testvectors...

Have you tested all your applicable components against the Wycheproof test vectors and passed?

> Just another nail in the long overdue C/C++ coffin

C, f**ing C. By the sake of god. Not C++.

https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383...

Something like that in modern C++ would have been done using span<> and that prevents this kind of out-of-bound access party-time.

This and the commit diff itself tell the tale: https://github.com/XKCP/XKCP/issues/105

With parameters as specified by SHA3 it's a lot slower than BLAKE3

Keccak (SHA-3) is actually a good deal faster than BLAKE(1) in hardware. That’s the reason why they chose it: It has acceptable performance in software, and very good performance in hardware.

KangarooTwelve / MarsupilamiFourteen are Keccak variants with fewer rounds; they should smoke BLAKE2 and probably even BLAKE3 in dedicated hardware. Also, they have tree hashing modes of operation like the later BLAKE developers.

The BLAKE family is best in situations where you want the best possible software performance; indeed, there are cases where you do not want hardware to outperform software (e.g. key derivation functions) where some Salsa20/ChaCha20/BLAKE variant makes the most sense. The Keccak family is when one already has dedicated hardware instructions (e.g. ARM already has a hardware level Keccak engine; Intel is dragging their feet but it is only a matter of time) or is willing to trade software performance for more hardware performance.

Keccak code is here: https://github.com/XKCP/XKCP