galoisinc / cryptol

Cryptol: The Language of Cryptography

Cryptol, version 3

This version of Cryptol is (C) 2013-2023 Galois, Inc., and
distributed under a standard, three-clause BSD license. Please see
the file LICENSE, distributed with this software, for specific
terms and conditions.

What is Cryptol?

The Cryptol specification language was designed by Galois for the NSA Laboratory for Advanced Cybersecurity Research as a public standard for specifying cryptographic algorithms. A Cryptol reference specification can serve as the formal documentation for a cryptographic module. Unlike current specification mechanisms, Cryptol is fully executable, allowing designers to experiment with their programs incrementally as their designs evolve.

This release is an interpreter for version 3 of the Cryptol language. The interpreter includes a :check command, which tests predicates written in Cryptol against randomly-generated test vectors (in the style of QuickCheck). There is also a :prove command, which calls out to SMT solvers, such as Yices, Z3, CVC4, or CVC5, to prove predicates for all possible inputs.

Getting Cryptol Binaries

Cryptol binaries for Mac OS X, Linux, and Windows are available from the GitHub releases page. Mac OS X and Linux binaries are distributed as a tarball which you can extract to a location of your choice. Windows binaries are distributed both as tarballs and as .msi installer packages which place a shortcut to the Cryptol interpreter in the Start menu.

On Mac OS X, Cryptol is also available via Homebrew. Simply run brew update && brew install cryptol to get the latest stable version.

Getting Z3

Cryptol currently uses Microsoft Research's Z3 SMT solver by default to solve constraints during type checking, and as the default solver for the :sat and :prove commands. Cryptol generally requires the most recent version of Z3, but you can see the specific version tested in CI by looking here.

You can download Z3 binaries for a variety of platforms from their releases page. If you install Cryptol using Homebrew, the appropriate version of Z3 will be installed automatically. If you're using Linux, the package manager for your distribution may include Z3, as well, though sometimes the available versions are somewhat old.

After installation, make sure that z3 (or z3.exe on Windows) is on your PATH.

Note for 64-bit Linux Users

On some 64-bit Linux configurations, 32-bit binaries do not work. This can lead to unhelpful error messages like z3: no such file or directory, even when z3 is clearly present. To fix this, either install 32-bit compatibility packages for your distribution, or download the x64 version of Z3.

Building Cryptol From Source

In addition to the binaries, the Cryptol source is available publicly on GitHub.

Cryptol builds and runs on various flavors of Linux, Mac OS X, and Windows. We regularly build and test it in the following environments:

• macOS 12, 64-bit
• Ubuntu 20.04, 64-bit
• Ubuntu 22.04, 64-bit
• Windows Server 2019, 64-bit

Prerequisites

Cryptol is regularly built and tested with the three most recent versions of GHC, which at the time of this writing are 9.4.8, 9.6.2, and 9.8.2. The easiest way to install an appropriate version of GHC is with ghcup.

Some supporting non-Haskell libraries are required to build Cryptol. Most should already be present for your operating system, but you may need to install the following:

• The GNU Multiple Precision Arithmetic Library (GMP)
• ncurses

You'll also need Z3 installed when running Cryptol.

Building Cryptol

After a fresh checkout of cryptol, be sure to initialize its git submodules:

git submodule update --init

Then, from the Cryptol source directory, run:

./cry build

This will build Cryptol in place. From there, there are additional targets:

• ./cry run: run Cryptol in the current directory
• ./cry test: run the regression test suite

Installing Cryptol

If you run cabal v2-install --installdir=DIR in your source directory after running one of the above ./cry command, you will end up with a binary in DIR.

Configuring Cryptol

Cryptol can use several external files to control its operation. Normally, the build process embeds these files into the executable. However, these embedded files can be overwritten with local copies in two ways:

• Copy the contents of the lib directory into $HOME/.cryptol.

• Set the CRYPTOLPATH environment variable to name some other directory that contains the files from the lib directory.

Contributing

We believe that anyone who uses Cryptol is making an important contribution toward making Cryptol a better tool. There are many ways to get involved.

Users

