No, it is targeting both. I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, I haven't looked to see if there is any sensitive memory scrubbing. Of the bugs listed most are performance bugs by someone who doesn't know C very well yet have they done the things actually!my required in a crypto library like attempting to make sure all branches are the same instruction length for all implemented algorithms?

> I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks,

Oh come on, the chosen primitives are all designed for easy immunity against timing attacks. I haven't verified this formally, but I basically ripped off safe designs, and I tried to be careful about avoiding secret dependant branches and indices.

> I haven't looked to see if there is any sensitive memory scrubbing.

There's a whole test suite for that.

Look at the makefile, then select whatever sanitiser it lists (comment/uncomment the relevant CC line at the begining). Then run `./test.sh`. You can also run the relevant executables under Valgrind. Finally, there's a way to run it under the TIS-Interpreter, though that is veeery slow.

> by someone who doesn't know C very well

Could you tell me how you inferred that? That could help me improve.

The chosen primitives can still be implemented such that there are timing side channels.

This doesn't happen naturally, except for Poly105 and curve25519 (for those one indeed has to be careful). A naive implementation of Chacha20 for instance is pretty much guaranteed to be immune to timing attacks.

> I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks

He actually talked about avoiding side-channel attacks in his two previous articles about Chacha20 and Poly1305.