forked from anoma/ferveo
-
Notifications
You must be signed in to change notification settings - Fork 10
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Preliminary prose about the different Ferveo decryption variants.
- Loading branch information
1 parent
da66060
commit 56b5784
Showing
2 changed files
with
44 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |