"x /^ y" is x/y rounded up, i.e. the least n such that x <= y*n.
"x %^ y" is the least k such that x+k is a multiple of y.
For comparison,
"x / y" is x/y rounded down, i.e. the greatest n such that x >= y*n.
"x % y" is the least k such that x-k is a multiple of y.
The new syntax is much more suggestive of the relation to "/" and "%".
Cryptol could not prove that subtracting `65 + padding` from `512 * chunks`
in the constraint `msgLen == 512 * chunks - (65 + padding)` was well
defined, and rejected the function. This constraint was redundant, so
removing it allowed the function to typecheck.
The width table in CryptolTC.z3 wasn't large enough to solve constraints
about the width of 64-bit words. This change is a bit of a band-aid, as
larger words will expose the same problem. Longer-term, we should try to
solve these constraints after the SMT-based phase, using some other
approach.
The constraints in CryptoBox were too permissive, and when adjusted to
represent the true intent (that values fit within 64-bits), and the
width table was updated, the example will type-check again.
Thanks to @tommd for tracking both of these down.
Cryptol 2.3-alpha couldn't math, but thanks to @yav's hard work, Cryptol 2.3 and
later can math! So with our new found powers comes great simplification. Not
all is perfect, much like Dori-Mic's situation, but things are much better.
See the width constraints in SCrypt.cry for areas that could be improved with
some semi-obvious statements (forall x. 1 + width x >= width (x - 1)).
A new Cryptol user! Alexander Semenov from the Russian Academy of
Sciences is the developer of the Transalg tool, which can also translate
cryptographic algorithms (written in imperative form) into SAT problems.
He recently started experimenting with Cryptol, and wrote up
implementations of several stream ciphers, included in this commit.
The new type signature for popCount is simpler, and more importantly
passes the typechecker. The old one really _ought_ to typecheck, though,
so a shrunken version of it is now in the test suite for #126
The `random` primitive previously took a `[32]` seed, but this causes
inconsistency between 32-bit and 64-bit platforms when the seed is large
enough to wrap around in GHC's representation of an `Int`. This patch
switches to an API that seeds directly with four 64-bit words, and so
should behave the same way on our supported platforms.
I've found that exposing helper types that are only of internal concern to the
function to be bad form. These values should be in where clauses both to help
the type checker not get distracted and to keep the user-facing API as clean as
possible.
