4dc5eda23a
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. |
||
|---|---|---|
| .. | ||
| prim | ||
| File.md | ||
| Keys.cry | ||
| README.md | ||
Minilock in Cryptol
miniLock is a low-barrier to use file encryption utility based on the algorithms:
- SCrypt
- PBKDF2
- HMAC-SHA512
- Blake2s
- Base64
- Base58
- CryptoBox
- Salsa20
- Curve25519
- Poly1305
This example is a specification of miniLock file encryption in Cryptol including all component algorithms as well as primitive JSON encoding to allow inter-operability between the official miniLock written in JavaScript and files produced by Cryptol.
Use
To encrypt a file consider:
CRYPTOLPATH=`pwd`/prim cryptol File.md
Then use the miniLock function such as can be seen in test_lock:
miniLock [(theirID, nonceA)] filename contents (myPrivKey, myPubKey) key nonceF (ephemPriv, ephemPub)
Note SCrypt, and thus miniLock ID and key derivation from user passwords, is too
expensive for the Cryptol interpreter to compute on all but todays more powerful
computers. The ID generation can be done using mkID from Keys.cry.
License
Copyright (c) 2013-2016 Galois, Inc. Distributed under the terms of the BSD3 license (see LICENSE file)