[ewanm89]

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?

[loup-vaillant]

> 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.

[cryptonector]

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

[loup-vaillant]

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.

[snakeanus]

> 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.