Monocypher

Do you mean fuzz testing does not use even distributions? There’s a bias towards extrema, or at least some guarantee to test zero and MAX? I guess that would work. Also, would you consider the following to be fuzz testing? https://github.com/LoupVaillant/Monocypher/blob/master/tests...

Legal types don't like the Unlicense either as far as I can tell[1]. You'll find software that is dual licensed CC-0 and something else, too,[2,3] because anything public-domain-ish with no attribution may be perceived as too risky. [1] https://softwareengineering.stackexchange.com/a/147120 [2] https://github.com/BLAKE3-team/BLAKE3/blob/master/LICENSE [3] https://github.com/LoupVaillant/Monocypher/blob/master/LICEN...

I'd have to go with Monocypher. It makes very tasteful use of comments, functions and macros to maximize readability and clarity. https://github.com/LoupVaillant/Monocypher

> Tests can then also serve as a kind of documentation. They would have to be written with documentation in mind, which distracts them from their primary purpose: catching bugs. Trying to understand Monocypher from just its test suite¹ for instance would be a pretty bad idea. That test suite is top notch at catching bugs, but it sucks big time at documenting Monocypher. https://github.com/LoupVaillant/Monocypher/blob/master/tests...

Here's a real world example: https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a... So I have this function, `crypto_wipe()` that wipes memory regions with `volatile` so the compiler doesn't optimises it away. In the link above I was using it thus: crypto_stuff(stuff_ctx *ctx) { // stuff crypto_wipe(ctx, sizeof(ctx)); // BUUUG!! } See the bug? I should have dereferenced `ctx` in the sizeof operator. As it was, was only wiping a pointer's worth of data instead of the whole structure. Oops. Now I write this instead: crypto_stuff(stuff_ctx *ctx) { // stuff WIPE_CTX(ctx); // correct! } The amount of repetition I avoid this way is almost negligible, but that was enough to trigger a mistake (I had quite a lot of wiping to do). With the macro, errors are much easier to spot (so much so that I am will

> I'll grant OP a Magic Cloak of Error Abolishment and an enchanted ring with +4 INT, +4 WIS, and +3 VARIABLE-NAMING... Most of those come from my test suite. Without that, I'm back to -2 INT, -3 WIS, and a Cursed Cloak of Mistakes. I did let some bugs slip through the first time around… > what's the very first thing I'm gonna do when I inherit his project for support or further development? Start ripping it apart to add tests so that I can verify the behaviour of the system pre, and post, change. As far as Monocypher is concerned, I already did that. Test vectors, property based test, sanitisers, code coverage analysis, the works. The public interface is testable enough that you don't need to take apart anything to thoroughly test that library (it already is). Huge help with "making positive changes to the code within hours". This cha

#define FOR(i, start, end) for (size_t (i) = (start); (i) < (end); (i)++) yuck EDIT: Also, what the hell is this macro defined in the middle of a function and then only used twice: https://github.com/LoupVaillant/Monocypher/blob/master/src/m... Why do you need this function for "constant time comparison to 0": https://github.com/LoupVaillant/Monocypher/blob/master/src/m... static int neq0(u64 diff) { // constant time comparison to zero // return diff != 0 ? -1 : 0 u64 half = (diff >> 32) | ((u32)diff); return (1 & ((half - 1) >> 32)) - 1; } I am incredibly skeptical that you've done better than the compiler with this bit twiddling stuff. You realize that on x86_64, it probably compiles down to 1-2 instructions to write `diff != 0`, right?

I think crypto code is a bad example. This[1] would not be considered "idiomatic" anywhere, except in crypto. And for example, if one was optimizing for code readability over performance, I expect that would look very different (although you could do much of the same with macros, but I'm not sure if that's any better). [1]: https://github.com/LoupVaillant/Monocypher/blob/master/src/m...

I have developed some kind of instinct that is non-trivial to teach, and impossible to convey in a small HN comment. But my primary proxy is size. The less code the better. But even that have to give way to other concerns, such as style constraints, and straight up performance. While I can't show the code I was talking about above (it was proprietary), I can show my crypto library, Monocypher¹. I think it is a good example of what I mean by high-quality code. (Yes, I am boasting. I believe this is justified. Also, quality requirements for crypto code are kinda off the chart.) [1]: https://github.com/LoupVaillant/Monocypher

`ctx->c` is a u32[1] and msg is u8. So yeah there is integer promotion here. [1]: https://github.com/LoupVaillant/Monocypher/blob/master/src/m...

I believe this[1] is the patch that fixes this bug. I tried to reproduce the behavior but couldn't succeed. Maybe I was doing something wrong. Would really appreciate it if someone here could show a test case where this matters. [1] https://github.com/LoupVaillant/Monocypher/commit/347189c50c...