Introduce encrypted threshold decryption request/response functionality #52
Conversation
Codecov Report
@@ Coverage Diff @@
## main #52 +/- ##
=========================================
+ Coverage 7.01% 15.24% +8.22%
=========================================
Files 16 16
Lines 2523 2841 +318
=========================================
+ Hits 177 433 +256
- Misses 2346 2408 +62
|
…r a single ThresholdDecrpytionRequest to be encrypted multiple times while specifying different response encrypting keys each time.
…ypted counterparts.
derekpierre
changed the title
…t and add appropriate getters for python.
…Ursula to know what key to use to decrypt request.
| self.backend | ||
| .decrypt(sk.as_ref()) | ||
| .map(E2EEThresholdDecryptionRequest::from) | ||
| .map_err(|err| PyValueError::new_err(format!("{}", err))) |
There was a problem hiding this comment.
Unrelated to this PR, but maybe we could turn this often-repeated conversion into a helper function, similarly how we use .map_err(map_js_err) in WASM bindings:
| .map_err(|err| PyValueError::new_err(format!("{}", err))) | |
| .map_err(mapy_py_err) |
nucypher-core/src/dkg.rs
Outdated
| @@ -78,6 +92,121 @@ impl<'a> ProtocolObjectInner<'a> for ThresholdDecryptionRequest { | |||
|
|
|||
| impl<'a> ProtocolObject<'a> for ThresholdDecryptionRequest {} | |||
|
|
|||
| /// A request for an Ursula to derive a decryption share that specifies the key to encrypt Ursula's response. | |||
| #[derive(PartialEq, Debug, Clone, Serialize, Deserialize)] | |||
| pub struct E2EEThresholdDecryptionRequest { | |||
There was a problem hiding this comment.
Just checking, does the third "E" stand for something? E2E is "end to end", right?
There was a problem hiding this comment.
✔️ E2E is what it should be since it isn't encrypted (third E) - I modified my thinking about this functionality but never updated the class name.
There was a problem hiding this comment.
I find this name to be describing something too broad that it reaches the level of inaccuracy. The name "E2E" describes the wider-usage instead of this object instead of it's substance, and falls out of convention with other encrypted entities like EncryptedTreasureMap. Also, the character sequence E2EE is unreadable imo.
| pub struct E2EEThresholdDecryptionRequest { | |
| pub struct EncryptedThresholdDecryptionRequest { |
There was a problem hiding this comment.
After a re-read I think I'm mixed up here. Can you help me understand why EncryptedThesholdDecryptionRequest and E2EEThresholddecryptionRequest need to be different?
There was a problem hiding this comment.
The crux of the design is around the ability to re-use the same ThresholdDecryptionRequest:
-
To be encrypted for different Ursulas - the
request_encrypting_keys -
To be used by different Bobs (see #3128 where Enrico returns a decryption request that can be reused by any Bob) i.e. to be associated with different
response_encrypting_keys
Therefore, we don't want to put the response_encrypring_key on the ThresholdDecryptionRequest object itself because this would be per-Bob.
Next, the response_encrypting_key needs to also be encrypted. So currently, that is done by ThresholdDecryptionRequest.encrypt(request_encrypting_key, response_encrypting_key) and the resulting object is a EncryptedThresholdDecryptionRequest which holds the request and response key both encrypted using the request_encrypting_key. This EncryptedThresholdDecryptionRequest struct only has the encrypted bytes and the ritual id.
When this object gets decrypted using EncryptedThresholdDecryptionRequest.decrypt(secret_key) it needs to return the decryption request (plain form) and the response_encrypting_key. These two items are therefore represented by this E2EThresholdDecryptionRequest. It has two members, decryption_request and response_encrypting_key. It's basically and intermediary object/struct to be consistent since JS does not allow tuples.
I'm open to alternative names.
|
Btw, heads up, |
Use Umbral keys for now for encryption/decryption - similar to the
TreasureMap/EncryptedTreasureMapwork; we'll move away from Umbral when the time comes i.e. we determine the appropriate crypto scheme to use.First foray into Rust ⚙️ 🥳 .
Builds ontop of #48.
Introduces:
EncryptedThresholdDecryptionRequest- encrypted version of theThresholdDecryptionRequestE2EThresholdDecryptionRequest- intermediate struct that stores theThresholdDecryptionRequestand theresponse_encrypting_keyi.e. the key Ursula will use to encrypt theThresholdDecryptionResponse. Using an intermediary allows for a singleThresholdDecryptionRequestobject to be reused for differentresponse_encrypting_keysand encrypted for different Ursulas.EncryptedThresholdDecryptionResponse- encrypted version of theThresholdDecryptionResponseFor reviewers: