Implementation of Olaf

.gitignore

@@ -11,3 +11,4 @@ Cargo.lock
 *.bak
 
 *.s
+.DS_Store

.rustfmt.toml

@@ -0,0 +1,31 @@
+# Basic
+edition = "2021"
+max_width = 100
+use_small_heuristics = "Max"
+
+# Imports
+imports_granularity = "Preserve"
+reorder_imports = false
+reorder_modules = false
+
+# Consistency
+newline_style = "Unix"
+
+# Misc
+chain_width = 80
+spaces_around_ranges = false
+reorder_impl_items = false
+match_arm_leading_pipes = "Preserve"
+match_arm_blocks = false
+match_block_trailing_comma = true
+trailing_comma = "Vertical"
+# trailing_semicolon = false
+# use_field_init_shorthand = true
+
+# where_single_line = true  # does not work on fn
+# brace_style = "AlwaysNextLine"  # does not work on method fn
+
+# Format comments
+comment_width = 100
+wrap_comments = true
+

Cargo.toml

@@ -22,17 +22,25 @@ curve25519-dalek = { version = "4.1.0", default-features = false, features = [
     "zeroize",
     "precomputed-tables",
     "legacy_compatibility",
+    "rand_core",
+    "serde",
 ] }
 subtle = { version = "2.4.1", default-features = false }
 merlin = { version = "3.0.0", default-features = false }
 getrandom_or_panic = { version = "0.0.3", default-features = false }
 rand_core = { version = "0.6.2", default-features = false }
-serde_crate = { version = "1.0.130", package = "serde", default-features = false, optional = true }
+serde = { version = "1.0.130", default-features = false, optional = true }
 serde_bytes = { version = "0.11.5", default-features = false, optional = true }
 cfg-if = { version = "1.0.0", optional = true }
 sha2 = { version = "0.10.7", default-features = false }
 failure = { version = "0.1.8", default-features = false, optional = true }
-zeroize = { version = "1.6", default-features = false, features = ["zeroize_derive"] }
+zeroize = { version = "1.6", default-features = false, features = [
+    "zeroize_derive",
+] }
+derive-getters = "0.3.0"
+chacha20poly1305 = { version = "0.10.1", default-features = false }
+hex = { version = "0.4", default-features = true, optional = true }
+thiserror = { version = "1.0", default-features = false, optional = true }
 
 [dev-dependencies]
 rand = "0.8.5"
@@ -47,17 +55,39 @@ serde_json = "1.0.68"
 name = "schnorr_benchmarks"
 harness = false
 
+[[bench]]
+name = "olaf_benchmarks"
+required-features = ["alloc", "aead"]
+
 [features]
+std = [
+    "alloc",
+    "getrandom",
+    "serde_bytes/std",
+    "rand_core/std",
+    "getrandom_or_panic/std",
+    "chacha20poly1305/std",
+    "hex/std",
+    "thiserror",
+]
 default = ["std", "getrandom"]
 preaudit_deprecated = []
 nightly = []
-alloc = ["curve25519-dalek/alloc", "rand_core/alloc", "getrandom_or_panic/alloc", "serde_bytes/alloc"]
-std = ["alloc", "getrandom", "serde_bytes/std", "rand_core/std", "getrandom_or_panic/std"]
+alloc = [
+    "curve25519-dalek/alloc",
+    "rand_core/alloc",
+    "getrandom_or_panic/alloc",
+    "serde_bytes/alloc",
+]
 asm = ["sha2/asm"]
-serde = ["serde_crate", "serde_bytes", "cfg-if"]
+serde = ["dep:serde", "serde_bytes", "cfg-if"]
 # We cannot make getrandom a direct dependency because rand_core makes
 # getrandom a feature name, which requires forwarding.
-getrandom = ["rand_core/getrandom", "getrandom_or_panic/getrandom", "aead?/getrandom"]
+getrandom = [
+    "rand_core/getrandom",
+    "getrandom_or_panic/getrandom",
+    "aead?/getrandom",
+]
 # We thus cannot forward the wasm-bindgen feature of getrandom,
 # but our consumers could depend upon getrandom and activate its
 # wasm-bindgen feature themselve, which works due to cargo features
@@ -66,3 +96,4 @@ getrandom = ["rand_core/getrandom", "getrandom_or_panic/getrandom", "aead?/getra
 # See https://github.com/rust-lang/cargo/issues/9210
 # and https://github.com/w3f/schnorrkel/issues/65#issuecomment-786923588
 aead = ["dep:aead"]
+cheater-detection = []

annoucement.md

@@ -28,7 +28,7 @@ In 2015, Mike Hamburg resolved this conflict in his [Decaf](https://eprint.iacr.
 
 We employ Ristretto throughout schnorrkel, which reduces malleability, simplifies the analysis of our higher level protocols, and makes it safer to compose schnorrkel protocols with each other and with other similar protocols.
 
-Also, there are minor practical hiccups with the hash functions designed for NIST competitions, but most especially that they create a byte stream oriented interface over a block oriented permutation.  This improves performance of computing MACs on data that arrives in order but piecemeal, but weakens the permutation's natural domain seperation.  We need strong domain seperation in more complex protocols like signatures and NIZKs.  [STROBE](https://strobe.sourceforge.io/) is a strong general purpose symmetric cryptography construction based on Keccak-f(1600), the permutation driving the SHA3 competition winner.  [Merlin](https://doc.dalek.rs/merlin/index.html) is a STROBE scheme for NIZKs, which does almost perfect domain seperation.  
+Also, there are minor practical hiccups with the hash functions designed for NIST competitions, but most especially that they create a byte stream oriented interface over a block oriented permutation.  This improves performance of computing MACs on data that arrives in order but piecemeal, but weakens the permutation's natural domain separation.  We need strong domain separation in more complex protocols like signatures and NIZKs.  [STROBE](https://strobe.sourceforge.io/) is a strong general purpose symmetric cryptography construction based on Keccak-f(1600), the permutation driving the SHA3 competition winner.  [Merlin](https://doc.dalek.rs/merlin/index.html) is a STROBE scheme for NIZKs, which does almost perfect domain separation.  
 
 In principle, ristretto and merlin together should let schnorrkel play nicely with other future dalek ecosystem crates, like [bulletproofs](https://github.com/dalek-cryptography/bulletproofs).  We've no current plans to exploit this, but this should simplify weak anonymity parachains analogous to Monero or Mimblewimble. 
 
@@ -107,7 +107,7 @@ As an aside, there are now several approaches to doing threshold multi-signature
 
 ### Future 
 
-In future, we want schnorrkel to grow by providing an even more diverse array of cryptographic building blocks, while retaining our existing safety promisses.  We therefore welcome discussions with other implementors around our future directions, like threshold multi-signatures, but also tooling for layer two solutions, like adaptor, blind, and ring signatures.
+In future, we want schnorrkel to grow by providing an even more diverse array of cryptographic building blocks, while retaining our existing safety promises.  We therefore welcome discussions with other implementors around our future directions, like threshold multi-signatures, but also tooling for layer two solutions, like adaptor, blind, and ring signatures.