From 56b57841e50412d9a60e9e01ea561aa4fc262362 Mon Sep 17 00:00:00 2001
From: derekpierre <derek.pierre@gmail.com>
Date: Tue, 18 Jul 2023 16:31:58 -0400
Subject: [PATCH] Preliminary prose about the different Ferveo decryption
 variants.

---
 book/src/SUMMARY.md  |  1 +
 book/src/variants.md | 43 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)
 create mode 100644 book/src/variants.md

diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md
index ee5181af..4727acee 100644
--- a/book/src/SUMMARY.md
+++ b/book/src/SUMMARY.md
@@ -8,6 +8,7 @@
   - [Initialization](./dkginit.md)
   - [Publicly Verifiable Secret Sharing](./pvss.md)
 - [Threshold Encryption Scheme](./tpke.md)
+  - [Threshold Decryption Variants](./variants.md)
 
 
 # Appendix
diff --git a/book/src/variants.md b/book/src/variants.md
new file mode 100644
index 00000000..eba38621
--- /dev/null
+++ b/book/src/variants.md
@@ -0,0 +1,43 @@
+# Threshold Decryption (Variants)
+
+Threshold decryption can be performed using one of two optional cryptographic strategies a.k.a *variants*:
+- Simple
+- Precomputed
+
+The chosen variant dictates the decryption shares returned by Validators and how they should be combined. Either variant can be used 
+for decryption, and each has its advantages and disadvantages.
+
+
+## Simple
+
+When decrypting using the *Simple* variant, any arbitrary m-of-n set of Validators (where `m` is the threshold) will each return a simple decryption share, and any
+`m` set of decryption shares can be combined to successfully decrypt the encrypted data. Any combination of the `m` simple decryption shares from the `n` Validators.
+can be used to obtain the decrypted data.
+
+This is the case where you can concurrently contact `n` Validators and simply wait until any `m` responds with decryption shares.
+
+### Advantages
+- Any (arbitrary) `m` shares out of `n` can be requested and obtained
+- Any singular unresponsive Validator does not prevent the ability to combine returned `simple` decryption shares
+- Only one request round is needed if done concurrently i.e. send `n` request, and wait for `m` replies.
+
+### Disadvantages
+- Since the `m` Validators are arbitrary, combining the decryption shares requires the requester to do a more computationally intensive operation when combining returned decryption fragments.
+
+
+## Precomputed
+
+When decrypting using the *Precomputed* variant, you will first choose a specific sub-set of `m` Validators from `n` arbitrary m-of-n set of Validators (where `m` is the threshold),
+and those specific `m` Validators need to reply with precomputed decryption shares. If any of those `m` Validators do not respond, you will need logic to choose another group of `m` Validators (without any Validator
+that didn't respond). Alternatively, you can switch to using `simple` if the first round of `precomputed` fails.
+
+
+### Advantages
+In the happy path:
+- faster operation since the requester only contacts `m` Validators (no need for the other (`n`-`m`)), and `m` Validators respond
+- since the list of `m` Validators is known, the operation to combine the `m` precomputed decryption shares is less computationally intensive than `simple`, which can work well for a lightweight requester.
+
+
+### Disadvantages
+- If the happy case, doesn't happen it ends up being an overall slower operation than `simple`.
+- Availability issue - `precomputed` requires failover logic if any of the specific `m` Validates is unresponsive.