Gregory Maxwell

> it's somewhat crazy for clang to rely on it if you control only half of the C implementation, Yeah. That's also my point. They're perfectly right that the "implementation"...

or split into inplace and neg, and neg branches then calls inplace. Most usage would just use inplace directly.

Well we always have randomness in these cases-- because we have a secret. :) But just running an extra sha2 compression function run would be pretty bad for performance.

That's my thought, I think there isn't a reason to drop the constant time anymore, but it would perhaps still be good to add more blinding.

So that they don't end up floating around uninitialized and mixing uninitialized stuff in places (harmlessly and even without causing valgrind to complain, but it's a pita to reason about).

Still too twitchy: I am able to observe failures. FWIW, generally checks out fine, and I confirmed it catches some obscure bugs I tried adding.

Can we go forward with this but disable the testing RNG tests by default and make running them part of our release process? I don't like the possibility of spurious...

Can I suggest that this be changed so that it runs the randomness tests with a static seed? This way it won't cause spurious failures for users, but will still...

Current test with a static seed. just for the RNG tests. People tend to copy-paste new responses when a non-normative function changes, so known responses really are only just "this...

> Unfortunately we use quite a few divisions, so this does not lead anywhere. Is there any way to tell if the divisor is a compile time constant? We generally...