If you write Cryptol programs that you think would benefit the community, fork the GitHub repository, and add them to the examples/contrib directory and submit a pull request.

We host a Cryptol mailing list, which you can join here.

If you run into a bug in Cryptol, if something doesn't make sense in the documentation, if you think something could be better, or if you just have a cool use of Cryptol that you'd like to share with us, use the issues page on GitHub, or send email to [email protected].

Developers

If you'd like to get involved with Cryptol development, see the list of low-hanging fruit. These are tasks which should be straightforward to implement. Make a fork of this GitHub repository, send along pull requests and we'll be happy to incorporate your changes.

Repository Structure

• /cryptol: Haskell sources for the front-end cryptol executable and read-eval-print loop
• /docs: LaTeX and Markdown sources for the Cryptol documentation
• /examples: Cryptol sources implementing several interesting algorithms
• /lib: Cryptol standard library sources
• /src: Haskell sources for the cryptol library (the bulk of the implementation)
• /tests: Haskell sources for the Cryptol regression test suite, as well as the Cryptol sources and expected outputs that comprise that suite

Where to Look Next

The docs directory of the installation package contains an introductory book, the examples directory contains a number of algorithms specified in Cryptol.

If you are familiar with version 1 of Cryptol, you should read the Version2Changes document in the docs directory.

For a large collection of Cryptol examples, see the cryptol-specs repository.

Cryptol is still under active development at Galois. We are also building tools that consume both Cryptol specifications and implementations in (for example) C or Java, and can (with some amount of work) allow you to verify that an implementation meets its specification. See more information on the SAW website.

Thanks!

We hope that Cryptol is useful as a tool for educators and students, commercial and open source authors of cryptographic implementations, and by cryptographers to

• specify cryptographic algorithms
• check or prove properties of algorithms
• generate test vectors for testing implementations
• experiment with new algorithms

Acknowledgements

Cryptol has been under development for over a decade with many people contributing to its design and implementation. Those people include (but are not limited to) Aaron Tomb, Adam Foltzer, Adam Wick, Alexander Bakst, Andrew Kent, Andrei Stefanescu, Andrey Chudnov, Andy Gill, Benjamin Barenblat, Ben Jones, Ben Selfridge, Brett Boston, Bretton Chen, Brian Huffman, Brian Ledger, Chris Phifer, Daniel Wagner, David Thrane Christiansen, David Lazar, Dylan McNamee, Eddy Westbrook, Edward Yang, Eric Mertens, Eric Mullen, Fergus Henderson, Hazel Weakly, Henry Blanchette, Iavor Diatchki, Jeff Lewis, Jim Teisher, Joe Hendrix, Joe Hurd, Joe Kiniry, Joel Stanley, Joey Dodds, John Launchbury, John Matthews, Jonathan Daugherty, Kenneth Foner, Kevin Quick, Kyle Carter, Ledah Casburn, Lee Pike, Levent Erkök, Lisanna Dettwyler, Magnus Carlsson, Mark Shields, Mark Tullsen, Matt Sottile, Matthew Yacavone, Nathan Collins, Philip Weaver, Robert Dockins, Ryan Scott, Sally Browning, Sam Anklesaria, Sigbjørn Finne, Stephen Magill, Thomas Nordin, Trevor Elliott, and Tristan Ravitch.

Much of the work on Cryptol has been funded by, and lots of design input was provided by, the team at the NSA's Laboratory for Advanced Cybersecurity Research, including Brad Martin, Frank Taylor, and Sean Weaver.

Portions of Cryptol are also based upon work supported by the Office of Naval Research under Contract No. N68335-17-C-0452. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Office of Naval Research.

cryptol's Issues

formalize Cryptol type system

Do an on-paper formalization of Cryptol's type system.

front-end improvements: vi mode

Write and/or polish vi Cryptol mode.

get Iavor's type-checker constraint solver work integrated

Get Iavor's type-checker constraint solver work integrated. This includes:

