Yawning Angel

> > `Cipher/AES.h` and `Cipher/AES.cpp` need to be shot into the sun and burned > > As the one who wrote them, yes, I'll even sign the space gun sending...

You don't need to save/restore RFLAGS, because the assembly snippet already specifies that it's clobbered, and "Odin's syscall intrinsic will always return -errno on failure" makes preserving CF non-important. Otherwise...

While this is an improvement in outcome over the current K256 code, where signatures produced are always malformed, this inherits the probabilistic signature failure issue from P256.

The break statements should fall through instead I believe, though it's been years since I thought about the code, and looked at the logging library I used to write this.

> We're planning on switching to libsecp256k1-style field arithmetic for that prime anyway May I ask why? The current implementations produce more than adequate performance (in line with other implementations),...

> Quick notes: > * Inversion is too slow now because our faster jumpdivstep-based algorithm is not in the repository yet. One can get a sense of the performance speedup...

Since this has come up recently. Safety features that rely on reading comprehension are inadequate. DISABLE, not warn.

Sort of related to #190

Note: This is probably extremely non-trivial to do, because the "obvious" way of importing multiple versions of oasis-core simultaniously (ie: `replace`) doesn't work due to limitations. Honestly if we want...

As a side note: Do we want to expose a VRF construct somewhere so that it would be easy to make a chainlink VRF knockoff? I think to do it...