dkg-evrf Security Proofs (#681)

* Add audit statement for `dkg-evrf`

This doesn't cover the implementation, solely the academia and background.

Also moves the existing audit of the `crypto` folder for organizational
reasons.

* Add files via upload

audits/crypto/Cypher Stack March 2023/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2023 Cypher Stack
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

audits/crypto/Cypher Stack March 2023/README.md

@@ -0,0 +1,7 @@
+# Cypher Stack /crypto Audit, March 2023
+
+This audit was over the /crypto folder, excluding the ed448 crate, the `Ed448`
+ciphersuite in the ciphersuite crate, and the `dleq/experimental` feature. It is
+encompassing up to commit 669d2dbffc1dafb82a09d9419ea182667115df06.
+
+Please see https://github.com/cypherstack/serai-audit for provenance.

audits/crypto/dkg/evrf/README.md

@@ -0,0 +1,50 @@
+# eVRF DKG
+
+In 2024, the [eVRF paper](https://eprint.iacr.org/2024/397) was published to
+the IACR preprint server. Within it was a one-round unbiased DKG and a
+one-round unbiased threshold DKG. Unfortunately, both simply describe
+communication of the secret shares as 'Alice sends $s_b$ to Bob'. This causes,
+in practice, the need for an additional round of communication to occur where
+all participants confirm they received their secret shares.
+
+Within Serai, it was posited to use the same premises as the DDH eVRF itself to
+achieve a verifiable encryption scheme. This allows the secret shares to be
+posted to any 'bulletin board' (such as a blockchain) and for all observers to
+confirm:
+
+- A participant participated
+- The secret shares sent can be received by the intended recipient so long as
+  they can access the bulletin board
+
+Additionally, Serai desired a robust scheme (albeit with an biased key as the
+output, which is fine for our purposes). Accordingly, our implementation
+instantiates the threshold eVRF DKG from the eVRF paper, with our own proposal
+for verifiable encryption, with the caller allowed to decide the set of
+participants. They may:
+
+- Select everyone, collapsing to the non-threshold unbiased DKG from the eVRF
+  paper
+- Select a pre-determined set, collapsing to the threshold unbaised DKG from
+  the eVRF paper
+- Select a post-determined set (with any solution for the Common Subset
+  problem), allowing achieving a robust threshold biased DKG
+
+Note that the eVRF paper proposes using the eVRF to sample coefficients yet
+this is unnecessary when the resulting key will be biased. Any proof of
+knowledge for the coefficients, as necessary for their extraction within the
+security proofs, would be sufficient.
+
+MAGIC Grants contracted HashCloak to formalize Serai's proposal for a DKG and
+provide proofs for its security. This resulted in
+[this paper](<./Security Proofs.pdf>).
+
+Our implementation itself is then built on top of the audited
+[`generalized-bulletproofs`](https://github.com/kayabaNerve/monero-oxide/tree/generalized-bulletproofs/audits/crypto/generalized-bulletproofs)
+and
+[`generalized-bulletproofs-ec-gadgets`](https://github.com/monero-oxide/monero-oxide/tree/fcmp%2B%2B/audits/fcmps).
+
+Note we do not use the originally premised DDH eVRF yet the one premised on
+elliptic curve divisors, the methodology of which is commented on
+[here](https://github.com/monero-oxide/monero-oxide/tree/fcmp%2B%2B/audits/divisors).
+
+Our implementation itself is unaudited at this time however.