• modular interface to constraint solver
• implement an instance of this modular API (use GHC's new one!)
• finally, add some heuristics (others have asked for user-provided axioms-how would we represent those?)

document literal type inference issues in The Book

See #30. Though in the longer run, something that loose less like a kludge to users is probably warranted.

mechanize denotational semantics

See #45.

"While loops" example in documentation

Just a minor thing in the while loop example in section 2.13 "Recursion and recurrences": the index starts in 0, and idx is tested to be less than or equal to length(xs).

Cheers!

front-end improvements: Emacs mode

Incorporate and extend Austin's cryptol-mode.

mechanically formalize Cryptol's type system

Based upon #55.

precisely codify new process, development, repository, and release standards

This will, of course, require input from several team members. Thanks to @acfoltzer for reminding me to add an issue for this.

:prove yields cvc4 error

Trying this:

average33 : [32] -> [32] -> [32]
average33 x y = drop`{1}(z'/2)
    where
          z' : [33]
          z' = (zero # x) + (zero # y)

average1 : [32] -> [32] -> [32]
average1 x y = x/2 + y/2 + (x%2 && y%2)

average2 : [32] -> [32] -> [32]
average2 x y = lo + ((hi - lo)>>1) where
    lo = min x y
    hi = max x y

property av1 x y = average33 x y == average1 x y
property av2 x y = average33 x y == average2 x y

property applesOranges x y = average1 x y == average2 x y

:check of all three properties works fine, :prove of applesOranges works fine, but :prove of av1 or av2 results in:

*** An error occurred.
***  Failed to complete the call to cvc4
***  Executable   : "/opt/local/bin/cvc4"
***  Options      : --lang smt
***  Exit code    : 1
***  Solver output: 
***  ==============================================================================
***  (error "Parse Error: <stdin>:21.22: expecting bit-vector terms")
***  ==============================================================================
***  Giving up..

See issue289.cry in the tests/issues directory of the repository

add rigor to the prelude

Include formal specifications for built-ins and verify that they conform to them.

mechanize operational semantics

Mechanize the on-paper operational semantics.

write formal denotational semantics for Cryptol

Doing so, and mechanizing such, permits us to verify our verification backend.

add a chapter about design decisions to the Cryptol book

@dylanmc will work on this with me.

develop a long-term Cryptol road map

@dylanmc will work on this with me, with support from @yav, @brianhuffman, @atomb, @acfoltzer, and others.

HSMT assessment

• possibly pull in HSMT (from Minho) to replace the back-end of SBV?

Support :let in the Cryptol REPL?

It would be nice to be able to define new symbols at the REPL, like this:

:let timesTwo x = x * 2
:let double x = x + x
:prove \x = timesTwo x == double x

Yes, this could be done with lots of lambdas, but the above would be very helpful.

make test fails

The regression tests run by make test are currently failing 4 of 63 for me.
I am running v2.0.0 and have tried both cvc4-1.3-x86_64-linux-opt and cvc4-2014-04-26-x86_64-linux-opt.

:solve True works fine for me

Testing on Linux-x86_64
issues:
  issue148.icry: [Failed]
meld issues/issue148.icry.stdout /home/dcox/workspaces/dcox/cryptol/tests/output/issues/issue148.icry.stdout
  issue289.icry: [Failed]
meld issues/issue289.icry.stdout /home/dcox/workspaces/dcox/cryptol/tests/output/issues/issue289.icry.stdout
  issue225.icry: [Failed]
meld issues/issue225.icry.stdout /home/dcox/workspaces/dcox/cryptol/tests/output/issues/issue225.icry.stdout
  issue218.icry: [Failed]
meld issues/issue218.icry.stdout /home/dcox/workspaces/dcox/cryptol/tests/output/issues/issue218.icry.stdout
regression:
renamer:

         Test Cases   Total       
 Passed  59           59          
 Failed  4            4           
 Total   63           63          
make: *** [test] Error 1
```sh

type error with the program in issue #3

when I load the program Dylan put in issue #3, I actually get a bunch of type-checking errors unless I put an explicit annotation zero : [1] in the expression z'.

The constraints look solvable to me, but maybe a rewrite is missing? Here's what I get:

error] at T.cry:5:11--5:39:
  Unsolved constraint:
    33 >= ?i3 + 0
      arising from
      matching types
      at T.cry:5:11--5:39
  where
  ?i3 is 1st type parameter
         of expression (#)
         at T.cry:5:22--5:23
[error] at T.cry:5:16--5:39:
  Unsolved constraint:
    ?i3 + (33 - ?i3) >= ?b3 + 0
      arising from
      matching types
      at T.cry:5:16--5:39
  where
  ?b3 is 1st type parameter
         of expression (#)
         at T.cry:5:35--5:36
  ?i3 is 1st type parameter
         of expression (#)
         at T.cry:5:22--5:23
[error] at T.cry:5:35--5:36:
  Unsolved constraint:
    fin ?b3
      arising from
      use of expression (#)
      at T.cry:5:35--5:36
  where
  ?b3 is 1st type parameter
         of expression (#)
         at T.cry:5:35--5:36
[error] at T.cry:2:1--5:39:
  Unsolved constraint:
    32 == ?i3 + (33 - ?i3) - ?b3
      arising from
      matching types
      at T.cry:2:1--5:39
  where
  ?b3 is 1st type parameter
         of expression (#)
         at T.cry:5:35--5:36
  ?i3 is 1st type parameter
         of expression (#)
         at T.cry:5:22--5:23
[error] at T.cry:2:1--5:39:
  Unsolved constraint:
    32 == 33 - ?i3
      arising from
      matching types
      at T.cry:2:1--5:39
  where
  ?i3 is 1st type parameter
         of expression (#)
         at T.cry:5:22--5:23

typo: unknwon --> unknown

https://github.com/GaloisInc/cryptol/blob/master/src/Cryptol/TypeCheck/Solver/Smtlib.hs#L152

you probably never saw this since "unknown" would be produced only in the presence of quantifiers; but would be good to get rid of that!

extend the prelude

map/fold/zip ... go through class notes, ask @yav and JL

Question on "Monomorphic types" section

In section 2.11.1 "Monomorphic types" of the documentation, it is said that type "[17]" is equivalent to type "[1][17]Bit". This confuses me a bit, as I do not get in which sense these types are equivalent.

For example, 1 : [17] type checks correctly, while 1 : [1][17]Bit does not. Maybe you mean that [17] and [17]Bit are equivalent? Or you mean that [1][17]Bit and [17] are kind of isomorphic? In that case, I would rather remove the Bit thing, and state it more generally, like "[1]t is equivalent to t".

Cheers!

zero type inference

I would expect the following to typecheck and run:

groupBy`{16}("hello this is cool" # zero)

But I get the following error:

Cannot evaluate polymorphic value.
Type: {a} (16 * a >= 18) => [a][16][8]

It does work if I specify a type for the zero:

groupBy`{16}("hello this is cool" # (zero:[inf][8]))
[[0x68, 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x74, 0x68, 0x69, 0x73, 0x20,
  0x69, 0x73, 0x20, 0x63, 0x6f],
 [0x6f, 0x6c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
  0x00, 0x00, 0x00, 0x00, 0x00],
 ...]

But I would hope that zero would automatically get the right type assigned to it. Hopefully this will just go away with the new type system constraint solver, but I thought I'd document it here.

verify the Cryptol interpreter against the mechanized formal semantics

See #43 and #42.

improve error messages

As @acfoltzer says, "The current raw dumps of the cvc4 output aren’t always the most helpful ;)".

cryptol should support :allSat

subject says it all; it's a pain to add "refutations" manually; and now that you've got it thru SBV, this should be more or less trivial to implement.

Source install on MacOSX Mavericks

Did brew install (after brew update and so on) for ghc and cabal-install, cabal install for alex and happy), cloned repository , installed CVC4 binaries using mac installer, ran make in cryptol directory. I see

loki:cryptol cbrew$ make
cabal -j install .
Resolving dependencies...
Notice: installing into a sandbox located at
/Users/cbrew/working/cryptol/.cabal-sandbox
Configuring cryptol-2.0.0...
Failed to install cryptol-2.0.0
Last 10 lines of the build log ( /Users/cbrew/working/cryptol/.cabal-sandbox/logs/cryptol-2.0.0.log ):
cabal: Error: some packages failed to install:
cryptol-2.0.0 failed during the configure step. The exception was:
user error (The package 'cryptol' requires Cabal library version -any &&

=1.18 but no suitable version is installed.)
make: *** [.cabal-sandbox/bin/cryptol] Error 1
loki:cryptol cbrew$

and

loki:cryptol cbrew$ cabal --version
cabal-install version 1.20.0.0
using version 1.20.0.0 of the Cabal library

and

loki:cryptol cbrew$ uname -a
Darwin loki.local 13.1.0 Darwin Kernel Version 13.1.0: Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64 x86_64

Looks to me as if the requirement for the cabal library (as stated in the error message) is actually satisfied, but the build system isn't seeing it that way, Any ideas?

Heuristic control over iteSolver

Right now :set iteSolver=off is the default, for performance reasons. What this means is that :prove with some programs that use function-recursion won't succeed. Setting it on by default will slow down :prove for everything. Brian said he thinks we could come up with a heuristic to control this automatically, so normal users won't have to worry about it, but it might be good to leave manual control in for experts.

pass verbose flag down to sbv

[This can help debug problems as in issue #3]

if the cryptol flag "debug" is set, then you guys should pass it down to the sbv solver as the "verbose" field of the solver set to True. That way SBV will also print out a bunch of things that can help elucidate any downstream issues.

iteSolver causes cryptol to terminate

$ cryptol
                        _        _
   ___ _ __ _   _ _ __ | |_ ___ | |
  / __| '__| | | | '_ \| __/ _ \| |
 | (__| |  | |_| | |_) | || (_) | |
  \___|_|   \__, | .__/ \__\___/|_|
            |___/|_| version 2.0.0 (28043c3)

Loading module Cryptol
Cryptol> :set iteSolver=on
Cryptol> :sat \x -> if((x>=1000) && ((x:[32]) <= 10000)) then (((x*x)%10000) == x) else False
cryptol: SBV.isTheorem: Received:
Unknown. Potential counter-example:
  s0 = 0 :: SWord32
$ 

One Symbolic Simulator

Have Cryptol use the SawCore symbolic simulator - don't want to maintain these parallel code bases that do so much similar stuff. Open question: Is this for a 2.1 or 2.2 release?

Type checker needs help in Enigma.cry

The following code won't type-check unless the commented-out signature is included:

module EnigmaBroke where 

type Rotor       = [26](Char, Bit)

mkRotor : {a} (fin a) => ([26]Char,[a]) -> Rotor
mkRotor (_,_) = zero

scramble : (Bit, Char, Rotor) -> (Bit, Char, Rotor)
scramble (_,_,_) = zero

joinRotors : {n} (fin n) => ([n]Rotor, Char) -> ([n]Rotor, Char)
joinRotors (rotors, inputChar) = (rotors', outputChar)
  where
    initRotor = mkRotor (['A' .. 'Z'], [])
    // ncrs : [n+1](Bit, [8], Rotor)  // Doesn't Type-check unless this declaration is included
    ncrs = [(True, inputChar, initRotor)]
               # [ scramble (notch, char, r)
                 | r <- rotors
                 | (notch, char, rotor') <- ncrs
                 ]
    rotors' = tail [ r | (_, _, r) <- ncrs ]
    (_, outputChar, _) = ncrs ! 0

This should be fixed in an upcoming enhancement to the type-checking constraint solver. This issue is included in tests/issues/issue225.cry

rework ITE

Clean up the ITEsolver heuristic.

front-end improvements: C-level API

C-level API -> then integration with Python -> integration with Sage (obviate writing .cry files and invoking interperter)

iteSolver broken for sat calls

Consider this program:

bitCountFast : [32] -> [8]
bitCountFast = go 0
  where go c n = if n == 0
                 then c
                 else go (c+1) (n && (n-1))

bitCountSlow : [32] -> [8]
bitCountSlow xs = sums ! 0
  where sums = [0] # [ s + (if b then 1 else 0)
                     | s <- sums
                     | b <- xs
                     ]

I can successfully do this:

Main> :set iteSolver=on
Main> :set prover=z3
Main> :prove \n -> bitCountFast n == bitCountSlow n
Q.E.D.

Which is great. But look at this:

Main> :sat \n -> bitCountFast n == bitCountSlow n
Unsatisfiable.

Not only Cryptol takes a loooong time to compute this result; it's just wrong. (Fast and wrong, I can live with; slow and wrong is just horrible!) In particular, note how Cryptol says something is provably true but is not satisfiable; which is just plain wrong.

I've an idea why this is the case, but this github-issue-tracker is too small to contain it! :-) However, see my comments on #21, which should help resolve the issue.

If then else causing an issue with type constraints

Here's a simplification from an implementation of Salsa:

Salsa20_expansion : {a} (a >= 1, 2 >= a) => ([16*a][8], [16][8]) -> [64][8]                         
Salsa20_expansion(k, n) = z
  where
    [s0, s1, s2, s3] = if (`a == 2) then split("expand 32-byte k")
                                    else split("expand 16-byte k")
    k1 = take`{16}(k#zero)
    k2 = drop`{16}(zero#k)
    x = s0 # k1 # s1 # n # s2 # k2 # s3
    z = x 

The type checker fails like this:

[error] at salsa-mini.cry:2:1--2:18:
  Failed to validate user-specified signature.
    In the definition of 'Salsa20_expansion', at salsa-mini.cry:2:1--2:18:
      for any type a
        a >= 1
        2 >= a
      =>
      fin ?d
        arising from use of expression (#) at salsa-mini.cry:9:24--9:25
      ?b + 16 * a == 16 + ?c
        arising from matching types at salsa-mini.cry:8:10--8:27
      ?d + 16 * a == 32
        arising from matching types at salsa-mini.cry:9:10--9:27

even though "it's plain to see" that it should typecheck. This seems to be caused by the "if then else" construct.

See tests/issues/issue148.cry

why not "cabal install cryptol"?

well this is not a real bug, but I don't see why we can't just "cabal install cryptol"

at least the Haddock'ed sources should be hosted somewhere for us to browse, as browsing thru github is rather painful.

better error reporting when solver(s) are misconfigured

When I pass the following (incorrect) property below to :prove

revRev : [3][8] -> Bit
property revRev s = reverse s == reverse (reverse s)

Cryptol gives this error:

***  Failed to complete the call to cvc4
***  Executable   : "/opt/local/bin/cvc4"
***  Options      : --lang smt
***  Exit code    : -5
***  Solver output: 
***  dyld: lazy symbol binding failed: Symbol not found: __ZN3cln13print_integerERSojRKNS_4cl_IE
***    Referenced from: /opt/local/lib/libcvc4.2.dylib
***    Expected in: flat namespace
***  dyld: Symbol not found: __ZN3cln13print_integerERSojRKNS_4cl_IE
***    Referenced from: /opt/local/lib/libcvc4.2.dylib
***    Expected in: flat namespace

This is on Mac OS 10.9.3, Cryptol 2.0.0 and cvc4 1.3

verify verification backend for Cryptol

See #45 and #46.

Literal type inference oddity with hex and octal

Cryptol2 seems to treat hex-literals weirdly when it comes to type checking. To wit:

Cryptol> 411:[32]
411
Cryptol> 0x19b:[32]

[error] at <interactive>:1:1--1:11:
  Type mismatch:
    Expected type: 32
    Inferred type: 12

This is truly bizarre. For instance, there appears to be absolutely no way of writing a 11 bit literal in hex:

Cryptol> 0x3:[11]

[error] at <interactive>:1:1--1:9:
  Type mismatch:
    Expected type: 11
    Inferred type: 4
Cryptol> 0x03:[11]

[error] at <interactive>:1:1--1:10:
  Type mismatch:
    Expected type: 11
    Inferred type: 8
Cryptol> 0x003:[11]

[error] at <interactive>:1:1--1:11:
  Type mismatch:
    Expected type: 11
    Inferred type: 12
Cryptol> 0x0003:[11]

[error] at <interactive>:1:1--1:12:
  Type mismatch:
    Expected type: 11
    Inferred type: 16

A similar experiment with octal (0o) shows it has the same problem.

write formal operational semantics for Cryptol

This process might unearth some tweaks we need to make. After writing the new semantics on paper, we can then turn to mechanizing them (#42) and then use them to verify our interpreter (#44).

front-end improvements: Notebook interface

Notebook interface - polish and host it somewhere (funding to do this from Verifier "soon").

mainline with SBV

We will work with @LeventErkok on eliminating our ad hoc fork of SBV and ensuring a clean dependency between Cryptol and (a future release of) SBV. In doing so we will help close #18.

The issues dependent upon this one are #32, #33, #34.

Recursive imports

Cryptol appears to load imports multiple times when dealing with transitive dependencies. For example, suppose you have the following modules:

module a where

module b where
import a

module c where
import a
import b

Cryptol will print out:

Loading module Cryptol
Cryptol> :load c.cry
Loading module Cryptol
Loading module Cryptol
Loading module a
Loading module Cryptol
Loading module Cryptol
Loading module a
Loading module b
Loading module c

I'd expect not to see this many loading statements.

Support for exponentiation in type constraints

Can Cryptol be enhanced to propagate constants through the exponentiation (log2) given below?

f : {a} (fin a) => [2^^a] -> Bit
f x = True
Main> f (zero:[16])

Cannot evaluate polymorphic value.
Type: {a} (fin a, 16 == 2 ^^ a) => Bit

This simple improvement would make it easier to represent truth tables as functions in Cryptol version 2.

:prove correctSimon32_64 doesn't seem to terminate

I killed the command after 10 minutes. The proof takes a few seconds in Cryptol 1.

Nested tuple projection not working - defaulting error

x = ( 1, (2, 3))
z = x.2.2

yields:

Cryptol> (1,(2,3)).2.2
[warning] at <interactive>:1:1--1:14:
  Defaulting type parameter 'bits'
             of literal or demoted expression
             at <interactive>:1:2--1:3
  to 1

[error] at <interactive>:1:7--1:8:
  Unsolved constraint:
    fin ?j3
      arising from
      use of literal or demoted expression
      at <interactive>:1:7--1:8
  where
  ?j3 is type parameter 'bits'
         of literal or demoted expression
         at <interactive>:1:7--1:8
[error] at <interactive>:1:7--1:8:
  Unsolved constraint:
    ?j3 >= width 3
      arising from
      use of literal or demoted expression
      at <interactive>:1:7--1:8
  where
  ?j3 is type parameter 'bits'
         of literal or demoted expression
         at <interactive>:1:7--1:8
[error] at <interactive>:1:5--1:6:
  Unsolved constraint:
    fin ?i3
      arising from
      use of literal or demoted expression
      at <interactive>:1:5--1:6
  where
  ?i3 is type parameter 'bits'
         of literal or demoted expression
         at <interactive>:1:5--1:6
[error] at <interactive>:1:5--1:6:
  Unsolved constraint:
    ?i3 >= width 2
      arising from
      use of literal or demoted expression
      at <interactive>:1:5--1:6
  where
  ?i3 is type parameter 'bits'
         of literal or demoted expression
         at <interactive>:1:5--1:6

Support for concurrent solvers

Since we support many solvers (thanks to SBV), and each has its sweet spot of the kinds of problems it can solve, we should be able to support the concurrent execution of multiple solvers.

The point of this feature is to support for following use-cases:

1. accept the answer of the fastest solver and kill all others, to make the tool feel more efficient,
2. wait for an answer from all solvers to double-check (or triple- etc.) the result, and possibly
3. use an appropriate solver for a given verification (certain solvers at better at some problems than others), and finally
4. use a fast solver for the verification and a slower solver (or a second run of the same solver) to emit a certificate.

The first two "seem easy", the latter might be interesting research projects.

front-end changes to SBV

• work with LE to get the front-end changes we need (Sam has added a lower-level bit vector layer to the library - integrate those)
• maybe fork SBV, talk with @LeventErkok about pulling our changes
• if we can't create One SBV To Rule Them All, we can (temporarily) fork, but that would be a bummer

assign open issues to milestone